פקודות 'עשה' ו'עשה' מראש

התיעוד הזה כבר הסבר על טעינה מראש, אבל לא מספיק לגבי הדרך הנכונה לעשות זאת. הדבר חשוב, כי לא משנה אם אתם משתמשים ב-Workbox, קל לשמור מראש יותר מדי קבצים במטמון ולבזבז נתונים ורוחב פס. עליך להפעיל שיקול דעת לגבי ההשפעה של המטען הייעודי (payload) על חוויית המשתמש.

כשתקראו את המסמך הזה, חשוב שתבינו שאלו הנחיות כלליות. ייתכן שהארכיטקטורה והדרישות של האפליקציה ידרשו ממך לבצע פעולות שונות מאלה שהוצעו כאן, אבל ההנחיות האלה הן ברירות מחדל טובות.

מומלץ לבצע: שמירה מראש של נכסים סטטיים קריטיים

המועמדים הטובים ביותר לשמירה מראש במטמון הם נכסים סטטיים קריטיים, אבל מה נחשב כנכס 'קריטי'? מנקודת המבט של המפתח, לפעמים מפתה לחשוב על אפליקציה שלמה כ"קריטית", אבל נקודת המבט של המשתמש היא הדבר החשוב ביותר. חשוב על נכסים קריטיים כנכסים ההכרחיים ביותר כדי לספק חוויית משתמש:

• גיליונות סגנונות גלובליים.
• קובצי JavaScript שמספקים פונקציונליות גלובלית.
• מעטפת HTML של מעטפת האפליקציה, אם הדבר רלוונטי לארכיטקטורה שלכם.

תזכורת: אלו הנחיות כלליות, לא המלצות קשות. כשמעלים נכסים מראש למטמון, מומלץ להכין מראש פחות קבצים במטמון מאשר לבצע יותר פעולות כאלה.

מה כדאי לעשות: לשמור מראש חלופה במצב אופליין לאתרים מרובי-דפים

באתרים אופייניים שיש בהם כמה דפים, יכול להיות שכדי לטפל בבקשות ניווט, כדאי להשתמש באסטרטגיית שמירה במטמון ברשת קודם או ברשת בלבד.

במקרים כאלה, כדאי לוודא שה-Service Worker שומר מראש במטמון ומגיב עם דף חלופי אופליין כשהמשתמש שולח בקשת ניווט במצב אופליין. אחת מהדרכים לעשות זאת ב-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 של אתר שלם היא שתגי עיצוב שמועברים עכשיו במטמון יוצגו תמיד מהמטמון בשלב מאוחר יותר עד לעדכון ה-Service Worker. זו שיטה נהדרת לשיפור הביצועים, אבל אם קוד ה-HTML באתר משתנה לעיתים קרובות, היא עלולה להוביל לנטישה משמעותית.

עם זאת, יש כמה חריגים לכלל הזה. אם אתם פורסים אתר קטן עם כמה קובצי HTML סטטיים, סביר להניח שאפשר לשמור מראש את כל הדפים האלו כדי שיהיו זמינים במצב אופליין. אם יש לכם אתר גדול במיוחד, כדאי לשמור מראש במטמון כמה דפים עם ערך גבוה וחלופה אופליין, ולהסתמך על השמירה במטמון בזמן הריצה כדי לשמור דפים אחרים במטמון.

לא מומלץ: לשמור מראש תמונות רספונסיביות או סמל אתר

זאת פחות הנחיה כללית ויותר כלל. תמונות רספונסיביות הן פתרון מורכב לבעיה מורכבת: יש הרבה משתמשים במכשירים שונים, שכל אחד מהם משתנה בגודל מסך, בדחיסות הפיקסלים ובתמיכה בפורמטים חלופיים. אם אתם שומרים מראש קבוצה שלמה של תמונות רספונסיביות, סביר להניח שאתם שומרים מראש כמה תמונות במטמון כאשר המשתמש עשוי להוריד רק אחת מהן בסופו של דבר.

סמל אתר מציג מצב דומה, בכך שאתרים פורסים לעיתים קרובות קבוצה שלמה של סמלי אתרים לתרחישים שונים. ברוב המקרים, רק סמל אתר אחד מבוקש, ולכן תהליך העיבוד מראש של קבוצת סמל האתר כולו הוא בזבוז באותה מידה.

אתם יכולים לעשות טובה למשתמשים ולא לשמור מראש קבוצות של תמונות וסמלי אתר רספונסיביות. במקום זאת, אפשר להסתמך על שמירה במטמון בזמן הריצה. אם חובה לשמור מראש תמונות במטמון, כדאי לשמור מראש תמונות בשימוש נרחב שאינן חלק מקבוצה של תמונות רספונסיביות או סמלי אתר. קובצי SVG פחות מסוכנים מבחינת השימוש בנתונים, פורמט SVG יחיד עובר עיבוד באופן אופטימלי, ללא קשר לדחיסות הפיקסלים של מסך נתון.

אל:

תמיכה משתנה של דפדפנים בממשקי API מהווה אתגר מתמשך עבור מפתחי אתרים, ומילוי אוטומטי הוא אחת הדרכים שבהן האתגר מתמודד עם האתגר. דרך אחת למזער את עלות הביצועים של polyfills היא לבצע בדיקת תכונות ולטעון רק רכיבי polyfill עבור הדפדפנים שזקוקים להם.

מאחר שטעינה מותנית של polyfills מתבצעת במהלך זמן ריצה ביחס לסביבה הנוכחית, שמירה מראש של polyfills במטמון היא הימור. חלק מהמשתמשים ירוויחו מזה, ואחרים יבזבזו רוחב פס כדי להוסיף שימושים בלתי נחוצים.

אל תשמור מראש רכיבי polyfill מסוימים. שמירה במטמון של זמן ריצה תעזור לכם לוודא שהם יישמרו במטמון רק בדפדפנים שמחייבים אותם כדי למנוע בזבוז נתונים.

סיכום

כדי לשמור מראש במטמון צריך לחשוב מראש על הנכסים שיהיו למשתמשים בפועל, אבל בהחלט אפשר לעשות זאת כמו שצריך תוך עדיפות של הביצועים והאמינות בעתיד.

לא בטוחים אם כדאי לשמור מראש נכסים מסוימים במטמון? מומלץ לבקש מ-Workbox להחריג את הנכסים האלה וליצור מסלול לשמירה במטמון של זמן ריצה כדי לטפל בהם. בכל מקרה, הסבר לגבי התהליך מראש מופיע בהמשך בתיעוד הזה, כך שתוכלו ליישם את העקרונות האלה בלוגיקת השמירה במטמון בעתיד.