اگر صفحه اصلی در یک ثانیه باز می‌شود اما ذخیره محصول یا ورود به پیشخوان ده ثانیه طول می‌کشد، بهینه‌سازی تصویر صفحه اصلی احتمالاً مسئله شما نیست. کاربران واردشده معمولاً page cache را دور می‌زنند و wp-admin باید PHP، دیتابیس، AJAX، cron و گاهی APIهای خارجی را در هر درخواست اجرا کند.
پاسخ سریع: مشخص کنید کدام صفحه یا عملیات مدیریت کند است، درخواست‌های document و admin-ajax.php یا REST را در Network ثبت کنید و timestamp را با PHP/MySQL log تطبیق دهید. افزونه‌های مدیریتی، Heartbeat، jobهای صف و workerهای PHP از علت‌های محتمل‌اند؛ خاموش کردن تصادفی آن‌ها راه‌حل امن نیست.
الگوی کندی سرنخ اصلی است
- ورود کند است یا همه منوها؟
- فقط فهرست سفارش/محصول یا ویرایش یک رکورد؟
- ذخیره کند است یا بارگذاری اولیه؟
- فقط یک نقش کاربری یا همه مدیران؟
- در ساعت مشخص، هنگام backup یا اجرای صف؟
- مرورگر منتظر server است یا JavaScript صفحه قفل می‌شود؟
هر بار تست، URL، عملیات، مدت، کاربر و زمان را ثبت کنید. مقایسه صفحه Dashboard با ویرایش محصول بدون توجه به workload نتیجه دقیقی نمی‌دهد.
چرا سایت عمومی سریع ولی مدیریت کند است؟
صفحات عمومی ممکن است از CDN یا page cache تحویل شوند، اما مدیریت شخصی و dynamic است. همچنین widgetهای داشبورد، شمارنده‌ها، noticeها، بررسی license، REST و درخواست‌های background در مدیریت فعال‌اند. برای تحلیل کلی frontend و backend، راهنمای کندی سایت وردپرس را نیز ببینید.
در DevTools چه چیزی را بررسی کنیم؟
در Network گزینه Preserve log را فعال و عملیات کند را تکرار کنید. درخواست‌هایی با زمان Waiting بالا به backend نزدیک‌ترند؛ درخواست pending به endpoint خارجی یا AJAX می‌تواند کل رابط را معطل کند. Response، status و initiator را ببینید. credential، nonce و اطلاعات سفارش را قبل از اشتراک HAR پاک کنید.
اگر document سریع است ولی کلیک‌ها دیر پاسخ می‌دهند، Long Taskهای JavaScript، خطاهای Console و تعداد assetهای مدیریتی را بررسی کنید. افزونه‌ای که CSS/JS خود را در تمام صفحات wp-admin بارگذاری می‌کند می‌تواند رابط را سنگین کند، حتی اگر PHP سریع باشد.
افزونه‌ها و درخواست‌های خارجی
افزونه امنیتی، آمار، backup، SEO، فروشگاه و license checker ممکن است در hookهای مدیریت query یا HTTP request اجرا کنند. timeout یک API خارجی می‌تواند هر بار بارگذاری را چند ثانیه عقب بیندازد. در لاگ یا profiler نام host و مدت را پیدا کنید؛ غیرفعال کردن کنترل TLS یا allow کردن عمومی مقصد راه‌حل مناسبی نیست.
آزمون افزونه باید روی staging یا پنجره نگهداری انجام شود. افزونه‌ها را گروهی isolate و سپس عامل را تکی بررسی کنید. فقط تعداد افزونه معیار نیست؛ رفتار یک افزونه در همان صفحه اهمیت دارد.
admin-ajax، Heartbeat و REST
Heartbeat برای قفل نوشته و هماهنگی نشست‌ها کاربرد دارد. فراوانی غیرعادی درخواست یا callback سنگین متصل به آن می‌تواند بار ایجاد کند، اما خاموش کردن کامل ممکن است قابلیت‌های مدیریت را بشکند. ابتدا initiator، payload، interval و callback را پیدا کنید و سپس همان عامل را اصلاح کنید.
برای REST، status و body را بررسی کنید. پاسخ 401/403 با 500 مسیر یکسان ندارد. اگر ویرایشگر بلوکی ذخیره نمی‌کند یا درخواست JSON کند است، راهنمای REST API وردپرس کمک می‌کند.
دیتابیس و صفحات فهرست
فهرست محصولات، سفارش‌ها و رسانه ممکن است queryهای شمارشی، meta و فیلتر زیادی اجرا کند. تعداد آیتم نمایشی، ستون افزوده‌شده توسط افزونه‌ها و جستجوی بدون index را بررسی کنید. Query Monitor در staging می‌تواند caller و زمان query را نشان دهد؛ slow query log برای اثر سطح دیتابیس مفید است.
حذف مستقیم postmeta یا option برای سریع کردن پنل خطر از دست رفتن داده دارد. ابتدا query کند و مالک داده را مشخص، backup قابل restore تهیه و روش پاک‌سازی رسمی افزونه را پیدا کنید.
wp-cron و صف‌های پس‌زمینه
گاهی درخواست مدیر cron عقب‌افتاده را تحریک می‌کند یا صفحه وضعیت، شمارش بزرگی از jobها انجام می‌دهد. نام hook، مدت و صف را ثبت کنید. اجرای دستی همه jobها می‌تواند ایمیل، sync یا پردازش سفارش را تکرار کند. job بزرگ را به batchهای کنترل‌شده تقسیم کنید و cron واقعی را فقط پس از شناخت workload جایگزین کنید.
PHP-FPM و ظرفیت هم‌زمانی
اگر همه درخواست‌های dynamic کندند ولی cache عمومی سریع است، workerهای PHP ممکن است اشباع باشند. queue، active/idle worker، duration درخواست و memory را هم‌زمان ببینید. افزایش تعداد worker بدون RAM کافی خطر swap و OOM دارد؛ افزایش timeout نیز bottleneck را رفع نمی‌کند.
uptime
top
free -hاین snapshotها را هنگام کندی بگیرید. اگر CPU وردپرس بالا است، فرایند تشخیص CPU بالا را دنبال کنید.
روال تشخیص پیشنهادی
- یک عملیات کند قابل تکرار انتخاب و زمان آن را ثبت کنید.
- Network و Console مرورگر را بررسی کنید.
- لاگ PHP و وردپرس را با همان timestamp تطبیق دهید.
- query، HTTP call و hookهای صفحه را در staging profile کنید.
- CPU، RAM، disk latency و صف PHP را هنگام درخواست ببینید.
- عامل مظنون را جدا تغییر دهید و دوباره همان عملیات را بسنجید.
راه‌حل‌های کم‌ریسک
widget و ستون غیرضروری را در سطح کاربر مخفی کنید، افزونه‌های بلااستفاده را پس از بررسی حذف کنید، noticeهای ناشی از خطای واقعی را رفع کنید و jobهای سنگین را از request تعاملی جدا سازید. تعداد رکورد هر صفحه را معقول کنید، اما از پنهان‌کردن داده به‌جای اصلاح query پرهیز کنید.
اشتباه‌های رایج
- انتظار اثر page cache روی wp-admin
- خاموش کردن Heartbeat بدون شناخت callbackها
- حذف داده‌های options یا meta با SQL ناشناخته
- افزایش worker و RAM limit بدون محاسبه ظرفیت
- فعال گذاشتن profiler سنگین روی production
- نادیده گرفتن تفاوت نقش کاربر و صفحه خاص
چه زمانی کمک تخصصی لازم است؟
اگر پنل فقط زیر بار، هنگام sync یا در صفحات ووکامرس کند می‌شود، اندازه‌گیری باید از مرورگر تا PHP و MySQL ادامه یابد. سرویس افزایش سرعت وردپرس می‌تواند bottleneck مدیریت را بدون اتکا به cache صفحه عمومی مشخص کند.
پرسش‌های متداول
آیا CDN پیشخوان را سریع می‌کند؟
معمولاً HTML مدیریت cache نمی‌شود؛ CDN شاید asset و شبکه را بهبود دهد، اما PHP یا query کند را حل نمی‌کند.
آیا پاک کردن revisionها پنل را سریع می‌کند؟
فقط اگر اثر آن اندازه‌گیری و query مرتبط باشد. حذف کورکورانه داده راه عمومی نیست و backup لازم دارد.
چرا فقط ذخیره محصول کند است؟
hookهای ذخیره، sync موجودی، تولید meta، webhook یا API خارجی ممکن است فقط هنگام write اجرا شوند.