رؤوس مُخزّن HTTP التحكم في التخزين، وعلامة التحقق (ETag)، وحدة العمر دون تخمين

كل استجابة HTTP تُرسلها هي إما محفوظة في الذاكرة أو ليست كذلك — وإذا لم تكن مُدروسًا، فإن المتصفح يُقرر ذلك نيابة عنك. النتيجة عادةً ما تكون مزيجًا من تحميل مُفرط للعناصر التي تتغير بانتظام وغياب التخزين للعناصر التي تُغير ببطء. كلاهما يضر المستخدمين.

تُقدم هذه المبادئ المعرفية لك نموذجًا ذهنيًا لوضع عناصر تخزين HTTP بشكل صحيح للمرة الأولى: ما يتحكم به كل إرشاد، كيف تُحفّز إعادة التحقق من خلال ETags، وكيفية اختيار أوقات التسليم (TTL) التي تُحافظ على التحديثات دون تقديم محتوى قديم.

كيف تعمل مُخزون المتصفح فعليًا

عندما يطلب المتصفح موردًا، فإنه يتحقق أولاً من مخزونه المحلي. إذا وُجد نسخة محفوظة حديثة، فإنه يُقدّمها فورًا — دون أي طلب على الشبكة. وإذا كان من الممكن أن تكون النسخة المحفوظة قديمة، فإنه يُرسل طلبًا شرطيًا إلى المصدر. يُجيب المصدر إما بتأكيد أن المورد لم يتغير (304 Not Modified) أو بارسال الاستجابة المحدثة بالكامل (200 OK).

تُوجد مُراكز توزيع (CDNs) في منتصف هذه المرحلة. تُخزن الاستجابات أقرب إلى المستخدمين جغرافيًا، وتُحترم نفس عناصر التخزين في HTTP — مع بعض التوسعات الخاصة بالـ CDN مثل s-maxage.

ثلاثة أسئلة تحدد سلوك التخزين:

• هل يمكن تخزين هذه الاستجابة على الإطلاق؟ تُتحكم بها Cache-Control: no-store أو private
• ما مدة صلاحيتها؟ تُتحكم بها max-age أو s-maxage
• كيف يتم التحقق من تقادم المحتوى؟ تُتحكم بها ETags أو Last-Modified

إرشادات رأسية Cache-Control

ال Cache-Control الرأسية هي الطريقة الأساسية لتحديد سياسة التخزين. تُفصل بين عدة إرشادات بفاصلة. إليك ما يفعله كل منها:

max-age

max-age=N تُخبر المخزون (المتصفح والـ CDN) كم عدد الثواني التي يبقى فيها الاستجابة مُحدثة. تُعتبر الاستجابة المُحدثة مُحدثة لمدة دقيق 24 ساعة من تاريخ استلامها. بعد ذلك، يجب على المخزون إعادة التحقق قبل تقديمها مرة أخرى. max-age=86400 للموارد الثابتة مع أسماء ملفات مُحددة (مثل

)، يكون عامًا شائعًا: main.abc123.js. بالنسبة للوثائق HTML، يكون النطاق أقصر بكثير — أو لا توجد تخزين على الإطلاق — لأن الوثائق HTML تشير إلى هذه الموارد المُحددة. max-age=31536000s-maxage

تُستبدل

s-maxage للمخزون المشترك (CDNs، خوادم الوسيط) فقط. يتجاهل المتصفح هذه الإرشاد. هذا يسمح بتقديم استجابات محفوظة لفترة طويلة للعملاء، مع الحفاظ على طبقة الـ CDN أكثر توازنًا. نمط شائع هو max-age — يُحفوظ المتصفح لمدة ساعة، ويُحفوظ الـ CDN لمدة 24 ساعة. Cache-Control: public, max-age=3600, s-maxage=86400 no-cache

لا يعني "لا تُخزن". يعني أن المخزون يجب أن يُعيد التحقق مع المصدر قبل تقديم الاستجابة المحفوظة، حتى لو كانت محدثة. تُحفوظ الاستجابة، ولكن كل استخدام يتطلب رحلة إلى التحقق من صلاحيتها. هذا مناسب للمحتوى الذي يتغير بانتظام ولكنه يستفيد من توفير الاتصالات من خلال استجابة 304.

no-cache no-store

هي الإرشاد الوحيد الذي يمنع التخزين تمامًا. لا يُحفوظ في مخزون المتصفح، ولا في الـ CDN، ولا في القرص. استخدمها للردود التي تحتوي على بيانات حساسة للمستخدم — مثل فواتير البنوك، السجلات الطبية، أو الرموز. لا تستخدمها كمُعيار افتراضي لأنك لم تفكر بعد في التخزين.

