چگونه افزونه کند وردپرس را پیدا کنیم؟

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

فرض کنید یک سایت ۳۰ افزونه فعال دارد و صاحب سایت احساس می‌کند بعد از نصب یک افزونه جدید، سرعت افت کرده است. غیرفعال کردن افزونه‌ها به‌صورت تصادفی شاید در نهایت مشکل را پیدا کند، اما روش حرفه‌ای این نیست. باید بتوانیم مشخص کنیم کدام افزونه در کدام بخش از سایت، چه مقدار بار ایجاد می‌کند و آیا این بار واقعاً دلیل کندی است یا فقط یکی از عوامل مشکل.

در این مقاله دقیقاً به همین موضوع می‌پردازیم: چگونه افزونه کند وردپرس را پیدا کنیم؟ قرار نیست فقط چند افزونه را غیرفعال کنید و امیدوار باشید مشکل برطرف شود. روش‌های عملی برای بررسی زمان اجرای PHP، کوئری‌های دیتابیس، درخواست‌های AJAX، فایل‌های JavaScript و CSS، Heartbeat، Cron و حتی تفاوت عملکرد افزونه در پیشخوان و بخش کاربری را بررسی می‌کنیم. در پایان نیز می‌توانید با یک فرآیند مرحله‌به‌مرحله مشخص کنید مشکل از کدام افزونه است و قبل از حذف یا جایگزینی آن، تأثیر واقعی‌اش را روی سایت بسنجید.

تیم پشتیبان سایت کمک وردپرس بصورت تخصصی میتواند به این موضوعات بپردازد و مشکلات فنی در این زمینه را برای شما رفع کند لازم به ذکر است مواردی که در این مقاله ذکر شده قبل از اجرا حتما از سایت خود بکاپ تهیه کنید .

فهرست مطالب

• چگونه افزونه کند وردپرس را پیدا کنیم؟
• چرا بعضی افزونه‌های وردپرس باعث کندی سایت می‌شوند؟
• از کجا بفهمیم یک افزونه باعث کندی وردپرس شده است؟
• ابزارهای حرفه‌ای برای پیدا کردن افزونه کند وردپرس
• بررسی افزونه‌ها با Query Monitor
• پیدا کردن افزونه سنگین در سمت کاربر
• پیدا کردن افزونه کند در پیشخوان وردپرس
• بررسی AJAX، Cron و Heartbeat
• روش اصولی تست افزونه‌ها بدون حدس و خطا
• بعد از پیدا کردن افزونه کند چه کار کنیم؟
• سؤالات متداول

چگونه افزونه کند وردپرس را پیدا کنیم؟

برای چگونه افزونه کند وردپرس را پیدا کنیم؟ یک پاسخ کوتاه وجود دارد: باید عملکرد سایت را قبل و بعد از غیرفعال کردن افزونه، در یک شرایط یکسان اندازه‌گیری کنید. صرفاً اینکه یک افزونه تعداد زیادی فایل JavaScript دارد، حجم زیادی از کد PHP دارد یا امکانات زیادی ارائه می‌دهد، به معنی کند بودن آن نیست. افزونه‌ای ممکن است کد زیادی داشته باشد اما فقط در صفحه خاصی اجرا شود؛ در مقابل یک افزونه ظاهراً ساده می‌تواند در تمام درخواست‌های سایت، کوئری‌های اضافی به دیتابیس ارسال کند.

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

اول مشخص کنید مشکل از سمت سرور است یا مرورگر

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

بنابراین اگر صفحه در ابتدا چند ثانیه سفید می‌ماند و بعد محتوا نمایش داده می‌شود، باید بیشتر به سمت PHP، دیتابیس، هاست، APIهای خارجی یا پردازش‌های سمت سرور شک کرد. اما اگر HTML خیلی سریع دریافت می‌شود و صفحه در مرورگر هنگام اجرای فایل‌های JavaScript یا دریافت منابع مختلف کند است، احتمالاً باید بخش Front-end را بررسی کنید.

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

هر افزونه‌ای که در سایت فعال است، الزاماً مقصر نیست

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

برای مثال، فرض کنید یک فروشگاه ووکامرس از افزونه فیلتر محصولات استفاده می‌کند. ممکن است در صفحه اصلی هیچ مشکلی ایجاد نکند، اما در صفحه فروشگاه هنگام اعمال فیلتر قیمت و ویژگی‌ها، تعداد زیادی درخواست AJAX ایجاد شود. در این حالت تست صفحه اصلی و نتیجه‌گیری درباره عملکرد کل افزونه اشتباه است. باید دقیقاً همان سناریویی را بررسی کرد که کاربر در آن با کندی مواجه شده است.

قبل از بررسی افزونه‌ها، یک خط مبنا ایجاد کنید

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

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

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

چرا بعضی افزونه‌های وردپرس باعث کندی سایت می‌شوند؟

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

