يمكنك الاستجابة لطلبات التنقل بدون الانتظار على الشبكة باستخدام عامل خدمة.
طلبات التنقل هي طلبات لمستندات HTML ينشئها المتصفح كلما أدخلت عنوان URL جديدًا في شريط التنقل أو تتبع رابطًا على صفحة ينقلك إلى عنوان URL جديد. هذا هو المكان الذي يُحدث فيه العاملون في مجال الخدمات أكبر تأثير لهم على الأداء: إذا كنت تستخدم عامل خدمة للرد على طلبات التنقل بدون انتظار الشبكة، يمكنك التأكد من سرعة التنقل بشكل موثوق، بالإضافة إلى المرونة في حالة عدم توفر الشبكة. وهذا هو أكبر مكسب منفرد في الأداء ينتج من مشغّل الخدمات، مقارنةً بما هو ممكن باستخدام التخزين المؤقت عبر HTTP.
كما هو موضّح في دليل تحديد الموارد التي تم تحميلها من الشبكة، يكون طلب التنقّل هو الأول من بين العديد من الطلبات التي يُحتمل أن يتم إجراؤها خلال "العرض الإعلاني بدون انقطاع" لحركة بيانات الشبكة. يبدأ محتوى HTML الذي تحمِّله عبر طلب التنقّل تسلسل جميع الطلبات الأخرى للموارد الفرعية مثل الصور والنصوص البرمجية والأنماط.
داخل معالِج أحداث fetch الخاص بعامل الخدمات، يمكنك تحديد ما إذا كان الطلب عبارة عن عملية تنقُّل من خلال وضع علامة في المربّع بجانب السمة request.mode في FetchEvent. وإذا تم ضبطها على 'navigate'،
يكون طلب تنقُّل.
وكقاعدة عامة، لا تستخدم علامة Cache-Control headers طويلة الأمد لتخزين
استجابة HTML مؤقتًا لطلب التنقّل. ويجب أن يشعروا بالرضا عادةً عن طريق الشبكة،
باستخدام Cache-Control: no-cache، لضمان أن تنسيق HTML وسلسلة طلبات الشبكة اللاحقة (بشكل معقول) محدَّثان. مخالفة الشبكة في كل مرة ينتقل فيها المستخدم إلى صفحة جديدة، مع الأسف يعني أن كل عملية تنقل قد تكون بطيئة. وهذا يعني على الأقل أنّ الموقع الإلكتروني لن يكون سريعًا بشكل موثوق.
أساليب مختلفة للهياكل
قد يكون من الصعب معرفة كيفية الاستجابة لطلبات التنقّل مع تجنب الشبكة. ويعتمد الأسلوب الصحيح بشكل كبير على بنية موقعك الإلكتروني وعدد عناوين URL الفريدة التي قد ينتقل إليها المستخدمون.
على الرغم من عدم وجود حل واحد يناسب الجميع، إلا أن الإرشادات العامة التالية يُفترض أن تساعدك في تحديد النهج الأكثر قابلية للتطبيق.
المواقع الثابتة الصغيرة
إذا كان تطبيق الويب يتكون من عدد صغير نسبيًا (بضع عشرين) عناوين URL فريدة، وكان كل عنوان من عناوين URL هذه يتوافق مع ملف HTML ثابت مختلف، فإن إحدى المناهج القابلة للتطبيق هي تخزين جميع ملفات HTML مؤقتًا والاستجابة لطلبات التنقل باستخدام ملف HTML مخزن مؤقتًا ومناسب.
باستخدام الإعداد المسبق، يمكنك تخزين رمز HTML مؤقتًا مقدمًا فور تثبيت مشغّل الخدمات، وتعديل رمز HTML المخبأ في كل مرة تعيد فيها إنشاء موقعك الإلكتروني وإعادة نشر مشغّل الخدمات.
بدلاً من ذلك، إذا كنت تفضِّل تجنب إرسال ملفات HTML مؤقتًا بالكامل، ربما لأنّ المستخدمين يميلون إلى الانتقال إلى مجموعة فرعية فقط من عناوين URL على موقعك الإلكتروني، يمكنك استخدام استراتيجية التخزين المؤقت في وقت التشغيل "تقريبًا أثناء إعادة التحقق". ومع ذلك، كن حذرًا بشأن هذه الطريقة، حيث يتم تخزين كل مستند HTML فردي مؤقتًا وتحديثه بشكل منفصل. ومن الأنسب استخدام التخزين المؤقت في وقت التشغيل للغة HTML إذا كان لديك عدد صغير من عناوين URL التي تتم إعادة زيارتها بشكل متكرر من قِبل مجموعة المستخدمين نفسها وإذا كنت تشعر بارتياح حيال إعادة التحقق من عناوين URL هذه بشكل مستقل عن بعضها.
تطبيقات من صفحة واحدة
تستخدم تطبيقات الويب الحديثة بنية الصفحة الواحدة بشكل متكرر. وفيها، تعدِّل JavaScript من جانب العميل رمز HTML استجابةً لإجراءات المستخدم. يستخدم هذا النموذج واجهة برمجة التطبيقات للسجلّ لتعديل عنوان URL الحالي أثناء تفاعل المستخدم مع تطبيق الويب، ما يؤدي إلى عملية تنقل "تمت محاكاتها" بفاعلية. وعلى الرغم من أن عمليات التنقل اللاحقة قد تكون "زائفة"، إلا أن عملية التنقل الأولية تكون حقيقية، ولا يزال من المهم التأكد من عدم حظره على الشبكة.
لحسن الحظ، إذا كنت تستخدم بنية الصفحة الواحدة، هناك نمط مباشر يجب اتّباعه لعرض عملية التنقّل الأولية من ذاكرة التخزين المؤقت: Application Shell. في هذا النموذج، يستجيب عامل الخدمات لطلبات التنقّل من خلال عرض ملف HTML واحد واحد سبق أن تم تخزينه مؤقتًا، بغض النظر عن عنوان URL المطلوب. يجب أن يكون رمز HTML هذا مجرّدًا ومكونًا من مؤشر تحميل عام أو محتوى هيكلي. بعد أن يحمِّل المتصفّح محتوى HTML هذا من ذاكرة التخزين المؤقت، تتولّى لغة JavaScript الحالية من جهة العميل مهام عرض محتوى HTML الصحيح لعنوان URL من طلب التنقّل الأصلي.
ويوفّر Workbox الأدوات التي تحتاجها لتنفيذ هذه الطريقة، ويتيح لك navigateFallback
option تحديد مستند HTML الذي تريد استخدامه كهيكل للتطبيق، بالإضافة إلى قائمة اختيارية تتيح السماح والرفض بحصر هذا السلوك في مجموعة فرعية من عناوين URL.
تطبيقات من صفحات متعددة
وإذا كان خادم الويب ينشئ محتوى HTML الخاص بموقعك الإلكتروني بشكل ديناميكي، أو إذا كان لديك أكثر من بضع عشرات من الصفحات الفريدة، سيكون من الصعب جدًا تجنُّب الشبكة عند التعامل مع طلبات التنقّل. من المحتمل أن تنطبق عليك النصائح الواردة في كل شيء آخر.
ولكن بالنسبة إلى مجموعة فرعية معيّنة من التطبيقات المتعددة الصفحات، قد تتمكن من تنفيذ عامل خدمة ينسخ المنطق المستخدم في خادم الويب بشكل كامل لإنشاء رمز HTML. تعمل هذه الطريقة بشكل أفضل إذا كان بإمكانك مشاركة معلومات التوجيه والنماذج بين بيئات مشغّلي الخدمات والخادم، وخاصةً إذا كان خادم الويب يستخدم JavaScript (بدون الاعتماد على الميزات الخاصة بـ Node.js، مثل الوصول إلى نظام الملفات).
إذا كان خادم الويب الخاص بك يندرج ضمن هذه الفئة وكنت تريد استكشاف طريقة واحدة لنقل إنشاء HTML خارج الشبكة وإلى مشغّل الخدمات، يمكن أن تساعدك الإرشادات الواردة في مقالة ما بعد SPA: بنيات بديلة لتطبيق الويب التقدّمي (PWA) في البدء.
كل شيء آخر
إذا لم تتمكّن من الاستجابة لطلبات التنقّل باستخدام رمز HTML الذي تم تخزينه مؤقتًا، عليك اتخاذ خطوات لضمان
عدم إبطاء عمليات التنقل بإضافة عامل خدمة إلى موقعك الإلكتروني (لمعالجة الطلبات الأخرى التي ليست بتنسيق HTML). سيؤدي بدء مشغّل الخدمات بدون استخدامه للاستجابة لطلب التنقل إلى توفير وقت استجابة صغير (كما هو موضّح في مقالة إنشاء تطبيقات أسرع وأكثر مرونةً
مع مشغّل الخدمات). يمكنك تخفيف هذه الأعباء عن طريق تفعيل ميزة تُسمّى التحميل المسبق
للتنقّل، ثم استخدام
استجابة الشبكة
التي تم تحميلها مسبقًا داخل معالِج أحداث fetch.
يوفّر Workbox مكتبة مساعدة ترصد ما إذا كان التحميل المسبق للتنقّل متاحًا. وفي حال كان الأمر كذلك، يبسّط عملية طلب استخدام استجابة الشبكة من مشغّل الخدمات.
صورة من "آرون بوردن" على قناة Un وتتوفر