no-store public و private

تُسمح بشكل صريح بمخزون مشاركة (CDNs) لتخزين الاستجابة، حتى لو كان الطلب يحتوي على

public تُقيّد التخزين إلى متصفح المستخدم فقط — يجب أن لا يُخزنها الـ CDN. بالنسبة للردود المُصادقة التي تكون مخصصة للمستخدم، Authorization الرأس. private تمنع تزويد ردّة مستخدم واحد بردّة آخر. private must-revalidate

تمنع المخزون من تقديم ردود قديمة عندما لا يمكنه الوصول إلى المصدر. بدونها، قد يُقدم مخزون مُنتهي الصلاحية إذا كان الاتصال غير متاح. معها، يفشل الطلب بـ 504 إذا لم يكن المصدر متاحًا. استخدمها للبيانات التي يكون تقديمها قديمًا أسوأ من حدوث خطأ.

must-revalidate ETags: التحقق الدقيق من التحديث

يُعدّ ETag معرفة مُولدة من قبل الخادم للنسخة المحددة من المورد — أفكر فيه كمُطبّق للجسم المُستند. يُرسل الخادم هذا في الاستجابة:

عندما تنتهي صلاحية النسخة المحفوظة، يُرسل المتصفح طلبًا شرطيًا يحتوي على ETag المحفوظ:

ETag: "abc123def456"

إذا لم يتغير المورد، يُجيب الخادم بـ

If-None-Match: "abc123def456"

وبدون جسم — مما يوفر مساحة للاتصال مع التأكيد على التحديث. إذا تغير المورد، يُجيب الخادم بـ 304 Not Modified وETAG الجديد. 200 OK الفرق بين ETag القوي والضعيف

الـ ETag القوي

