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

برای سناخت کامل عملکرد سایت با Monitor Query و اجرای گام‌به‌گام آن، تا انتهای این مطلب با ما همراه باشید.

افزونه Query Monitor چیست و چه چیزی را نشان می‌دهد؟

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

یک نکته را از همین ابتدا روشن کنیم: Query Monitor افزونۀ کش نیست و چیزی را به‌صورت خودکار بهینه نمی‌کند و نصب آن به‌تنهایی سرعت سایت را بیشتر نمی‌کند. کاربرد اصلی‌اش این است که منشأ کندی را واضح‌تر نشان دهد؛ مثلاً مشخص کند یک افزونه کوئری سنگین اجرا می‌کند، قالب درخواست‌های غیرضروری می‌فرستد یا یک تابع خاص زمان زیادی می‌گیرد. به همین دلیل، بررسی سایت با این ابزار می‌تواند پیش از حذف افزونه‌ها، تغییر قالب یا ارتقای سرور، مسیر عیب‌یابی را دقیق‌تر کند.

در نسخه‌های جدید Query Monitor پنلی به نام Timeline هم وجود دارد. این پنل رویدادهای مهم هر درخواست را روی یک خط زمانی نمایش می‌دهد و مشخص می‌کند کدام بخش دیرتر تمام شده است. اگر هنوز نمی‌دانید بررسی‌ سایت‌تان را از کجا شروع کنید، Timeline معمولاً نقطۀ شروع مناسبی است.

قبل از شروع عیب‌یابی سرعت سایت وردپرس، چه کارهایی انجام دهیم؟

پیش از انجام هر تغییری، وضعیت فعلی سایت‌تان را ثبت کنید. صفحه‌ای را انتخاب کنید که کندی در آن محسوس و قابل تکرار است؛ مثلاً صفحۀ محصول ووکامرس، یک آرشیو سنگین، صفحۀ اصلی یا بخشی از پیشخوان. زمان بارگذاری و شاخص‌های اصلی را با ابزاری مثل PageSpeed Insights یادداشت کنید تا بعداً بتوانید اثر واقعی تغییرات را با وضعیت اولیه مقایسه کنید.

افزونه Query Monitor بیشتر اتفاق‌هایی را نشان می‌دهد که داخل وردپرس و در سمت سرور رخ می‌دهند. در مقابل، PageSpeed Insights و ابزارهای مرورگر برای بررسی رندر صفحه، JavaScript، تصاویر و Core Web Vitals مناسب‌ترند. البته این ابزارها جای یکدیگر را نمی‌گیرند و هرکدام بخش متفاوتی از مشکل را روشن می‌کنند. برای ارزیابی دقیق سرعت سایت، بهتر است داده‌های سمت سرور و تجربۀ کاربر را کنار هم ببینید.

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

نصب افزونه Query Monitor در وردپرس

برای نصب افزونه Query Monitor، از پیشخوان وردپرس به بخش: «افزونه‌ها > افزودن افزونه تازه» بروید، Query Monitor را جست‌وجو کنید و پس از نصب، آن را فعال کنید. در زمان آخرین بررسی این مقاله، نسخه 4.0.7 منتشر شده است و صفحۀ رسمی WordPress.org نیز برای نسخۀ فعلی حداقل WordPress 6.2 و PHP 7.4 را پیشنهاد می‌کند. اگر سایت شما قدیمی است، پیش از نصب، نسخۀ وردپرس و PHP را هم بررسی کنید.

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

در نصب معمولی وردپرس، اطلاعات افزونه به‌صورت پیش‌فرض برای Administrator قابل مشاهده است. در وردپرس Multisite نیز Super Admin به این داده‌ها دسترسی دارد.

درنظر داشته باشید که خود Query Monitor برای جمع‌آوری این اطلاعات مقداری سربار ایجاد می‌کند. با وجد اینکه توسعه‌دهندۀ افزونه این اثر را معمولاً کم توصیف می‌کند، اما در صفحاتی با صدها کوئری، مصرف حافظه می‌تواند بیشتر شود. به همین دلیل، روی سایت‌های پرترافیک بهتر است بعد از پایان عیب‌یابی دوباره بررسی کنید که فعال ماندن دائمی افزونه ضروری است یا نه.

