تتالي إبطال ذاكرة التخزين المؤقت. الجزء 2

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

النهج رقم 2: عمال الخدمة

الحل الثاني للمشكلة هو إعادة إنتاج وظائف بطاقات الاستيراد باستخدام عامل خدمة.

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

 const importMap = {  '/main.mjs': '/main-1a2b.mjs',  '/dep1.mjs': '/dep1-b2c3.mjs',  '/dep2.mjs': '/dep2-3c4d.mjs',  '/dep3.mjs': '/dep3-d4e5.mjs',  '/vendor.mjs': '/vendor-5e6f.mjs', }; addEventListener('fetch', (event) => {  const oldPath = new URL(event.request.url, location).pathname;  if (importMap.hasOwnProperty(oldPath)) {    const newPath = importMap[oldPath];    event.respondWith(fetch(new Request(newPath, event.request)));  } }); 

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

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

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

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

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

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

لتنظيم التخزين المؤقت الأولي للملفات باستخدام مكتبة فحص صندوق العمل ، يمكنك تمرير عناوين الملفات والسلاسل مع معلومات إصدار هذه الملفات إلى طريقة مكتبة precacheAndRoute() :

 import {preacacheAndRoute} from 'workbox-precaching'; precacheAndRoute([  {url: '/main.mjs', revision: '1a2b'},  {url: '/dep1.mjs', revision: 'b2c3'},  {url: '/dep2.mjs', revision: '3c4d'},  {url: '/dep3.mjs', revision: 'd4e5'},  {url: '/vendor.mjs', revision: '5e6f'}, ]); 

كيف بالضبط لإنشاء خطوط مع الإصدارات متروك للمطور نفسه. ولكن إذا كان لا يريد إنشاء هذه الملفات بنفسه ، فستساعد مهمة إنشاء بيان ما قبل التخزين المؤقت على تبسيط حزم العمل الخاصة ببناء صندوق العمل وحزم العمل و webpack-webpack-plugins (حتى يتمكنوا من إنشاء كل رمز عامل الخدمة).

يحتوي مشروع العرض التوضيحي الخاص بي على مثال لتطبيق التخزين المؤقت الأولي باستخدام عامل خدمة في تطبيق Rollup (باستخدام workbox-cli cli ) وفي تطبيق webpack (باستخدام workbox-webpack-plugin ).

المنهج رقم 3: البرامج النصية المخصصة لتحميل الموارد

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

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

إذا كنت تستخدم Rollup ، فيمكنك ضبط خيار output.format على system . في هذه الحالة ، سيتم تنفيذ خريطة استيراد للتطبيق بالطريقة نفسها التي تم وصفها في وصف الطريقة الأولى لحل مشكلة إبطال ذاكرة التخزين المؤقت المتتالية.

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

ebWebpack وتحميل الموارد باستخدام البرامج النصية

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

تتمثل ميزة هذا النهج في أن وقت تشغيل حزمة الويب يمكن (وبالتالي فهو يعمل بالفعل) أن يتضمن تعييناته الخاصة بين أسماء / معرّفات الأجزاء وعناوينها (يشبه هذا ما أوصي به هنا). هذا يعني أن حزم webpack التي تستخدم تقسيم الرموز تكون أقل عرضة للمعاناة من إبطال ذاكرة التخزين المؤقت المتتالية.

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

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

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

موارد مشروع الويب الأخرى

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

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

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

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

النتائج

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

إذا تحدثنا عن الخيار الأفضل ، فبصراحة ، هذا يعتمد على الكثير.

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

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

بالإضافة إلى ذلك ، يعد عمال الخدمة الخيار الوحيد لأولئك الذين يستخدمون وحدات JavaScript في الإنتاج. (وبالنظر إلى أن 98٪ من المستخدمين لديهم متصفحات تدعم كلاً من العاملين بالخدمة ووحدات JS ، لم يكن من الصعب علي اختيار هذا الخيار).

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

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

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

أعزائي القراء! هل يؤثر إبطال التخزين المؤقت المتتالي على مشروعك؟ إذا كان الأمر كذلك ، فيرجى إخبارنا كيف تخطط لحلها.