معالجة طلبات التنقّل

الاستجابة لطلبات التنقل دون الانتظار على الشبكة باستخدام أحد مشغّلي الخدمات.

جيف بوسنيك

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

على النحو الموضّح بالتفصيل في دليل تحديد الموارد التي تم تحميلها من دليل الشبكة، يكون طلب التنقّل هو الأول من بين الطلبات العديدة التي يُحتمل أن تكون قد تم إجراؤها خلال "تدفق" حركة بيانات الشبكة. إنّ رمز HTML الذي تُحمِّله من خلال طلب التنقّل يبدأ تدفق جميع الطلبات الأخرى للموارد الفرعية مثل الصور والنصوص البرمجية والأنماط.

داخل معالج أحداث fetch لدى مشغّل الخدمات، يمكنك تحديد ما إذا كان الطلب هو التنقّل من خلال الاطّلاع على السمة request.mode على FetchEvent. في حال ضبطها على 'navigate'، فيكون طلب تنقل.

كقاعدة عامة، لا تستخدِم Cache-Control headers طويلة الأجل لتخزين استجابة HTML لطلب التنقّل في ذاكرة التخزين المؤقت. يجب أن يحصل المستخدمون عادةً على رضاهم من خلال الشبكة باستخدام Cache-Control: no-cache، لضمان أن يكون تنسيق HTML، إلى جانب سلسلة طلبات الشبكة اللاحقة، حديثة (على نحو معقول). إنّ تعذُّر الاتصال بالشبكة في كل مرة ينتقل فيها المستخدم إلى صفحة جديدة يعني لسوء الحظ أن كل عملية تنقّل قد تكون بطيئة. وهذا يعني على الأقل أنّها لن تكون سريعة بشكل موثوق.

ملاحظة: Cache-Control: no-cache تعني أنه على المتصفح التحقق (أو "إعادة التحقق") مع الخادم قبل استخدام مورد تم تخزينه مؤقتًا في السابق. يتطلب هذا اتصال شبكة ذهاب وعودة قبل التمكن من استخدام المورد.

مناهج مختلفة للهياكل

قد يكون معرفة كيفية الاستجابة لطلبات التنقّل مع تجنب الاتصال بالشبكة أمرًا صعبًا. يعتمد النهج الصحيح إلى حد كبير على بنية موقع الويب وعدد عناوين URL الفريدة التي قد ينتقل إليها المستخدمون.

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

المواقع الثابتة الصغيرة

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

وباستخدام ميزة التخزين المؤقت، يمكنك تخزين ملف HTML مؤقتًا مسبقًا فور تثبيت مشغّل الخدمة، وتحديث رمز HTML المُخزَّن مؤقتًا في كل مرة تعيد فيها إنشاء الموقع الإلكتروني وتعيد نشر مشغّل الخدمة.

بدلاً من ذلك، إذا كنت تفضّل تجنُّب التخزين المؤقت لكل ترميز HTML مسبقًا، ربما لأن المستخدمين يميلون إلى الانتقال إلى مجموعة فرعية فقط من عناوين URL على موقعك الإلكتروني، يمكنك استخدام استراتيجية التخزين المؤقت لوقت التشغيل قديمًا أثناء إعادة التحقق. ومع ذلك، كن حذرًا بشأن هذا النهج، حيث يتم تخزين كل مستند 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 خارج الشبكة إلى مشغّل الخدمات، يمكن أن تساعدك الإرشادات الواردة في ما بعد SPA: البُنى الأساسية البديلة لتطبيق PWA.

كل شيء آخر

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

يوفّر Workspace مكتبة مساعِدة ترصد ما إذا كان التحميل المُسبق للتنقّل متاحًا أم لا، وبالتالي يبسِّط عملية إبلاغ عامل الخدمة باستخدام استجابة الشبكة.

صورة من تصوير آرون بوردين على قناة UnLaunch