آزمایش تأثیر کش بر سرعت وردپرس

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

چرا سنجش کش بدون عدد، تصمیم کور است

سه سال پیش روی یک فروشگاه اینترنتی کار می‌کردم که صاحبش سه افزونه کش مختلف را پشت سر هم امتحان کرده بود و هر بار نتیجه را «فایده نداشت» توصیف می‌کرد. وقتی خط پایه را گرفتم و بعد از فعال‌سازی اولین لایه کش، دوباره اندازه گرفتم، معلوم شد TTFB (Time To First Byte) از ۸۹۰ میلی‌ثانیه به ۳۱۰ رسیده — یعنی اثری که او توصیفش می‌کرد در عدد وجود داشت، اما چون آن را ندیده بود، نتوانسته بود تصمیم درست را ادامه بدهد و افزونه را وسط راه حذف کرده بود. ماجرا دو درس دارد: اول این‌که سرعت وردپرس بدون عدد، حدس است. دوم این‌که کش نه یک کلید روشن/خاموش، بلکه سه لایه مستقل است که هرکدام جداگانه اندازه‌گیری می‌شوند. آنچه در ادامه می‌آید، نسخه بازنویسی‌شده همان آزمایش است. هدف عدد جادویی نیست؛ هدف این است که دست شما راه بیفتد و در پروژه بعدی، تصمیم کش را با داده بگیرید نه با حس. اگر با نقشه کلی بهینه‌سازی سرعت آشنا نیستید، ابتدا مقاله بهینه‌سازی سرعت سایت چیست را بخوانید تا جایگاه کش در تصویر بزرگ مشخص شود.

آزمایش را چگونه طراحی کردم

آزمایش روی یک نصب تازه وردپرس با داده واقعی یک سایت نمونه اجرا شد: حدود سی نوشته با تصاویر، سه برگه، یک قالب سبک و پنج افزونه رایج (سئو، فرم تماس، بکاپ، تصویر و اسنشاتینگ). هاست هم اشتراکی و معمولی بود تا واقعیت پروژه‌های معمول مشتریان من بازتاب پیدا کند، نه شرایط آزمایشگاهی. برای هر اندازه‌گیری، سه صفحه را انتخاب کردم — خانه، یک نوشته بلند و یک برگه با فرم — و برای هرکدام دو نوع عدد ثبت کردم: یک TTFB با ابزار خط فرمان و یک گزارش موبایل از ابزار تست سرعت که در بهترین ابزارهای تست سرعت سایت معرفی کرده‌ام. هر عدد را سه بار اجرا و میانه را ثبت کردم تا نوسان سرور در نتیجه خلط نشود. از LCP (Largest Contentful Paint) هم به‌عنوان شاخص سرعت دیداری استفاده کردم؛ اگر با این معیارها آشنایی ندارید، توضیح کاملشان در Core Web Vitals چیست آمده.

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

اعداد خط پایه: پیش از هر کش

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

• TTFB خانه: حدود ۸۵۰ میلی‌ثانیه
• TTFB نوشته بلند: حدود ۹۱۰ میلی‌ثانیه
• TTFB برگه فرم: حدود ۷۸۰ میلی‌ثانیه
• LCP موبایل خانه: حدود ۴٫۳ ثانیه
• تعداد درخواست‌های استاتیک: ۴۲

این تصویر اولیه با آنچه در بیشتر پروژه‌های تازه می‌بینم همخوان است: TTFB بالا، LCP شکننده، و یک تعداد درخواست که نصفشان با لایه تصویر و قالب مربوط‌اند. اگر در سایت خودتان عدد TTFB بیشتر از ۸۰۰ میلی‌ثانیه می‌بینید و نمی‌دانید از هاست است یا افزونه، ترتیب شک‌کردن را در تأثیر TTFB بر سرعت بارگذاری و تأثیر هاست بر سرعت سایت جدا نوشته‌ام.

لایه اول: کش صفحه (Page Cache)

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

• TTFB خانه: از ۸۵۰ به ۲۴۰ میلی‌ثانیه
• TTFB نوشته بلند: از ۹۱۰ به ۲۷۰ میلی‌ثانیه
• TTFB برگه فرم: از ۷۸۰ به ۲۲۰ میلی‌ثانیه
• LCP موبایل خانه: از ۴٫۳ به ۳٫۱ ثانیه