7 گام افزایش سرعت وردپرس با افزونه Query Monitor

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

گام اول: پیدا کردن نقطۀ کند در Timeline

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

اگر چند رویداد پشت سر هم زمان زیادی گرفته‌اند، احتمالاً بخشی از تأخیر در همان زنجیره ایجاد شده است. روی رویداد مشکوک کلیک کنید تا پنل مرتبط باز شود و جزئیات بیشتری ببینید.

Timeline قرار نیست به‌تنهایی علت نهایی را مشخص کند و بیشتر برای پیدا کردن نقطۀ شروع است. بعد از شناسایی رویداد مشکوک، باید وارد پنل تخصصی همان بخش شوید و علت را دقیق‌تر بررسی کنید. این روش باعث می‌شود وقتتان را صرف بررسی همه بخش‌ها نکنید.

گام دوم: بررسی کوئری‌های کند و تکراری پایگاه داده

پایگاه داده یکی از بخش‌هایی است که می‌تواند خیلی زود روی سرعت سایت اثر بگذارد؛ مخصوصاً وقتی یک افزونه یا قالب تعداد زیادی کوئری تکراری یا سنگین اجرا کند. پنل Queries در افزونه Query Monitor هر کوئری SQL را همراه با زمان اجرا، محل فراخوانی (caller) و مؤلفۀ مسئول (component) نشان می‌دهد. به‌جای یک تشخیص کلی مثل «دیتابیس کند است»، می‌توانید ببینید مشکل از هستۀ وردپرس، قالب یا کدام افزونه آمده است. در این بخش، این 4 مورد معمولاً بیشترین سرنخ را به شما می‌دهند:

1. Queries by Component: تعداد کوئری‌ها و مجموع زمان اجرای آن‌ها را برای هر افزونه، قالب یا هستۀ وردپرس کنار هم نشان می‌دهد. اگر سهم یک افزونه از زمان دیتابیس غیرعادی است، بررسی را از همان مؤلفه شروع کنید.
2. Slow Queries: کوئری‌هایی را نشان می‌دهد که اجرای آن‌ها از آستانۀ زمانی مشخصی عبور کرده است. برای پیدا کردن نقاط واقعاً کند، این فهرست معمولاً از نگاه کردن صرف به تعداد کل کوئری‌ها مفیدتر است.
3. Duplicate Queries: کوئری‌های یکسانی را که چند بار در یک بارگذاری اجرا شده‌اند مشخص می‌کند. تکرار زیاد می‌تواند نشانۀ اجرای کوئری داخل حلقه یا نبود کش مناسب در کد باشد.
4. Query Errors: خطاهای پایگاه داده را همراه با متن خطا و محل فراخوانی نمایش می‌دهد. این بخش برای پیدا کردن خطاهایی که در ظاهر صفحه دیده نمی‌شوند هم مفید است.

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

پس فقط به یک عدد نگاه نکنید و تعداد کوئری، زمان اجرا، میزان تکرار، نوع صفحه و مؤلفۀ مسئول را کنار هم بسنجید. بعد از هر تغییر هم همان صفحه را در شرایط مشابه دوباره آزمایش کنید، در غیر این صورت مقایسۀ نتیجه، چندان قابل اتکا نیست.

گام سوم: پیدا کردن افزونه یا قالب سنگین

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

Query Monitor بسیاری از داده‌ها را بر اساس افزونه، قالب یا هستۀ وردپرس دسته‌بندی می‌کند. اگر در Queries by Component یک مؤلفه زمان بالایی دارد یا Timeline چند رویداد طولانی را به همان افزونه نسبت می‌دهد، بررسی را از همان‌جا شروع کنید. این بخش یکی از جاهایی است که افزونه Query Monitor عیب‌یابی را از آزمون‌وخطا به یک بررسی هدفمند تبدیل می‌کند.

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

