بشكل عام، يمكن أن تؤدي ميزة التخزين المؤقت إلى تحسين الأداء من خلال تخزين البيانات حتى يتم عرض الطلبات المستقبلية للبيانات نفسها بشكل أسرع. على سبيل المثال، يمكن أن يتجنّب المورد المخزّن مؤقتًا من الشبكة رحلة ذهاب وإياب إلى الخادم. يمكن أن تؤدي نتيجة الحساب المخزّنة مؤقتًا إلى عدم احتساب الوقت اللازم لإجراء العملية الحسابية نفسها.
في Chrome، يتم استخدام آلية ذاكرة التخزين المؤقت بطرق مختلفة، وذاكرة التخزين المؤقت لبروتوكول HTTP هي أحد الأمثلة على ذلك.
آلية عمل ذاكرة التخزين المؤقت لبروتوكول HTTP في Chrome حاليًا
اعتبارًا من الإصدار 85، يخزّن Chrome الموارد التي يتم جلبها من الشبكة، باستخدام عناوين URL الخاصة بالموارد المعنيّة كمفتاح ذاكرة التخزين المؤقت. (يُستخدَم مفتاح ذاكرة التخزين المؤقت لتحديد مورد مخزّن مؤقتًا).
يوضّح المثال التالي كيفية تخزين صورة واحدة مؤقتًا ومعالجتها في ثلاثة سياقات مختلفة:
https://x.example/doge.png }
يزور مستخدم صفحة (https://a.example) تطلب صورة
(https://x.example/doge.png). يتم طلب الصورة من الشبكة ويتم
تخزينها مؤقتًا باستخدام https://x.example/doge.png كمفتاح.
https://x.example/doge.png }
ينتقل المستخدم نفسه إلى صفحة أخرى (https://b.example) تطلب
الصورة نفسها (https://x.example/doge.png).
يتحقّق المتصفّح من ذاكرة التخزين المؤقت لبروتوكول HTTP لمعرفة
ما إذا كان قد سبق أن تم تخزين هذا المورد في ذاكرة التخزين المؤقت، وذلك باستخدام عنوان URL للصورة كمفتاح. يعثر المتصفّح على مطابقة في ذاكرة التخزين المؤقت، لذا يستخدم النسخة المخزّنة مؤقتًا من المرجع.
https://x.example/doge.png }
ولا يهمّ ما إذا تم تحميل الصورة من داخل إطار iframe. إذا زار المستخدم
موقعًا إلكترونيًا آخر (https://c.example) يتضمّن إطار iframe
(https://d.example) وطلب إطار iframe الصورة نفسها
(https://x.example/doge.png)، سيظل بإمكان المتصفّح تحميل الصورة من
ذاكرة التخزين المؤقت لأنّ مفتاح ذاكرة التخزين المؤقت هو نفسه في جميع الصفحات.
وقد كانت هذه الآلية تعمل بشكل جيد من منظور الأداء منذ فترة طويلة. ومع ذلك، يمكن أن يكشف الوقت الذي يستغرقه الموقع الإلكتروني للردّ على طلبات HTTP عن أنّ المتصفّح قد وصل إلى المورد نفسه في السابق، ما يعرّض المتصفّح لهجمات على الأمان والخصوصية، مثل ما يلي:
- رصد ما إذا كان المستخدِم قد زار موقعًا إلكترونيًا معيّنًا: يمكن للمهاجم رصد سجلّ تصفّح المستخدِم من خلال التحقّق مما إذا كانت ذاكرة التخزين المؤقت تتضمّن موردًا قد يكون خاصًا بموقع إلكتروني معيّن أو مجموعة نموذجية من المواقع الإلكترونية.
- هجوم البحث على مستوى المواقع الإلكترونية: يمكن للمهاجم رصد ما إذا كانت سلسلة عشوائية متوفّرة في نتائج البحث التي يعرضها محرّك بحث معيّن للمستخدم، وذلك من خلال التحقّق مما إذا كانت صورة "ما مِن نتائج بحث" التي يستخدمها موقع إلكتروني معيّن متوفرة في ذاكرة التخزين المؤقت للمتصفّح.
- تتبُّع الإجراءات على مواقع إلكترونية متعددة: يمكن استخدام ذاكرة التخزين المؤقت لتخزين معرّفات مشابهة لملفات تعريف الارتباط بصفتها آلية لتتبُّع الإجراءات على مواقع إلكترونية متعددة.
وللحدّ من هذه المخاطر، سيقسّم Chrome ذاكرة التخزين المؤقت لبروتوكول HTTP بدءًا من الإصدار 86.
كيف سيؤثّر تقسيم ذاكرة التخزين المؤقت في ذاكرة التخزين المؤقت لبروتوكول HTTP في Chrome؟
من خلال تقسيم ذاكرة التخزين المؤقت، سيتمّ استخدام "مفتاح عزل الشبكة" الجديد بالإضافة إلى عنوان URL للمورد لإنشاء مفاتيح للموارد المخزّنة مؤقتًا. يتألّف مفتاح عزل الشبكة من الموقع الإلكتروني ذي المستوى الأعلى والموقع الإلكتروني للإطار الحالي.
راجِع المثال السابق مرة أخرى لمعرفة كيفية عمل تقسيم ذاكرة التخزين المؤقت في سياقات مختلفة:
https://a.example, https://a.example, https://x.example/doge.png }
يزور مستخدم صفحة (https://a.example) تطلب صورة
(https://x.example/doge.png). في هذه الحالة، يتم طلب الصورة من
الشبكة وتخزينها مؤقتًا باستخدام مجموعة تتألف من https://a.example (الموقع الإلكتروني من المستوى الأعلى)،
https://a.example (الموقع الإلكتروني للإطار الحالي)، وhttps://x.example/doge.png (عنوان URL
للمورد) كمفتاح. (يُرجى العِلم أنّه عندما يكون طلب المورد من الإطار العلوي، يكون الموقع الإلكتروني على المستوى الأعلى والموقع الإلكتروني للإطار الحالي في مفتاح عزل الشبكة متطابقَين).
https://b.example, https://b.example, https://x.example/doge.png }
يزور المستخدِم نفسه صفحة مختلفة (https://b.example) تطلب
الصورة نفسها (https://x.example/doge.png). على الرغم من أنّه تم تحميل الصورة نفسها في
المثال السابق، لن يتمّ العثور عليها في ذاكرة التخزين المؤقت لأنّ المفتاح لا يتطابق.
يتم طلب الصورة من الشبكة وتخزينها مؤقتًا باستخدام مجموعة تتألف من https://b.example و
https://b.example وhttps://x.example/doge.png كمفتاح.
https://a.example, https://a.example, https://x.example/doge.png }
يعود المستخدم الآن إلى https://a.example ولكن هذه المرة تم تضمين الصورة
(https://x.example/doge.png) في إطار iframe. في هذه الحالة،
المفتاح هو مجموعة تحتوي على https://a.example وhttps://a.example وhttps://x.example/doge.png
وتحدث مطابقة في ذاكرة التخزين المؤقت. (يُرجى العِلم أنّه عندما يكون الموقع الإلكتروني الأعلى مستوى وإطار iframe
هما الموقع الإلكتروني نفسه، يمكن استخدام المورد المخزّن مؤقتًا في إطار المستوى الأعلى.
https://a.example, https://c.example, https://x.example/doge.png }
عاد المستخدم إلى https://a.example ولكن هذه المرة تكون الصورة مستضافة في ملف div مضمّن من https://c.example.
في هذه الحالة، يتم تنزيل الصورة من الشبكة لأنّه لا يتوفّر
مورد في ذاكرة التخزين المؤقت يتطابق مع المفتاح المكوّن من https://a.example
https://c.example وhttps://x.example/doge.png.
https://a.example, https://c.example, https://x.example/doge.png }
ماذا لو كان النطاق يحتوي على نطاق فرعي أو رقم منفذ؟ يزور المستخدِم
https://subdomain.a.example، الذي يتضمّن إطار iframe
(https://c.example:8080)، الذي يطلب الصورة.
وبما أنّ المفتاح يتم إنشاؤه استنادًا إلى "scheme://eTLD+1"، يتم تجاهل النطاقات الفرعية وأرقام المنفذ. وبالتالي، يحدث تصادم في ذاكرة التخزين المؤقت.
https://a.example, https://c.example, https://x.example/doge.png }
ماذا لو كان عنصر iframe مُدمجًا عدة مرات؟ ينتقل المستخدم إلى
https://a.example، التي تتضمّن إطار iframe (https://b.example)، الذي يتضمّن بدوره
إطار iframe آخر (https://c.example)، الذي يطلب الصورة أخيرًا.
بما أنّ المفتاح مأخوذ من الإطار العلوي (https://a.example) والإطار العميق الذي يحمّل المورد (https://c.example)، يحدث توفّر في ذاكرة التخزين المؤقت.
الأسئلة الشائعة
هل هذه الميزة مفعَّلة على متصفّح Chrome؟ كيف يمكنني التحقّق من ذلك؟
يتم طرح هذه الميزة تدريجيًا حتى أواخر عام 2020. لمعرفة ما إذا كان إصدار Chrome الذي تستخدمه يتوافق مع هذه الميزة، اتّبِع الخطوات التالية:
- افتح
chrome://net-export/واضغط على بدء التسجيل على القرص. - حدِّد مكان حفظ ملف السجلّ على جهاز الكمبيوتر.
- تصفَّح الويب على Chrome لمدة دقيقة.
- ارجع إلى
chrome://net-export/واضغط على إيقاف التسجيل. - الانتقال إلى
https://netlog-viewer.appspot.com/#import - اضغط على اختيار ملف وأرسِل ملف السجل الذي حفظته.
سيظهر لك ناتج ملف السجلّ.
في الصفحة نفسها، ابحث عن SplitCacheByNetworkIsolationKey. إذا كان مصحوبًا بعلامة
Experiment_[****]، يعني ذلك أنّه تم تفعيل ميزة "تقسيم ذاكرة التخزين المؤقت على الويب" في Chrome. إذا كان يليه
Control_[****] أو Default_[****]، يعني ذلك أنّه غير مفعّل.
كيف يمكنني اختبار تقسيم ذاكرة التخزين المؤقت على الويب في متصفّح Chrome؟
لاختبار تقسيم ذاكرة التخزين المؤقت على الويب في Chrome، عليك تشغيل Chrome باستخدام علامة سطر ملف تعريف الارتباط: --enable-features=SplitCacheByNetworkIsolationKey. اتّبِع
التعليمات الواردة في مقالة تشغيل Chromium باستخدام الخيارات لتعرف
كيفية تشغيل Chrome باستخدام خيار في سطر الأوامر على نظام التشغيل.
بصفتي مطوّر ويب، هل هناك أي إجراء يجب اتّخاذه استجابةً لهذا التغيير؟
هذا التغيير ليس جذريًا، ولكن قد يفرض اعتبارات متعلقة بالأداء لبعض خدمات الويب.
على سبيل المثال، قد تلاحظ المواقع الإلكترونية التي تقدّم أعدادًا كبيرة من الموارد القابلة للاحتفاظ بها في ذاكرة التخزين المؤقت على العديد من المواقع الإلكترونية (مثل الخطوط والنصوص البرمجية الرائجة) زيادةً في عدد الزيارات. وقد يعتمد المستخدِمون أيضًا على هذه الخدمات بشكلٍ متزايد.
(هناك اقتراح لتفعيل المكتبات المشتركة بطريقة تحافظ على الخصوصية ويُطلق عليها المكتبات المشتركة على الويب (فيديو تقديمي)، ولكنّه لا يزالقيد المراجعة).
ما هو تأثير هذا التغيير في السلوك؟
يزداد إجمالي معدّل عدم توفّر ذاكرة التخزين المؤقت بنسبة %3.6 تقريبًا، وتكون التغييرات في سرعة عرض المحتوى على الصفحة (FCP) متواضعة (%0.3 تقريبًا)، ويزداد إجمالي نسبة البايتات المحمَّلة من الشبكة بنسبة %4 تقريبًا. يمكنك الاطّلاع على مزيد من المعلومات حول تأثير ذلك على الأداء في الشرح المفصّل لتقسيم ذاكرة التخزين المؤقت لبروتوكول HTTP.
هل هذا معياري؟ هل تتصرف المتصفّحات الأخرى بشكلٍ مختلف؟
تم توحيد أقسام ذاكرة التخزين المؤقت على HTTP في مواصفات الجلب، إلا أنّ المتصفّحات تتصرف بشكلٍ مختلف:
- Chrome: يستخدم مخطط المستوى الأعلى scheme://eTLD+1 ومخطط الإطار scheme://eTLD+1
- Safari: يستخدم eTLD من المستوى الأعلى +1
- Firefox: التحضير لتنفيذ باستخدام top-level scheme://eTLD+1 والتفكير في تضمين مفتاح ثانٍ مثل Chrome
كيف يتم التعامل مع طلب البيانات من العمال؟
يستخدم العاملون المخصّصون المفتاح نفسه المستخدَم في إطارهم الحالي. إنّ مهام الخدمة ومهام المعالجة المشترَكة أكثر تعقيدًا لأنّه يمكن مشاركتها بين عدة مواقع إلكترونية في المستوى الأعلى. يجري حاليًا مناقشة الحلّ لهذه المشكلة.