افزایش سرعت وردپرس؛ چگونه مشکل افزونه، دیتابیس و سرور را تشخیص دهیم؟

برای افزایش سرعت وردپرس، ابتدا مشخص کنید کدام بخش کند است: دریافت پاسخ اولیه، نمایش محتوای اصلی یا واکنش صفحه به کلیک کاربر. این سه مشکل الزاماً یک علت ندارند. نصب افزونهٔ کش یا ارتقای سرور، بدون شناخت علت، ممکن است هزینه ایجاد کند و بخش کند سایت را دست‌نخورده باقی بگذارد.

مسیر عملی این است: چند صفحه و عملیات مهم را اندازه‌گیری کنید، عامل پرهزینه را پیدا کنید، یک تغییر مشخص انجام دهید و نتیجه را دوباره بسنجید. این راهنما کمک می‌کند بین کندی قالب و افزونه، پایگاه داده، مسیر شبکه و کمبود منابع سرور تفاوت بگذارید؛ سپس بهینه‌سازی سایت وردپرس را از جایی شروع کنید که شواهد نشان می‌دهند.

افزایش سرعت وردپرس را از تشخیص بخش کند شروع کنید

«سایت کند است» برای عیب‌یابی کافی نیست. آیا کاربر صفحهٔ محصول را دیر می‌بیند؟ جست‌وجو طول می‌کشد؟ دکمهٔ افزودن به سبد دیر واکنش نشان می‌دهد؟ یا پیشخوان وردپرس کند است، درحالی‌که مرورگر صفحات عمومی را سریع باز می‌کند؟ نشانی صفحه، عملیات، زمان وقوع و وضعیت ورود کاربر را ثبت کنید.

سه تا پنج نمونهٔ مهم انتخاب کنید؛ برای فروشگاه، صفحهٔ اصلی، محصول، دسته‌بندی، جست‌وجو و فرایند خرید گزینه‌های مناسبی هستند. این تعداد پیشنهاد شروع است، نه استاندارد فنی. صفحهٔ اصلی به‌تنهایی نمایندهٔ کل سایت نیست و صفحهٔ پرداخت معمولاً با صفحهٔ مقاله رفتار متفاوتی دارد.

آزمون را برای موبایل و دسکتاپ و، در صورت نیاز، از شبکه‌های کاربران هدف انجام دهید. بازدید مهمان و کاربر واردشده را جدا ثبت کنید. نتیجهٔ صفحه‌ای که از کش آماده پاسخ می‌گیرد را با نتیجهٔ همان صفحه پس از پاک‌شدن کش مخلوط نکنید. پیش از تغییرات، از فایل‌ها و پایگاه داده پشتیبان قابل بازیابی تهیه کنید و تنظیمات فعلی را نگه دارید.

ابزارهای سنجش را به سؤال درست وصل کنید

در PageSpeed Insights نشانی صفحه را وارد کنید و نتایج موبایل و دسکتاپ را جدا ببینید. دو نوع گزارش را از هم تشخیص دهید: آزمون آزمایشگاهی برای بررسی یک بارگذاری کنترل‌شده، و دادهٔ میدانی برای تجربهٔ کاربران واقعی. امتیاز بالای آزمایشگاهی، به‌تنهایی به‌معنی سریع‌بودن همهٔ مسیرهای سایت نیست.

دادهٔ میدانی این ابزار از CrUX می‌آید و بازهٔ ۲۸ روز گذشته را پوشش می‌دهد؛ بنابراین گزارشِ کل این بازه اثر اصلاح امروز را فوراً نشان نمی‌دهد. اگر نمونهٔ کافی برای صفحه وجود نداشته باشد، ابزار ممکن است دادهٔ کل دامنه را نشان دهد یا اصلاً دادهٔ میدانی ارائه نکند. نبود داده، تأیید سرعت نیست. این تفاوت‌ها در توضیح رسمی PageSpeed Insights آمده است.

برای خواندن گزارش، این معیارها را بشناسید:

معیارهای میدانی و بررسی درخواست‌های شبکه

