اگر فاصله زمانی مشخصی میان آپدیت و شروع کندی وجود دارد، این هم‌بستگی ارزش بررسی دارد؛ اما ثابت نمی‌کند آخرین افزونه تنها مقصر است. پس از به‌روزرسانی ممکن است migration دیتابیس، بازسازی cache، تولید asset، اجرای cron یا ناسازگاری با نسخه PHP آغاز شود. بازگرداندن فوری فایل‌ها بدون توجه به تغییر schema نیز می‌تواند وضعیت را بدتر کند.
پاسخ سریع: نسخه‌های قبل و بعد، زمان دقیق deployment و نخستین نشانه کندی را ثبت کنید. URL و عملیات کند را با baseline پیش از آپدیت مقایسه کنید، log و jobهای پس‌زمینه را ببینید و تغییر را روی clone دیتابیس بازتولید کنید. rollback فقط با backup سازگار و مسیر رسمی انجام شود.
اول مشخص کنید چه چیزی آپدیت شده است
- هسته وردپرس، یک افزونه یا قالب؟
- نسخه PHP، وب‌سرور یا دیتابیس هم تغییر کرده است؟
- چند بسته در یک maintenance window ارتقا یافته‌اند؟
- آیا deployment شامل build تازه CSS/JS یا تغییر CDN بوده است؟
- آیا migration یا job پس از upgrade هنوز در حال اجرا است؟
فهرست مبهم «همه‌چیز آپدیت شد» امکان نسبت دادن علت را از بین می‌برد. نسخه دقیق، checksum بسته و ترتیب تغییرات را نگه دارید.
کندی frontend، مدیریت یا job پس‌زمینه؟
اگر فقط بازدیدکننده ناشناس کند شده، cache و asset جدید را بررسی کنید. اگر wp-admin کند است ولی صفحه عمومی cache می‌شود، queryهای مدیریت، REST، AJAX و workerهای PHP مهم‌ترند. اگر سایت ظاهراً سالم است اما CPU بالا مانده، migration، queue و cron را جست‌وجو کنید.
راهنمای تشخیص کندی کلی وردپرس کمک می‌کند TTFB را از رندر مرورگر جدا کنید. همان URL، وضعیت login و cache status را قبل و بعد مقایسه کنید؛ تست دو صفحه متفاوت نتیجه قابل اتکا نمی‌دهد.
Cache سرد و بازسازی فایل‌ها
پس از deployment ممکن است page cache، object cache یا OPcache سرد باشد. چند درخواست نخست می‌توانند کندتر باشند، اما کندی پایدار با عنوان warm-up توجیه نمی‌شود. hit/miss، زمان warm شدن و purgeهای تکراری را ثبت کنید. اگر هر درخواست cache را invalid می‌کند، منتظر ماندن مشکلی را حل نمی‌کند.
افزونه یا قالب ممکن است assetها را دوباره تولید کند. خطای write، permission یا فضای ناکافی می‌تواند این تولید را در هر درخواست تکرار کند. log فایل‌سیستم و مسیر cache را بررسی کنید؛ استفاده از chmod 777 راه‌حل عمومی و امن نیست.
Migration دیتابیس و کارهای پس از آپدیت
بعضی افزونه‌ها schema، index یا داده مشتق‌شده را به‌روزرسانی می‌کنند. اگر migration ناقص مانده باشد، کد جدید ممکن است queryهای جایگزین و پرهزینه اجرا کند. وضعیت نسخه افزونه، log upgrade و jobهای scheduled را ببینید. ساخت دستی ستون یا اجرای SQL گرفته‌شده از نسخه دیگر خطرناک است.
قبل از retry، بدانید migration idempotent است یا نه. روی فروشگاه، اجرای دوباره sync یا job سفارش ممکن است اثر تجاری داشته باشد. clone دیتابیس production با داده حساس پاک‌سازی‌شده محل مناسب‌تری برای بازتولید است.
ناسازگاری PHP یا extension
هشدار، deprecation یا fallback سازگاری می‌تواند بعد از تغییر PHP مصرف را بالا ببرد. نسخه PHP وب با CLI ممکن است متفاوت باشد. PHP-FPM log، OPcache و extensionهای لازم را بررسی کنید؛ فقط خاموش کردن نمایش warning کافی نیست، چون تولید و ثبت انبوه warning همچنان I/O ایجاد می‌کند.
اگر fatal error نیز رخ می‌دهد، راهنمای خرابی بعد از آپدیت افزونه را دنبال کنید. کندی و crash می‌توانند از یک ناسازگاری مشترک ناشی شوند.
افزونه کندکننده را چگونه تأیید کنیم؟
- سناریوی کند و معیار baseline را تعریف کنید.
- clone یا staging هم‌نسخه بسازید.
- افزونه‌های تغییرکرده را ابتدا بررسی کنید، نه اینکه همه را مقصر فرض کنید.
- query، HTTP call و hook را با profiler مناسب ردیابی کنید.
- یک تغییر در هر بار انجام دهید و نتیجه را تکرار کنید.
- نسخه قبلی را فقط همراه با سازگاری schema آزمایش کنید.
برای روش دقیق‌تر از راهنمای یافتن تداخل افزونه‌ها استفاده کنید؛ اما توجه کنید تداخل عملکردی با bottleneck کارایی یکسان نیست.
چرا Rollback همیشه ساده نیست؟
بازگرداندن فایل افزونه، migration دیتابیس را لزوماً برنمی‌گرداند. نسخه قدیمی ممکن است schema جدید را نشناسد. backup باید شامل دیتابیس و فایل‌ها در یک نقطه سازگار باشد و داده‌های جدید پس از آن—به‌خصوص سفارش‌ها—جدا مدیریت شود. روی production ابتدا مسیر rollback را در staging تمرین کنید.
چک‌لیست اندازه‌گیری
- TTFB و زمان کل چند URL ثابت
- cache hit/miss و زمان warm-up
- CPU، RAM، swap و disk latency
- PHP worker queue و slow request
- slow query و HTTP call خارجی
- cron/queueهای در حال اجرا یا عقب‌افتاده
- خطاها و warningهای جدید پس از نسخه
اشتباه‌های رایج
- پاک‌کردن مداوم cache بدون بررسی علت invalidation
- rollback فایل بدون دیتابیس سازگار
- غیرفعال کردن همه افزونه‌ها روی فروشگاه زنده
- نسبت دادن کندی شبکه به کد جدید بدون اندازه‌گیری
- به‌روزرسانی چند لایه دیگر در میانه تشخیص
- حذف job یا queue بدون شناخت اثر
چگونه از تکرار جلوگیری کنیم؟
نسخه‌ها را pin و changelog را مرور کنید، backup قابل restore بگیرید و upgrade را ابتدا روی staging هم‌نسخه انجام دهید. smoke test باید صفحات عمومی، ورود، ذخیره، checkout و jobهای اصلی را پوشش دهد. baseline عملکرد و alert پس از deployment کمک می‌کند regression سریع دیده شود.
چه زمانی بررسی تخصصی لازم است؟
اگر چند افزونه هم‌زمان ارتقا یافته‌اند، migration درگیر است یا کندی فقط زیر بار دیده می‌شود، rollback حدسی خطر دارد. سرویس افزایش سرعت وردپرس می‌تواند regression را با نسخه، query، PHP و منابع زیرساخت تطبیق دهد.
پرسش‌های متداول
آیا چند ساعت صبر کنیم تا سایت سریع شود؟
فقط اگر job یا warm-up قابل مشاهده و رو به اتمام وجود دارد. کندی پایدار بدون شاخص پیشرفت نیاز به تشخیص دارد.
آیا نسخه قبلی افزونه را نصب کنیم؟
تنها پس از بررسی changelog، schema، backup و تست clone؛ downgrade کورکورانه ممکن است ناسازگاری داده بسازد.
چرا فقط کاربران واردشده کندی دارند؟
آن‌ها معمولاً page cache را دور می‌زنند و hookها، toolbar و درخواست‌های شخصی بیشتری اجرا می‌شود.