HTTP Cache Headers للمبتدئ: من 1.8 ثانية لـ 180ms في الزيارة الثانية

بصمة فريدة للملف (زي رقم نسخة). لما الـ max-age تنتهي، المتصفح بيبعت طلب فيه If-None-Match: "a3f9b2". لو السيرفر شاف نفس البصمة، بيرد 304 Not Modified من غير محتوى. المتصفح بيستخدم النسخة من الكاش.

3) Last-Modified

تاريخ آخر تعديل للملف. أبسط من ETag لكن أقل دقة (بيشتغل بدقة الثانية). لو ETag موجود، المتصفح بيتجاهل Last-Modified.

إعداد عملي شغّال على Express و NGINX

على Express (Node.js):

على NGINX (للملفات الستاتيك):

القاعدة الذهبية: HTML بـ no-cache، الأصول الستاتيك بـ max-age طويل + immutable. لما تعدّل CSS، غيّر اسم الملف (app.v2.css) فالمتصفح هيحمّله طبيعي.

الأرقام المقاسة على موقع حقيقي

اختبرت موقع e-commerce فيه 28 ملف ستاتيك (CSS + JS + 22 صورة منتج)، حجم الكل 480KB، على شبكة Fast 3G في Chrome DevTools:

• قبل الـ caching: زيارة 1 = 1.84 ثانية، زيارة 2 = 1.81 ثانية (نفسها).
• بعد Cache-Control: max-age=31536000, immutable: زيارة 1 = 1.84 ثانية، زيارة 2 = 180ms.
• 10x أسرع في الزيارة الثانية، بدون لمس الكود.

في تقارير Cloudflare لسنة 2024، 71% من الـ HTTP requests بترد من cache (متصفح أو CDN) في المواقع اللي مفعّلة الـ headers صح.

Trade-offs لازم تفهمها

1. التحديث الفوري بيبقى أصعب. لو حطيت max-age=31536000 على ملف اسمه app.js ثابت، المستخدم اللي زار الموقع امبارح هيستخدم النسخة القديمة لمدة سنة. الحل: ضيف hash في الاسم (app.a3f9b2.js) واتركه يتغيّر مع كل deploy.
2. الـ ETag بيكلّف CPU. توليد الـ hash لكل response بيستهلك دورات معالج. على سيرفر فيه 5000 RPS، ده ممكن يضيف 3-7% CPU. لو الملف ستاتيك، استخدم Last-Modified بدلاً.
3. الكاش بيخبّي البَجز. لو الـ API بيرجّع بيانات حسّاسة لمستخدم وحطّيت headers غلط، ممكن مستخدم تاني يشوف بياناته. خد بالك من Cache-Control: private للمحتوى الخاص بمستخدم.
4. Vary header مهم. لو ترجم الصفحة حسب لغة المتصفح، لازم تضيف Vary: Accept-Language وإلا المستخدم العربي ممكن يشوف نسخة إنجليزية من الكاش.

متى لا تستخدم الـ caching

• API responses بتتغيّر كل ثانية (أسعار، live data). استخدم Cache-Control: no-store.
• صفحات فيها بيانات شخصية (لوحة تحكم، حساب بنكي). Cache-Control: private, no-cache.
• ملفات HTML ديناميكية اللي السيرفر بيرندرها لكل طلب. كاش الـ HTML نفسه = كارثة. كاش الأصول الستاتيك بس.
• أول 24 ساعة من إطلاق ميزة جديدة. سيب الـ cache قصير (5 دقايق مثلًا) لحد ما تتأكد إن الفيتشر مفيش فيه bug.

المصادر الرسمية

• RFC 9111 — HTTP Caching: https://www.rfc-editor.org/rfc/rfc9111
• MDN — Cache-Control: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
• web.dev — HTTP cache: https://web.dev/articles/http-cache
• Cloudflare — Cache Hit Ratio: https://developers.cloudflare.com/cache/concepts/cache-hit-ratio/
• NGINX docs — expires directive: https://nginx.org/en/docs/http/ngx_http_headers_module.html

الخطوة التالية

افتح موقعك في Chrome، اضغط F12، روح Network tab، اضغط Reload. شوف عمود "Size". لو فيه ملفات ستاتيك (.js, .css, .png) مكتوب جنبهم حجم بدل "memory cache" أو "disk cache"، انت دلوقتي بتدفع ضريبة شبكة بدون داعي. ضيف الـ headers اللي فوق على السيرفر، اعمل reload تاني، وقارن. لو الزمن قل بنسبة أقل من 70%، ابعتلي مخرجات الـ Network tab وهنشوف الـ headers سوا.