طبق راهنمای Web Vitals گوگل، هدف خوب برای LCP حداکثر ۲٫۵ ثانیه، برای INP حداکثر ۲۰۰ میلی‌ثانیه و برای CLS حداکثر ۰٫۱ است. گوگل برای ارزیابی میدانی، صدک ۷۵ را با تفکیک موبایل و دسکتاپ بررسی می‌کند؛ یعنی حدود سه‌چهارم نمونه‌ها باید در محدودهٔ هدف قرار بگیرند. این اعداد معیار تجربهٔ کاربر هستند، نه تضمین رتبهٔ جست‌وجو یا زمان یکسان برای همهٔ سایت‌ها.

برای بررسی جزئی‌تر، ابزار توسعه‌دهندهٔ مرورگر را باز کنید. در بخش Network، درخواست اصلی صفحه و ستون زمان‌بندی را ببینید؛ سپس فایل‌های حجیم، درخواست‌های طولانی و پاسخ‌های ناموفق را جدا کنید. نمودار آبشاری ترتیب و مدت دریافت منابع را نشان می‌دهد. شرایط کش و محدودسازی شبکه را ثبت کنید تا مقایسهٔ بعدی معتبر باشد. راهنمای Network در Chrome DevTools روش استفاده از این بخش را توضیح می‌دهد.

از نشانهٔ کندی به آزمون بعدی برسید

معیار نامطلوب، محل شروع بررسی است؛ اثبات علت نیست. برای مثال، TTFB بالا می‌تواند از اتصال شبکه، انتظار برای پردازش PHP، پایگاه داده یا سرویس بیرونی ناشی شود. LCP نامطلوب نیز ممکن است با پاسخ اولیهٔ کند شروع شده باشد، حتی اگر تصویر صفحه حجم زیادی نداشته باشد.

فرض کنید در یک فروشگاه، صفحات عمومی از کش سریع پاسخ می‌گیرند، اما جست‌وجوی محصول کند است. این سناریوی فرضی نشان می‌دهد که نتیجهٔ خوب صفحهٔ اصلی نمی‌تواند عملکرد پرس‌وجوی جست‌وجو را تأیید کند. آزمون بعدی باید همان جست‌وجو و افزونهٔ مرتبط را بررسی کند؛ خرید فوری سرور بزرگ‌تر هنوز تصمیم مستندی نیست.

اگر پاسخ اولیه کند است، برنامه و پایگاه داده را بررسی کنید

TTFB زمان خالص اجرای وردپرس نیست. در اندازه‌گیری مرورگر، مراحل اتصال، DNS و TLS نیز می‌توانند در آن سهم داشته باشند. راهنمای TTFB این اجزا را تفکیک می‌کند. اگر فقط یک شبکه یا منطقه مشکل دارد، مسیر دسترسی را هم بررسی کنید؛ اگر سرور همان درخواست را دیر پردازش می‌کند، بررسی برنامه اولویت پیدا می‌کند.

برای مشاهدهٔ پرس‌وجوهای پایگاه داده، خطاهای PHP و درخواست‌های HTTP بیرونی، ابزاری مانند Query Monitor مفید است. آن را با دسترسی مجاز و ترجیحاً در محیط آزمایشی به کار بگیرید. زمان و تکرار پرس‌وجوها را در کنار افزونه یا قالب مسئول بررسی کنید. تعداد زیاد پرس‌وجوها به‌تنهایی به‌معنی کندی بیشتر نیست؛ یک پرس‌وجوی طولانی هم می‌تواند مسئله‌ساز باشد.

آزمون افزونه‌ها برای افزایش سرعت وردپرس

برای آزمون افزونه‌ها، نسخه‌ای جدا از سایت تهیه کنید، همان عملیات کند را بازتولید کنید و هر بار فقط یک افزونهٔ مشکوک را غیرفعال کنید. شرایط کش را ثابت نگه دارید. اگر زمان بهتر شد، افزونه را دوباره فعال و آزمون را تکرار کنید تا تغییر تصادفی را با اثر افزونه اشتباه نگیرید. سپس تنظیمات، تداخل‌ها یا جایگزین سازگار آن را بررسی کنید.

