الإجراءات المسموح بها وغير المسموح بها للاستعداد المسبق

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

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

يجب إجراء ما يلي: تخزين مواد العرض الثابتة المهمة في ذاكرة التخزين المؤقت مسبقًا

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

• أوراق الأنماط العامة.
• ملفات JavaScript توفّر وظائف عامة.
• هيكل HTML في التطبيق، إذا كان ذلك ينطبق على البنية الأساسية.

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

تنفيذ إجراء: تخزين مؤقت مسبق لإجراء احتياطي بلا اتصال بالإنترنت لمواقع إلكترونية متعددة الصفحات

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

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

import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';

navigationPreload.enable();

// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);

// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
  return request.mode === 'navigate';
}, new NetworkOnly({
  plugins: [
    new PrecacheFallbackPlugin({
      fallbackURL: '/offline.html'
    })
  ]
}));

registerRoute(networkOnlyNavigationRoute);

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

ربما تفعل: ضع في اعتبارك التخطيط المسبق

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

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

ربما لا تفعل ذلك: تخزين مؤقت لملف HTML ثابت

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

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

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

عدم إجراء تخزين مؤقت للصور المتجاوبة أو الرموز المفضّلة

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

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

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

لا تفعل: تخزين الرموز البرمجية مؤقتًا بشكل مسبق

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

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

لا تخزن رموز polyfill مؤقتًا بشكل مسبق. اعتمِد على التخزين المؤقت لوقت التشغيل لضمان عدم إضاعة البيانات إلا في المتصفّحات التي تتطلّب ذلك.

الخلاصة

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

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