🤾🏼 👨‍👨‍👦 🍛 BFCache ، أو هناك والعودة. تقرير ياندكس 🛸 ⤴️ 👋🏻

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

- مرحبا ، اسمي فيكتور. أعمل كجزء من فريق كبير إلى حد ما يتعامل مع صفحة البحث.

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

سأقدم عددًا من الأمثلة من شركات معروفة. أجرت Google تجربة. لقد قاموا عن قصد بتضمين تأخير في صفحة البحث وقياس مدى تأثير ذلك على الأداء. اتضح أنه في المتوسط كانت هناك عمليات بحث أقل بنسبة نصف بالمائة لكل مستخدم. ما هو نصف بالمائة؟ احسب: نصف بالمائة من مئات الملايين من مستخدمي Google عدد كبير جدًا.

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

مثال من AliExpress. لقد قاموا بتسريع موقعهم بنسبة 36٪ وتلقوا طلبات أكثر بكثير من المستخدمين. الأوامر هي أموال مباشرة. بشكل عام ، من الواضح بالفعل للجميع أن السرعة مهمة جدًا ، فهي تؤثر ، من خلال عدد معين من المقاييس ، على الأموال المكتسبة.

وعامل آخر. اليوم تحدثنا بالفعل عن تحسين الصورة. من خلال تحسين حركة المرور الخاصة بك ، وتقليل عدد التنزيلات ، فإنك تدفع أموالًا أقل للمضيفين لحركة المرور الصادرة. هذا هو المال الذي سيبقى في جيبك. ماذا لو عرضت عليك فجأة خصمًا بنسبة 10٪ على حركة المرور من أي مضيف بدون أي قيود وشروط؟ وإذا كنت أقترح التأكد من تحميل حصة صفحاتك - على سبيل المثال ، عشرة بالمائة - بواسطة المستخدم على الفور تقريبًا؟ لن يرفض أحد.

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

بادئ ذي بدء ، تجمع Google إحصاءات حول كيفية استخدام هذه المتصفحات في متصفحاتها. وقد نشروا مثل هذا الرقم: يتبين ، في المتوسط ، من جميع فتحات الصفحات ، من كل التنقل في متصفح Chrome المحمول ، أن حوالي 19٪ هي حركة ذهابًا وإيابًا من خلال القصة. فكر ماذا يعني ذلك؟ إذا كنت تقريبًا ، اتضح أن 20٪ من التنقل ينتقل إلى الصفحة التي انتقل إليها المستخدم للتو.

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

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

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

الحل يقترح نفسه. ماذا نفعل؟ نحن ، عندما يغادر المستخدم صفحتنا ، لا نقوم بتنظيفها على الفور. نقوم ببساطة بحفظ حالتها وإخفائها بصريًا عن المستخدم بحيث تظل تحت غطاء المتصفح تحت تصرف المتصفح.

ماذا سنفعل إذا قرر المستخدم العودة؟ فقط أظهر له نفس الصفحة المحفوظة. يمكن عرضها على الفور تقريبا.

تسمى هذه التقنية ذاكرة التخزين المؤقت للخلف / للأمام ، من الكلمات "ذهابًا وإيابًا". اختصار لـ bfcache.

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

إظهار ملف GIF

مثال مماثل من بحثنا. على اليسار يوجد Safari المعتاد على macOS مع تعطيل bfcache ، على اليمين هو نفس Safari مع الإعدادات الافتراضية وتم تمكين bfcache. هذه حالة شائعة إلى حد ما: يأتي الشخص في البحث ، وقد لا يعرف بالضبط ما يبحث عنه ، وقد يطلب العديد من خيارات الاستعلام. سألت الطلب الأول - شيء غير صحيح. يبدو أن الطلب الثاني أفضل. ثالثًا - لا ، أسوأ ، ارجع إلى الطلب السابق. وفي هذه اللحظة ، سيكون من الجيد ألا تجعله ينتظر. لقد شاهد هذا الطلب السابق للتو ، أظهره على الفور.

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

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

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

API ومتصفح الدعم

أقرب إلى الموضوع. لنفترض أنني أقنعتك بالفعل ، أنت: "نعم ، موضوع جيد ، يجب أن نعمل مع هذا." ما هي واجهات برمجة التطبيقات التي لدينا تحت تصرفنا ، ما الذي يمكننا العمل معه إذا اتفقنا على أخذ bfcache في الاعتبار ، وكيف يتم دعم ذلك من قبل المتصفحات؟