در فروشگاه فعال، افزونهٔ درگاه، موجودی یا عضویت را صرفاً برای تست خاموش نکنید. حالت عیب‌یابی Health Check & Troubleshooting می‌تواند افزونه‌ها و قالب را برای نشستِ کاربرِ درحال بررسی تغییر دهد، بدون تغییر ظاهر معمول سایت برای سایر بازدیدکنندگان؛ بااین‌حال، جای آزمون کامل سفارش و سرویس‌های بیرونی در نسخهٔ جدا را نمی‌گیرد. غیرفعال‌کردن افزونه هم لزوماً کش، کدهای باقی‌مانده یا کارهای بیرونی آن را حذف نمی‌کند.

پرس‌وجوهای کند و داده‌های autoload

اگر پایگاه داده سهم بزرگی از زمان پردازش دارد، ابتدا پرس‌وجوی کند و عامل تولید آن را مشخص کنید. در دسترسی سروری، مدیر پایگاه داده می‌تواند گزارش پرس‌وجوهای کند MySQL را با تنظیم مناسب بررسی کند. جمع‌آوری و نگهداری این گزارش باید کنترل‌شده باشد؛ ممکن است دادهٔ حساس داشته باشد یا حجم زیادی ایجاد کند.

پاک‌سازی پایگاه داده را با حذف بی‌قاعدهٔ جدول‌ها یا گزینه‌ها شروع نکنید. وردپرس تنظیمات autoload را در بسیاری از درخواست‌ها بارگذاری می‌کند؛ دادهٔ غیرضروری در این بخش ارزش بررسی دارد، اما هر گزینهٔ بزرگ قابل حذف نیست. توضیح WordPress Core دربارهٔ autoload نیز نشان می‌دهد که رفتار و مقدارهای آن به نسخه و شیوهٔ ثبت گزینه وابسته‌اند. مالک داده را شناسایی کنید و پاک‌سازی را پس از پشتیبان‌گیری و آزمون انجام دهید.

کش را متناسب با نوع داده تنظیم کنید

برای استفادهٔ درست، سازوکارهای متفاوت کش را بشناسید. در کش صفحه، سامانه می‌تواند خروجی آمادهٔ یک صفحهٔ عمومی را نگه دارد تا برنامه در هر بازدید آن را دوباره تولید نکند. مرورگر با کش محلی، فایل‌های قابل ذخیره را برای بازدیدهای بعدی نگه می‌دارد. نوع دیگری با نام کش شیء یا Object Cache، بعضی داده‌های موردنیاز برنامه را نگه می‌دارد؛ کش پایدارِ شیء به اتصال و پیکربندی مناسب نیاز دارد و صرف نصب یک افزونه، وجود سرویس آماده را ثابت نمی‌کند.

مستندات کش شیء وردپرس تفاوت کش درون یک درخواست با نگهداری پایدار را توضیح می‌دهد. از طرف دیگر، OPcache در PHP کدِ ازپیش‌پردازش‌شدهٔ PHP را نگه می‌دارد؛ نه صفحهٔ کامل را و نه سفارش مشتری را. این لایه‌ها جای یکدیگر را نمی‌گیرند.

برای صفحه‌های عمومی، ابتدا بررسی کنید آیا کش واقعاً پاسخ می‌دهد و سامانه پس از ویرایش محتوا، نسخهٔ قدیمی را به‌درستی پاک می‌کند. پاسخ سریع همراه با قیمت یا محتوای قدیمی نتیجهٔ قابل قبول نیست. چند افزونه با قابلیت‌های تکراری نصب نکنید؛ مسئولیت کش و پاک‌سازی در افزونه، وب‌سرور و CDN باید روشن باشد.

در فروشگاه، سبد خرید، تسویه‌حساب، حساب کاربری و پاسخ‌های شخصی را از کش عمومی صفحه خارج کنید. راهنمای کش ووکامرس بر همین استثناها تأکید دارد. تنظیم باید با کوکی‌ها، نشست‌ها و نشانی‌های واقعی سایت هماهنگ باشد. پس از تغییر، با دو کاربر مستقل بررسی کنید که سایت سبد خرید یا اطلاعات یک نفر را به دیگری نشان ندهد؛ قیمت، موجودی و نتیجهٔ پرداخت هم درست بمانند.