کوئری‌های زیاد به دیتابیس

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

بارگذاری فایل‌های اضافی در تمام صفحات

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

ارتباط با سرویس‌های خارجی

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

پردازش‌های سنگین PHP

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

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

اجرای عملیات در همه درخواست‌های وردپرس

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

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

از کجا بفهمیم یک افزونه باعث کندی وردپرس شده است؟

قبل از اینکه سراغ ابزارهای تخصصی برویم، باید بدانیم چه نشانه‌هایی می‌توانند ما را به یک افزونه مشکوک کنند. هیچ‌کدام از این نشانه‌ها به‌تنهایی اثبات نمی‌کنند که یک افزونه مقصر است، اما وقتی چند مورد هم‌زمان دیده شوند، ارزش بررسی دارند.

کندی بعد از نصب یا به‌روزرسانی یک افزونه

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

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

کندی فقط در یک صفحه خاص

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

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

کندی فقط در پیشخوان وردپرس

اگر سایت برای کاربران عادی سریع است اما مدیریت وردپرس بسیار کند شده، نباید بلافاصله سراغ تصاویر و فایل‌های Front-end بروید. افزونه‌های مدیریتی، گزارش‌گیری، امنیت، آمار، بکاپ و اتصال به سرویس‌های خارجی می‌توانند در Dashboard پردازش‌های سنگینی انجام دهند.

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

افزایش ناگهانی مصرف CPU یا PHP Workers

اگر هاست یا سرور شما امکان مشاهده منابع مصرفی را دارد، افزایش CPU، RAM یا PHP Workers می‌تواند سرنخ مهمی باشد. با این حال، نمودار مصرف منابع به‌تنهایی مشخص نمی‌کند کدام افزونه عامل مشکل است. باید زمان افزایش مصرف را با عملیات سایت، Cronها، سفارش‌ها، بازدیدها و تغییرات اخیر مقایسه کنید.

اگر تعداد PHP Workerهای هم‌زمان سریعاً پر شود، درخواست‌های جدید ممکن است در صف قرار بگیرند و کاربر این وضعیت را به شکل کندی یا حتی خطای 502 و 504 مشاهده کند.

ابزارهای حرفه‌ای برای پیدا کردن افزونه کند وردپرس

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

چرا فقط PageSpeed کافی نیست؟

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

از طرف دیگر، ممکن است یک افزونه از نظر PageSpeed مشکل بزرگی ایجاد نکند ولی در سمت سرور Queryهای سنگینی اجرا کند. بنابراین برای پیدا کردن افزونه کند، باید Server-side و Client-side را جداگانه بررسی کرد.

بررسی افزونه‌ها با Query Monitor

اگر قرار باشد فقط یک ابزار برای عیب‌یابی فنی وردپرس انتخاب کنیم، Query Monitor یکی از گزینه‌های بسیار کاربردی است. این ابزار اطلاعاتی درباره Queryهای دیتابیس، زمان اجرای PHP، Hookها، درخواست‌های AJAX، REST API، HTTP Requests و خطاهای PHP در اختیار توسعه‌دهنده قرار می‌دهد.

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

بررسی Database Queries

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

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

بررسی Queryهای تکراری

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

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

بررسی زمان اجرای PHP

اگر Queryهای دیتابیس مشکل اصلی نباشند، باید به زمان اجرای PHP توجه کرد. در این مرحله می‌توان بررسی کرد کدام بخش از فرآیند تولید صفحه زمان بیشتری مصرف می‌کند و آیا یک افزونه یا Hook خاص در این فرآیند نقش دارد.

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

پیدا کردن افزونه سنگین در سمت کاربر

گاهی افزونه از نظر PHP کاملاً قابل قبول است، اما فایل‌های Front-end زیادی به سایت اضافه می‌کند. در چنین شرایطی باید از ابزارهای مرورگر کمک بگیریم.

بررسی Network در Chrome DevTools

در Chrome می‌توانید DevTools را باز کرده و وارد بخش Network شوید. سپس صفحه را با Cache مناسب یا در صورت نیاز در حالت Disable Cache بارگذاری کنید. حالا می‌توان فایل‌های CSS، JavaScript، فونت، تصویر و درخواست‌های XHR یا Fetch را بررسی کرد.

هدف این نیست که صرفاً تعداد فایل‌ها را بشمارید. باید ببینید چه فایل‌هایی زمان زیادی برای دریافت یا اجرا مصرف می‌کنند و آیا نام فایل یا مسیر آن به یک افزونه خاص مربوط است.

بررسی JavaScriptهای افزونه‌ها

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

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

Waterfall چه چیزی به ما می‌گوید؟

