ציפיות בנוגע לפריסה של קובץ שירות (service worker)

פריסת קובץ שירות (service worker) עשויה לשנות את ההתנהגות של אתר באופן בלתי צפוי. מאחר שבעזרת Workbox קל לכתוב ולפרוס קובץ שירות (service worker), לפעמים קל יותר לפספס חלק מההשפעות שיש ל-Service Worker על האתר לאחר הפריסה.

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

מלכודות מראש למטמון

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

מכיוון שהתנהגות ברירת המחדל של workbox-webpack-plugin היא להורות ל-Service Worker לשמור מראש נכסים שנוצרו באופן אוטומטי, ולכן הדבר עלול להיות בעייתי באופן שקל לפספס, כי חסם ההטמעה הוא נמוך.

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

הכול בתזמון

אם קובץ שירות (service worker) שומר מראש פריט כלשהו, יש חשיבות לשעה שבה הוא רשום. בדרך כלל, קובצי שירות (service worker) נרשמים באמצעות רכיבי <script> מוטבעים. המשמעות היא שמנתחי HTML עשויים לגלות את קוד הרישום של קובץ השירות (service worker) לפני טעינת הנכסים הקריטיים של הדף.

זו בעיה. באופן אידיאלי, קובץ שירות (service worker) צריך להיות ניטרלי במקרה הגרוע ביותר, אבל הוא לא יפגע בביצועים. אתם יכולים להעניק למשתמשים טובה ולרשום קובץ שירות (service worker) כאשר האירוע load של הדף מופעל. כך תפחיתו את הסיכויים ששמירה מראש במטמון תפריע לטעינת נכסים קריטיים של דף, וכתוצאה מכך הדף יוכל להפוך לאינטראקטיבי מהר יותר בלי שתצטרכו לטפל בבקשות מהרשת לנכסים שייתכן שאין בהם צורך עד למועד מאוחר יותר בכל מקרה.

שיקולים התחשבים בשימוש בנתונים

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

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

הפעלת קובץ השירות (service worker) יכולה לעכב בקשות רשת

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

כשמשתמשים באסטרטגיות שלא ניתן להציג אותן מהמטמון וצריך לעבור לרשת, במיוחד כשמטפלים בבקשות ניווט, זמן האתחול תמיד לוקח קצת עיכוב. בהתאם ליכולות המכשיר ו/או ללחץ המעבד (CPU), ייתכן עיכוב משמעותי בבקשת ניווט בגלל אתחול איטי של קובץ השירות (service worker). בפריסה של קובץ שירות (service worker) ללא ידיעת העיכוב הזה, משתמשים עלולים לחוות פגיעה לא מכוונת בביצועים.

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

אסטרטגיות שמתמקדות במטמון עשויות לגרום לכך שההפעלה שלהן תתבטל

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

שמירה במטמון בזמן ריצה של נכסים סטטיים שלא עודכנו

חבילות APK בדרך כלל מפרסמות נכסים סטטיים עם גיבוב מבוסס-תוכן בשם הקובץ (לדוגמה, styles.a4edf38c.css). ב-Service Workers שמשתמשים באסטרטגיות של שמירה במטמון, מתייעצים קודם עם המטמון לגבי נכסים סטטיים, ומשתמשים באסטרטגיה שמתמקדת ברשת לתגי עיצוב של דפים, לא צריכות להיות בעיות של שמירה במטמון כי יש התייחסות לנכסים מעודכנים בתגי עיצוב שתמיד מאוחזרים מהרשת.

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

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

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

מכסות נפח האחסון של Mind

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

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

פותרת את הבעיות האלה בצורה הטובה ביותר ב-Workbox, אבל עדיין אפשר לחרוג ממכסות האחסון. אפשר לשלוט בצורה מדויקת יותר במטמון באמצעות המודול של Workbox-expiration.

אל דאגה

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