الاستجابة لطلبات التنقّل بدون انتظار الشبكة باستخدام عامل خدمة
طلبات التنقّل هي طلبات لمستندات 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 من الشبكة إلى الخدمة العاملة، يمكنك البدء باستخدام الإرشادات الواردة في مقالة ما بعد التطبيقات المُدمجة: البنى المعمارية البديلة لتطبيقك المتوافق مع الأجهزة الجوّالة.
كل شيء آخر
إذا لم تتمكّن من الاستجابة لطلبات التنقّل باستخدام صفحات HTML المخزّنة مؤقتًا، عليك اتّخاذ خطوات لضمان عدم تباطؤ التنقّلات نتيجةً لإضافة عامل خدمة إلى موقعك الإلكتروني (لمعالجة الطلبات الأخرى غير HTML). سيؤدي بدء مشغّل الخدمات بدون استخدامه للردّ على طلب تنقّل
إلى حدوث وقت استجابة بسيط (كما هو موضّح في مقالة إنشاء التطبيقات التي تعمل بشكل أسرع وأكثر ثباتًا
باستخدام مشغّل الخدمات). يمكنك تقليل هذه التكلفة الإجمالية من خلال تفعيل
ميزة تُعرف باسم تحميل ملف التنقّل
مسبَقًا، ثم استخدام
استجابة
الشبكة
التي تم تحميلها مسبقًا داخل معالِج أحداث fetch.
توفّر Workbox مكتبة مساعدة ترصد الميزات لمعرفة ما إذا كان تحميل التنقّل مُتاحًا، وإذا كان الأمر كذلك، تعمل على تبسيط عملية إخبار مشغّل الخدمة باستخدام استجابة الشبكة.
صورة Aaron Burden على Unsplash