أين يوجد bfcache بالفعل ، أين يمكنني رؤيته؟

- تم تنفيذه منذ فترة طويلة في متصفحات Firefox و Safari (و macOS و iOS) ، وكذلك في Internet Explorer 11 (!). عادة نقوم بتوبيخ مطوري Microsoft ، لكنهم حاولوا هنا للتو.

- يتم تنفيذه في متصفح UC Browser 11/12 ، إصدار Android.

- فجأة ليس في كروم. وفي Chromium هذه الميزة قيد التطوير.

لذلك ، عندما يفعلون ذلك في Chromium ، ستحصل جميع هذه المتصفحات تقريبًا (وهذه ليست قائمة كاملة) على هذه الوظيفة عاجلاً أم آجلاً - مجانًا ، بدون SMS وتسجيل.

هل هناك أي نوع من API؟ أريد إدارة bfcache ، أريد تشغيله وإيقافه مباشرة من JavaScript ، لمعرفة ما إذا كانت هناك أي صفحة في bfcache أم لا. ماذا عن مثل API؟ لا يوجد مثل API. وقد تم ذلك بوعي: يجب ألا تريد الصفحة تشغيل bfcache أو إيقاف تشغيلها للجميع ولذاتها. أو معرفة ما إذا كان هناك أي شخص في هذا bfcache أم لا. كل هذا بسبب الأمن.

^{_{رابط من الشريحة}}

لكن ماذا لدينا؟ أنواع الملاحة. هناك نوع من رابط الرابط المسبق ، عندما نريد عرض صفحة مسبقًا. هناك نوع خاص من التنقل بالنسبة له: سيتم فتح هذه الصفحة باستخدام NavigationType “prerender”. إذا قمنا فقط بفتح الصفحة في متصفح ، فسيكون هناك "تنقل". إذا نقرنا على زر "تحديث" ، فسيتم "إعادة التحميل".

نحن مهتمون بنوع التنقل "back_forward" هنا ، وهذا يشير بوضوح إلى أن المستخدم تحرك ذهابًا وإيابًا من خلال القصة. هذا هو بالضبط نوع التنقل الذي يمكن أن يعمل به bfcache.

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

وفقًا لذلك ، إذا كان المتصفح لن يخزن الصفحة مؤقتًا ، فسيستمر إخفاء الصفحة كاذبًا. وإذا كان المتصفح يعرض الصفحة أثناء التحميل العادي ، أو لا يستخدم bfcache ، فسيستمر عرض الصفحات أيضًا كاذبًا.

^{_{رابط من الشريحة}}

يتوفر دعم الأحداث في جميع المتصفحات تقريبًا ، حتى تلك التي لا تدعم bfcache حتى الآن.

^{_{الارتباط من الشريحة}}

ينطبق الشيء نفسه على المجال المستمر. إنه موجود بالفعل في Chrome ، ولا يزال Chrome لا يدعم bfcache. أي أن هذا المجال سيكون دائمًا فيه ، ولكنه سيكون خاطئًا في الوقت الحالي.

عندما صادفت هذه الظاهرة ، bfcache ، كان علي دراستها ، والنقر على جميع الجوانب ، ومشاهدة كيف تعمل. أردت على الفور أن أرى في صفحتي عندما أفتح قيمة الحقل الثابت في معالجاتي.

يبدو أن كل شيء بسيط للغاية. لقد كتبت معالجًا وإخراجًا إلى console.log () ما يأتي إلي. ولكن عند فتح DevTools في بعض المتصفحات ، قد يتم إيقاف bfcache فجأة. بمعنى ، لقد فتحت DevTools ، وأعود ذهابًا وإيابًا من خلال الصفحات ، واستمراري في الكذب دائمًا ، والصفحة لا تدخل في bfcache. حسنًا ، لدي أداة قوية أخرى - تنبيه.

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

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

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

أضع هذا الرمز المصحح في برنامج نصي خارجي.

ولكن لا ، لقد سقطت معالجات إخفاء الصفحات في صفحة سفاري! لسبب ما ، فإنها لا تعمل من نص خارجي.

حسنًا ، لدي إصدار يعمل بالفعل. كان علي أن أترك الأمر هكذا.

