تاريخ النشر: 21 أكتوبر 2024، تاريخ آخر تعديل: 9 سبتمبر 2025
يُجري Chrome تغييرًا للسماح باستخدام ذاكرة التخزين المؤقت للصفحات (bfcache) للصفحات التي تستخدم Cache-Control: no-store عندما يكون ذلك آمنًا. تعرَّف على ما يعنيه ذلك للمطوّرين.
الخلفية
يُعدّ ضبط Cache-Control: no-store كعنوان HTTP إشارة إلى أنّه يجب عدم تخزين الصفحة في ذاكرة التخزين المؤقت لبروتوكول HTTP. يجب استخدام هذا الخيار للصفحات التي تحتوي على بيانات حساسة، مثلاً الصفحات التي يسجّل فيها المستخدم الدخول، ولكن غالبًا ما يتم استخدام التوجيه no-store على الصفحات التي لا تحتوي على بيانات حساسة.
باستخدام ذاكرة التخزين المؤقت للصفحات السابقة/التالية، بدلاً من إتلاف الصفحة عندما ينتقل المستخدم إلى صفحة أخرى، نؤجّل عملية الإتلاف ونوقف تنفيذ JavaScript مؤقتًا. إذا عاد المستخدم إلى الصفحة سريعًا، نعيد عرضها ونستأنف تنفيذ JavaScript. ويؤدي ذلك إلى انتقال المستخدم من صفحة إلى أخرى بشكل شبه فوري.
على الرغم من أنّ مواصفات HTML لا تتطلّب ذلك، تستخدم المتصفّحات عادةً Cache-Control: no-store كإشارة لتجنُّب وضع الصفحة في ذاكرة التخزين المؤقت للخلف والأمام. هذا هو السبب الأكبر لعدم استخدام ذاكرة التخزين المؤقت للخلف والأمام، ويحدث ذلك في% 17 تقريبًا من عمليات التنقّل في السجلّ على الأجهزة الجوّالة و% 7 من عمليات التنقّل في السجلّ على أجهزة الكمبيوتر المكتبي. وهذا يعني أنّ هذه الصفحات لا تستفيد من عمليات الاستعادة السريعة ويجب إعادة تحميل الصفحة بالكامل، بما في ذلك أي طلبات شبكة وتنفيذ JavaScript وعرض.
يتم غالبًا ضبط Cache-Control: no-store لتجنُّب مشاكل التخزين المؤقت عند تغيير الموقع الإلكتروني، ولكن هذا السبب أقل صلة بالموضوع عند استخدام ذاكرة التخزين المؤقت للصفحات (bfcache)، لأنّه تتم استعادة الصفحة الكاملة كما لو أنّها ظلت مفتوحة طوال الوقت.
كيف سيغيّر Chrome هذا السلوك؟
أعلن Chrome عن نيّته تغيير هذا السلوك، ولكنّه يتّخذ نهجًا حذرًا بشأن هذا التغيير. لقد أجرينا تجارب منذ الإصدار 116 من Chrome، ورفعنا تدريجيًا نسبة عمليات تحميل الصفحات، ومن المتوقّع أن تصل النسبة إلى% 100 في آذار (مارس) ونيسان (أبريل) 2025.
البيانات الحسّاسة
على الرغم من أنّ تحليلنا يوضّح أنّ معظم عمليات التنقّل للخلف أو للأمام لا تتضمّن بيانات حسّاسة، وبالتالي من المفترض أن تكون مؤهّلة للاستفادة من ذاكرة التخزين المؤقت للصفحات (bfcache)، هناك حالات لا يجب فيها وضع الصفحات في ذاكرة التخزين المؤقت هذه. على سبيل المثال، عند تسجيل الخروج، يجب ألا يكون من الممكن استرداد صفحة تم تسجيل الدخول إليها من خلال الرجوع أو الانتقال إلى الأمام.
لتجنُّب ذلك، سيُزيل Chrome صفحة من ذاكرة التخزين المؤقت للخلف والأمام عند إجراء تغييرات على ملفات تعريف الارتباط أو طرق المصادقة الأخرى.
بالإضافة إلى ذلك، سيؤدي استخدام واجهات برمجة التطبيقات التالية للصفحات التي تستخدم Cache-Control: no-store إلى استمرار عدم أهلية هذه الصفحات للاستفادة من ميزة "التخزين المؤقت للصفحات":
يُرجى العِلم أنّ هذه ليست قائمة شاملة بواجهات برمجة التطبيقات التي تمنع استخدام ذاكرة التخزين المؤقت للصفحات، بل هي واجهات برمجة التطبيقات التي تحظر ذاكرة التخزين المؤقت للصفحات على صفحات Cache-Control: no-store حتى إذا لم يتم استخدامها عند مغادرة الصفحة.
تم أيضًا تقليل مهلة التخزين المؤقت للصفحات التي تستخدم Cache-Control: no-store إلى 3 دقائق (بدلاً من 10 دقائق المستخدمة للصفحات التي لا تستخدم Cache-Control: no-store) للحدّ من المخاطر.
خيارات عدم الموافقة في Enterprise
غالبًا ما تستخدم المؤسسات برامج يصعب تحديثها وأجهزة مشترَكة. يمكن إيقاف سياسة AllowBackForwardCacheForCacheControlNoStorePageEnabled لمواصلة منع استخدام ميزة "التخزين المؤقت للصفحات" لصفحات Cache-Control: no-store.
اختبار التغيير
يمكن للمطوّرين اختبار هذا التغيير باستخدام العلامة التالية:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
في حال انطباق أيّ من الاستثناءات السابقة، مثل تغيير ملفات تعريف الارتباط، سيؤدي ذلك إلى منع الصفحة من استخدام ذاكرة التخزين المؤقت للصفحات (bfcache) مع ظهور السبب "لا يمكن إدخال الصفحات التي يتضمّن مصدرها الرئيسي السمة Cache-Control: no-store في ذاكرة التخزين المؤقت للصفحات" في أداة اختبار ذاكرة التخزين المؤقت للصفحات في Chrome DevTools.
يمكنك استخدام صفحة اختبار ذاكرة التخزين المؤقت للخلف والأمام هذه للاختبار مع هذا الخيار وبدونه.
المعلومات التي يجب أن يعرفها المطوّرون
مع أنّ المطوّرين لن يحتاجوا إلى إجراء أي تغييرات ليستفيد المستخدمون من زيادة استخدام ذاكرة التخزين المؤقت للصفحات السابقة/التالية، هناك بعض الأمور التي قد يحتاجون إلى أخذها في الاعتبار نتيجةً لذلك. وقد تكون المواقع الإلكترونية الأخرى قد واجهت اعتبارات مشابهة عند إطلاق ميزة bfcache في ديسمبر 2021.
هل يجب أن يهدف المطوّرون إلى تقليل استخدام Cache-Control: no-store؟
يتم تفعيل ذاكرة التخزين المؤقت للخلف والأمام في Cache-Control: no-store في الظروف المحدودة المذكورة سابقًا وعلى متصفّح Chrome فقط. قد تظلّ المتصفّحات الأخرى تحظر استخدام ذاكرة التخزين المؤقت للخلف والأمام عند استخدام Cache-Control: no-store.
يبقى من الأفضل تقليل استخدام Cache-Control: no-store بدلاً من الاعتماد على هذه الإرشادات.
التأثير في الأداء
والسبب الذي يدفعنا إلى إجراء هذا التغيير هو تحسين تجربة الصفحة للمستخدمين على الويب. لقد لاحظنا تحسّنًا ملحوظًا في "مؤشرات Core Web Vitals" عند إطلاق ميزة bfcache لأول مرة، ونريد الآن أن نتيح هذه التحسينات نفسها للمزيد من المواقع الإلكترونية.
قد يلاحظ مالكو المواقع الإلكترونية تحسّنًا في مؤشرات Core Web Vitals عند طرح هذه الميزة، ويمكنهم قياس استخدام ذاكرة التخزين المؤقت للصفحات الخلفية في CrUX، بما في ذلك في CrUX Vis.
إحصاءات التأثير
تؤدي الصفحات المستعادة من ذاكرة التخزين المؤقت للصفحات (bfcache) إلى "استعادة" الصفحة القديمة (بما في ذلك مساحة التخزين المؤقت في JavaScript) بدلاً من إعادة تحميل الصفحة. لا تقيس العديد من خدمات الإحصاءات الرائجة عمليات استعادة البيانات من ذاكرة التخزين المؤقت للخلف والأمام كعمليات مشاهدة جديدة للصفحة، لأنّها لا تنشّط عمليات مشاهدة الصفحة إلا عند تحميلها في البداية.
لذلك، قد تشهد المواقع الإلكترونية انخفاضًا في عمليات تحميل الصفحات في إحصاءاتها عند بدء استخدام ذاكرة التخزين المؤقت للخلف والأمام للمرة الأولى. ننصحك بالتعامل معها كعمليات مشاهدة للصفحة، وذلك من خلال ضبط أدوات الاستماع للحدث pageshow والتحقّق من السمة persisted:
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
التعامل مع التعديلات عند استعادة الصفحة
بما أنّ المواقع الإلكترونية قد تلاحظ الآن استخدام ميزة "التخزين المؤقت للصفحات" في حالات لم تكن تلاحظها من قبل، وعندما تتم إعادة تحميل الصفحة بالكامل باستخدام بيانات جديدة، قد يهم المطوّرين إعادة تحميل البيانات عند استعادة الصفحة من ذاكرة التخزين المؤقت.
يمكن بدء عمليات التحديث بطريقة مشابهة لتسجيل المزيد من مشاهدات الصفحة في "إحصاءات Google" باستخدام الحدث pageshow والتحقّق من السمة persisted.
يُرجى العِلم أنّه ليس من الضروري تعديل كل المحتوى، وقد يفضّل المستخدمون الرجوع إلى المحتوى الذي شاهدوه سابقًا. على سبيل المثال، قد يؤدي إعادة تحميل قائمة المقالات إلى عدم ظهور مقالة كان المستخدم يريد العودة إلى عرضها.
التأثير في الإعلانات
على غرار تأثير الإحصاءات، قد تشهد المواقع الإلكترونية انخفاضًا في مرات ظهور الإعلانات إذا تم تحميل الإعلانات عند تحميل الصفحة فقط. يمكن إعادة تحميل الإعلانات آليًا عند استعادة الصفحة من ذاكرة التخزين المؤقت الخلفية لضمان التكافؤ مع عمليات تحميل الصفحة الكاملة، وذلك باستخدام الحدث pageshow والتحقّق من السمة persisted، ولكن قد لا يكون ذلك الإجراء المناسب دائمًا. راجِع مستندات مقدّم خدمة الإعلانات لمعرفة كيفية بدء عمليات إعادة تحميل الإعلانات.
مزيد من المعلومات حول ميزة "التخزين المؤقت للصفحات"
لمزيد من المعلومات حول ميزة "التخزين المؤقت للصفحات"، يمكنك الاطّلاع على دليلنا الفني الشامل حول ميزة "التخزين المؤقت للصفحات".
الملاحظات
نحن نتطلّع إلى تلقّي ملاحظاتك بشأن هذا التغيير، ويمكنك تقديمها في أداة تتبُّع المشاكل في Chrome باستخدام مكوّن bfcache.
الخاتمة
يسرّنا أن نتيح مزايا ذاكرة التخزين المؤقت الاحتياطية للعديد من الصفحات الأخرى بهدف تحسين تجربة المستخدمين. لقد درسنا هذا التغيير بعناية، ونسعى إلى طرحه بأكثر الطرق أمانًا. نأمل أن تساعد المعلومات المقدَّمة هنا المطوّرين في فهم هذا التغيير وإجراء أي تغييرات ضرورية لتجنُّب المشاكل عند حدوث ذلك.