واکشی منابع از طریق شبکه هم کند و هم گران است:
- پاسخ های بزرگ نیازمند رفت و برگشت های زیادی بین مرورگر و سرور است.
- صفحه شما تا زمانی که تمام منابع حیاتی آن به طور کامل دانلود نشوند بارگیری نمی شود.
- اگر کاربر در سایت شما دارای یک برنامه داده تلفن همراه محدود است، هر درخواست شبکه غیرضروری پول او را هدر می دهد.
چگونه می توانید از درخواست های غیر ضروری شبکه جلوگیری کنید؟ حافظه پنهان HTTP مرورگر اولین خط دفاعی شماست. این لزوماً قدرتمندترین یا منعطف ترین رویکرد نیست و شما کنترل محدودی بر طول عمر پاسخ های حافظه پنهان دارید، اما مؤثر است، در همه مرورگرها پشتیبانی می شود و به کار زیادی نیاز ندارد.
این راهنما به شما اصول اولیه اجرای موثر حافظه پنهان HTTP را نشان می دهد.
سازگاری با مرورگر
HTTP Cache نام کلی مجموعه ای از API های پلتفرم وب است که در همه مرورگرها پشتیبانی می شوند:
Cache-Control
ETag
Last-Modified
نحوه عملکرد کش HTTP
تمام درخواست‌های HTTP که مرورگر می‌کند ابتدا به حافظه پنهان مرورگر هدایت می‌شوند تا بررسی شود که آیا یک پاسخ ذخیره‌شده معتبر وجود دارد که می‌تواند برای انجام درخواست استفاده شود. اگر مطابقت وجود داشته باشد، پاسخ از حافظه پنهان خوانده می شود، که هم تاخیر شبکه و هم هزینه های انتقال داده را حذف می کند.
رفتار حافظه پنهان HTTP توسط ترکیبی از سرصفحه‌های درخواست و سرصفحه‌های پاسخ کنترل می‌شود. در یک سناریوی ایده آل، شما هم روی کد برنامه وب خود که هدرهای درخواست را تعیین می کند و هم بر پیکربندی وب سرور خود که هدرهای پاسخ را تعیین می کند، کنترل دارید.
برای یک مرور مفهومی عمیق تر، به مقاله HTTP Caching MDN مراجعه کنید.
سرصفحه های درخواست: به پیش فرض ها پایبند باشید (معمولا)
تعدادی هدر مهم وجود دارد که باید در درخواست‌های خروجی برنامه وب شما گنجانده شود، اما مرورگر تقریباً همیشه هنگام درخواست از طرف شما، آنها را تنظیم می‌کند. هدرهای درخواستی که بر بررسی تازگی تأثیر می گذارند، مانند If-None-Match و If-Modified-Since بر اساس درک مرورگر از مقادیر فعلی در حافظه پنهان HTTP ظاهر می شوند.
این خبر خوبی است: به این معنی است که می‌توانید به اضافه کردن برچسب‌هایی مانند <img src="my-image.png"> در HTML خود ادامه دهید، و مرورگر به طور خودکار از ذخیره HTTP بدون تلاش اضافی مراقبت می‌کند.
هدرهای پاسخ: وب سرور خود را پیکربندی کنید
بخشی از راه‌اندازی حافظه پنهان HTTP که بیشترین اهمیت را دارد هدرهایی است که وب سرور شما به هر پاسخ خروجی اضافه می‌کند. هدرهای زیر همگی در رفتار موثر در حافظه پنهان نقش دارند:
-
Cache-Control - سرور می‌تواند یک دستورالعمل
Cache-Controlرا برای تعیین اینکه مرورگر و سایر حافظه‌های نهان میانی چگونه و برای چه مدت پاسخ فردی را در حافظه پنهان نگه دارند، بازگرداند. -
ETag - هنگامی که مرورگر پاسخ حافظه پنهان منقضی شده را پیدا می کند، می تواند یک توکن کوچک (معمولاً هش محتوای فایل) را به سرور ارسال کند تا بررسی کند که آیا فایل تغییر کرده است یا خیر. اگر سرور همان رمز را برگرداند، پس فایل همان است و نیازی به دانلود مجدد آن نیست.
-
Last-Modified - این هدر همان هدف
ETagرا انجام می دهد، اما از یک استراتژی مبتنی بر زمان برای تعیین اینکه آیا یک منبع تغییر کرده است یا خیر، بر خلاف استراتژی مبتنی بر محتواETagاستفاده می کند.
برخی از سرورهای وب دارای پشتیبانی داخلی برای تنظیم آن هدرها به صورت پیش فرض هستند. برخی دیگر سرصفحه ها را به طور کامل حذف می کنند مگر اینکه شما به صراحت آنها را پیکربندی کنید. جزئیات خاص نحوه پیکربندی هدرها بسته به وب سروری که استفاده می کنید بسیار متفاوت است، و برای دریافت دقیق ترین جزئیات باید به اسناد سرور خود مراجعه کنید.
برای صرفه جویی در جستجوی شما، در اینجا دستورالعمل هایی برای پیکربندی چند وب سرور محبوب آورده شده است:
حذف هدر پاسخ Cache-Control ، ذخیره HTTP را غیرفعال نمی کند! درعوض، مرورگرها به طور موثر حدس می‌زنند که چه نوع رفتار ذخیره‌سازی برای یک نوع محتوا بیشتر منطقی است. به احتمال زیاد کنترل بیشتری نسبت به پیشنهادات می‌خواهید، بنابراین باید برای پیکربندی سرصفحه‌های پاسخ خود وقت بگذارید.
از کدام مقادیر سرصفحه پاسخ باید استفاده کنید؟
دو سناریو مهم وجود دارد که هنگام پیکربندی هدرهای پاسخ سرور وب خود باید آنها را پوشش دهید.
ذخیره طولانی مدت برای URL های نسخه شده
فرض کنید سرور شما به مرورگرها دستور می دهد تا یک فایل CSS را به مدت 1 سال کش کنند ( Cache-Control: max-age=31536000 ) اما طراح شما به تازگی یک به روز رسانی اضطراری ایجاد کرده است که باید فوراً آن را پیاده سازی کنید. چگونه به مرورگرها اطلاع می‌دهید که کپی ذخیره شده «بیات شده» فایل را به‌روزرسانی کنند؟ شما نمی توانید، حداقل بدون تغییر URL منبع.
پس از اینکه مرورگر پاسخ را در حافظه پنهان ذخیره کرد، نسخه ذخیره شده در حافظه پنهان تا زمانی استفاده می شود که دیگر تازه نباشد، همانطور که max-age تعیین می شود یا expires ، یا تا زمانی که به دلایل دیگری از حافظه پنهان خارج شود، مانند پاک کردن حافظه پنهان مرورگر توسط کاربر. در نتیجه، کاربران مختلف ممکن است هنگام ساخت صفحه، نسخه‌های مختلفی از فایل را بارگیری کنند: کاربرانی که به تازگی منبع را واکشی کرده‌اند از نسخه جدید استفاده می‌کنند، اما کاربرانی که نسخه قبلی (اما هنوز معتبر) را در حافظه پنهان ذخیره کرده‌اند، از نسخه قدیمی‌تر استفاده می‌کنند.
برای دریافت حافظه پنهان سمت سرویس گیرنده و به‌روزرسانی‌های سریع، می‌توانید URL منبع را تغییر دهید و کاربر را مجبور کنید پاسخ جدید را هر زمان که محتوای آن تغییر کرد بارگیری کند. معمولاً، این کار را با جاسازی اثر انگشت فایل یا شماره نسخه در نام فایل آن انجام می‌دهید: برای مثال style.x234dff.css .
هنگام پاسخ به درخواست‌هایی برای نشانی‌های اینترنتی که حاوی اطلاعات « اثر انگشت » یا نسخه‌سازی هستند و محتوای آنها هرگز تغییر نمی‌کند، Cache-Control: max-age=31536000 به پاسخ‌های خود اضافه کنید.
تنظیم این مقدار به مرورگر می‌گوید که زمانی که نیاز به بارگیری همان URL در سال آینده داشته باشد (31,536,000 ثانیه، حداکثر مقدار پشتیبانی شده)، می‌تواند بلافاصله از مقدار موجود در حافظه پنهان HTTP استفاده کند، بدون اینکه نیازی به درخواست شبکه برای شما باشد. اصلا وب سرور این عالی است—شما فوراً قابلیت اطمینان و سرعتی را که از اجتناب از شبکه به دست می آید به دست آورده اید!
ابزارهای ساخت مانند بسته وب می‌توانند فرآیند اختصاص اثر انگشت هش به URL دارایی شما را خودکار کنند .
اعتبار سنجی مجدد سرور برای URL های بدون نسخه
متأسفانه، همه URL هایی که بارگیری می کنید نسخه بندی نشده اند. شاید نتوانید قبل از استقرار برنامه وب خود یک مرحله ساخت اضافه کنید، بنابراین نمی توانید هش را به URL دارایی خود اضافه کنید. و هر برنامه وب به فایل‌های HTML نیاز دارد، که تقریباً هرگز شامل اطلاعات نسخه‌سازی نمی‌شود، زیرا هیچ‌کس زحمت استفاده از برنامه وب شما را به خود نمی‌دهد اگر لازم باشد به یاد داشته باشد که URL بازدیدکننده https://example.com/index.34def12.html است. بنابراین چه کاری می توانید برای آن URL ها انجام دهید؟
حافظه پنهان HTTP به تنهایی آنقدر قدرتمند نیست که از شبکه کاملاً اجتناب کند. (نگران نباشید - به زودی در مورد کارگران خدماتی که پشتیبانی بیشتری را ارائه می دهند، یاد خواهید گرفت.) اما چند مرحله وجود دارد که می توانید برای اطمینان از اینکه درخواست های شبکه تا حد امکان سریع و کارآمد هستند انجام دهید.
مقادیر Cache-Control زیر می‌تواند به شما کمک کند تا مکان و نحوه ذخیره‌سازی URLهای بدون نسخه را به دقت تنظیم کنید:
-
no-cacheبه مرورگر می‌گوید که قبل از استفاده از نسخه کش URL، هر بار باید مجدداً با سرور اعتبارسنجی کند. -
no-storeبه مرورگر و دیگر کش های میانی (مانند CDN) می گوید که هرگز هیچ نسخه ای از فایل را ذخیره نکنند. -
private: مرورگرها می توانند فایل را کش کنند اما کش های میانی نمی توانند. -
public: هر کش می تواند پاسخ را ذخیره کند.
به پیوست: فلوچارت Cache-Control مراجعه کنید تا فرآیند تصمیم گیری از کدام مقدار(های) Cache-Control استفاده شود. Cache-Control همچنین می‌تواند فهرست دستورالعمل‌های جدا شده با کاما را بپذیرد. به پیوست مراجعه کنید: نمونه‌های Cache-Control .
تنظیم ETag یا Last-Modified نیز می تواند کمک کننده باشد. همانطور که در سرصفحه‌های Response ذکر شد، ETag و Last-Modified هر دو هدف یکسانی را دنبال می‌کنند: تعیین اینکه آیا مرورگر نیاز به بارگیری مجدد یک فایل کش که منقضی شده است یا خیر. توصیه می کنیم از ETag استفاده کنید زیرا دقیق تر است.
فرض کنید 120 ثانیه از واکشی اولیه گذشته است و مرورگر درخواست جدیدی را برای همان منبع آغاز کرده است. ابتدا مرورگر حافظه پنهان HTTP را بررسی می کند و پاسخ قبلی را پیدا می کند. متأسفانه مرورگر نمی تواند از پاسخ قبلی استفاده کند زیرا منقضی شده است. در این مرحله، مرورگر می تواند یک درخواست جدید ارسال کند و پاسخ کامل جدید را دریافت کند. با این حال، این ناکارآمد است زیرا اگر منبع تغییر نکرده باشد، دلیلی برای بارگیری مجدد اطلاعاتی که از قبل در حافظه پنهان است وجود ندارد.
این مشکلی است که توکن های اعتبارسنجی ETag برای حل آن طراحی شده اند. سرور یک توکن دلخواه را تولید و برمی گرداند که معمولاً هش یا اثر انگشت دیگری از محتویات فایل است. مرورگر نیازی به دانستن نحوه ایجاد اثر انگشت ندارد. فقط باید در درخواست بعدی آن را به سرور ارسال کند. اگر اثر انگشت همچنان یکسان است، منبع تغییر نکرده است و مرورگر می‌تواند از دانلود صرفنظر کند.
تنظیم ETag یا Last-Modified ، درخواست اعتبارسنجی مجدد را بسیار کارآمدتر می کند و به آن اجازه می دهد سرصفحه های درخواست If-Modified-Since یا If-None-Match ذکر شده در سرصفحه های درخواست را فعال کند.
وقتی یک سرور وب با پیکربندی مناسب آن سرصفحه‌های درخواست ورودی را می‌بیند، می‌تواند تأیید کند که آیا نسخه منبعی که مرورگر از قبل در حافظه پنهان HTTP خود دارد با آخرین نسخه در سرور وب مطابقت دارد یا خیر. اگر مطابقت وجود داشته باشد، سرور می‌تواند با یک پاسخ HTTP 304 Not Modified پاسخ دهد، که معادل «هی، به استفاده از آنچه قبلاً دریافت کرده‌ای ادامه بده!» هنگام ارسال این نوع پاسخ، داده‌های بسیار کمی برای انتقال وجود دارد، بنابراین معمولاً سریع‌تر از ارسال نسخه‌ای از منبع واقعی درخواستی است.
/file از سرور درخواست می‌کند و شامل سرصفحه If-None-Match می‌شود تا به سرور دستور دهد فقط در صورتی که ETag فایل روی سرور با مقدار If-None-Match مرورگر مطابقت نداشته باشد، فایل کامل را برگرداند. در این مورد، مقادیر مطابقت دارند، بنابراین سرور یک پاسخ 304 Not Modified را با دستورالعمل‌هایی برای مدت زمان بیشتری که فایل باید در حافظه پنهان بماند، برمی‌گرداند ( Cache-Control: max-age=120 ).خلاصه
حافظه پنهان HTTP یک راه موثر برای بهبود عملکرد بار است زیرا درخواست های غیر ضروری شبکه را کاهش می دهد. در همه مرورگرها پشتیبانی می‌شود و راه‌اندازی آن به کار زیادی نیاز ندارد.
پیکربندی‌های Cache-Control زیر شروع خوبی هستند:
-
Cache-Control: no-cacheبرای منابعی که باید قبل از هر استفاده مجدداً با سرور تأیید شوند. -
Cache-Control: no-storeبرای منابعی که هرگز نباید کش شوند. -
Cache-Control: max-age=31536000برای منابع نسخه شده.
سربرگ ETag یا Last-Modified می تواند به شما کمک کند تا منابع حافظه نهان منقضی شده را مجدداً اعتبارسنجی کنید.
بیشتر بدانید
اگر به دنبال فراتر رفتن از اصول اولیه استفاده از هدر Cache-Control هستید، بهترین شیوه های ذخیره سازی و راهنمای گچاهای حداکثر سنی جیک آرچیبالد را بررسی کنید.
برای راهنمایی در مورد نحوه بهینه سازی استفاده از حافظه پنهان برای بازدیدکنندگان بازگشتی، به Love your cache مراجعه کنید.
ضمیمه: نکات بیشتر
اگر زمان بیشتری دارید، در اینجا راه‌های بیشتری برای بهینه‌سازی استفاده از حافظه پنهان HTTP وجود دارد:
- از URL های ثابت استفاده کنید. اگر محتوای یکسانی را در URL های مختلف ارائه دهید، مرورگر آن محتوا را چندین بار واکشی و ذخیره می کند.
- ریزش را به حداقل برسانید. اگر بخشی از یک منبع (مانند یک فایل CSS) به‌طور مکرر به‌روزرسانی می‌شود، در حالی که بقیه فایل به‌روزرسانی نمی‌شود (مانند کدهای کتابخانه)، کدهایی که اغلب به‌روزرسانی می‌شوند را به یک فایل جداگانه تقسیم کنید و از یک استراتژی کش کوتاه مدت استفاده کنید. کدی که مکرراً به‌روزرسانی می‌شود، و یک استراتژی طولانی مدت حافظه پنهان برای کدهایی که اغلب تغییر نمی‌کنند.
- اگر درجه ای از کهنگی در خط مشی
Cache-Controlشما قابل قبول است، دستورالعمل جدیدstale-while-revalidateدر نظر بگیرید.
پیوست: فلوچارت Cache-Control
Cache-Control . ضمیمه: نمونه های Cache-Control
مقدار Cache-Control | توضیح |
|---|---|
max-age=86400 | پاسخ را می توان توسط مرورگرها و حافظه های پنهان واسطه ای تا یک روز (60 ثانیه در 60 دقیقه در 24 ساعت) در حافظه پنهان نگه داشت. |
private, max-age=600 | پاسخ را می توان توسط مرورگر ذخیره کرد، اما نه حافظه پنهان واسطه، تا ده دقیقه (60 ثانیه در 10 دقیقه). |
public, max-age=31536000 | پاسخ را می توان توسط هر کش به مدت یک سال ذخیره کرد. |
no-store | پاسخ را نمی توان در حافظه پنهان ذخیره کرد و باید در هر درخواست به طور کامل واکشی شود. |
واکشی منابع از طریق شبکه هم کند و هم گران است:
- پاسخ های بزرگ نیازمند رفت و برگشت های زیادی بین مرورگر و سرور است.
- صفحه شما تا زمانی که تمام منابع حیاتی آن به طور کامل دانلود نشوند بارگیری نمی شود.
- اگر کاربر در سایت شما دارای یک برنامه داده تلفن همراه محدود است، هر درخواست شبکه غیرضروری پول او را هدر می دهد.
چگونه می توانید از درخواست های غیر ضروری شبکه جلوگیری کنید؟ حافظه پنهان HTTP مرورگر اولین خط دفاعی شماست. این لزوماً قدرتمندترین یا منعطف ترین رویکرد نیست و شما کنترل محدودی بر طول عمر پاسخ های حافظه پنهان دارید، اما مؤثر است، در همه مرورگرها پشتیبانی می شود و به کار زیادی نیاز ندارد.
این راهنما به شما اصول اولیه اجرای موثر حافظه پنهان HTTP را نشان می دهد.
سازگاری با مرورگر
HTTP Cache نام کلی مجموعه ای از API های پلتفرم وب است که در همه مرورگرها پشتیبانی می شوند:
Cache-Control
ETag
Last-Modified
نحوه عملکرد کش HTTP
تمام درخواست‌های HTTP که مرورگر می‌کند ابتدا به حافظه پنهان مرورگر هدایت می‌شوند تا بررسی شود که آیا یک پاسخ ذخیره‌شده معتبر وجود دارد که می‌تواند برای انجام درخواست استفاده شود. اگر مطابقت وجود داشته باشد، پاسخ از حافظه پنهان خوانده می شود، که هم تاخیر شبکه و هم هزینه های انتقال داده را حذف می کند.
رفتار حافظه پنهان HTTP توسط ترکیبی از سرصفحه‌های درخواست و سرصفحه‌های پاسخ کنترل می‌شود. در یک سناریوی ایده آل، شما هم روی کد برنامه وب خود که هدرهای درخواست را تعیین می کند و هم بر پیکربندی وب سرور خود که هدرهای پاسخ را تعیین می کند، کنترل دارید.
برای یک مرور مفهومی عمیق تر، به مقاله HTTP Caching MDN مراجعه کنید.
سرصفحه های درخواست: به پیش فرض ها پایبند باشید (معمولا)
تعدادی هدر مهم وجود دارد که باید در درخواست‌های خروجی برنامه وب شما گنجانده شود، اما مرورگر تقریباً همیشه هنگام درخواست از طرف شما، آنها را تنظیم می‌کند. هدرهای درخواستی که بر بررسی تازگی تأثیر می گذارند، مانند If-None-Match و If-Modified-Since بر اساس درک مرورگر از مقادیر فعلی در حافظه پنهان HTTP ظاهر می شوند.
این خبر خوبی است: به این معنی است که می‌توانید به اضافه کردن برچسب‌هایی مانند <img src="my-image.png"> در HTML خود ادامه دهید، و مرورگر به طور خودکار از ذخیره HTTP بدون تلاش اضافی مراقبت می‌کند.
هدرهای پاسخ: وب سرور خود را پیکربندی کنید
بخشی از راه‌اندازی حافظه پنهان HTTP که بیشترین اهمیت را دارد هدرهایی است که وب سرور شما به هر پاسخ خروجی اضافه می‌کند. هدرهای زیر همگی در رفتار موثر در حافظه پنهان نقش دارند:
-
Cache-Control - سرور می‌تواند یک دستورالعمل
Cache-Controlرا برای تعیین اینکه مرورگر و سایر حافظه‌های نهان میانی چگونه و برای چه مدت پاسخ فردی را در حافظه پنهان نگه دارند، بازگرداند. -
ETag - هنگامی که مرورگر پاسخ حافظه پنهان منقضی شده را پیدا می کند، می تواند یک توکن کوچک (معمولاً هش محتوای فایل) را به سرور ارسال کند تا بررسی کند که آیا فایل تغییر کرده است یا خیر. اگر سرور همان رمز را برگرداند، پس فایل همان است و نیازی به دانلود مجدد آن نیست.
-
Last-Modified - این هدر همان هدف
ETagرا انجام می دهد، اما از یک استراتژی مبتنی بر زمان برای تعیین اینکه آیا یک منبع تغییر کرده است یا خیر، بر خلاف استراتژی مبتنی بر محتواETagاستفاده می کند.
برخی از سرورهای وب دارای پشتیبانی داخلی برای تنظیم آن هدرها به صورت پیش فرض هستند. برخی دیگر سرصفحه ها را به طور کامل حذف می کنند مگر اینکه شما به صراحت آنها را پیکربندی کنید. جزئیات خاص نحوه پیکربندی هدرها بسته به وب سروری که استفاده می کنید بسیار متفاوت است، و برای دریافت دقیق ترین جزئیات باید به اسناد سرور خود مراجعه کنید.
برای صرفه جویی در جستجوی شما، در اینجا دستورالعمل هایی برای پیکربندی چند وب سرور محبوب آورده شده است:
حذف هدر پاسخ Cache-Control ، ذخیره HTTP را غیرفعال نمی کند! درعوض، مرورگرها به طور موثر حدس می‌زنند که چه نوع رفتار ذخیره‌سازی برای یک نوع محتوا بیشتر منطقی است. به احتمال زیاد کنترل بیشتری نسبت به پیشنهادات می‌خواهید، بنابراین باید برای پیکربندی سرصفحه‌های پاسخ خود وقت بگذارید.
کدام مقادیر هدر پاسخ را باید استفاده کنید؟
دو سناریو مهم وجود دارد که هنگام پیکربندی هدرهای پاسخ سرور وب خود باید آنها را پوشش دهید.
ذخیره طولانی مدت برای URL های نسخه شده
فرض کنید سرور شما به مرورگرها دستور می دهد تا یک فایل CSS را به مدت 1 سال کش کنند ( Cache-Control: max-age=31536000 ) اما طراح شما به تازگی یک به روز رسانی اضطراری ایجاد کرده است که باید فوراً آن را پیاده سازی کنید. چگونه به مرورگرها اطلاع می‌دهید که کپی ذخیره شده «بیات شده» فایل را به‌روزرسانی کنند؟ شما نمی توانید، حداقل بدون تغییر URL منبع.
پس از اینکه مرورگر پاسخ را در حافظه پنهان ذخیره کرد، نسخه ذخیره شده در حافظه پنهان تا زمانی استفاده می شود که دیگر تازه نباشد، همانطور که max-age تعیین می شود یا expires ، یا تا زمانی که به دلایل دیگری از حافظه پنهان خارج شود، مانند پاک کردن حافظه پنهان مرورگر توسط کاربر. در نتیجه، کاربران مختلف ممکن است هنگام ساخت صفحه، نسخه‌های مختلفی از فایل را بارگیری کنند: کاربرانی که به تازگی منبع را واکشی کرده‌اند از نسخه جدید استفاده می‌کنند، اما کاربرانی که نسخه قبلی (اما هنوز معتبر) را در حافظه پنهان ذخیره کرده‌اند، از نسخه قدیمی‌تر استفاده می‌کنند.
برای دریافت حافظه پنهان سمت سرویس گیرنده و به‌روزرسانی‌های سریع، می‌توانید URL منبع را تغییر دهید و کاربر را مجبور کنید پاسخ جدید را هر زمان که محتوای آن تغییر کرد بارگیری کند. معمولاً، این کار را با جاسازی اثر انگشت فایل یا شماره نسخه در نام فایل آن انجام می‌دهید: برای مثال style.x234dff.css .
هنگام پاسخ به درخواست‌هایی برای نشانی‌های اینترنتی که حاوی اطلاعات « اثر انگشت » یا نسخه‌سازی هستند و محتوای آنها هرگز تغییر نمی‌کند، Cache-Control: max-age=31536000 به پاسخ‌های خود اضافه کنید.
تنظیم این مقدار به مرورگر می‌گوید که زمانی که نیاز به بارگیری همان URL در سال آینده داشته باشد (31,536,000 ثانیه، حداکثر مقدار پشتیبانی شده)، می‌تواند بلافاصله از مقدار موجود در حافظه پنهان HTTP استفاده کند، بدون اینکه نیازی به درخواست شبکه برای شما باشد. اصلا وب سرور این عالی است—شما فوراً قابلیت اطمینان و سرعتی را که از اجتناب از شبکه به دست می آید به دست آورده اید!
ابزارهای ساخت مانند بسته وب می‌توانند فرآیند اختصاص اثر انگشت هش به URL دارایی شما را خودکار کنند .
اعتبار سنجی مجدد سرور برای URL های بدون نسخه
متأسفانه، همه URL هایی که بارگیری می کنید نسخه بندی نشده اند. شاید نتوانید قبل از استقرار برنامه وب خود یک مرحله ساخت اضافه کنید، بنابراین نمی توانید هش به URL دارایی خود اضافه کنید. و هر برنامه وب به فایل‌های HTML نیاز دارد، که تقریباً هرگز شامل اطلاعات نسخه‌سازی نمی‌شود، زیرا هیچ‌کس زحمت استفاده از برنامه وب شما را به خود نمی‌دهد اگر لازم باشد به یاد داشته باشد که URL بازدیدکننده https://example.com/index.34def12.html است. بنابراین چه کاری می توانید برای آن URL ها انجام دهید؟
حافظه پنهان HTTP به تنهایی آنقدر قدرتمند نیست که از شبکه کاملاً اجتناب کند. (نگران نباشید - به زودی در مورد کارگران خدماتی که پشتیبانی بیشتری را ارائه می دهند، یاد خواهید گرفت.) اما چند مرحله وجود دارد که می توانید برای اطمینان از اینکه درخواست های شبکه تا حد امکان سریع و کارآمد هستند انجام دهید.
مقادیر Cache-Control زیر می تواند به شما کمک کند تا بتوانید URL های بدون نسخه را در کجا و چگونه ذخیره کنید:
-
no-cacheبه مرورگر می‌گوید که قبل از استفاده از نسخه کش URL، هر بار باید مجدداً با سرور اعتبارسنجی کند. -
no-storeبه مرورگر و دیگر کش های میانی (مانند CDN) می گوید که هرگز هیچ نسخه ای از فایل را ذخیره نکنند. -
private: مرورگرها می توانند فایل را کش کنند اما کش های میانی نمی توانند. -
public: هر کش می تواند پاسخ را ذخیره کند.
به پیوست: فلوچارت Cache-Control مراجعه کنید تا فرآیند تصمیم گیری از کدام مقدار(های) Cache-Control استفاده شود. Cache-Control همچنین می‌تواند فهرست دستورالعمل‌های جدا شده با کاما را بپذیرد. به پیوست مراجعه کنید: نمونه‌های Cache-Control .
تنظیم ETag یا Last-Modified نیز می تواند کمک کننده باشد. همانطور که در سرصفحه‌های Response ذکر شد، ETag و Last-Modified هر دو هدف یکسانی را دنبال می‌کنند: تعیین اینکه آیا مرورگر نیاز به بارگیری مجدد یک فایل کش که منقضی شده است یا خیر. توصیه می کنیم از ETag استفاده کنید زیرا دقیق تر است.
فرض کنید 120 ثانیه از واکشی اولیه گذشته است و مرورگر درخواست جدیدی را برای همان منبع آغاز کرده است. ابتدا مرورگر حافظه پنهان HTTP را بررسی می کند و پاسخ قبلی را پیدا می کند. متأسفانه مرورگر نمی تواند از پاسخ قبلی استفاده کند زیرا منقضی شده است. در این مرحله، مرورگر می تواند یک درخواست جدید ارسال کند و پاسخ کامل جدید را دریافت کند. با این حال، این ناکارآمد است زیرا اگر منبع تغییر نکرده باشد، دلیلی برای بارگیری مجدد اطلاعاتی که از قبل در حافظه پنهان است وجود ندارد.
این مشکلی است که توکن های اعتبارسنجی ETag برای حل آن طراحی شده اند. سرور یک توکن دلخواه را تولید و برمی گرداند که معمولاً هش یا اثر انگشت دیگری از محتویات فایل است. مرورگر نیازی به دانستن نحوه ایجاد اثر انگشت ندارد. فقط باید در درخواست بعدی آن را به سرور ارسال کند. اگر اثر انگشت همچنان یکسان است، منبع تغییر نکرده است و مرورگر می‌تواند از دانلود صرفنظر کند.
تنظیم ETag یا Last-Modified ، درخواست اعتبارسنجی مجدد را بسیار کارآمدتر می کند و به آن اجازه می دهد سرصفحه های درخواست If-Modified-Since یا If-None-Match ذکر شده در سرصفحه های درخواست را فعال کند.
وقتی یک سرور وب با پیکربندی مناسب آن سرصفحه‌های درخواست ورودی را می‌بیند، می‌تواند تأیید کند که آیا نسخه منبعی که مرورگر از قبل در حافظه پنهان HTTP خود دارد با آخرین نسخه در سرور وب مطابقت دارد یا خیر. اگر مطابقت وجود داشته باشد، سرور می‌تواند با یک پاسخ HTTP 304 Not Modified پاسخ دهد، که معادل «هی، به استفاده از آنچه قبلاً دریافت کرده‌ای ادامه بده!» هنگام ارسال این نوع پاسخ، داده‌های بسیار کمی برای انتقال وجود دارد، بنابراین معمولاً سریع‌تر از ارسال نسخه‌ای از منبع واقعی درخواستی است.
/file از سرور درخواست می‌کند و شامل سرصفحه If-None-Match می‌شود تا به سرور دستور دهد فقط در صورتی که ETag فایل روی سرور با مقدار If-None-Match مرورگر مطابقت نداشته باشد، فایل کامل را برگرداند. در این مورد، مقادیر مطابقت دارند، بنابراین سرور یک پاسخ 304 Not Modified را با دستورالعمل‌هایی برای مدت زمان بیشتری که فایل باید در حافظه پنهان بماند، برمی‌گرداند ( Cache-Control: max-age=120 ).خلاصه
حافظه پنهان HTTP یک راه موثر برای بهبود عملکرد بار است زیرا درخواست های غیر ضروری شبکه را کاهش می دهد. در همه مرورگرها پشتیبانی می‌شود و راه‌اندازی آن به کار زیادی نیاز ندارد.
پیکربندی‌های Cache-Control زیر شروع خوبی هستند:
-
Cache-Control: no-cacheبرای منابعی که باید قبل از هر استفاده مجدداً با سرور تأیید شوند. -
Cache-Control: no-storeبرای منابعی که هرگز نباید کش شوند. -
Cache-Control: max-age=31536000برای منابع نسخه شده.
سربرگ ETag یا Last-Modified می تواند به شما کمک کند تا منابع حافظه نهان منقضی شده را مجدداً اعتبارسنجی کنید.
بیشتر بدانید
اگر به دنبال فراتر رفتن از اصول اولیه استفاده از هدر Cache-Control هستید، بهترین شیوه های ذخیره سازی و راهنمای گچاهای حداکثر سنی جیک آرچیبالد را بررسی کنید.
برای راهنمایی در مورد نحوه بهینه سازی استفاده از حافظه پنهان برای بازدیدکنندگان بازگشتی، به Love your cache مراجعه کنید.
ضمیمه: نکات بیشتر
اگر زمان بیشتری دارید، در اینجا راه‌های بیشتری برای بهینه‌سازی استفاده از حافظه پنهان HTTP وجود دارد:
- از URL های ثابت استفاده کنید. اگر محتوای یکسانی را در URL های مختلف ارائه دهید، مرورگر آن محتوا را چندین بار واکشی و ذخیره می کند.
- ریزش را به حداقل برسانید. اگر بخشی از یک منبع (مانند یک فایل CSS) به‌طور مکرر به‌روزرسانی می‌شود، در حالی که بقیه فایل به‌روزرسانی نمی‌شود (مانند کدهای کتابخانه)، کدهایی که اغلب به‌روزرسانی می‌شوند را به یک فایل جداگانه تقسیم کنید و از یک استراتژی کش کوتاه مدت استفاده کنید. کدی که مکرراً به‌روزرسانی می‌شود، و یک استراتژی طولانی مدت حافظه پنهان برای کدهایی که اغلب تغییر نمی‌کنند.
- اگر درجه ای از کهنگی در خط مشی
Cache-Controlشما قابل قبول است، دستورالعمل جدیدstale-while-revalidateدر نظر بگیرید.
پیوست: فلوچارت Cache-Control
Cache-Control . ضمیمه: نمونه های Cache-Control
مقدار Cache-Control | توضیح |
|---|---|
max-age=86400 | پاسخ را می توان توسط مرورگرها و حافظه های پنهان واسطه ای تا یک روز (60 ثانیه در 60 دقیقه در 24 ساعت) در حافظه پنهان نگه داشت. |
private, max-age=600 | پاسخ را می توان توسط مرورگر ذخیره کرد، اما نه حافظه پنهان واسطه، تا ده دقیقه (60 ثانیه در 10 دقیقه). |
public, max-age=31536000 | پاسخ را می توان توسط هر کش به مدت یک سال ذخیره کرد. |
no-store | پاسخ را نمی توان در حافظه پنهان ذخیره کرد و باید در هر درخواست به طور کامل واکشی شود. |