سأذكر بإيجاز ما تمكنت من التعامل معه في يوم واحد فقط. أولاً ، يمكن لـ DevTools تعطيل التخزين المؤقت. ربما تتذكر أنه في DevTools على علامة التبويب "الشبكة" في Chrome ، يوجد مربع اختيار "تعطيل ذاكرة التخزين المؤقت". يقوم بتعطيل ذاكرة التخزين المؤقت للشبكة ، وقد لا يؤثر على bfcache ، أو ربما. التشبيه واضح: لقد فتحنا DevTools ، مما يعني أننا نطور وقد لا نحتاج إلى التخزين المؤقت. ربما يزعجنا.

الميزة الثانية هي التنبيه. سيتجاهله Firefox و Safari بصمت ويستمران في تنفيذ المعالجات بشكل أكبر ، كما لو لم يكن هناك تنبيه. و Chrome واحد فقط في وحدة التحكم سيكتب خطأ باللون الأحمر - لديك تنبيه ، لقد قمت بحظره ، تعرف عنه!

مرة أخرى ، أذكرك أنه قد لا يتم استدعاء معالجات من برنامج نصي خارجي في Safari ، وهذا أمر غريب للغاية.

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

ميزات التنفيذ

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

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

ثم بدأت في دمج ما تعلمته في جدول واحد. لدي شيء مثل ما يلي:

قرأت وثائق المتصفحات - لفايرفوكس ، سفاري ، عائلة Chromium. كانت هناك وثائق متاحة على IE ، وإن كانت قديمة. نحن المبرمجين لا يحبون تحديث الوثائق بعد التغييرات في المتصفح؟ عندما أدركت أن المعلومات قديمة ، بدأت في اختبار صفحاتي الصغيرة في المتصفحات والتحقق من واجهة برمجة التطبيقات التي تعمل وأيها لا يعمل.

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

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

ثعلب النار

فيما يلي بعض التفاصيل المثيرة للاهتمام من متصفحات محددة. سأبدأ مع فايرفوكس ، كان أول من فعل كل شيء.

^{_{الارتباط من الشريحة}}

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

^{_{رابط من الشريحة}}

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

إذا كنت تريد التجربة مرة واحدة ، فيمكنك فتح about about: صفحة الشبكات في Firefox. هناك يمكنك إدخال نفس الحقول في قسم "اليومية". يمكننا أن نوضح في حقلين ما وأين يتم تسجيل الدخول ، وباستخدام الأزرار تبدأ السجل وتوقفه.

^{_{رابط من الشريحة}}

متى يرفض Firefox تخزين الصفحة مؤقتًا؟ إذا كانت لديك طلبات غير مكتملة ، بما في ذلك طلبات AJAX أو طلبات موارد مثل الصور ، فسيرفض وضع الصفحة في bfcache. يعتقد أنه لم يكتمل ، لم ينته من التنزيل ، هناك نوع من النشاط المشبوه. لكن كل هذا لا ينطبق على favicon. إذا نسيت الرمز المفضل ، إذا لم يتم تحميله ، فيعتقد - حسنًا ، سيفعل ذلك ، فمن الطبيعي لموقعك.

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

إذا كنت تستخدم IndexedDB ... فهذه قصة مفيدة. سابقًا ، في التنفيذ الأول ، بحثوا: إذا كان لديك IndexedDB وكانت هناك معاملة غير مكتملة ، فإن هذه الصفحة لا يتم تخزينها مؤقتًا ، لأنه ليس من الواضح كيفية التعامل معها (نحن نحاول إخفاءها في منتصف المعاملة). ولكن بعد ذلك فقدوا ببساطة هذه الشفرة أثناء إعادة البيع. وكما قد تتخيل ، لم يكن لديهم اختبارات لهذا. لديهم حتى خلل في متتبع الأخطاء. يبلغ من العمر عامين بالفعل مع شيء. كتب الناس: "bfcache مع IndexedDB لا يعمل بشكل صحيح ، فماذا أفعل؟" أجاب مطورو Firefox - إنه ينهار حقًا ، لقد فقدنا هذا النص فقط أثناء إعادة البيع ، حسنًا ، دعه يستمر. الأخلاق: كتابة الاختبارات ، حتى إذا كتبت فايرفوكس ، وإلا فإن كل شيء يمكن أن ينتهي للأسف.

وهناك عامل آخر مثير للاهتمام لعدم التوافر في bfcache - إذا كان المحتوى المختلط مسموحًا به صراحة. ما هذا؟

^{_{رابط من الشريحة}}

افترض أن صفحتك تفتح عبر HTTPS ، ولكنك ما زلت تحمل بعض الموارد عبر HTTP ، وخاصة النصوص البرمجية. بمعنى ، لديك برنامج نصي غير متعلق بالأمان ، يمكن لأي شخص تعديله.

