أحب ذاكرة التخزين المؤقت ❤️

سيستخدم المستخدمون الذين يُحمِّلون موقعك الإلكتروني للمرة الثانية ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا تأكَّد من أنّه يعمل بشكل جيد.

Sam Thorogood

هذه المشاركة مرفقة بفيديو أعجبني في ذاكرة التخزين المؤقت، وهو جزء من المحتوى الموسّع في فعالية Chrome Dev Summit لعام 2020. ننصحك بمشاهدة الفيديو:

عندما يُحمِّل المستخدمون موقعك الإلكتروني للمرة الثانية، سيستخدم المتصفّح الذي يستخدمونه الموارد داخل ذاكرة التخزين المؤقت الخاصة ببروتوكول HTTP للمساعدة في تسريع عملية التحميل. لكن معايير التخزين المؤقت على الويب تعود إلى عام 1999، وهي محددة على نطاق واسع إلى حد كبير - حيث إن تحديد ما إذا كان يمكن جلب ملف، مثل CSS أو صورة، مرة أخرى من الشبكة مقابل التحميل من ذاكرة التخزين المؤقت الخاص بك هو علم غير دقيق.

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

الأهداف

وعند تحميل موقعك الإلكتروني للمرة الثانية، يكون لديك هدفان:

1. التأكد من حصول المستخدمين على أحدث إصدار متاح - إذا قمت بتغيير شيء ما، فيجب أن يظهر بسرعة
2. الإجراء الأول أثناء استرجاع البيانات قدر الإمكان من الشبكة

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

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

الخلفية

بصفتنا مطوّري برامج على الويب، لقد اعتدنا جميعًا على فكرة امتلاك "ذاكرة تخزين مؤقت قديمة". لكننا نعلم، بشكلٍ غريزي، الأدوات المتاحة لحل هذه المشكلة، مثل إجراء "إعادة تحميل صعب" أو فتح نافذة تصفّح متخفٍ أو استخدام مجموعة من أدوات المطوّرين في متصفّحك لمحو بيانات الموقع الإلكتروني.

لا يتمتع المستخدمون العاديون الموجودون على الإنترنت بنفس الرفاهية. لذا، على الرغم من أنّ لدينا بعض الأهداف الأساسية المتمثلة في ضمان قضاء المستخدمين وقتًا ممتعًا في تحميل المحتوى الثاني، إلا أنّه من المهم أيضًا التأكد من عدم مواجهتهم وقتًا سيئًا أو عدم توقفهم عن العمل. (شاهِد الفيديو إذا أردت سماع ما أتحدث عنه حول كيفية توقّف الموقع الإلكتروني web.dev/live تقريبًا).

كخلفية عامة، هناك سبب شائع حقًا لـ "ذاكرة التخزين المؤقت القديمة" هو في الواقع الخيار الافتراضي للتخزين المؤقت في عصر 1999. تعتمد على عنوان Last-Modified:

يتم الاحتفاظ بكل ملف تقوم بتحميله لمدة إضافية تبلغ 10% من عمره الحالي، كما يراه المتصفح. على سبيل المثال، إذا تم إنشاء index.html قبل شهر، سيتم تخزينه مؤقتًا من خلال المتصفّح لمدة ثلاثة أيام أخرى تقريبًا.

كانت هذه فكرة حسنة النية، ولكن نظرًا للطبيعة المتكاملة للمواقع الإلكترونية في الوقت الحالي، يعني هذا السلوك التلقائي أنّه من الممكن

المسار المضاء جيدًا

إنّ الطريقة التلقائية الحديثة للتخزين المؤقت هي عدم استخدام التخزين المؤقت على الإطلاق واستخدام شبكات توصيل المحتوى (CDN) لعرض المحتوى الخاص بك بالقرب من المستخدمين. في كل مرة يُحمِّل فيها أحد المستخدمين موقعك الإلكتروني، سينتقل إلى الشبكة للتأكد من أنه قد يكون محدَّثًا. سيكون لهذا الطلب وقت استجابة سريع، لأنّه سيتم تقديمه من خلال شبكة توصيل للمحتوى (CDN) بالقرب من كل مستخدم جغرافيًا.

يمكنك ضبط مضيف الويب للرد على طلبات الويب باستخدام العنوان التالي:

Cache-Control: max-age=0,must-revalidate,public

ويفيد ذلك في الأساس بأنّ الملف صالح بدون أي وقت من الأوقات، وأنّك يجب عليك التحقّق من صحته من خلال الشبكة قبل أن تتمكّن من استخدامه مرة أخرى (وإلا قد تكون الملف "مقترَح" فقط).

