افزونه Cache فقط در لایه‌ای که کنترل می‌کند می‌تواند اثر بگذارد. اگر صفحه cache hit نمی‌شود، کاربر واردشده است، checkout dynamic است یا زمان در API خارجی و مرورگر مصرف می‌شود، نصب افزونه تازه نتیجه چشمگیری ندارد. حتی پیکربندی هم‌زمان چند ابزار cache ممکن است purge و خروجی را غیرقابل پیش‌بینی کند.
پاسخ سریع: ابتدا با header یا log ثابت کنید درخواست واقعاً cache hit شده است. TTFB hit و miss را جدا مقایسه کنید و ببینید bottleneck backend است یا frontend. سپس policy، bypass و invalidation را اصلاح کنید؛ فعال بودن گزینه «Cache enabled» به تنهایی معیار نیست.
۱. اصلاً Cache Hit رخ نمی‌دهد
cookie کاربر، query string، header، device variation یا rule مسیر ممکن است هر درخواست را bypass کند. URL تست، وضعیت login و headerهای cache را ثبت کنید. درخواست نخست پس از purge miss طبیعی است؛ چند درخواست یکسان لازم است.
۲. صفحه موردنظر Dynamic است
سبد خرید، checkout، حساب کاربری و wp-admin نباید HTML عمومی یکسان بگیرند. Page Cache برای این مسیرها محدود است. Object Cache ممکن است queryها را کم کند، اما اجرای PHP ادامه دارد. تفاوت Page Cache و Object Cache انتخاب لایه را روشن می‌کند.
۳. مشکل در Frontend است، نه تولید HTML
اگر document سریع می‌رسد ولی تصویر، فونت، CSS یا JavaScript دیر کامل می‌شود، cache HTML فقط بخشی از مسئله را پوشش می‌دهد. DevTools waterfall و Long Task را ببینید. ترکیب و minify خودکار فایل‌ها نیز می‌تواند ترتیب اجرا یا source map را خراب کند؛ هر گزینه را جدا آزمایش کنید.
۴. Bottleneck با Cache دور زده نمی‌شود
API خارجی، upload، جستجو، query شخصی، cron و عملیات write ممکن است در hit عمومی اجرا نشوند اما مسیر تجاری را کند کنند. تشخیص کندی وردپرس کمک می‌کند محل زمان تلف‌شده را پیدا کنید. cache نباید جای رفع query یا timeout خراب را بگیرد.
۵. چند لایه با هم ناسازگارند
CDN، reverse proxy، افزونه و hosting cache ممکن است هم‌زمان فعال باشند. اگر purge فقط یک لایه را پاک کند، محتوای قدیمی باقی می‌ماند. اگر هر لایه دیگری را دائماً purge کند، hit rate پایین می‌آید. مالکیت هر cache، کلید، TTL و مسیر purge را مستند کنید.
۶. Cache مدام پاک می‌شود
ویرایش، import، sync موجودی یا افزونه‌ای که purge سراسری می‌زند می‌تواند cache را همیشه سرد نگه دارد. زمان purge را با deployment و jobها تطبیق دهید. حذف خودکار کل cache در interval ثابت درمان invalidation نیست و ممکن است CPU/MySQL را در cold start بالا ببرد.
۷. تست شما قابل مقایسه نیست
location، شبکه، cookie، URL، device و cache state باید ثابت باشند. نمره دو ابزار متفاوت را قبل و بعد مقایسه نکنید. برای backend، TTFB و server timing؛ برای frontend، waterfall و معیارهای رندر را جدا ببینید. راهنمای TTFB روش اندازه‌گیری را توضیح می‌دهد.
چک‌لیست تشخیص
- در حالت ناشناس یک URL عمومی ثابت انتخاب کنید.
- redirect و header cache را ثبت کنید.
- درخواست سرد و چند درخواست گرم را مقایسه کنید.
- همان URL را در حالت login و dynamic جدا بسنجید.
- زمان HTML را از دانلود و JavaScript جدا کنید.
- log purge، error و منابع origin را بررسی کنید.
- یک تغییر در هر مرحله اعمال کنید.
افزونه Cache چه چیزی را نباید خراب کند؟
login، فرم، nonce، زبان، ارز، سبد، checkout، callback پرداخت و REST write باید smoke test شوند. با دو نشست مستقل مطمئن شوید پاسخ شخصی جابه‌جا نمی‌شود. صفحه سریع با قیمت یا سبد اشتباه بهبود محسوب نمی‌شود.
تنظیمات بهینه‌سازی فایل
defer، delay و minify با page cache یکسان نیستند. delay کردن script ممکن است consent، analytics یا تعامل اصلی را تغییر دهد. هر قابلیت را با تست عملکردی و Console بررسی کنید. حذف CSS «استفاده‌نشده» بر اساس یک صفحه می‌تواند component صفحه دیگر را بشکند.
چه زمانی افزونه را عوض کنیم؟
ابتدا مطمئن شوید ابزار فعلی با hosting و وب‌سرور سازگار و فقط یک مالک برای page cache وجود دارد. اگر visibility لازم، purge معتبر یا پشتیبانی معماری شما را ندارد، جایگزینی قابل بررسی است. مهاجرت افزونه باید ruleهای قدیمی، drop-in و فایل‌های باقی‌مانده را کنترل کند؛ نصب روی نصب مشکل را بیشتر می‌کند.
سه سناریوی عیب‌یابی پس از فعال‌سازی
صفحه سریع است اما محتوای قدیمی می‌بینیم
ابتدا مشخص کنید پاسخ از browser، CDN، proxy یا افزونه آمده است. age و cache key را بررسی و purge هدفمند همان URL را آزمایش کنید. پاک کردن همه لایه‌ها تشخیص اینکه کدام invalidation خراب بوده را از بین می‌برد.
کاربر واردشده محتوای کاربر دیگر را می‌بیند
این یک مشکل صحت و حریم خصوصی است؛ cache عمومی مسیر را فوراً و کنترل‌شده bypass کنید، شواهد header و cookie را نگه دارید و rule را روی staging اصلاح کنید. فقط کاهش TTL پاسخ کافی نیست.
پس از purge CPU بالا می‌رود
احتمال cold-cache stampede را با access log، PHP queue و MySQL بررسی کنید. purge سراسری را تکرار نکنید؛ warm-up محدود صفحات امن و invalidation هدفمند را طراحی کنید.
تغییر را چگونه منتشر کنیم؟
تنظیم تازه را ابتدا روی staging و سپس درصد محدودی از ترافیک یا پنجره کم‌ریسک آزمایش کنید. معیار توقف شامل خطای checkout، login، پاسخ شخصی اشتباه و رشد منابع باشد. تنظیم قبلی، فایل‌های ایجادشده و روش rollback را پیش از rollout ثبت کنید.
اشتباه‌های رایج
- فعال کردن همه گزینه‌ها با یک کلیک
- نصب دو افزونه cache و minify هم‌زمان
- cache عمومی صفحات شخصی
- پاک کردن cache بعد از هر request
- قضاوت فقط با نمره صفحه اصلی
- نادیده گرفتن cache سرور یا CDN
معیار موفقیت
hit rate پایدار، کاهش TTFB صفحات cacheable، فشار کمتر origin و نبود خطای صحت یا regression معیارهای اصلی‌اند. صفحات dynamic نیز باید جدا baseline داشته باشند. نتیجه را زیر ترافیک عادی و پس از warm-up بسنجید.
چه زمانی کمک تخصصی لازم است؟
اگر چند cache layer دارید، hit/miss مشخص نیست یا فروشگاه پس از cache رفتار نادرست دارد، آزمون بیشتر روی production ریسک دارد. سرویس افزایش سرعت وردپرس می‌تواند policy و bottleneck را با شواهد واقعی اصلاح کند.
پرسش‌های متداول
آیا پاک کردن Cache سایت را سریع می‌کند؟
اغلب موقتاً cache را سرد می‌کند؛ purge برای تغییر مشخص است، نه راه بهینه‌سازی دائمی.
آیا افزونه پولی حتماً سریع‌تر است؟
خیر؛ سازگاری معماری، policy و bottleneck واقعی مهم‌تر از مدل فروش ابزار است.
چرا مدیر سایت اثر Cache را نمی‌بیند؟
کاربر واردشده معمولاً page cache را bypass می‌کند؛ با مرورگر ناشناس و headerها آزمایش کنید.