أ ) يعني أن الاستجابة متماثلة تمامًا على المستوى المُحدد. أما ("abc123"الـ ETag الضعيف ) يعني أن الاستجابات متماثلة من حيث المعنى ولكن قد تختلف بطرق بسيطة مثل الفراغ أو ترتيب الرؤوس. يمكن إنشاء الـ ETags الضعيف بكفاءة أكبر ولكن لا يمكن استخدامه في طلبات النطاق. ما لم يكن لديك سبب محدد لاستخدام الـ ETags الضعيف، استخدم الـ ETags القوي. (W/"abc123"Last-Modified: البديل القديم

قبل ETags، استخدم الخوادم

أوقات تثبيت للاستجابة. يُرسل الخادم: Last-Modified يُحقق المتصفح مع:

Last-Modified: Thu, 01 May 2026 12:00:00 GMT

يُرد الخادم بـ 304 إذا لم يتغير المورد منذ تلك اللحظة.

If-Modified-Since: Thu, 01 May 2026 12:00:00 GMT

العيب: الأوقات المُحددة لها دقة تبلغ ثانية واحدة. إذا تم تعديل الملف مرتين في نفس الثانية، سيُظهر كأنه لم يتغير. يعالج ETags هذا بشكل صحيح ويُفضّله. معظم الأطراف الحديثة تُرسل كلاهما — يستخدم المتصفح أي منهما متاح، مع تفضيل ETags.

إيقاف التخزين دون تدمير التحديثات

مدة طويلة

على مورد ثابت تكون آمنة فقط إذا تغيرت عنوان الملف عند تغيير المحتوى. توجد طريقتين: max-age الطبقة المُعتمدة على عنوان الملف (مُوصى بها)

أضف مُلخصًا لملف المحتوى في اسم الملف:

. عند تغيير الملف، يتغير المُلخص، يتغير عنوان الملف، ويُطلب الملف الجديد — مما يتجاوز المخزون تمامًا. يبقى الاسم القديم في المخزون لكنه لا يُطلب مرة أخرى بعد أن تُشير الوثائق HTML إلى الاسم الجديد. main.a1b2c3d4.jsيقوم Webpack، Vite، وأغلب المُجمّعات الحديثة بذلك تلقائيًا. يسمح هذا النمط بوضع

— الإرشاد Cache-Control: public, max-age=31536000, immutable يُخبر المتصفح أن لا يُحاول إعادة التحقق حتى لو كانت المُدخلة مُتضررة تقنيًا. immutable الأسئلة المُرفقة (أقل موثوقية)

إضافة نسخة إلى عنوان الملف كمُدخل سؤال (

) يُخلق عنوان مختلف تقنيًا، لكن بعض الـ CDNs والوسيطات تتجاهله عند بناء مفاتيح التخزين. استخدام الطبقة المُعتمدة في المسار أكثر موثوقية ويشتهر بدعمها.main.js?v=1.2.3أخطاء شائعة تؤثر على التخزين

تخزين استجابات واجهات برمجة تُفترض أنها لا يجب تخزينها

يجب أن تستخدم

أو على الأقل Cache-Control: no-store لواجهات برمجة تُرجع بيانات مخصصة للمستخدم أو متأثرة بالزمن. من الأخطاء الشائعة أن يسمح الـ CDN بحفظ استجابة مثل private, no-cacheوتقديم بيانات أحد المستخدمين لآخر. إذا لم تُحدد وحدة /api/user/profile في واجهة برمجة، سيقوم بعض الـ CDNs بحفظها باستخدام تقنيات تلقائية. Cache-Control إهمال Vary: Accept-Encoding

إذا كان الخادم يُقدّم نسخ مُضغوطة ونسخ غير مضغوطة حسب رؤية العميل

يجب أن يُخزن المخزون نسخًا منفصلة لكل نسخة. بدون Accept-Encoding قد يُخزن الـ CDN النسخة المضغوطة ويُقدّمها لعميل لا يدعم المضغوط — أو العكس. يجب دائمًا تعيينها عند وجود تغييرات مُدروسة. Vary: Accept-Encodingاستخدام no-cache عندما يعني no-store

يُكتب المطورون غالبًا

عندما يريدون منع التخزين تمامًا، لكن Cache-Control: no-cache يُخزن الاستجابة — فقط يتطلب إعادة التحقق قبل كل استخدام. استخدم no-cache عندما لا تريد أن يُحفوظ الاستجابة في أي مكان. no-store وضع max-age على HTML دون استراتيجية توقف التخزين

تُشير الوثائق HTML إلى موارد مُحددة. إذا تم تخزين HTML بـ

مدة طويلة، فلن يُدرك المستخدمون التحديثات الجديدة في أسماء الموارد بعد التحديث — سيستمر في تشغيل الـ HTML القديم الذي يشير إلى الأسماء القديمة. ضع مدة قصيرة (أو max-age) على HTML، واحتفظ بفترات طويلة للملفات الثابتة التي تُشير إليها. no-cacheاحسب فترة انتهاء الصلاحية قبل الإطلاق

يُصبح اختيار

أبسط عندما يمكنك رؤية ما يعنيه في الوقت الحقيقي. يتيح لك max-age على iotools.cloud إدخال مدة التسليم بالثواني ورؤية التاريخ الدقيق لانتهاء الصلاحية. مفيد لفحص القيم مثل 86400 (24 ساعة)، 2592000 (30 يوم)، أو 31536000 (سنة واحدة) قبل تثبيتها في إعدادات الخادم أو قواعد الـ CDN. حاسبة عمر التخزين المؤقت لـ HTTP / max-age مُراجعة عملية تخزين عملية عملية

الوثائق HTML:

• — يجب إعادة التحقق دائمًا، يستفيد من 304 عندما لا يتغير شيء Cache-Control: no-cache الموارد الثابتة المُحددة (الكود، الأسلوب، الصور مع ملخص في اسم الملف):
• الموارد غير المُحددة (الخطوط، أيقونات المتصفح): Cache-Control: public, max-age=31536000, immutable
• (أسبوع واحد) Cache-Control: public, max-age=604800 استجابات واجهات برمجة (عامة، متأثرة بالزمن):
• — مدة تُخزن في المتصفح قصيرة، مدة تُخزن في الـ CDN أطول Cache-Control: public, max-age=60, s-maxage=300 استجابات واجهات برمجة (مخصصة للمستخدم):
• البيانات الحساسة: Cache-Control: private, no-cache
• يجب دائمًا تعيين Cache-Control: no-store
• عند تقديم استجابات مضغوطة بشكل شرطي Vary: Accept-Encoding يجب أن تكون ETags مُفعّلة بشكل افتراضي لأي شيء تُخزن فيه — فهي الميكانيكية التي تجعل إعادة التحقق مُستهلكًا للبيانات. معظم الخوادم الويب (Nginx، Apache، Caddy) تُولّد ETags تلقائيًا ما لم تُعطَ مُعطلة.

يجب أن تكون علامات ETags مفعّلة بشكل افتراضي لكل شيء يتم تخزينه — فهي الميكانيزم الذي يجعل إعادة التحقق من الاتصال فعّالة من حيث التدفق. تُولّد معظم خوادم الويب (Nginx، Apache، Caddy) علامات ETags تلقائيًا ما لم تُعطَ إيقافها.

قد يعجبك أيضاً