وتكون عملية التحقّق هذه منخفضة التكلفة نسبيًا من حيث عدد وحدات البايت التي يتم نقلها. فإذا لم يتغير ملف صورة كبير، سيتلقّى المتصفّح استجابة صغيرة بصيغة 304، إلا أنّها تكلف وقت استجابة لأنّه لا يزال على المستخدم الانتقال إلى الشبكة للعثور على ذلك. وهذه هي الجانب السلبي الأساسي لهذا النهج. ويمكن أن تعمل بشكل جيد حقًا للأشخاص الذين لديهم اتصالات سريعة في العالم الأول، وحيثما تكون شبكة توصيل المحتوى (CDN) التي تختارها ذات تغطية رائعة، ولكن ليس مع الأشخاص الذين قد يستخدمون اتصالات جوّال أبطأ أو يستخدمون بنية أساسية سيئة.

بغض النظر عن ذلك، فإنّ هذا المنهج الحديث هو الإعداد التلقائي على شبكة توصيل المحتوى (CDN) الشهيرة وNetlify، ولكن يمكن تهيئته على أيّ شبكة توصيل محتوى (CDN) تقريبًا. بالنسبة إلى "استضافة Firebase"، يمكنك تضمين هذا العنوان في قسم الاستضافة من ملف firebase.json:

"headers": [
  // Be sure to put this last, to not override other headers
  {
    "source": "**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=0,must-revalidate,public"
    }
  }
]

لذلك بينما ما زلت أقترح هذا كافتراضي معقول، إلا إنه فقط - الإعداد الافتراضي! يمكنك متابعة القراءة لمعرفة كيفية الدخول وترقية الإعدادات التلقائية.

عناوين URL المضمّنة في الملف المرجعي

من خلال تضمين تجزئة من محتوى الملف في اسم مواد العرض والصور وما إلى ذلك يتم عرضه على موقعك الإلكتروني، يمكنك ضمان أنّ هذه الملفات ستتضمّن دائمًا محتوى فريد، وسيؤدي ذلك إلى إنشاء ملفات باسم sitecode.af12de.js على سبيل المثال. عندما يستجيب الخادم لطلبات هذه الملفات، يمكنك توجيه متصفّحات المستخدم النهائي إلى تخزينها مؤقتًا لفترة طويلة من خلال ضبطها باستخدام العنوان التالي:

Cache-Control: max-age=31536000,immutable

هذه القيمة هي سنة بالثواني. ووفقًا للمواصفات، يساوي هذا فعليًا "إلى الأبد".

من المهم عدم إنشاء علامات التجزئة هذه يدويًا، لأنّ ذلك يتطلّب عملاً يدويًا. يمكنك استخدام أدوات مثل Webpack وrollup وما إلى ذلك لمساعدتك في ذلك. احرص على قراءة المزيد عنها في تقرير الأدوات.

تذكَّر أنّ لغة JavaScript لا يمكنها الاستفادة من عناوين URL المضمّنة في بصمة الإصبع فحسب، بل يمكن أيضًا تسمية مواد العرض مثل الرموز وCSS وملفات البيانات الأخرى غير القابلة للتغيير بهذه الطريقة. (احرص على مشاهدة الفيديو أعلاه لمعرفة المزيد عن تقسيم الرموز، والذي يتيح لك شحن رموز أقل كلما تغير موقعك الإلكتروني).

وبغض النظر عن كيفية تعامل موقعك الإلكتروني مع التخزين المؤقت، فإنّ هذه الأنواع من الملفات التي تتضمّن بصمات أصابع ذات قيمة كبيرة لأي موقع إلكتروني قد تنشئه. معظم المواقع لا تتغير مع كل إصدار.

بالطبع، لا يمكننا إعادة تسمية الصفحات "المألوفة" التي تواجه المستخدمين بالطريقة التالية: إعادة تسمية ملف index.html إلى index.abcd12.html، وهذا عمل غير ممكن ولا يمكنك الطلب من المستخدمين الانتقال إلى عنوان URL جديد في كل مرة يحمِّلون فيها موقعك الإلكتروني. لا يمكن إعادة تسمية عناوين URL "المألوفة" هذه وتخزينها مؤقتًا بهذه الطريقة، مما يقودني إلى حل وسط محتمل.

الأرض الوسطى

عندما يتعلق الأمر بالتخزين المؤقت، لا يزال هناك مجال للحل الأساسي. لقد قدمت خيارين إضافيين: التخزين المؤقت مطلقًا أو التخزين المؤقت مطلقًا. وسيكون هناك عدد من الملفات التي قد ترغب في تخزينها مؤقتًا لبعض الوقت، مثل عناوين URL "المألوفة" التي ذكرتُها أعلاه.

