رفع خطای کش در GTmetrix با بررسی پاسخ واقعی فایل آغاز می‌شود. Specify a cache validator و Configure entity tags نام‌هایی آشنا در گزارش‌های قدیمی‌اند؛ برای گزارش فعلی باید مسئلهٔ همان درخواست را بررسی کنید. افزودن یک دستور یکسان به همهٔ صفحات، راه‌حل عمومی نیست.
تازگی کش با اعتبارسنجی تفاوت دارد
طبق راهنمای کش HTTP، مرورگر می‌تواند پاسخ ذخیره‌شده‌ای را که هنوز تازه است، بدون درخواست دوباره استفاده کند. Cache-Control با max-age مدت تازگی را بر حسب ثانیه مشخص می‌کند. Expires تاریخ و ساعت انقضاست؛ در حضور max-age معتبر، آن دستور بر Expires اولویت دارد.
وقتی پاسخ نیازمند اعتبارسنجی باشد، مرورگر می‌تواند ETag قبلی را در If-None-Match یا زمان Last-Modified را در If-Modified-Since بفرستد. اگر منبع مطابق شرط تغییری نکرده باشد، پاسخ 304 بدون بدنهٔ کامل امکان استفاده از نسخهٔ ذخیره‌شده را می‌دهد. برای نسخهٔ تغییرکرده معمولاً پاسخ تازه همراه محتوا دریافت می‌شود.
ETag چیست و چگونه باید ساخته شود؟
ETag شناسهٔ نسخهٔ یک نمایش از منبع است. این مقدار الزاماً MD5 نیست و روش تولید آن به سرور یا برنامه بستگی دارد. یک رشتهٔ ثابت برای تمام فایل‌ها یا نسخه‌های تغییرکرده، اعتبارسنجی درستی ایجاد نمی‌کند. فایل فشرده و غیرفشرده و خروجی متفاوت برنامه نیز باید متناسب با معنای اعتبارسنج خود مدیریت شوند.
Last-Modified باید زمان تغییر معتبر منبع را نشان دهد؛ قرار دادن زمان فعلی در هر پاسخ، معادل تشخیص تغییر واقعی نیست. لازم نیست تمام پاسخ‌های سایت الزاماً هر دو هدر را داشته باشند. معیار، سیاست صحیح برای نوع منبع و رفتار پاسخ‌دهنده است، نه اضافه‌کردن هدر برای خاموش‌شدن یک هشدار.
رفع خطای کش در GTmetrix بر اساس نوع فایل
برای فایل عمومی ثابت، مدت تازگی متناسب با روش به‌روزرسانی انتخاب کنید. فایل دارای نام نسخه‌دار یا هش محتوا می‌تواند سیاست طولانی‌تری داشته باشد، به شرط آنکه هنگام تغییر محتوا نام فایل هم تغییر کند. دستور immutable را بدون این شرط روی فایل قابل‌تغییر با نشانی ثابت اعمال نکنید.
سبد خرید، حساب کاربری و پاسخ شخصی با تصویر عمومی یکسان نیستند. در Cache-Control، private ذخیره در کش مشترک را منع می‌کند. no-cache به معنی ممنوعیت ذخیره نیست؛ استفادهٔ دوباره نیازمند اعتبارسنجی است. no-store دستور ذخیره‌نکردن پاسخ است و به‌خودی‌خود تمام نسخه‌های قدیمی موجود را پاک نمی‌کند.
هدر را در کدام لایه اصلاح کنیم؟
ببینید فایل را وب‌سرور، برنامه، افزونه یا CDN تحویل می‌دهد. تنظیم همان لایه اهمیت دارد. Nginx فایل htaccess را اجرا نمی‌کند و یک قانون Apache ممکن است برای خروجی برنامه یا CDN کافی نباشد. تغییر سرور مبدأ را با پاسخ نهایی دریافت‌شده توسط کاربر تطبیق دهید.
برای منابع بیرونی که مدیریت نمی‌کنید، هدرهای میزبان خودتان پاسخ آن سرویس را عوض نمی‌کند. امکان حذف وابستگی، جایگزینی مجاز یا تماس با ارائه‌دهنده را بررسی کنید. غیرفعال‌کردن سراسری ETag نیز درمان عمومی اختلاف میان چند سرور نیست؛ تولید سازگار اعتبارسنج‌ها و تنظیم کش باید بررسی شود.
آزمون نتیجه بدون برداشت اشتباه
در Network مرورگر، URL و Response Headers فایل را ببینید. نخستین دریافت را از دریافت مجدد و درخواست شرطی پس از نیاز به اعتبارسنجی جدا کنید. فعال‌بودن Disable cache در ابزار توسعه می‌تواند رفتار آزمون را تغییر دهد. انتظار نداشته باشید هر بار حتماً 304 ببینید؛ پاسخ تازه ممکن است اصلاً به شبکه نرود.
در پایان، تغییر فایل باید نسخهٔ جدید را در زمان مورد انتظار به کاربر برساند و دادهٔ خصوصی وارد کش عمومی نشود. هدف کاهش انتقال غیرضروری با حفظ صحت و محرمانگی پاسخ است. برای همین، سیاست کش را بر اساس نوع منبع انتخاب کنید و فقط به یک امتیاز کلی تکیه نکنید.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