^{_{الارتباط من الشريحة}}

بشكل افتراضي ، لا يقوم Firefox ، مثل المتصفحات الأخرى ، بتنفيذ مثل هذا البرنامج النصي غير ^{_{المتعلق}} بالأمان الآن. ولكن إذا كان ذلك مهمًا للغاية بالنسبة لك ، فقد صعدت إلى الإعدادات وسمحت بتنفيذها ، ومن ثم ، فلن تخزن هذه الصفحة في ذاكرة التخزين المؤقت. سيقول - حسنًا ، لقد أخبرتني ألا أطبق الشفرة ، ولكن بعد ذلك لا ، لا!

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

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

^{_{رابط من الشريحة}}

لذا ، رمز جيكو. يمكن فتحه وقراءته وعرضه مجانًا على الإنترنت. وتفشيت. هناك أهم طريقة - CanSavePresentation () ، فهي تجيب على السؤال: هل من الممكن تخزين هذا المستند في ذاكرة التخزين المؤقت؟ أي أن هذا هو المصدر النهائي للحقيقة حول ما يتم تنفيذه الآن في Firefox. ومع ذلك - من هناك علمت أنه يمكنك قراءة السجل. هناك مثل هذا المتغير - gPageCacheLog. هذا هو السجل الذي كُتب فيه كل شيء. هذه قصة مثيرة للاهتمام حول رحلة إلى C ++.

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

سفاري

أفظع ما يفعله Safari عندما تصل الصفحة إلى bfcache: إذا كان لديك طلبات AJAX معلقة ، فإن Safari يقتلها فقط.

حتى إذا غطيتهم بمعالجات الأخطاء وحاولت التحقق من كل شيء ، قم بتصحيحه - يبدو كما لو أن الطلب لم يكن موجودًا على الإطلاق. بعد التعافي من bfcache ، لن يكون لديك أي خطأ ، لا "موافق" ، لا شيء على الإطلاق.

يتم استدعاء معالجات إخفاء الصفحات ، كما قلت ، في Safari فقط إذا كانت مكتوبة بخط نصي مضمّن في الصفحة. من برنامج نصي خارجي ، قد يعملون أو لا يعملون - كم هو محظوظ. لكني حذرتك.

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

نقطة أخرى مثيرة للاهتمام. كما تعلم ، يمكنك فتح عدة نوافذ من خلال window.open (). وفي نفس الوقت ، هذه النوافذ لها روابط مع بعضها البعض. أي أنه يمكنهم الصعود في وقت واحد إلى نافذة بعضهم البعض ، وقراءة / كتابة خصائص مختلفة. لا يتداخل فتح النوافذ الفرعية مع bfcache. وهنا ، على الأرجح ، يكون Safari قاسيًا تمامًا كما هو الحال مع طلبات AJAX ، أي أن كل شيء يمزق بشدة وداعًا. مطورو آبل يحبونها أكثر.

مرة أخرى دقيقة C ++! مصادر WebKit ليست سرية أيضًا ، ويمكن أيضًا فتحها وقراءتها ودراستها.

^{_{رابط من الشريحة}}

الموجودة على GitHub ، هناك أبرزت وظيفتين مهمتين:

- canCacheFrame () - تحقق مما إذا كان يمكن تخزين هذا الإطار مؤقتًا.
- في الكائنات المختلفة على الصفحة ، مثل عنصر أو خط HTML ، هناك طرق canSuspendForDocumentSuspension (). هذا الكائن مسؤول عما إذا كان يمكنه التخزين المؤقت أو التجميد أم لا.

وجانب آخر مهم: WebKit لديه اختبارات مريحة للغاية. هناك ، مباشرة في مجلد LayoutTests / fast / history ، في شكل html صغير ومضغوط وموجز ، هناك اختبارات لعمل واجهات برمجة التطبيقات المختلفة التي يتم تنفيذها في Safari مع bfcache. هذا مثال حي لكيفية كتابة التعليمات البرمجية في Safari باستخدام واجهات برمجة التطبيقات هذه وكيف تؤثر أو لا تؤثر على ما إذا كانت تسمح بزيارات bfcache أم لا. من المثير للاهتمام أن نرى.

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

الكروم.

