رفع کندی وردپرس با Query Monitor با شناسایی عامل تأخیر شروع می‌شود. تعداد زیاد افزونه به‌تنهایی علت را مشخص نمی‌کند؛ یک درخواست خارجی کند یا کوئری نامناسب ممکن است سهم بیشتری داشته باشد. این ابزار اطلاعات تشخیصی می‌دهد و خودش جای اصلاح مشکل را نمی‌گیرد.
آماده‌سازی برای رفع کندی وردپرس با Query Monitor
صفحه و سناریوی کند را مشخص کنید: پیشخوان، مقالهٔ عمومی، جستجو یا عملیات فروشگاه. روی محیط تستِ مشابه، Query Monitor را از مخزن رسمی نصب و فعال کنید. با حساب مجاز همان سناریو را باز کنید و از منوی نوار مدیریت، گزارش درخواست فعلی را ببینید.
نتیجهٔ مدیر واردشده با بازدیدکنندهٔ ناشناس الزاماً یکسان نیست. کش صفحه، نقش کاربر و دادهٔ آزمایش را ثبت کنید. پنل عیب‌یابی ممکن است اطلاعات مسیرها یا درخواست‌ها را نشان دهد؛ خروجی حاوی کلید، نشانی خصوصی یا دادهٔ کاربر را عمومی منتشر نکنید.
کوئری‌های دیتابیس را درست بخوانید
در بخش Queries و زیرگزارش Queries by Component، تعداد و زمان کوئری‌های منتسب به هسته، قالب و افزونه‌ها را مقایسه کنید. مستند Query Monitor توضیح می‌دهد که این جمع‌بندی بر فعالیت دیتابیس متمرکز است؛ عدد آن، کل زمان اجرای افزونه نیست.
کوئری کند یا تکراری را باز کنید و فراخوان و زمینهٔ اجرای آن را بخوانید. تعداد زیاد کوئری همیشه از یک کوئری بسیار کند بدتر نیست. برای اصلاح، محل تکرار، نیاز واقعی داده و امکان کش مناسب را بررسی کنید؛ حذف جدول یا اجرای دستور عمومی تعمیر، پاسخ مستقیم این گزارش نیست.
درخواست خارجی، خطای PHP و فایل‌های صفحه
بخش HTTP API Calls به درخواست‌های سمت سرور وردپرس مربوط است؛ برای مثال تماس افزونه با یک سرویس بیرونی. وضعیت پاسخ، مدت و مؤلفهٔ آغازکننده را ببینید. این فهرست معادل همهٔ عکس‌ها، CSS و JavaScript دریافت‌شده در مرورگر نیست.
برای فایل‌های مرورگر از Network ابزار توسعه‌دهنده استفاده کنید. بخش Scripts و Styles در Query Monitor نیز وابستگی‌ها و ثبت فایل‌ها را نشان می‌دهد. در گزارش PHP، خطا و مؤلفهٔ مربوط را پیگیری کنید؛ هر هشدار به‌تنهایی اثبات علت اصلی کندی نیست.
Debug Bar و تنظیم موقت عیب‌یابی
Debug Bar ابزار جایگزین دیگری برای نمایش اطلاعات کوئری و کش است. برای بررسی کوئری با این ابزار، می‌توان در محیط تست مقادیر زیر را در wp-config.php، پیش از خط پایان و بارگذاری وردپرس تنظیم کرد. اگر ثابت‌ها از قبل وجود دارند، همان تعریف را ویرایش کنید و تعریف تکراری نسازید:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SAVEQUERIES', true );حروف ثابت‌ها و مقدار false باید دقیق باشند؛ wp_DEBUG یا FULSE جایگزین معتبر نیستند. نمایش عمومی خطا را فعال نکنید. این نمونه برای آزمایش محدود است و تنظیمات خطای خود PHP نیز باید با محیط هماهنگ باشد.
طبق مستند دیباگ وردپرس، SAVEQUERIES ثبت کوئری، زمان و فراخوان را فعال می‌کند و سربار دارد؛ پس از عیب‌یابی آن را خاموش کنید. SCRIPT_DEBUG نسخهٔ توسعهٔ فایل‌های هسته را بارگذاری می‌کند و ابزار عمومی نمایش همهٔ خطاهای JavaScript نیست.
اصلاح و مقایسهٔ نتیجه
یک عامل مشخص را در محیط تست تغییر دهید و همان درخواست را دوباره بسنجید. اگر سرویس خارجی کند است، علت اتصال و تنظیم timeout را بررسی کنید؛ اگر کوئری مشکل دارد، اصلاح همان مؤلفه لازم است. پس از پایان، ابزار تشخیصی غیرضروری را کنار بگذارید و زمان بارگذاری واقعی را بدون سربار آن مقایسه کنید.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