اگر مشکل از یک خطای جدی PHP آمده و سایت به صفحۀ سفید می‌رسد، راهنمای «رفع خطای صفحه سفید وردپرس» می‌تواند در کنار Query Monitor برای پیدا کردن علت اصلی کمک‌کننده باشد.

گام چهارم: بررسی خطاهای PHP

هشدارها، Noticeها، پیام‌های Deprecated و خطاهای PHP فقط پیام‌های فنی روی صفحه نیستند. بسته به تنظیمات سرور، ممکن است در هر بارگذاری داخل فایل لاگ نوشته شوند. اگر این اتفاق مرتب تکرار شود، هم عیب‌یابی را شلوغ می‌کند و هم می‌تواند سربار اضافی ایجاد کند.

وقتی خطای PHP رخ دهد، Query Monitor پنل مربوط به آن را نمایش می‌دهد. برای هر خطا می‌توانید پیام، سطح خطا، محل فراخوانی، مؤلفۀ مسئول و تعداد دفعات تکرار را ببینید؛ اطلاعاتی که معمولاً برای رسیدن به منشأ مشکل کافی‌اند. از طرفی خطاهایی را جدی‌تر بگیرید که در هر بارگذاری چند بار تکرار می‌شوند. ابتدا مشخص کنید از کدام افزونه یا قالب آمده‌اند، سپس نسخه نرم‌افزار، سازگاری آن با PHP و وردپرس و تغییرات نسخه‌های جدیدتر را بررسی کنید. این خطاها در بعضی سایت‌ها می‌توانند یکی از دلایل پنهان کندی باشند.

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

گام پنجم: شناسایی درخواست‌های HTTP کند

همۀ زمان پردازش داخل خود وردپرس مصرف نمی‌شود. بعضی افزونه‌ها برای اعتبارسنجی لایسنس، ارتباط با درگاه، سرویس پیامک، دریافت اطلاعات از API یا ابزارهای تحلیلی به سرویس‌های بیرونی درخواست می‌فرستند. اگر مقصد دیر پاسخ دهد یا درخواست به timeout برسد، کاربر هم تا پایان این فرایند منتظر می‌ماند.

در پنل HTTP API می‌توانید زمان پاسخ، کد وضعیت و مؤلفه‌ای را که درخواست را ساخته ببینید. اگر یک درخواست خارجی در هر بارگذاری اجرا می‌شود و زمان زیادی می‌گیرد، بسته به کاربرد آن می‌توان کش کردن نتیجه، کم کردن دفعات فراخوانی، انتقال پردازش به زمان مناسب‌تر یا تنظیم timeout را بررسی کرد.

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

گام ششم: بررسی JavaScript و CSS با Scripts و Styles

گاهی منشأ کندی سرعت سایت نه PHP است و نه دیتابیس. ممکن است یک افزونه فایل‌های JavaScript و CSS خود را در همه صفحات بارگذاری کند، حتی جایی که آن قابلیت استفاده نمی‌شود. در نتیجه، حجم بیشتر صفحه و کار اضافه روی مرورگر ایجاد می‌شود.

پنل‌های Scripts و Styles در افزونه Query Monitor فایل‌هایی را نشان می‌دهند که از مسیر enqueue وردپرس وارد صفحه شده‌اند. dependencyها و مؤلفۀ ثبت‌کننده هر فایل هم قابل مشاهده‌اند؛ بنابراین راحت‌تر می‌توان فهمید هر اسکریپت یا استایل از کجا آمده است. در سایت‌های بزرگ، بررسی کنید که آیا فایل‌های یک افزونه واقعاً باید در همه صفحات لود شوند یا فقط در چند صفحۀ مشخص لازم‌اند. اگر توسعۀ اختصاصی دارید، صف‌گذاری شرطی فایل‌ها می‌تواند بخشی از بار غیرضروری را کم کند.

البته Query Monitor ابزار کامل تحلیل فرانت‌اند نیست. برای بررسی حجم فایل‌ها، زمان دانلود، رندر و Core Web Vitals همچنان به DevTools مرورگر، Lighthouse یا PageSpeed Insights نیاز دارید.

