طريقه الاستفادة من التخزين المؤقت للمتصفح

يتم تشغيل هذه القاعدة عندما يكتشف PageSpeed Insights أن استجابة الخادم لا تتضمن رؤوس تخزين مؤقت واضحة أو عندما يتم تعيين الموارد على التخزين المؤقت لمدة زمنية قصيرة فقط.

نظرة عامة

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

التوصيات

مكِّن التخزين المؤقت للمتصفح مع الخادم. ويجب أن تتضمن الموارد الثابتة مهلة تخزين مؤقت لا تقل عن أسبوع. وبالنسبة إلى موارد الجهات الخارجية مثل الإعلانات والأدوات، يجب ألا تقل مهلة التخزين المؤقت عن يوم واحد. إلا أننا نوصي بتعيين الإعدادات التالية مع جميع الموارد القابلة للتخزين المؤقت:

• عيِّن Expires على أسبوع واحد كحد أدنى، ومن المفضل تعيينه على عام واحد، في المستقبل. (نفضل ضبط قيمة Expires على Cache-Control: max-age لأن هذا الإعداد مدعوم على نطاق أوسع.) لا تعينه على فترة أكثر من عام في المستقبل نظرًا لأن هذا يعد خرقًا لإرشادات RFC.
• إذا كنت تعرف تحديدًا متى سيتغير المورد، فمن الأفضل تعيين فترة انتهاء صلاحية أقصر. ولكن إذا كنت تعتقد أن "التغيير قد يكون بعد وقت قصير" ولا تعرف متى، فعليك تعيين فترة انتهاء صلاحية طويلة واستخدام ملف URL المرجعي (الموضح أدناه).

رؤوس Expires وCache-Control: max-age

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

رؤوس Last-Modifed وETag

تحدد هذه الرؤوس الكيفية التي يتعين على المتصفح بها تحديد ما إذا كانت الملفات هي نفسها لأغراض التخزين المؤقت. وفي رأس Last-Modified يعد هذا هو التاريخ. أما في رأس ETag، فيمكن أن يكون هذا أية قيمة تحدد موردًا بشكل فريد (عادة نسخ الملف أو علامات تخصيص محتوى). يعد الرأس Last-Modified رأس تخزين مؤقت "ضعيف" حيث يستخدم المتصفح مساعدًا لتحديد جلب العنصر من ذاكرة تخزين مؤقت أم لا.

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

ما هي رؤوس التخزين المؤقت التي يتعين عليَّ استخدامها؟

من الضروري تحديد Expires أو Cache-Control max-age وتحديد Last-Modified أو ETag مع جميع الموارد القابلة للتخزين المؤقت. ومن التكرار تحديد كل من Expires وCache-Control: max-age، أو تحديد كل من Last-Modified وETag.

استخدام ملف URL المرجعي

بالنسبة إلى الموارد التي تتغير أحيانًا، يمكننا أن نجعل المتصفح يحفظ نسخة مؤقتة من المورد حتى يتم تغييره على الخادم، وعند ذلك يخبر الخادم المتصفح عن توفر نسخة جديدة. يمكننا تنفيذ ذلك من خلال تخصيص عنوان URL فريد لكل نسخة من المورد. لنفترض مثلاً أن لدينا موردًا باسم "my_stylesheet.css". يمكننا إعادة تسمية الملف ليصبح "my_stylesheet_fingerprint.css". وعندما يتغير المورد يتغير ملفه المرجعي وذلك بدوره يؤدي إلى تغير عنوان URL. وبعد تغير عنوان URL، يتم إجبار المتصفح على إعادة جلب المورد. ويتيح لنا الملف المرجعي تعيين مدة طويلة لانتهاء الصلاحية في المستقبل حتى مع الموارد التي تتغير بشكل أكثر تكرارًا من ذلك.

وهناك طريقة شائعة لإنشاء ملف مرجعي وهي من خلال رقم سداسي عشري بتنسيق 128 بت يشفِّر علامة تخصيص محتوى الملف.

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