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

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

Sam Thorogood

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

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

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

الأهداف

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

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

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

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

الخلفية

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

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

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

مخطّط بياني يوضّح مدة التخزين المؤقت لمواد العرض المختلفة من خلال متصفّح المستخدم
سيتم التخزين المؤقت لمواد العرض التي يتم إنشاؤها في أوقات مختلفة (باللون الرمادي) في أوقات مختلفة، بحيث ينتج عن التحميل الثاني مجموعة من مواد العرض المخزّنة مؤقتًا والجديدة

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

كانت هذه فكرة حسنة النية في يوم ما، ولكن بالنظر إلى الطبيعة المتكاملة لمواقع الويب الحالية يعني هذا السلوك الافتراضي أنه من الممكن للوصول إلى حالة يكون فيها المستخدم لديه ملفات مصممة لإصدارات مختلفة من موقعك الإلكتروني (على سبيل المثال، لغة JavaScript من إصدار يوم الثلاثاء وخدمة مقارنة الأسعار (CSS) من يوم الجمعة )، وكل ذلك لأن هذه الملفات لم يتم تحديثها في نفس الوقت بالضبط.

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

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

يمكنك إعداد مضيف الويب للاستجابة لطلبات الويب باستخدام العنوان التالي:

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

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

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

بغض النظر عن هذا، هذا نهج حديث هو الإعداد التلقائي لشبكة توصيل المحتوى (CDN) الشائعة، وNetlify، ولكن يمكن إعداده على أي شبكة توصيل محتوى تقريبًا. بالنسبة إلى استضافة 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 وغيرها لمساعدتك في حلّ هذه المشكلة. التأكد من للاطّلاع على المزيد من المعلومات عنها في تقرير الأدوات.

تذكر أن عناوين URL المستندة إلى بصمات الأصابع ليست وحدها التي تستفيد من JavaScript، يمكن أيضًا تسمية الأصول مثل الرموز و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