گام هفتم: بررسی Object Cache و محیط سرور

وردپرس برای جلوگیری از تکرار بعضی محاسبات از Object Cache استفاده می‌کند. در سایت‌های پویا که حجم کوئری و پردازش بالاست، Persistent Object Cache با ابزارهایی مثل Redis یا Memcached می‌تواند مفید باشد؛ البته به شرطی که زیرساخت و پیکربندی سایت از آن پشتیبانی کند و واقعاً به آن نیاز داشته باشید.

Query Monitor اطلاعات محیط وردپرس، PHP، دیتابیس و وب‌سرور را هم نمایش می‌دهد. اگر نشانه‌ها به محدودیت حافظه، نسخه PHP، وضعیت کش یا منابع سرور اشاره کنند، این اطلاعات برای ادامۀ عیب‌یابی مفید خواهند بود.

ارتقای زیرساخت نیز نباید اولین واکنش به کندی سایت باشد. اگر مشکل از یک کوئری ناکارآمد یا API خارجی کند باشد، سرور قوی‌تر الزاماً ریشۀ مسئله را برطرف نمی‌کند. اطلاعاتی که افزونه Query Monitor نشان می‌دهد کمک می‌کند بفهمید واقعاً با محدودیت منابع روبه‌رو هستید یا باید جای دیگری را اصلاح کنید.

بعد از پیدا کردن علت، چطور سرعت سایت را بهتر کنیم؟

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

نشانه در Query Monitor	علت محتمل	اقدام پیشنهادی
Slow Queries یا زمان بالای یک مؤلفه	کوئری ناکارآمد، افزونۀ سنگین یا ساختار نامناسب دیتابیس	کد و تنظیمات را بررسی کنید. در صورت نیاز، افزونه را به‌روزرسانی کنید و سراغ اصلاح کوئری یا ایندکس‌ها بروید.
Duplicate Queries	اجرای چندبارۀ یک کوئری یکسان	حلقه‌ها و منطق اجرا را بررسی کنید و اگر امکانش هست، نتیجه را کش کنید.
HTTP API با زمان پاسخ بالا	API خارجی کند یا فراخوانی بیش از حد	دفعات درخواست را کمتر کنید، پاسخ را موقتاً کش کنید یا پردازش را به زمان مناسب‌تری منتقل کنید.
PHP Errors پرتکرار	ناسازگاری، باگ یا کد قدیمی	منشأ خطا را پیدا و برطرف کنید. بسته به علت، به‌روزرسانی یا جایگزینی مؤلفه هم ممکن است لازم باشد.
Scripts/Styles غیرضروری	بارگذاری سراسری فایل‌های افزونه	فایل‌ها را فقط در صفحات لازم صف‌گذاری کنید و وابستگی‌های غیرضروری را کنار بگذارید.
زمان پردازش بالا بدون عامل نرم‌افزاری مشخص	محدودیت CPU ،RAM، دیسک یا پیکربندی سرور	منابع و لاگ‌ها را بررسی کنید و فقط در صورت وجود گلوگاه واقعی سراغ بهینه‌سازی یا ارتقای سرویس بروید.

توجه داشته باشید که لازم نیست تمام این راه‌حل‌ها را هم‌زمان اجرا کنید. ارزش عیب‌یابی در این است که هر تغییر را براساس مشکلی انجام دهید که در داده‌ها دیده‌اید. این کار هم ریسک را کمتر می‌کند و هم نشان می‌دهد کدام اصلاح واقعاً روی سرعت سایت اثر گذاشته است.

فرض کنید Query Monitor نشان می‌دهد بخش زیادی از زمان صرف انتظار برای یک API خارجی می‌شود. در این شرایط، ارتقای CPU احتمالاً تغییر چشمگیری ایجاد نمی‌کند. برعکس، اگر کد و کوئری‌ها وضعیت مناسبی دارند اما CPU یا RAM در ساعات پرترافیک مرتب به سقف می‌رسد، بررسی زیرساخت منطقی‌تر است.