Waterfall یکی از مفیدترین ابزارها برای فهمیدن ترتیب بارگذاری منابع است. با نگاه کردن به Waterfall می‌توانید متوجه شوید کدام درخواست دیر شروع شده، کدام درخواست زمان زیادی منتظر مانده و چه منابعی به‌صورت زنجیره‌ای به منابع دیگر وابسته هستند.

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

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

پیدا کردن افزونه کند در پیشخوان وردپرس

یکی از حالت‌هایی که در عیب‌یابی سایت‌های وردپرسی زیاد دیده می‌شود، این است که بخش کاربری سایت عملکرد قابل قبولی دارد اما پیشخوان وردپرس بسیار کند است. مدیر سایت روی یک منوی ساده کلیک می‌کند و چند ثانیه منتظر می‌ماند تا صفحه باز شود. در چنین شرایطی بررسی Front-end معمولاً مسیر درستی نیست و باید سراغ پردازش‌های مدیریتی برویم.

افزونه‌های گزارش‌گیری و داشبورد

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

برای تشخیص چنین مشکلی، صفحه اصلی پیشخوان را با صفحات ساده‌ای مانند «نوشته‌ها» یا «برگه‌ها» مقایسه کنید. اگر فقط یک بخش خاص کند است، همان بخش را هدف بررسی قرار دهید.

افزونه‌های امنیتی

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

این به معنی ضعیف یا نامناسب بودن افزونه امنیتی نیست. باید بررسی شود چه قابلیت‌هایی فعال هستند و آیا اجرای دائمی آن‌ها برای نیاز واقعی سایت ضروری است یا خیر.

افزونه‌های بکاپ

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

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

بررسی AJAX، Cron و Heartbeat

گاهی هیچ صفحه‌ای به شکل ظاهری مشکل ندارد، اما سایت در پس‌زمینه دائماً درخواست‌هایی ارسال می‌کند. این درخواست‌ها ممکن است از AJAX، REST API، Heartbeat API یا WP-Cron ایجاد شده باشند و مصرف منابع را بالا ببرند.

AJAX چگونه می‌تواند باعث کندی شود؟

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

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

در DevTools مرورگر، بخش Network و سپس Fetch/XHR محل مناسبی برای شروع این بررسی است. اگر هنگام یک عملیات ساده چندین درخواست پشت سر هم ایجاد می‌شود، باید مشخص شود هر درخواست متعلق به کدام افزونه یا قابلیت است.

Heartbeat API

Heartbeat API برای ارتباط دوره‌ای مرورگر با سرور استفاده می‌شود و در بخش‌هایی از وردپرس کاربرد دارد. مشکل زمانی ایجاد می‌شود که تعداد درخواست‌ها یا فاصله اجرای آن‌ها برای شرایط سایت مناسب نباشد.

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

WP-Cron و وظایف زمان‌بندی‌شده

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

اگر تعداد زیادی وظیفه زمان‌بندی‌شده ایجاد شده باشد یا یکی از آن‌ها مرتباً با تأخیر اجرا شود، مصرف منابع می‌تواند افزایش پیدا کند. در سایت‌های حرفه‌ای بهتر است وضعیت Cronها بررسی شود و وظایف غیرضروری یا تکراری شناسایی شوند.

روش اصولی تست افزونه‌ها بدون حدس و خطا

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

مرحله اول: مشکل را دقیق تعریف کنید

به جای اینکه بگویید «سایت کند شده»، مشخص کنید کدام قسمت کند است. مثلاً صفحه محصول در ۴ ثانیه باز می‌شود، ذخیره محصول در پیشخوان ۸ ثانیه طول می‌کشد یا بعد از کلیک روی افزودن به سبد خرید، پاسخ AJAX با تأخیر دریافت می‌شود.

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

مرحله دوم: وضعیت فعلی را ثبت کنید

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

مرحله سوم: افزونه‌های مشکوک را دسته‌بندی کنید

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

این دسته‌بندی به معنی متهم کردن افزونه‌های خاص نیست؛ بلکه فقط یک روش منطقی برای اولویت‌بندی بررسی است.

مرحله چهارم: تست روی Staging

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

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

مرحله پنجم: تست گروهی

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

مثلاً ابتدا افزونه‌های غیرضروری Front-end، سپس افزونه‌های مدیریتی و بعد افزونه‌هایی که با ووکامرس یا دیتابیس در ارتباط هستند بررسی شوند. اگر با غیرفعال کردن یک گروه مشکل برطرف شد، گروه را کوچک‌تر می‌کنیم تا افزونه موردنظر مشخص شود.

مرحله ششم: بازگرداندن افزونه‌ها

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

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

یک مثال واقعی از عیب‌یابی افزونه کند در فروشگاه وردپرسی

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

در چنین سناریویی اولین اقدام منطقی بررسی Network و Queryهای صفحه دسته‌بندی است. اگر مشخص شود با هر بار انتخاب فیلتر، چند درخواست AJAX ارسال می‌شود و هر درخواست Queryهای زیادی اجرا می‌کند، مسیر بررسی مشخص شده است.