كما قلت بالفعل ، لا يزال العمل جاريا ، كل شيء مغلق تحت العلم. يمكنك تنزيل Chrome Canary الجديد ، انتقل إلى الأعلام. الإعداد مخفي هناك - يمكنك محاولة اللعب به. قد ترى شيئا.

من المثير للاهتمام - لقد تحدثت بالفعل عن فتح صفحة من خلال window.open (). في Chromium ، لا يتم تخزين هذه الصفحات في ذاكرة التخزين المؤقت حتى الآن. لم يعرفوا كيفية حل كل هذا بشكل صحيح ، وقطعوه بلا خجل ، كما هو الحال في Safari ، لا يسمح لهم ضميرهم.

إذا لم يحدث DOMContentLoaded ، فلن يتم تخزين الصفحة أيضًا في ذاكرة التخزين المؤقت.

هناك العديد من واجهات برمجة التطبيقات الجديدة التي تبدأ بـ "الويب" - كما أنها صعبة وغير مفهومة معها ، وحتى الآن تقوم جميعها بإيقاف تشغيل bfcache بشكل افتراضي. أي أنه إذا كان هناك شيء عصري ، يتم استخدام جديد على الصفحة ، مثل WebGL و WebVR و WebUSB و WebBluetooth وما إلى ذلك ، فلن تدخل هذه الصفحة في bfcache.

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

إذا تم تمكين تحديد الموقع الجغرافي ، فإننا لا نقوم أيضًا بتخزينه مؤقتًا حتى الآن. أبسط من ذلك في الوقت الحالي.

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

^{_{رابط من الشريحة}}

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

^{_{رابط من الشريحة}}

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

Internet Explorer 11

رحلة في التاريخ لأولئك الذين لا يزال لديهم IE 11. بالنسبة لأولئك الذين لديهم كل شيء سيئ.

هناك bfcache هناك ، وهذه هي المشكلة الرئيسية ، لأنه يجب عليك التعامل معها. تقول الوثائق أن bfcache من المفترض أن يعمل فقط عبر HTTP. في الواقع ، في الإنتاج ، يعمل أيضًا على HTTPS لسبب ما. الأخلاق: إذا كنت مطورًا ، فيرجى الانتباه إلى وثائقك. ثم عليك أن تعاني بسببها.

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

إذا لم تنته الصفحة من التحميل ، فلن يتم تخزينها أيضًا في ذاكرة التخزين المؤقت. إذا كان شخص ما يستخدم مكونات ActiveX ، فإننا لا نقوم أيضًا بالتخزين المؤقت. وإذا كانت DevTools مفتوحة هناك أيضًا. هذه نقطة مهمة.

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

كان لدينا رمز جميل يحدد ما إذا كنا قد عادنا من ذاكرة التخزين المؤقت أو إعادة تحميلها من الخادم.

الآن يجب أن يتم استكماله بعكاز لـ IE. نحدد أن لدينا IE ، وفي بعض الحلول نفهم أن الصفحة تم استخراجها من ذاكرة التخزين المؤقت ومع ذلك كان لدينا تصفح محفوظات (back_forward).

علاوة على ذلك ، كيف تعرف ما إذا كانت الصفحة مخبأة؟ نأخذ وقت تحميلها. إذا تم تحميله من الخادم في 50 مللي ثانية أو أسرع ، فهذا لا يمكن أن يكون في IE - وهذا يعني أنه من ذاكرة التخزين المؤقت! :)

لقد ذكرت بالفعل التنقل عبر التاريخ. إذا كان لدينا نوع التنقل back_forward ، فراجعنا التاريخ ، وإذا كانت الصفحة من ذاكرة التخزين المؤقت ، فهذا يعني bfcache ، فلا توجد خيارات أخرى في IE.

ماذا بعد؟

ماذا تفعل بعد ذلك بهذه المعرفة؟ لا أريدك أن تنسى كل هذا مثل الكابوس.

- أولاً ، إليك أهم شيء صادفته وما أريد دفعك إليه: استخدم متصفحات مفتوحة المصدر! في الوصول المفتوح إلى الإنترنت الآن ، يوجد رمز المصدر لجميع المتصفحات الرائدة التي يستخدمها عملاؤنا. وهذه هي الوثائق الأكثر صلة بكيفية وكيفية دعمها وأين وكيف تعمل. بما في ذلك هناك اختبارات مكتوبة مباشرة في HTML و JS. استخدم ، انظر!

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

افتح ملف GIF

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

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

كما وعد ، ارتباط بالمواد.

BFCache ، أو هناك والعودة. تقرير ياندكس