تعداد زیاد افزونه‌ها الزاماً سایت را کند نمی‌کند و تعداد کم نیز تضمین سرعت نیست. یک افزونه ممکن است در هر درخواست API خارجی صدا بزند، query بدون index اجرا کند یا فقط در checkout سنگین باشد. هدف این است که «افزونه مظنون» را به «عامل تأییدشده در یک سناریوی مشخص» تبدیل کنیم.
پاسخ سریع: ابتدا URL یا عملیات کند و معیار baseline را ثبت کنید. clone یا staging هم‌نسخه بسازید، cache را در هر آزمون به شکل یکسان نگه دارید و افزونه‌ها را کنترل‌شده isolate کنید. سپس با Query Monitor، PHP slowlog یا APM مشخص کنید زمان در hook، query یا HTTP call کدام افزونه صرف می‌شود.
قبل از غیرفعال‌سازی، سناریو تعریف کنید
- باز شدن صفحه محصول برای کاربر ناشناس
- افزودن به سبد و checkout
- ذخیره محصول در wp-admin
- جستجو یا فیلتر
- اجرای cron، import یا webhook
یک افزونه ممکن است صفحه اصلی را تغییر ندهد ولی ذخیره سفارش را کند کند. هر آزمون باید URL، وضعیت login، داده ورودی، cache hit/miss و زمان اجرا را ثابت نگه دارد.
چرا روی production همه افزونه‌ها را خاموش نکنیم؟
این کار می‌تواند پرداخت، امنیت، فرم، SEO و jobهای پس‌زمینه را متوقف کند و هم‌زمان cache را پاک کند؛ در نتیجه داده مقایسه نیز آلوده می‌شود. از clone تازه دیتابیس و فایل‌ها استفاده کنید و اطلاعات حساس را در محیط آزمایش محافظت کنید. اگر staging به سرویس‌های واقعی متصل است، ارسال ایمیل، پرداخت و webhook را ایمن‌سازی کنید.
روش گروه‌بندی و نصف‌کردن
- افزونه‌های ضروری مسیر آزمایش را مشخص کنید.
- بقیه را در staging به دو گروه تقسیم کنید.
- یک گروه را غیرفعال و همان سناریو را چند بار اجرا کنید.
- اگر کندی رفع شد، عامل در گروه غیرفعال است؛ در غیر این صورت گروه فعال را بررسی کنید.
- تقسیم را تکرار کنید تا به چند گزینه محدود برسید.
- افزونه نهایی را تکی فعال/غیرفعال و اثر را تأیید کنید.
این روش از آزمون تکی ده‌ها افزونه سریع‌تر است، اما وابستگی میان افزونه‌ها می‌تواند نتیجه را تغییر دهد. برای تضاد رفتاری، راهنمای تداخل افزونه‌های وردپرس را نیز ببینید.
Query Monitor چه چیزی نشان می‌دهد؟
در محیط کنترل‌شده می‌تواند queryهای کند یا تکراری، caller، hookها، HTTP API call و خطاها را نشان دهد. تعداد query به‌تنهایی معیار نیست؛ duration، فراوانی و rowهای درگیر مهم‌اند. یک درخواست خارجی با timeout پنج‌ثانیه‌ای ممکن است از صد query کوچک اثر بیشتری داشته باشد.
Query Monitor خود overhead دارد و اطلاعات فنی نمایش می‌دهد؛ دسترسی آن را محدود و پس از آزمون production غیرفعال کنید. اگر کندی فقط زیر بار است، profiler یک درخواست منفرد کافی نیست و APM یا load test کنترل‌شده لازم می‌شود.
نشانه‌های افزونه در لاگ و Network
در DevTools، initiator و endpoint درخواست کند را ببینید. در PHP log و stack trace نخستین مسیر زیر wp-content/plugins سرنخ است، اما آخرین فایل الزاماً علت ریشه‌ای نیست. timestamp درخواست را با access log و PHP-FPM slowlog تطبیق دهید.
برای پیشخوان، درخواست‌های admin-ajax و REST را جدا کنید. راهنمای کندی wp-admin مسیرهای مخصوص مدیریت را توضیح می‌دهد.
HTTP callهای خارجی
license check، فونت، آمار، CRM، پیامک یا سرویس امنیتی ممکن است پاسخ کند یا DNS نامطمئن داشته باشد. host، timeout و رفتار fallback را ثبت کنید. خاموش کردن TLS verification یا hard-code کردن IP راه‌حل امن و پایدار نیست. پاسخ باید cache یا async شود فقط اگر منطق و تازگی داده اجازه می‌دهد.
Query و دیتابیس
افزونه‌ای که meta فراوان ذخیره می‌کند یا روی هر صفحه query بدون limit می‌زند می‌تواند bottleneck باشد. slow query log و plan را بررسی کنید. ساخت index باید روی clone آزمایش شود؛ index اضافی write و disk را گران می‌کند. پاک‌کردن جدول افزونه بدون backup و مستندات رسمی قابل قبول نیست.
cron و عملیات پس‌زمینه
بعضی افزونه‌ها فقط هنگام cron CPU می‌گیرند. نام hook، interval، duration و overlap را بررسی کنید. خاموش کردن افزونه ممکن است eventهای ثبت‌شده را باقی بگذارد؛ برعکس حذف event ممکن است کار ضروری را متوقف کند. قبل از تغییر، مالک و هدف هر job را مشخص کنید.
Cache نتیجه را چگونه منحرف می‌کند؟
اولین درخواست پس از purge با درخواست گرم برابر نیست. برای هر variant چند بار اجرا و cache status را ثبت کنید. اگر افزونه فقط برای کاربر واردشده فعال است، آزمون ناشناس چیزی نشان نمی‌دهد. page cache همچنین ممکن است کد افزونه را کاملاً دور بزند و کندی backend پنهان بماند.
اگر افزونه مقصر بود چه کنیم؟
- نسخه، تنظیم و سناریوی قابل بازتولید را مستند کنید.
- changelog و issueهای همان نسخه را بررسی کنید.
- قابلیت غیرضروری یا frequency job را با تنظیم رسمی اصلاح کنید.
- نسخه اصلاح‌شده را در staging آزمایش کنید.
- اگر جایگزین می‌کنید، سازگاری داده و migration را بسنجید.
- قبل و بعد با همان baseline اندازه‌گیری کنید.
ویرایش مستقیم فایل افزونه با آپدیت بعدی از بین می‌رود. patch باید قابل نگهداری باشد یا upstream شود. rollback نیز اگر migration دیتابیس انجام شده، فقط جایگزینی فایل نیست.
اشتباه‌های رایج
- قضاوت از روی شهرت یا تعداد افزونه‌ها
- تست صفحات متفاوت قبل و بعد
- نادیده گرفتن cache سرد و warm
- حذف افزونه و جدول‌های آن بدون backup
- فعال گذاشتن profiler روی production
- مقصر دانستن caller آخر بدون دیدن stack کامل
چه زمانی بررسی تخصصی لازم است؟
اگر کندی فقط زیر concurrency، در checkout یا jobهای متناوب رخ می‌دهد، آزمون دستی ساده کافی نیست. سرویس افزایش سرعت وردپرس می‌تواند درخواست، hook، query و مصرف منابع را به افزونه مشخص نسبت دهد و معیار اصلاح ارائه کند.
پرسش‌های متداول
آیا افزونه غیرفعال هم سایت را کند می‌کند؟
کد افزونه غیرفعال معمولاً اجرا نمی‌شود، اما cron، داده، drop-in یا تنظیمات باقی‌مانده باید جدا بررسی شوند.
آیا Query Monitor سرعت را کم می‌کند؟
overhead دارد؛ برای تشخیص کنترل‌شده استفاده و دسترسی آن محدود شود.
آیا حذف و نصب دوباره افزونه کافی است؟
اگر علت query، داده یا تنظیم باقی‌مانده باشد نه. ابتدا سناریو و علت را مشخص کنید.