يمكنك الاستجابة لطلبات التنقّل بدون انتظار الشبكة باستخدام مشغّل خدمات.
طلبات التنقّل هي طلبات لمستندات 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 على موقعك الإلكتروني، يمكنك استخدام استراتيجية التخزين المؤقت لوقت التشغيل stale-while-revalidate. ومع ذلك، يجب توخي الحذر بشأن هذا النهج، لأنّه يتم تخزين كل مستند HTML فردي مؤقتًا وتحديثه بشكل منفصل. يكون استخدام التخزين المؤقت أثناء التشغيل لملفات HTML مناسبًا إذا كان لديك عدد قليل من عناوين URL التي تتم زيارتها بشكل متكرر من قِبل مجموعة المستخدمين نفسها، وإذا كنت لا تمانع إعادة التحقق من عناوين URL هذه بشكل مستقل عن بعضها البعض.
التطبيقات من صفحة واحدة
تستخدم تطبيقات الويب الحديثة عادةً بنية الصفحة الواحدة. وفيها، يعدّل رمز JavaScript من جهة العميل ترميز HTML استجابةً لإجراءات المستخدمين. يستخدم هذا النموذج واجهة برمجة التطبيقات للسجلّ لتعديل عنوان URL الحالي أثناء تفاعل المستخدم مع تطبيق الويب، ما يؤدي إلى ما يُعرف فعليًا بالتنقّل "المحاكي". وعلى الرغم من أنّ عمليات التنقّل اللاحقة قد تكون "زائفة"، فإنّ عملية التنقّل الأولية تكون حقيقية، ومن المهم التأكّد من عدم حظرها على الشبكة.
لحسن الحظ، إذا كنت تستخدم بنية الصفحة الواحدة، هناك نمط مباشر يمكنك اتّباعه لعرض التنقّل الأولي من ذاكرة التخزين المؤقت، وهو هيكل التطبيق. في هذا النموذج، يستجيب مشغّل الخدمات لطلبات التنقّل من خلال عرض ملف HTML واحد نفسه الذي تم تخزينه مسبقًا، بغض النظر عن عنوان URL المطلوب. يجب أن يكون ملف HTML هذا بسيطًا، ويتكوّن مثلاً من مؤشر تحميل عام أو محتوى هيكلي. بعد أن يحمّل المتصفّح ملف HTML هذا من ذاكرة التخزين المؤقت، يتولّى رمز JavaScript الحالي من جهة العميل المهمة ويعرض محتوى HTML الصحيح لعنوان URL من طلب التنقّل الأصلي.
توفّر Workbox الأدوات اللازمة لتطبيق هذا النهج، إذ تتيح لك السمة navigateFallback
option تحديد مستند HTML الذي تريد استخدامه كهيكل التطبيق، بالإضافة إلى قائمة اختيارية مسموح بها وقائمة محظورة لحصر هذا السلوك في مجموعة فرعية من عناوين URL.
التطبيقات المتعدّدة الصفحات
إذا كان خادم الويب ينشئ رمز HTML لموقعك الإلكتروني بشكل ديناميكي، أو إذا كان لديك أكثر من بضع عشرات من الصفحات الفريدة، سيكون من الصعب تجنُّب الشبكة عند معالجة طلبات التنقّل. من المرجّح أن تنطبق عليك النصائح الواردة في قسم كل ما تبقّى.
ولكن بالنسبة إلى مجموعة فرعية معيّنة من التطبيقات المتعدّدة الصفحات، قد تتمكّن من تنفيذ مشغّل خدمات يكرّر بالكامل المنطق المستخدَم في خادم الويب لإنشاء رمز HTML. تعمل هذه الطريقة بشكل أفضل إذا كان بإمكانك مشاركة معلومات التوجيه والنمذجة بين بيئات الخادم وعامل الخدمة، وبشكل خاص، إذا كان خادم الويب يستخدم JavaScript (بدون الاعتماد على ميزات خاصة بـ Node.js، مثل الوصول إلى نظام الملفات).
إذا كان خادم الويب الخاص بك يندرج ضمن هذه الفئة وأردت استكشاف طريقة واحدة لنقل إنشاء HTML من الشبكة إلى مشغّل الخدمات، يمكنك الاطّلاع على الإرشادات الواردة في مقالة Beyond SPAs: alternative architectures for your PWA (ما بعد تطبيقات الصفحة الواحدة: البُنى البديلة لتطبيقات الويب التقدّمية) للبدء.
كل شيء آخر
إذا لم تتمكّن من الاستجابة لطلبات التنقّل باستخدام ملفات HTML المخزّنة مؤقتًا، عليك اتّخاذ خطوات لضمان أنّ إضافة مشغّل خدمات إلى موقعك الإلكتروني (لمعالجة الطلبات الأخرى غير المتعلّقة بملفات HTML) لن تؤدي إلى إبطاء عمليات التنقّل. سيؤدي بدء تشغيل مشغّل الخدمات بدون استخدامه للردّ على طلب تنقّل إلى حدوث قدر بسيط من وقت الاستجابة (كما هو موضّح في إنشاء تطبيقات أسرع وأكثر مرونة باستخدام مشغّل الخدمات). يمكنك تقليل هذا الوقت الإضافي من خلال تفعيل ميزة تُسمى التحميل المُسبق للتنقّل، ثم استخدام استجابة الشبكة التي تم تحميلها مُسبقًا داخل معالج الأحداث fetch.
يوفّر Workbox مكتبة مساعدة ترصد ما إذا كانت ميزة "التحميل المُسبَق للتنقّل" متاحة، وإذا كانت كذلك، فإنّها تبسّط عملية إعلام مشغّل الخدمات باستخدام استجابة الشبكة.