CDN می‌تواند تحویل محتوای قابل کش را تغییر دهد، اما کد ناکارآمد یا همهٔ درخواست‌های شخصی را اصلاح نمی‌کند. نتیجه را از شبکه‌های کاربران هدف بسنجید و مسیر دسترسی مستقیم و مسیر CDN را با شرایط قابل مقایسه بررسی کنید. صرف فعال‌بودن نام یک سرویس، مدرک استفادهٔ مؤثر از کش نیست.

برای نمایش سریع‌تر محتوا، تصویر و قالب را سبک کنید

در گزارش، عنصر LCP را پیدا کنید؛ ممکن است تصویر اصلی یا یک بلوک متن باشد. اگر تصویر است، ابعاد فایل را با اندازهٔ نمایش هماهنگ کنید، کیفیت بصری را حفظ کنید و حجم نسخهٔ ارسالی به موبایل را بررسی کنید. انتخاب WebP یا AVIF می‌تواند مناسب باشد، اما فرمت به‌تنهایی جای بررسی حجم، کیفیت و پشتیبانی ابزارهای سایت را نمی‌گیرد.

تصویر اصلیِ LCP را به بارگذاری تنبل موکول نکنید. این کار می‌تواند شروع دریافت آن را عقب بیندازد. بارگذاری تنبل برای تصاویر پایین صفحه کاربرد دارد؛ محل واقعی عنصر مهم را بررسی کنید. راهنمای بهینه‌سازی LCP گوگل همچنین نشان می‌دهد که کاهش حجم تصویر، اگر نمایش آن همچنان پشت اجرای کد یا سبک‌ها منتظر بماند، لزوماً کل مشکل را حل نمی‌کند.

برای کاهش جابه‌جایی محتوا، جای تصاویر و بنرها را از پیش مشخص کنید. تعداد خانواده‌ها و وزن‌های فونت را محدود و دریافت ناموفق یا دیرهنگام فونت را بررسی کنید. اسلایدر، ویدئوی خودکار و ابزارهای بیرونی را فقط وقتی نگه دارید که کاربردشان ارزش هزینهٔ بارگذاری را دارد.

تنظیم‌هایی مانند تأخیر اجرای JavaScript یا حذف CSS استفاده‌نشده را جداگانه آزمایش کنید. بعد از هر تغییر، منو، فرم، نمایش موبایل و فرایند خرید را کنترل کنید. ترکیب‌کردن همهٔ فایل‌ها یا فعال‌کردن همهٔ گزینه‌های یک افزونه، نسخهٔ عمومیِ مناسب برای هر سایت نیست.

اگر کلیک‌ها کندند، کار مرورگر را پیدا کنید

برای کندی منو، فیلتر محصول یا تایپ، همان تعامل را در بخش Performance مرورگر ثبت کنید. پردازش طولانی JavaScript و محاسبهٔ دوبارهٔ چیدمان می‌توانند واکنش دیداری را عقب بیندازند. راهنمای بهینه‌سازی INP پیشنهاد می‌کند ابتدا تعامل کند را بازتولید و سپس کارهای مسئول تأخیر را بررسی کنید.

فایل یا افزونهٔ مسئول را مشخص کنید و کد غیرضروریِ آن صفحه را کاهش دهید. برای نمونه، بارگذاری ابزار یک صفحهٔ خاص در همهٔ صفحات، نیاز به بررسی دارد. حذف یا تأخیر کد را با شناخت وابستگی‌ها انجام دهید؛ شکستن دکمهٔ خرید برای بهترشدن امتیاز، بهینه‌سازی موفقی نیست.

اگر کلیک فوری بازخورد می‌دهد، اما نتیجهٔ جست‌وجو یا ثبت سفارش دیر می‌رسد، درخواست شبکهٔ همان عملیات را هم بررسی کنید. INP زمان کامل عملیات سمت سرور را به‌تنهایی گزارش نمی‌کند. افزایش CPU سرور نیز کار سنگین JavaScript روی گوشی کاربر را مستقیماً برطرف نمی‌کند.

