آموزش گام‌به‌گام کش مرورگر در وردپرس؛ از هدرها تا اعتبارسنجی
- کش مرورگر چیست و چه فرقی با کش سرور دارد؟
- هدرهای Cache-Control و Expires هر کدام چه می‌گویند؟
- چه فایل‌هایی کش شوند و چقدر بمانند؟
- کش افزونهٔ وردپرس و کش سمت مرورگر؛ مرز وظایف
- تنظیم با و بدون افزونه؛ از htaccess تا پنل هاست
- اعتبارسنجی بعد از تغییر؛ چطور مطمئن شویم هدرها اعمال شدهاند؟
- جمع‌بندی؛ اشتباه‌های رایج و ترتیب کاری یک هفته
چرا این موضوع برای وردپرس جدی است؟ W3Techs می‌گوید حدود ۴۳٪ از کل سایت‌های وب با وردپرس ساخته شدهاند (تاریخ گردآوری: آبان ۱۴۰۵)؛ یعنی سهم بزرگی از بازدیدهای روزانهٔ وب، هر بار همان فایلهای قالب و افزونه را از اول دانلود میکنند، در حالی که میشود یک بار دانلود کرد و ماه‌ها از آن استفاده کرد. در گزارش‌های ابزارهای سرعت هم ردپایش همان‌جاست: فهرست بلند فایلهای بدون هدر کش.
پیش از شروع، مرز با دو مقالهٔ خانواده را روشن کنیم: بهینه‌سازی خط لولهٔ رندر صفحه سراغ مسیر رندر و اولویت منابع می‌رود؛ این مقاله سراغ حافظهٔ نهان سمت مرورگر. راهنمای کش وردپرس در سمت سرور و افزونه هم کش سمت سرور و افزونه را باز کرده؛ این‌جا لایهٔ بعدی همان زنجیره است. هیچ‌کدام جای دیگری را نمیگیرد؛ سایت سریع معمولاً هر سه لایه را با هم درست بسته است، چون کندی تک‌علتی نیست.
کش مرورگر چیست و چه فرقی با کش سرور دارد؟
اولین بازدید یک کاربر همه‌چیز را از صفر میگیرد: سند HTML، برگهٔ سبک، اسکریپت‌ها، تصاویر و فونت‌ها. مرورگر می‌تواند از هر فایلی که سرور برایش «قابل نگهداری» اعلام کند یک کپی محلی نگه دارد؛ در بازدید بعدی، پیش از دانلود، انبار محلی خودش را می‌گردد و اگر کپی معتبری پیدا کند، درخواست شبکه اصلاً زاده نمیشود. هم کاربر صرفه‌جویی میکند، هم سرور شما.
تفاوت با کش سرور جای کار است: کش سمت سرور مشترک است و HTML آماده را زودتر تحویل میدهد تا PHP و دیتابیس دوباره کار نکنند؛ کش سمت مرورگر شخصی است، روی دستگاه هر کاربر ساخته میشود و سراغ فایلهای ثابت می‌رود نه صفحهٔ پویا. به تجربهٔ ما هر سایت به هر دو نیاز دارد، چون حذف هر کدام هزینهٔ خودش را در گزارش سرعت نشان میدهد.
مقاله‌های این حوزه را در هاب سرعت و کارایی وردپرس یک‌جا مرتب نگه داشته‌ایم؛ این مقاله فقط لایهٔ مرورگر را عمیق باز میکند و لایه‌های دیگر را مرزی معرفی میکند.
هدرهای Cache-Control و Expires هر کدام چه می‌گویند؟
هدر Cache-Control زبان مشترک سرور و مرورگر برای مدیریت این انبار است. max-age=31536000 یعنی پاسخ حدود یک سال بدون پرسیدن دوباره معتبر است؛ no-cache معنی «استفاده ممنوع» ندارد، یعنی «قبل از مصرف از سرور بپرس نسخهٔ تازه‌تری هست یا نه»؛ و no-store یعنی اصلاً ذخیره نکن. پسوند public یا private هم می‌گوید حافظه‌های میانی مثل پروکسی حق نگهداری دارند یا فقط دستگاه کاربر.
هدر Expires نسل قدیمی‌تر است و به‌جای عمر نسبی، تاریخ و ساعت مطلق اعلام میکند؛ وقتی Cache-Control حضور دارد اولویت با آن است و Expires بیشتر برای سازگاری با ابزارهای قدیمی همراهش می‌آید. طبق مشخصهٔ HTTP این اولویت قراردادی است و در اجرا هم مرورگرهای مدرن عملاً سراغ Expires نمی‌روند مگر Cache-Control غایب باشد.
نکتهٔ سازمانی این است که این هدر را سرور می‌فرستد، نه مرورگر؛ کنترل کامل دست شما یا هاست شماست. به تجربهٔ ما بیشترین جایی که تنظیم‌ها بی‌اثر می‌ماند لایهٔ وب‌سرور است، چون قاعدهٔ سراسری هاست خروجی افزونه را بازنویسی میکند؛ پس اول هدر فعلی پاسخ را ببینید، بعد سراغ لایهٔ تنظیم بروید.
چه فایل‌هایی کش شوند و چقدر بمانند؟
یک عمر واحد برای همهٔ فایلها درست نیست؛ عمر هر فایل باید به سرعت تغییرش نزدیک باشد. سند HTML محتوای زنده است و کش طولانی برایش یعنی نسخهٔ کهنه برای کاربر وفادار؛ برعکس، فونت و فایلهای ثابت سال‌ها تغییر نمی‌کنند و کش بلند برایشان هدیه است. جدول زیر همان قرارداد اجرایی ماست.
| نوع فایل | عمر پیشنهادی | چرا |
|---|---|---|
| HTML صفحات | کوتاه؛ چند ثانیه تا چند دقیقه | محتوا تغییر میکند و کش طولانی نسخهٔ کهنه نشان میدهد |
| CSS و جاوااسکریپت | حدود یک سال، با نسخهگذاری نام فایل | با هر تغییر نام فایل عوض میشود و کش جدید میگیرد |
| تصاویر آپلودی | از ۳۰ روز تا یک سال | پس از انتشار کم‌تغییرند و حجم سنگین درخواست‌ها هستند |
| فونت‌ها | حدود یک سال | به‌ندرت عوض می‌شوند و دانلود دوباره‌شان گران است |
این عمرها قرارداد رایج مهندسی وب و تجربهٔ اجرای ماست؛ مرز نهایی هر سایت را تست خودش تعیین میکند.
شرط امن ماندن کش طولانی برای CSS و جاوااسکریپت، نسخهگذاری است: وقتی محتوای فایل عوض شد، نام یا پارامتر نسخهٔ آن در نشانی عوض شود تا مرورگر آن را فایل تازه‌ای ببیند. وردپرس همین کار را با پارامتر نسخه انجام میدهد؛ بدون نسخهگذاری، کش بلند یعنی کاربرانی که ماه‌ها نسخهٔ قدیمی می‌بینند و این خطر از کندی جدی‌تر است.
کش افزونهٔ وردپرس و کش سمت مرورگر؛ مرز وظایف
افزونه‌های کش وردپرس معمولاً چند کار با هم انجام می‌دهند: ساخت HTML استاتیک در سمت سرور، فشرده‌سازی، کوچک‌سازی فایلها — و تنظیم هدرهای مرورگر. دقت کنید هدر فقط یک دستورالعمل است؛ نگه‌داشتن کپی را خود مرورگر انجام میدهد. پس «نصب افزونهٔ کش» یعنی «ارسال هدر درست»، نه چیز بیشتر.
اشتباه رایج این فرض است که با نصب افزونه کار تمام شده. بعضی افزونه‌ها به‌صورت پیش‌فرض هدرهای مرورگر را فعال نمی‌کنند و بعضی هاست‌ها خروجی افزونه را با قاعدهٔ خودشان بازنویسی میکنند؛ نتیجه سایتی است که مدیرش فکر میکند کش مرورگر دارد و گزارش ابزار سرعت خلافش را می‌گوید. راه‌حل، اعتبارسنجی است که در بخش ششم آمده.
یک لایهٔ دیگر هم مرز را کامل میکند: اگر جلوی سایت CDN نشسته باشد، آن شبکه کش مخصوص خودش را در نقاط میانی می‌سازد؛ جدا از کش مرورگر و با داستان تنظیم خودش. مقایسهٔ کامل CDN برای سایت‌های ایرانی همین انتخاب را با عدد باز کرده؛ این‌جا فقط همین‌قدر بگوییم هدر شما به CDN هم می‌رسد و قاعدهٔ بد در لایهٔ بالا همان‌جا هم تکرار میشود.
تنظیم با و بدون افزونه؛ از htaccess تا پنل هاست
بدون افزونه هم مسیر باز است و در بعضی هاست‌ها تمیزتر. روی آپاچی، تنظیم با ماژول‌های mod_expires و mod_headers در فایل htaccess انجام میشود: قاعده‌ای برای پسوندهای ثابت مثل تصویر و فونت با max-age حدود یک سال، و قاعده‌ای برای سند HTML با max-age کوتاه یا no-cache. منطق دو خط است؛ سختی در دقت نگارش و جای درست قواعد است.
روی Nginx به‌جای htaccess، بلوک location برای پسوندهای استاتیک می‌نویسید و expires را همان‌جا ست می‌کنید. دو هشدار: وردپرس خودش این هدرها را نمی‌فرستد، کار وب‌سرور است؛ و پیش از دست‌زدن به این فایلها نسخهٔ پشتیبان بگیرید، چون یک غلط نگارشی می‌تواند کل سایت را از دسترس خارج کند و بازیابی آن ساعت‌ها وقت میبرد.
در هاست‌های اشتراکی گاهی هاست خودش هدرهای سراسری ست کرده؛ اضافه‌کردن قاعدهٔ موازی یعنی دو مقدار متناقض در پاسخ و رفتار متفاوت مرورگرها. ترتیب درست: اول وضعیت فعلی را با روش بخش بعد ثبت کنید، بعد تصمیم بگیرید قاعدهٔ موجود را ویرایش کنید یا قاعدهٔ تازه بنویسید.
اعتبارسنجی بعد از تغییر؛ چطور مطمئن شویم هدرها اعمال شدهاند؟
اعتبارسنجی یعنی دیدن هدر واقعی، نه حدس زدن آن. مسیر ساده در کروم: بازکردن ابزار توسعه‌دهنده‌ها با F12، رفتن به تب Network، بارگذاری دوبارهٔ صفحه، انتخاب یک فایل CSS و خواندن بخش Response Headers؛ دنبال مقدار cache-control می‌گردید. برای حذف اثر کش قبلی، صفحه را در پنجرهٔ ناشناس باز کنید یا با بازخوانی سخت تست بگیرید.
بعد از تست هدر، گزارش «کش مرورگر» ابزارهای سرعت را دوباره بخوانید؛ فهرست فایلهای بدون هدر باید کوتاه شده باشد. یک تفکیک را هم نگه دارید: بازدید اول تقریباً هیچ بهبودی نشان نمی‌دهد چون هنوز چیزی در انبار نیست؛ تفاوت در بازدید دوم و سوم است. پس سنجش را سرد و گرم جدا کنید تا عدد داستان درست را بگوید.
بعد از هر تغییر هم قاعده بسازید: هر تغییر جدا اعمال شود، جدا اعتبارسنجی شود و نتیجه در دفتر نگهداری ثبت شود. تغییرهای گروهی وقتی چیزی خراب شود، تشخیص مقصر را دشوار میکنند؛ تک‌تغییر و تک‌تست بازگشت‌پذیری ساده‌تری دارد.
جمع‌بندی؛ اشتباه‌های رایج و ترتیب کاری یک هفته
چهار اشتباه بیشتر از نبودِ خود هدرها آسیب می‌زند. یکی، کش طولانی روی سند HTML؛ کاربر وفادار نسخهٔ کهنه می‌بیند و شما خبردار نمی‌شوید. دو، نسخهگذاری نکردن فایلهای متغیر؛ قالب آپدیت میشود و بازدیدکننده با سبک نیمه‌شکسته روبه‌رو میشود. سه، کش کردن صفحات خصوصی مثل سبد خرید و حساب کاربری؛ این‌جا بحث سرعت نیست، درستی است. چهار، اعمال تغییر بدون اعتبارسنجی؛ فرض می‌ماند کار انجام شده و نیست. اشتباه مقابل هم هست: خالی‌کردن همهٔ کش‌ها به‌خاطر یک مورد، که سایت را برای همهٔ بازدیدکنندگان کند میکند؛ راه بهتر تفکیک و مستثناکردن است.
یک مرز انتظار هم صادقانه بگوییم: کش مرورگر بازدید دوم را بهتر میکند، نه بازدید اول را؛ کاربر تازه هنوز چیزی در انبارش ندارد. برای همان مسیر اول سراغ لایه‌های دیگر سرعت بروید؛ رندر و اولویت منابع، همان مسیری است که مقالهٔ خواهر این راهنما باز کرده است. کش مرورگر جایگزین هیچ لایه‌ای نیست، مکمل همهٔ آن‌هاست.
ترتیب کاری یک هفته‌ای: روز اول ثبت وضعیت هدرها برای چند فایل نمونه؛ روز دوم قاعدهٔ فایلهای ثابت با نسخهگذاری؛ روز سوم قاعدهٔ HTML کوتاه؛ روز چهارم اعتبارسنجی و تست سرد و گرم؛ روز پنجم ثبت نتایج در دفتر نگهداری. و اگر زیرساختی می‌خواهید که این لایه‌ها را پایش و منتشر کند، قابلیت‌های پلتفرم همین مسیر را پوشش میدهد و تعرفهٔ پلن‌های سوئیت مقیاس هر پلن را روشن میکند؛ دموی رایگان در فراخوان پایین نقطهٔ شروع کم‌ریسک است.
رصد ما، رشد شما.
سؤالات پرتکرار
کش مرورگر با کش افزونهٔ وردپرس چه فرقی دارد؟
کش افزونه در سمت سرور کار میکند و HTML آماده را به همهٔ بازدیدکنندگان میدهد؛ کش مرورگر روی دستگاه هر کاربر ساخته میشود و فایلهای ثابت را برای بازدید بعدی نگه میدارد. هر دو لازماند و یکی جای دیگری را نمیگیرد.
برای فایلهای CSS و جاوااسکریپت چقدر کش بگذارم؟
به تجربهٔ ما max-age حدود یک سال همراه با نسخهگذاری نام فایل، تعادل درستی است؛ فایل تغییر کرد، نامش عوض میشود و مرورگر نسخهٔ تازه را میگیرد. بدون نسخهگذاری، کش طولانی نسخهٔ کهنه نشان میدهد.
کش مرورگر مستقیماً رتبهٔ سئو را بالا میبرد؟
وعدهٔ مستقیمی نمیشود داد؛ اثرش از مسیر سرعت بازدیدهای بعدی و تجربهٔ کاربر میگذرد. چیزی که قطعی است، حذف درخواستهای تکراری شبکه در بازدید دوم است که هم کاربر و هم سرور حسش میکنند.
از کجا بفهمم هدرهای کش اعمال شدهاند؟
در ابزار توسعهدهندهٔ مرورگر، تب Network، یک فایل CSS را انتخاب کنید و در Response Headers مقدار cache-control را ببینید. تست را در پنجرهٔ ناشناس و با بازخوانی سخت بگیرید تا اثر کش قبلی نتیجه را خراب نکند.
اگر فایلها را یک سال کش کنم، کاربران نسخهٔ قدیمی نمیبینند؟
تنها اگر نسخهگذاری نکنید. وقتی با هر تغییر، نام یا پارامتر نسخهٔ فایل عوض شود، نشانی جدید برای مرورگر یعنی فایل جدید؛ همین سازوکار است که عمر بلند را امن میکند.