یعنی کش صفحه به‌تنهایی حدود ۶۵ تا ۷۰ درصد TTFB را پایین آورد. این درصد در سایت‌های داینامیک سنگین‌تر (فروشگاه‌های متوسط) حتی بیشتر هم می‌شود. نکته‌ای که کمتر دیده می‌شود: کاهش TTFB روی LCP اثر می‌گذارد، اما نه به‌تنهایی کافی است — بخش قابل‌توجهی از LCP هنوز در دست تصویر شاخص و فونت است. در اکثر پروژه‌ها، انتخاب اینکه کدام افزونه صفحه را کش کند به هاست بستگی دارد؛ مقایسه واقع‌بینانه‌شان را در بهترین افزونه‌های کش وردپرس و WP Rocket در برابر W3 Total Cache گذاشته‌ام. اگر هاست شما LiteSpeed دارد، انتخاب عملاً تمام است چون همان افزونه رایگان کافی است.

لایه دوم: کش مرورگر (Browser Cache)

لایه دوم روی سرور کاری نمی‌کند؛ روی دستگاه کاربر کار می‌کند. هدفش این است که فایل‌های استاتیک (تصویر، CSS، JS، فونت) یک بار دانلود شوند و در بازدید بعدی از کش مرورگر بیایند. در آزمایش من، این لایه اثر مستقیم روی TTFB نداشت — همان چیزی که خیلی‌ها را گمراه می‌کند — اما روی زمان دیداری بازدید دوم و سوم اثر چشمگیری داشت:

• LCP موبایل خانه در بازدید دوم: از ۳٫۱ به ۲٫۲ ثانیه
• تعداد درخواست‌های ارسال‌شده در بازدید دوم: از ۴۲ به ۹

یک هشدار عملی که در پروژه‌ها زیاد از دست می‌رود: کش مرورگر اگر بدون نسخه‌گذاری روی فایل‌ها فعال شود، پس از هر آپدیت قالب یا افزونه، کاربر بازگشتی نسخه کهنه CSS را می‌بیند و ظاهر سایت می‌شکند. فعال نگه‌داشتن query-string روی فایل‌ها (که در اکثر افزونه‌ها به‌عنوان version یا cache-busting شناخته می‌شود)، این ریسک را حذف می‌کند. اگر با این مفهوم آشنا نیستید، بخش تنظیمات امن در همان مقاله افزونه‌های کش توضیح داده شده.

لایه سوم: کش آبجکت و OPcache

لایه سوم برای بسیاری از سایت‌ها نادیده می‌ماند چون به‌سختی قابل‌مشاهده است: کش آبجکت (Object Cache) نتیجه کوئری‌های دیتابیس را نگه می‌دارد و OPcache، کد PHP را یک بار کامپایل و در حافظه سرور نگه می‌دارد. اثر این لایه روی صفحات کش‌نشده (پیشخوان، سبد خرید، صفحات کاربر) محسوس است و روی بار کلی سرور. در آزمایش من چون صفحه‌ها از قبل کش شده بودند، اثر TTFB عدد کوچکی بود:

• TTFB خانه: از ۲۴۰ به ۲۱۰ میلی‌ثانیه
• زمان بارگذاری پیشخوان: از ۱٫۶ به ۱٫۱ ثانیه

اثر جانبی هم داشت: مصرف RAM سرور ثابت‌تر شد. اگر با پنل هاست کار می‌کنید و در نمودار منابع، پرش‌های نامنظم می‌بینید، OPcache و Object Cache کمک می‌کنند این نمودار صاف شود. این لایه در سایت‌های فروشگاهی و عضوگیری‌محور ارزش دوچندان دارد چون آن‌ها بیشترین بخش کوئری‌شان خارج از کش صفحه اجرا می‌شود.

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

اعداد نهایی و خواندن جدول

جمع سه لایه، این تصویر را ساخت:

خواندن این جدول سه درس دارد. اول این‌که بیشترین پرش در لایه اول اتفاق می‌افتد و این لایه را نمی‌شود حذف کرد. دوم این‌که کش مرورگر روی بازدید دوم اثر می‌گذارد نه بازدید اول؛ پس اگر با ابزارهایی اندازه می‌گیرید که هر بار نصب تازه شبیه‌سازی می‌کنند، اثر آن را نمی‌بینید. سوم این‌که لایه سوم، اثرش کوچک اما برجاست و در سایتی که صفحات پویا زیاد دارد، بیشتر می‌شود. سرجمع، کش حدود ۷۵ درصد TTFB و نزدیک به ۵۰ درصد LCP را در همین آزمایش بهبود داد. این اعداد «معجزه» نیستند؛ نتیجه منطقی یک زنجیره درست‌چیده‌شده‌اند.

کجا کش معجزه نمی‌کند

سه سناریو هست که حتی با کش درست، سرعت به جایی نمی‌رسد و در حقیقت باید جای دیگری را اصلاح کرد:

• هاستِ زیر فشار: اگر TTFB شما حتی روی صفحه‌های کش‌شده بالای ۸۰۰ میلی‌ثانیه بماند، مشکل صف CPU سرور است نه پوسته یا افزونه. مسیر عیب‌یابی‌اش در تأثیر هاست بر سرعت سایت و راهکار کاهش بار در کاهش مصرف منابع هاست است.
• قالب سنگین: کش به شما کمک می‌کند HTML را سریع‌تر برسانید، اما فایل‌های CSS و JS که قالب در هر صفحه تزریق می‌کند را حذف نمی‌کند. اگر بایت‌های صفحه اول بالای ۵۰۰ کیلوبایت است، اول قالب را سبک کنید — مسیرش در قالب سبک وردپرس چیست.
• تصویر و فونت: LCP در اکثر سایت‌های وردپرسی، یک تصویر یا یک تیتر با فونت بیرونی است. کش هیچ‌کدام را سبک نمی‌کند. اگر LCP روی بازدید اول بالای ۳ ثانیه ماند، سراغ تصویر شاخص و font-display بروید.

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

اشتباهات رایج در سنجش تأثیر کش

در طول همین آزمایش و پروژه‌های واقعی، پنج اشتباه تکرارشونده را دیده‌ام که تصمیم را خراب می‌کنند:

1. اندازه‌گیری در حال لاگین ادمین. اکثر افزونه‌ها کش را برای کاربر لاگین‌کرده دور می‌زنند؛ پس اگر در همان مرورگری که ادمین هستید تست کنید، هیچ تفاوتی نمی‌بینید و نتیجه می‌گیرید کش کار نمی‌کند.
2. رهاکردن کش سرور روی کش افزونه. روی هاست‌هایی که لایه کش سرور دارند (SiteGround، Hostinger یا انواع LiteSpeed)، فعال‌کردن یک کش‌ساز دیگر روی همان لایه می‌تواند نتیجه را خراب کند یا حداقل بار اضافه بسازد. یکی را انتخاب کنید.
3. سنجش روی پروفایل دسکتاپ. معیار واقعی امروز موبایل است؛ اگر TTFB روی دسکتاپ خوب شد اما روی موبایل نه، فرق را در ترافیک شبکه و دستگاه ببینید.
4. یک بار اندازه‌گیری. سرورها در ساعات مختلف روز رفتار متفاوت دارند. حداقل سه عدد در سه ساعت مختلف بگیرید تا میانگین معنادار شود.
5. ندیدن اثر جانبی. گاهی کش سرعت را بالا می‌برد اما فرم یا سبد را می‌شکند. هر بار بعد از فعال‌سازی، سه صفحه پویا (سبد، تسویه، حساب) را هم دستی چک کنید.

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

پرسش‌های پرتکرار درباره کش و سرعت وردپرس

آیا یک افزونه کش برای همه سایت‌ها کافی است؟ نه به‌معنای «یک برند برای همه». پاسخ درست این است که سه لایه کش باید فعال باشند، اما برند و افزونه به هاست و نوع سایت بستگی دارد. روی هاست LiteSpeed، LiteSpeed Cache رایگان کافی است؛ روی هاست‌های معمولی، WP Rocket یا ترکیب W3 Total Cache با OPcache و یک کش‌ساز سبک.

کش روی سئو اثر دارد؟ مستقیم نه، غیرمستقیم بله. کش TTFB و LCP را بهتر می‌کند و این دو از معیارهای Core Web Vitals هستند که در تجربه صفحه گوگل وزن دارند. یعنی کش خودش سیگنال سئو نیست، اما زیربنای سیگنال‌های دیگر است.

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

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

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

انتخاب کش با عدد، نه با تبلیغ

آزمایش امروز یک پیام اصلی داشت: کش اضافه‌کردنی است، نه تعویض‌کردنی. سه لایه دارد که هرکدام نقش خودش را بازی می‌کند و باید جداگانه اندازه‌گیری شود. آن‌چه این آزمایش نشان داد در سایت‌های دیگر هم تکرار می‌شود: کش صفحه بیشترین سود را در TTFB می‌دهد، کش مرورگر در بازدید دوم، و کش آبجکت در بار سرور و پیشخوان. اگر امروز فقط یک کار می‌کنید، این باشد: قبل از هر تغییری، سه عدد TTFB و یک عدد LCP را روی سه صفحه بگیرید و در یک فایل ذخیره کنید. همین عادت کوچک، شما را از چرخه نصب و حذف افزونه‌های کش بیرون می‌آورد و تصمیم‌های بعدی‌تان را با داده می‌گیرید. اگر تجربه‌ای از اندازه‌گیری کش در پروژه‌ای واقعی دارید — به‌خصوص اگر نتایجی متفاوت از این آزمایش گرفته‌اید — بنویسید؛ همین داده‌هاست که تصویر را برای خواننده بعدی دقیق‌تر می‌کند. ⚡