إذا كنت تريد تخزين عناوين URL "المألوفة" هذه وHTML الخاصة بها في ذاكرة التخزين المؤقت، ننصحك بالتفكير في التبعيات التي تتضمنها، وطريقة تخزينها في ذاكرة التخزين المؤقت، ومدى تأثير التخزين المؤقت لعناوين URL الخاصة بها لفترة معيّنة. لنلقِ نظرة على صفحة HTML تتضمن صورة مثل هذه:

<img src="/images/foo.jpeg" loading="lazy" />

إذا عدّلت موقعك الإلكتروني أو غيّرته من خلال حذف هذه الصورة الكسولة أو تغييرها، قد تظهر صورة غير صحيحة أو غير متوفّرة للمستخدمين الذين يطّلعون على نسخة مخزّنة مؤقتًا من رمز HTML، لأنهم يحتفظون بنسخة /images/foo.jpeg الأصلية مؤقتًا عند زيارتهم لموقعك الإلكتروني.

فإذا كنت حريصًا، قد لا يؤثر ذلك عليك. ولكن على نطاق واسع، من المهم أن تتذكر أنّ موقعك الإلكتروني لم يعُد متوفّرًا على الخوادم فقط، وذلك عندما يخزّنه المستخدمون النهائيون في ذاكرة التخزين المؤقت. بل قد يكون متوفّرًا في أجزاء داخل ذاكرات التخزين المؤقت لمتصفّحات المستخدم النهائي.

بشكل عام، معظم الأدلة المتوفرة حول التخزين المؤقت ستتحدث عن هذا النوع من الإعدادات، هل تريد التخزين المؤقت لمدة ساعة أو عدة ساعات وما إلى ذلك. لإعداد هذا النوع من ذاكرة التخزين المؤقت، استخدم عنوانًا مثل هذا (الذي يخزّن مؤقتًا 3600 ثانية أو ساعة واحدة):

Cache-Control: max-age=3600,immutable,public

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

خيارات ليست بتنسيق HTML

بخلاف HTML، تتضمن بعض الخيارات الأخرى للملفات الموجودة في الوسط ما يلي:

• بشكل عام، ابحث عن مواد العرض التي لا تؤثر في مواد العرض الأخرى.

  • على سبيل المثال، تجنَّب استخدام CSS لأنّه يؤدي إلى تغييرات في طريقة عرض محتوى HTML

• الصور الكبيرة المستخدمة كجزء من المقالات في الوقت المناسب

  • من المحتمل ألا يزور المستخدمون أي مقالة واحدة أكثر من بضع مرات، لذا لا تخزّن مؤقتًا الصور أو الصور الرئيسية إلى الأبد وتهدر مساحة التخزين

• مادة عرض تمثل شيئًا بحد ذاته له مدى الحياة

  • قد يتم نشر بيانات JSON حول الطقس كل ساعة فقط، لذلك يمكنك تخزين النتيجة السابقة مؤقتًا لمدة ساعة - لن تتغير في نافذتك
  • قد تكون إصدارات المشروع مفتوح المصدر ذات معدّل محدود، لذلك عليك تخزين نسخة مؤقتًا من صورة حالة الإنشاء حتى يكون من الممكن أن تتغير الحالة

ملخّص

عندما يحمّل المستخدمون موقعك الإلكتروني للمرة الثانية، يعني ذلك أنّك حصلت على تصويت بثقة المحتوى، ويريدون العودة والاستفادة أكثر مما تقدّمه. في هذه المرحلة، لا يتعلق الأمر دائمًا بتقليل وقت التحميل، وتتوفر لك مجموعة من الخيارات للتأكد من أن متصفحك لا ينفذ سوى العمل الذي يحتاجه لتوفير تجربة سريعة وحديثة.

التخزين المؤقت ليس مفهومًا جديدًا على الويب، ولكنه ربما يحتاج إلى خيار افتراضي معقول، إذ يمكنك استخدام أحد المفهومَين والموافقة بشدّة على استراتيجيات تخزين مؤقت أفضل عند الحاجة. شكرًا على القراءة.

يمكن أيضًا مراجعة

للاطّلاع على دليل عام حول ذاكرة التخزين المؤقت لبروتوكول HTTP، يمكنك الاطّلاع على المقالة منع طلبات الشبكة غير الضرورية باستخدام ذاكرة التخزين المؤقت لبروتوكول HTTP.