چه زمانی ارتقای هاست یا سرور منطقی است؟

میزبانی روی عملکرد سایت اثر دارد، اما مهاجرت زمانی ارزش بررسی دارد که نشانۀ مشخصی از محدودیت منابع ببینید. اگر بعد از اصلاح افزونه‌ها، کوئری‌ها، کش و خطاهای برنامه همچنان CPU ،RAM یا I/O به گلوگاه تبدیل می‌شوند، سرویس قوی‌تر می‌تواند بخشی از راه‌حل باشد.

اگر پروژه به دسترسی مدیریتی، منابع قابل تنظیم و امکان پیکربندی اختصاصی نیاز دارد، «سرور مجازی» نسبت به هاست اشتراکی کنترل بیشتری در اختیار شما می‌گذارد. برای سایتی که بخش عمدۀ کاربرانش داخل ایران هستند و محل استقرار سرور در معماری پروژه اهمیت دارد، می‌توان «سرور مجازی ایران» را هم بررسی کرد. پروژه‌های بسیار پرترافیک یا بارهای پردازشی سنگین که به منابع سخت‌افزاری اختصاصی نیاز دارند، ممکن است در نهایت به «سرور اختصاصی ایران» برسند.

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

آیا Query Monitor خودش باعث کند شدن سایت می‌شود؟

بله. هر ابزار مانیتورینگ برای جمع‌آوری و نمایش اطلاعات مقداری سربار دارد. توسعه‌دهندۀ Query Monitor اثر آن بر زمان تولید صفحه را معمولاً کم می‌داند، اما در صفحاتی با صدها کوئری، مصرف حافظه می‌تواند بیشتر شود.

به همین دلیل، عددی که هنگام فعال بودن Query Monitor می‌بینید دقیقاً معادل تجربۀ کاربر نهایی نیست. این افزونه برای پیدا کردن علت کندی طراحی شده، نه برای ثبت نتیجه نهایی عملکرد سایت.

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

Query Monitor و Core Web Vitals چه تفاوتی دارند؟

Query Monitor و Core Web Vitals دو بخش متفاوت از عملکرد سایت را اندازه می‌گیرند. Query Monitor بیشتر اتفاق‌های داخل وردپرس و سمت سرور را نشان می‌دهد؛ Core Web Vitals روی تجربۀ کاربر، از سرعت نمایش محتوای اصلی گرفته تا پاسخ‌گویی و ثبات چیدمان، تمرکز دارد. طبق مستندات فعلی گوگل، برای قرار گرفتن در محدودۀ «خوب»، LCP باید حداکثر 2.5 ثانیه باشد، INP کمتر از 200 میلی‌ثانیه بماند و CLS از 0.1 بیشتر نشود. بنابراین بهتر است سرعت سایت را به یک عدد یا یک امتیاز خلاصه نکنید. ممکن است یک شاخص خوب باشد و بخش دیگری هنوز مشکل داشته باشد. تصمیم‌گیری برای بهینه‌سازی هم زمانی دقیق‌تر است که چند نشانه را کنار هم بررسی کنید.

برای مثال، ممکن است پاسخ‌گویی سرور مناسب باشد اما JavaScript سنگین یا جابه‌جایی عناصر صفحۀ تجربه کاربر را خراب کند. حالت برعکس هم ممکن است: ظاهر صفحه سریع نمایش داده شود اما بعضی درخواست‌های سمت سرور کند باشند. به همین دلیل، Core Web Vitals و داده‌های Query Monitor مکمل هم هستند. امتیاز خوب Core Web Vitals هم به‌تنهایی رتبه بالاتر در گوگل را تضمین نمی‌کند.

یک روند عملی برای عیب‌یابی با افزونه Query Monitor

برای اینکه بررسی‌ها پراکنده نشوند، می‌توانید مراحل بالا را به این ترتیب انجام دهید:

1. صفحه‌ای را انتخاب کنید که کندی در آن قابل تکرار است و وضعیت فعلی آن را ثبت کنید.
2. افزونۀ Query Monitor را فعال کنید و برای پیدا کردن سرنخ اولیه، Timeline را ببینید.
3. اگر نشانه‌ها به دیتابیس می‌رسند، Queries by Component ،Slow Queries و Duplicate Queries را بررسی کنید.
4. خطاهای PHP و درخواست‌های HTTP خارجی را هم بررسی کنید؛ این دو بخش گاهی در نگاه اول از قلم می‌افتند.
5. در Scripts و Styles دنبال فایل‌هایی بگردید که بدون نیاز در صفحه بارگذاری شده‌اند یا وابستگی‌های مسئله‌دار دارند.
6. در هر مرحله فقط یک تغییر مشخص انجام دهید. اگر چند چیز را هم‌زمان عوض کنید، بعداً مشخص نمی‌شود کدام تغییر اثر داشته است.
7. همان صفحه را با همان سناریوی قبلی دوباره تست کنید و نتیجه را با نقطه مبنا مقایسه کنید.
8. برای اندازه‌گیری نهایی، Query Monitor را از تست خارج کنید و PageSpeed Insights یا ابزار مشابه را دوباره اجرا کنید.

این روند پیچیده نیست، اما عیب‌یابی را قابل‌اعتمادتر می‌کند: ابتدا سرنخ را پیدا می‌کنید، فقط همان بخش را تغییر می‌دهید و بعد نتیجه را دوباره اندازه می‌گیرید. استفادۀ مؤثر از افزونه Query Monitor بیشتر از هر چیز به همین نظم در بررسی و مقایسه وابسته است.

جمع‌بندی

کندی در وردپرس معمولاً فقط یک علت ندارد. ممکن است یک افزونه کوئری سنگین اجرا کند، API بیرونی دیر پاسخ بدهد، خطای PHP مدام در لاگ ثبت شود یا منابع سرور در ساعات شلوغ کافی نباشند. Query Monitor کمک می‌کند این احتمال‌ها را به داده و مؤلفه مشخص وصل کنید. افزونه Query Monitor را باید ابزار تشخیص دانست، نه افزونه‌ای که صرفاً با فعال شدن سرعت سایت را بیشتر می‌کند. شما باید خودتان گلوگاه را پیدا کنید، اصلاح متناسب با همان مشکل را انجام دهید و بعد دوباره همان سناریو را بسنجید.

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

 

سؤالات متداول

آیا افزونه Query Monitor سرعت وردپرس را زیاد می‌کند؟

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

آیا Query Monitor برای سایت ووکامرسی هم قابل استفاده است؟

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

از کدام بخش Query Monitor برای بررسی کندی شروع کنیم؟

اگر از نسخۀ جدید استفاده می‌کنید، Timeline شروع مناسبی است؛ چون ترتیب و مدت رویدادها را سریع نشان می‌دهد. بعد از پیدا کردن بخش زمان‌بر، سراغ پنل تخصصی آن مثل Database Queries ،PHP Errors ،HTTP API Requests یا Scripts and Styles بروید.

آیا تعداد زیاد افزونه همیشه باعث کند شدن سایت می‌شود؟

نه. تعداد افزونه‌ها معیار دقیقی برای سرعت نیست. یک افزونۀ بدطراحی‌شده ممکن است بیشتر از چند افزونۀ سبک به سایت فشار وارد کند. Query Monitor کمک می‌کند به‌جای قضاوت براساس تعداد، ببینید کدام مؤلفه واقعاً زمان یا منابع بیشتری مصرف کرده است.

بعد از استفاده از Query Monitor باید آن را حذف کنیم؟

ضرورتی ندارد، اما بهتر است فعال ماندن دائمی آن یک تصمیم آگاهانه باشد. Query Monitor برای جمع‌آوری داده مقداری سربار دارد؛ بنابراین روی سایت‌های پرترافیک، بعد از پایان عیب‌یابی بررسی کنید که هنوز به آن نیاز دارید یا نه. برای سنجش نهایی سرعت هم بهتر است تست را بدون سربار این ابزار انجام دهید.