در مرحله بعد باید مشخص شود آیا مشکل از خود افزونه فیلتر است، از نحوه ساخت Queryها، تعداد محصولات، ساختار ویژگی‌ها یا تعامل آن با افزونه دیگری ناشی می‌شود.

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

تفاوت افزونه کند با تداخل افزونه‌ها

این دو موضوع را نباید با هم اشتباه گرفت. یک افزونه ممکن است به‌تنهایی عملکرد مناسبی داشته باشد اما در کنار یک افزونه دیگر مشکل ایجاد کند.

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

در چنین شرایطی حذف دائمی یکی از افزونه‌ها لزوماً بهترین راه‌حل نیست. ابتدا باید مشخص شود تداخل دقیقاً در کدام Hook، Query، درخواست AJAX یا فرآیند رخ می‌دهد.

بعد از پیدا کردن افزونه کند چه کار کنیم؟

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

۱. تنظیمات افزونه را بررسی کنید

بعضی افزونه‌ها قابلیت‌هایی دارند که برای همه سایت‌ها ضروری نیستند. غیرفعال کردن یک قابلیت غیرضروری می‌تواند بدون حذف کل افزونه، مصرف منابع را کاهش دهد.

۲. افزونه را به آخرین نسخه پایدار به‌روزرسانی کنید

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

۳. افزونه جایگزین را بررسی کنید

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

۴. حذف افزونه غیرضروری

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

۵. بهینه‌سازی اختصاصی

در پروژه‌های حرفه‌ای گاهی حذف افزونه امکان‌پذیر نیست. در این شرایط ممکن است بتوان با اصلاح Hookها، محدود کردن اجرای کد، کنترل Assetها، بهینه‌سازی Queryها یا تغییر نحوه اجرای فرآیند، عملکرد را بهتر کرد.

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

اشتباهات رایج هنگام پیدا کردن افزونه کند وردپرس

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

مزایا و محدودیت‌های روش‌های بررسی

جمع‌بندی؛ چگونه افزونه کند وردپرس را پیدا کنیم؟

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

فرآیند حرفه‌ای معمولاً با مشخص کردن سناریوی کندی شروع می‌شود، سپس وضعیت فعلی اندازه‌گیری می‌شود و بعد با ابزارهایی مانند Query Monitor و DevTools، بخش Server-side و Client-side جداگانه بررسی می‌شوند. در سایت‌های حساس نیز تست باید تا حد امکان روی Staging انجام شود.

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

اگر در بررسی‌های اولیه مشخص شد کندی سایت فقط به یک افزونه محدود نیست و عواملی مثل هاست، دیتابیس، قالب، ووکامرس، کش، تصاویر و فایل‌های Front-end نیز درگیر هستند، بهتر است کل سایت به‌صورت فنی بررسی شود. در چنین شرایطی پشتیبانی وردپرس می‌تواند شامل عیب‌یابی، بررسی تداخل افزونه‌ها، رفع خطا و بررسی عملکرد سایت باشد.

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

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

صرفاً تعداد افزونه‌ها معیار مناسبی نیست. ممکن است سایتی با ۳۰ افزونه عملکرد بسیار خوبی داشته باشد و سایتی با تعداد بسیار کمتر، به دلیل یک افزونه یا Query نامناسب کند باشد. کیفیت کدنویسی، نحوه اجرای افزونه و منابعی که مصرف می‌کند اهمیت بیشتری دارد.

چطور بفهمیم کدام افزونه بیشترین Query را اجرا می‌کند؟

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

آیا PageSpeed می‌تواند افزونه کند وردپرس را مشخص کند؟

به‌صورت مستقیم خیر. PageSpeed اطلاعات ارزشمندی درباره عملکرد صفحه و معیارهای تجربه کاربر ارائه می‌کند، اما برای شناسایی دقیق عامل Server-side باید از ابزارهای فنی دیگری مانند Query Monitor و ابزارهای مانیتورینگ سرور نیز کمک گرفت.

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

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

چرا فقط پیشخوان وردپرس کند شده ولی سایت برای کاربران سریع است؟

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

آیا افزونه‌ای که JavaScript زیادی دارد حتماً کند است؟

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

اگر افزونه کند را پیدا کردیم، حتماً باید آن را حذف کنیم؟

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

بهترین روش برای بررسی سرعت یک سایت وردپرسی چیست؟

بهترین روش، بررسی چندلایه است؛ یعنی هم زمان پاسخ سرور و PHP، هم Queryهای دیتابیس، هم درخواست‌های Network، هم JavaScript و CSS و هم وضعیت منابع سرور بررسی شوند. یک ابزار واحد معمولاً تصویر کاملی از علت کندی ارائه نمی‌کند.