چه زمانی ارتقای منابع یا تغییر میزبانی منطقی است؟

زمان کندی را با CPU، حافظهٔ در دسترس، استفاده از swap، تأخیر دیسک، صف درخواست‌های PHP و محدودیت‌های سرویس تطبیق دهید. در هاست اشتراکی، گزارش محدودیت‌ها را از پنل یا پشتیبانی بگیرید؛ در VPS، مانیتورینگ سیستم و برنامه را کنار هم بخوانید. میانگین روزانه ممکن است فشار کوتاهِ ساعت اوج را پنهان کند.

CPU بالای پایدار هم‌زمان با تأخیر درخواست‌ها، کمبود حافظه همراه با فشار swap، یا محدودیت ثبت‌شدهٔ پردازش می‌تواند بررسی ظرفیت را توجیه کند. اما مصرف بالا ممکن است نتیجهٔ پرس‌وجوی ناکارآمد، خزندهٔ پرمصرف یا کار پس‌زمینه هم باشد. ابتدا سهم این عوامل را مشخص کنید؛ تنها دیدن یک درصد مصرف، نسخهٔ خرید نمی‌دهد.

وقتی پس از اصلاح مشکلات مشخص، ظرفیت در بار واقعی همچنان کافی نیست، ارتقای منابع یا تغییر سرویس را با آزمون قابل مقایسه بررسی کنید. در صورت نیاز به کنترل سیستم‌عامل و تنظیمات نرم‌افزار، VPS گزینه‌ای برای بررسی است؛ مدیریت، به‌روزرسانی و پشتیبان‌گیری آن هم باید مسئول مشخص داشته باشد. مقایسهٔ هاست اشتراکی، VPS و سرور اختصاصی به تصمیم دربارهٔ مدل میزبانی کمک می‌کند.

نتیجه را با سرعت و صحت عملکرد بسنجید

پس از هر تغییر، همان صفحه و همان عملیات را با شرایط ثبت‌شده چند بار آزمایش کنید. خروجی‌ها را نگه دارید و به یک اجرای بهتر تکیه نکنید. وضعیت کش، زمان آزمون، دستگاه و شبکه باید مشخص باشد. برای بررسی بار هم‌زمان نیز از محیط مجاز و برنامهٔ کنترل‌شده استفاده کنید؛ تعداد بازدید ماهانه جای تعداد درخواست هم‌زمان را نمی‌گیرد.

معیار پایان کار، کاهش تأخیر در مسیر مهم کاربر همراه با عملکرد درست است. کاربر باید بتواند فرم را بفرستد و سفارش را ثبت کند. سایت باید محتوای تازه را نشان دهد و اطلاعات شخصی را وارد کش عمومی نکند. پس از انتشار تغییر نیز روند خطاها و دادهٔ میدانی را دنبال کنید تا بهبود آزمایشی را با تجربهٔ واقعی تطبیق دهید.

برای هر اقدام، یک یادداشت کوتاه نگه دارید: مشکل، مدرک، تغییر، نتیجه و روش برگشتِ تنظیم. این کار کمک می‌کند بهینه‌سازی بعدی را از حدس شروع نکنید و با به‌روزرسانی قالب یا افزونه، علت افت عملکرد را سریع‌تر پیدا کنید.

اگر بررسی‌ها کمبود ظرفیت یا نیاز به کنترل بیشتر محیط اجرا را نشان می‌دهند، سرور مجازی ابر آراد را متناسب با بار کاری بررسی کنید. برای پیگیری مسئلهٔ زیرساختی، زمان کندی، نشانی مسیر متأثر و گزارش مصرف منابع را از مسیر پشتیبانی ابر آراد مطرح کنید. پیش از خرید، منابع، مسئولیت مدیریت و محدودهٔ خدمات را روشن کنید؛ انتخاب سرور باید به شواهد عیب‌یابی متصل باشد.