کش مرورگر با Cache-Control و ETag: تنظیم و آزمون درست

برای هر پاسخ، سیاست کش مناسب انتخاب کنید

کش مرورگر به بازدید دوباره کمک می‌کند، اما همهٔ پاسخ‌ها را نباید یکسان ذخیره کرد. یک فایل CSS با نام مبتنی بر هش می‌تواند عمر طولانی داشته باشد؛ صفحهٔ حساب کاربر و پاسخ سفارش، سیاست دیگری می‌خواهند. ابتدا نوع پاسخ و نیاز به تازگی را مشخص کنید، سپس هدر را روی همان پاسخ تنظیم و آزمون کنید.

پنج دستور مهم Cache-Control

• max-age: مدت تازه‌بودن پاسخ بر حسب ثانیه؛ کش مرورگر از آن استفاده می‌کند.
• s-maxage: عمر پاسخ در کش مشترک مانند CDN؛ برای کش مشترک بر max-age مقدم است و مرورگر آن را نادیده می‌گیرد.
• no-cache: ذخیره مجاز است، ولی پیش از استفادهٔ دوباره باید اعتبارسنجی شود.
• no-store: پاسخ در کش HTTP ذخیره نشود؛ برای داده‌ای که نباید ذخیره شود به کار می‌رود.
• private: کش مشترک نباید پاسخ را ذخیره کند؛ به معنی ممنوعیت کش مرورگر نیست.

جزئیات این دستورها در مرجع Cache-Control در MDN آمده است. مرورگر max-age را به‌دلیل حضور s-maxage کنار نمی‌گذارد. همچنین private به تنهایی مانع ذخیرهٔ اطلاعات حساس روی دستگاه کاربر نمی‌شود.

سه سیاست نمونه، با محدودهٔ استفاده

# فایل عمومی با URL ثابت برای محتوای ثابت؛ مثلاً app.a81c9.css
Cache-Control: public, max-age=31536000, immutable

# HTML عمومی که پیش از استفادهٔ دوباره باید بررسی شود
Cache-Control: no-cache

# پاسخ حساب یا سفارش که نباید در کش HTTP ذخیره شود
Cache-Control: private, no-store

این‌ها نمونهٔ سیاست‌اند، نه تنظیم واحد برای همهٔ سایت‌ها. immutable به مرورگر می‌گوید پاسخ تازه تغییر نمی‌کند؛ بعد از پایان عمر کش، به معنی «هیچ‌وقت بررسی نکن» نیست. آن را فقط برای URLی به کار ببرید که محتوایش در همان URL تغییر نمی‌کند. نسخه در نام یا query باید واقعاً عوض شود و CDN نیز آن را در کلید کش لحاظ کند.

تصاویر و فونت‌ها هم به نسخه‌بندی نیاز دارند. اینکه یک فونت به‌ندرت تغییر می‌کند، دلیل کافی برای کش یک‌سالهٔ immutable روی URL قابل تغییر نیست. HTML حاوی نشست یا اطلاعات شخصی را با public کش نکنید؛ داشتن CDN این خطر را برطرف نمی‌کند.

ETag و پاسخ ۳۰۴ چه می‌کنند؟

سرور می‌تواند شناسهٔ نسخهٔ پاسخ را در ETag بفرستد. مرورگر هنگام اعتبارسنجی، آن را در If-None-Match برمی‌گرداند. اگر نسخه تغییر نکرده باشد، سرور پاسخ ۳۰۴ بدون بدنه می‌دهد؛ هنوز یک رفت‌وبرگشت شبکه وجود دارد. Last-Modified و If-Modified-Since نیز روش اعتبارسنجی دیگری‌اند؛ ETag تنها راه ممکن نیست.

پاسخ تازه ممکن است مستقیماً از memory cache یا disk cache استفاده شود و اصلاً به سرور نرسد. بنابراین توالی ثابت «بار دوم ۳۰۴، بار سوم صفر درخواست» وجود ندارد. برعکس، دیدن ۲۰۰ در ابزار مرورگر به‌تنهایی اثبات نبود کش نیست؛ ستون انتقال و جزئیات منبع را هم بخوانید.

آزمون قابل تکرار با curl و مرورگر

curl -sS -D - -o /dev/null https://example.com/assets/app.a81c9.css
curl -sS -D - -o /dev/null -H 'If-None-Match: "ETAG-FROM-FIRST-RESPONSE"' https://example.com/assets/app.a81c9.css

دامنه و مسیر مثال را با فایل واقعی خودتان جایگزین کنید؛ در دستور دوم ETag واقعی را دقیقاً با نقل‌قولش بگذارید. درخواست GET بدنه را دور می‌ریزد و هدرها را نگه می‌دارد. این روش برای بررسی endpointهایی که رفتار HEAD متفاوت دارند مفید است. اگر نسخه عوض نشده باشد و سرور درخواست شرطی را پشتیبانی کند، انتظار ۳۰۴ دارید.

1. در Network مرورگر، «Disable cache» را خاموش کنید؛ بار اول را ثبت کنید.
2. با همان پروفایل، دوباره به صفحه بروید و transferred bytes، Age، Cache-Control و عبارت memory/disk cache را مقایسه کنید.
3. فقط یک فایل آزمایشی را با URL جدید منتشر کنید و بررسی کنید HTML به نسخهٔ جدید اشاره می‌کند.
4. پاسخ CDN و origin ممکن است فرق کنند؛ هدر نهاییِ رسیده به کاربر را ملاک قرار دهید.

حالت ناشناس الزاماً کش را غیرفعال نمی‌کند؛ کش آن از پروفایل عادی جدا و عمرش محدود به نشست است. hard reload و فعال‌بودن Disable cache نیز شرایط آزمون را تغییر می‌دهند. هدر Age صفر یا نبود آن به‌تنهایی پاسخ قطعی دربارهٔ کش مرورگر نیست.

انتشار و بازگشت بدون گیرکردن نسخهٔ قدیمی

پیش از تغییر، هدر فعلی و URL یک نمونه را ثبت کنید. سیاست را فقط روی مسیرهای مشخصِ فایل‌های عمومی اعمال کنید؛ یک قاعدهٔ کلی روی همهٔ پاسخ‌ها نگذارید. فایل جدید را پیش از HTML ارجاع‌دهنده منتشر کنید و نسخهٔ قبلی را مدتی نگه دارید تا صفحهٔ کش‌شده لینک شکسته نگیرد. اگر پاسخ شخصی از کش مشترک سرو شد، مسیر مربوط را از کش خارج کنید و محتوای ذخیره‌شدهٔ آن را نیز پاک کنید؛ تغییر هدر به تنهایی نسخهٔ قبلاً ذخیره‌شده را حذف نمی‌کند.

اگر کش درست است، چرا سایت هنوز کند است؟

کش مرورگر، پاسخ کند HTML، فونت اولین بازدید یا اجرای سنگین جاوااسکریپت را الزاماً رفع نمی‌کند. درصد ثابتی برای بهبود همهٔ سایت‌ها وجود ندارد. بایت منتقل‌شده، زمان بازدید سرد و گرم و LCP را جدا ثبت کنید. سپس از فرآیند عیب‌یابی سایت کند و راهنمای سنجش تجربهٔ واقعی کاربران برای تعیین گلوگاه بعدی استفاده کنید.