تفعيل ميزة bfcache لعنصر التحكّم في ذاكرة التخزين المؤقت: no-store

يُجري Chrome تغييرًا للسماح باستخدام ذاكرة التخزين المؤقت للرجوع/الانتقال إلى الأمام (bfcache) للصفحات التي تستخدم Cache-Control: no-store عندما يكون ذلك آمنًا. تعرَّف على ما يعنيه ذلك للمطوّرين.

الخلفية

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

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

ومع أنّ مواصفات HTML لا تتطلّب ذلك، فإنّ المتصفّحات تستخدم عادةً Cache-Control: no-store كإشارة لتجنُّب وضع الصفحة في ذاكرة التخزين المؤقت في ذاكرة التخزين المؤقت. وهذا هو السبب الرئيسي لعدم استخدام ذاكرة التخزين المؤقت لسجلّ التصفّح، وذلك في ما يقرب من% 17 من عمليات التنقّل في السجلّ على الأجهزة الجوّالة و% 7 من عمليات التنقّل في السجلّ على أجهزة الكمبيوتر المكتبي. وهذا يعني أنّ هذه الصفحات لا تستفيد من عمليات الاستعادة السريعة ويجب إعادة تحميل الصفحة بالكامل، بما في ذلك أي طلبات للشبكة وتنفيذ JavaScript وعرض الصفحة.

غالبًا ما يتم ضبط القيمة Cache-Control: no-store لتجنّب مشاكل التخزين المؤقت عند تغيير الموقع الإلكتروني، ولكن هذا السبب أقل صلة عند استخدام ذاكرة التخزين المؤقت للصفحات (bfcache)، لأنّه تتم استعادة الصفحة الكاملة كما لو تم تركها مفتوحة طوال الوقت تقريبًا.

كيف يغيّر Chrome هذا السلوك

أعلن فريق Chrome عن نية تغيير هذا السلوك، ولكنه يتّخذ نهجًا حذرًا في هذا التغيير. لقد بدأنا بإجراء التجارب منذ الإصدار 116 من Chrome، وكان يتم تنفيذها على ‎5% من عمليات تحميل الصفحات حتى وقت قريب.

لقد زِدنا هذه النسبة إلى% 10 من عمليات تحميل الصفحات في 2 تشرين الأول (أكتوبر)، وننوي زيادتها إلى% 20 من عمليات تحميل الصفحات في شهر تشرين الثاني (نوفمبر)، بنسبة% 50 في أوائل العام المقبل. وسنطرح هذه الميزة بالكامل بعد ذلك بفترة قصيرة، وسنناقش بعض عمليات الإيقاف في المستقبل.

البيانات الحسّاسة

على الرغم من أنّ تحليلنا يُظهر أنّ معظم عمليات التنقّل للخلف أو للأمام لا تتضمّن بيانات حسّاسة، وبالتالي يجب أن تكون مؤهّلة لاستخدام ذاكرة التخزين المؤقت للصفحات (bfcache)، هناك حالات لا يجب فيها وضع الصفحات في ذاكرة التخزين المؤقت للصفحات (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

في حال انطباق أي من الاستثناءات السابقة، مثلاً تغيير ملفات تعريف الارتباط، سيؤدي ذلك إلى منع الصفحة من استخدام ميزة "التخزين المؤقت للصفحات" بسبب "لا يمكن للصفحات التي يحتوي موردها الرئيسي Cache-Control: no-store على ميزة "التخزين المؤقت للصفحات" التي تظهر في أداة اختبار ذاكرة التخزين المؤقت في أدوات مطوّري البرامج في Chrome.

يمكنك استخدام صفحة اختبار bfcache هذه للاختبار مع هذه العلامة أو بدونها.

معلومات يجب أن يعرفها المطوّرون

على الرغم من أنّ المطوّرين لن يحتاجوا إلى إجراء أي تغييرات ليستفيد المستخدمون من هذا الاستخدام الأكبر لـ bfcache، إلا أنّ هناك بعض الأمور التي قد يحتاجون إلى أخذها في الاعتبار نتيجةً لذلك. هذه هي الاعتبارات نفسها التي ربما واجهتها مواقع إلكترونية أخرى في الإطلاق الأولي لخدمة bfcache في كانون الأول (ديسمبر) 2021.

التأثير على الأداء

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

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

إحصاءات التأثير

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

لذلك، قد تلاحظ المواقع الإلكترونية انخفاضًا في عمليات تحميل الصفحات في إحصاءاتها عند بدء استخدام bfcache لأول مرة. ننصحك بالنظر إلى هذه الزيارات على أنّها مشاهدات صفحة، وذلك من خلال ضبط مستمعين لحدث 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');
  }
});

معالجة التعديلات عند استعادة الصفحة

بما أنّ المواقع الإلكترونية قد تلاحظ الآن استخدام ميزة "التخزين المؤقت للصفحات" عندما لم تكن تلاحظ ذلك من قبل، وبدلًا من إعادة تحميل الصفحة بالكامل باستخدام بيانات جديدة، قد يريد المطوّرون إعادة تحميل البيانات عند استعادة ميزة "التخزين المؤقت للصفحات".

يمكن تشغيل التعديلات بطريقة مشابهة لتسجيل مشاهدات صفحات إضافية للإحصاءات باستخدام الحدث pageshow والتحقّق من الموقع persisted.

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

التأثير في الإعلانات

على غرار تأثير الإحصاءات، قد تلاحظ المواقع الإلكترونية انخفاضًا في مرّات ظهور الإعلانات إذا كانت الإعلانات لا يتم تحميلها إلا عند تحميل الصفحة. يمكن إعادة تحميل الإعلانات آليًا عند استعادة bfcache لضمان التطابق مع عمليات تحميل الصفحة بالكامل، وذلك باستخدام الحدث pageshow والتحقّق من الخاصية persisted مرة أخرى، ولكن قد لا يكون هذا الإجراء مناسبًا في بعض الأحيان. يُرجى الرجوع إلى مستندات مقدّم الإعلانات لمعرفة كيفية بدء عمليات إعادة تحميل الإعلانات.

مزيد من المعلومات حول ميزة "التخزين المؤقت للصفحات"

لمزيد من المعلومات عن ميزة "التخزين المؤقت للصفحات"، يُرجى الاطّلاع على الدليل الفني الشامل لميزة "التخزين المؤقت للصفحات".

ملاحظات

يسرّنا معرفة ملاحظاتك بشأن هذا التغيير الذي يمكن تقديمه في نظام تتبُّع المشاكل في Chrome باستخدام مكوّن bfcache.

الخاتمة

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