Service worker יכול להפוך ביקורים חוזרים לעמידים יותר בפני בעיות חיבור ולצמצם עבודה חוזרת ברשת, אבל הוספתו אינה משפרת אוטומטית את Core Web Vitals. השאלות החשובות הן באילו בקשות עליו לטפל, עד כמה התשובות חייבות להיות עדכניות ומה קורה כשמפרסמים גרסה חדשה. מתחילים בקבוצה מוגבלת של משאבים ציבוריים. מרחיבים אותה כאשר הבדיקות מראות תועלת שמצדיקה את התחזוקה.
מפרידים בין הוורקר לבין המטמון
Service worker הוא סקריפט שמגיב לאירועים ויכול ליירט בקשות מעמודים שבשליטתו. Cache Storage הוא מאגר נפרד של זוגות בקשה ותשובה. אף אחד מהם אינו מחליף את מטמון HTTP של הדפדפן. גם בקשה שהוורקר שולח יכולה להיעזר במטמון HTTP הרגיל. לכן צריך לזהות איזו שכבה סיפקה את התשובה לפני שמייחסים את השיפור לקוד החדש.
Cache Storage אינו אוכף אוטומטית את כללי העדכניות של HTTP. היישום קובע מתי לשמור רשומות, לעדכן אותן ולמחוק אותן. כותרת תגובה מהשרת אינה תחליף למדיניות הזאת. אם המטרה היא רק שימוש חוזר בקובצי עיצוב ובתמונות ציבוריות, כדאי לבדוק קודם את הגדרות מטמון הדפדפן לפני שמוסיפים שכבה הניתנת לתכנות.
בוחרים אסטרטגיה לכל משאב
בקבצים ציבוריים שהכתובת שלהם מכילה טביעת אצבע של התוכן, בדיקת המטמון לפני הרשת היא נקודת פתיחה סבירה. כתובת שלא השתנתה אמורה לייצג תוכן שלא השתנה. ההיגיון הזה אינו מתאים אוטומטית למידע בחשבון, לזמינות מוצרים או למסמך HTML שצריך לשקף פריסה חדשה.
פנייה לרשת תחילה נותנת עדיפות לעדכניות, אבל עלולה להשאיר את המבקר ממתין בחיבור לא יציב. יש להגדיר במפורש ביטול, תשובה חלופית וטיפול בכשל. הגשת עותק שמור תוך רענונו ברקע מאפשרת שימוש חוזר מהיר, אך המבקר הנוכחי עשוי לקבל תוכן ישן יותר. היא גם יוצרת פעילות רשת כאשר כבר קיים עותק במטמון.
אלה החלטות מוצר. עמוד עזרה שזמין ללא חיבור יכול להיות שימושי; אישור תשלום מיושן עלול להטעות. אין סיבה להחיל מדיניות אחידה רק מפני שכל הבקשות עוברות דרך אותו קוד טיפול.
זוכרים גם את הביקור הראשון
רישום, התקנה, הפעלה ושליטה בעמוד הם מצבים שונים. וורקר שזה עתה נרשם בדרך כלל אינו שולט בעמוד הראשוני שרשם אותו. ביקורים חוזרים עשויים להרוויח לאחר שהוא מוכן, בעוד שמבקר חדש עדיין תלוי במסלול הטעינה הרגיל.
שמירה נרחבת מדי של משאבים מראש עלולה להתחרות במשאבים שהעמוד הנוכחי צריך. שומרים מראש רק את מה שנדרש לחוויית שימוש מתוכננת. את תגובת השרת, גילוי המשאבים והרינדור משפרים גם בנפרד. המדריך לקיצור זמן תגובת השרת נשאר רלוונטי גם כאשר ביקור שכבר נשמר במטמון נראה מהיר.
מתחילים בדוגמה בעלת גבולות ברורים
הוורקר הבא הוא דוגמה להמחשה: הוא שומר מראש רשימה מפורשת של קבצים ציבוריים ומחזיר מהמטמון תשובות לבקשות תואמות, כאשר הן זמינות. יש למקם אותו בקובץ וורקר, לרשום אותו בנפרד בהקשר מאובטח ולהחליף את הנתיבים בקבצים אמיתיים. התשובות שברשימה חייבות להיות ציבוריות ולא להשתנות לפי מצב ההתחברות לחשבון.
const CACHE = "editorialAssetsRelease";
const ASSETS = [
"/assets/site.abc123.css",
"/assets/brand.def456.svg"
];
self.addEventListener("install", event => {
event.waitUntil(
caches.open(CACHE).then(cache => cache.addAll(ASSETS))
);
});
self.addEventListener("fetch", event => {
const request = event.request;
const url = new URL(request.url);
if (request.method !== "GET" ||
url.origin !== self.location.origin ||
!ASSETS.includes(url.pathname + url.search)) return;
event.respondWith((async () => {
let cached;
try {
const cache = await caches.open(CACHE);
cached = await cache.match(request);
} catch {}
return cached || fetch(request);
})());
});בפרסום גרסה משנים יחד את שם המטמון ואת כתובות הקבצים המכילות טביעת אצבע. כישלון של בקשה חיונית בשמירה המקדימה עלול להכשיל את ההתקנה. הדוגמה אינה כוללת עמוד HTML חלופי, מטמון שגדל בזמן השימוש או השתלטות אוטומטית לאחר עדכון. כך ההיקף שלה נשאר מפורש. שילוב בסביבת אמת עדיין מחייב רישום, טיפול בעדכונים ומדיניות לפינוי מטמונים השייכים ליישום הזה.
מתכננים עדכונים שמתאימים ללשוניות פתוחות
וורקר חדש שהותקן יכול להמתין בזמן שהוורקר הפעיל ממשיך לשרת לקוחות קיימים. ההתנהגות הזאת מסייעת למנוע ערבוב של עמוד ישן עם משאבים חדשים שאינם תואמים לו. הקריאות skipWaiting() וכן clients.claim() משנות את מחזור החיים ואת השליטה בעמודים. הן אינן פעולות כלליות לשיפור מהירות שיש להוסיף כברירת מחדל.
מחליטים אם להציע למשתמש עדכון, להמתין לטעינה חוזרת טבעית או לתמוך במקביל בגרסאות תואמות. משאירים זמינים קבצים קודמים עם טביעת אצבע כל עוד עמודים קיימים עשויים לבקש אותם. מוחקים רק מטמונים שהיישום שלכם מנהל, ומתחשבים בלקוחות פעילים במדיניות השמירה. התיעוד על מחזור החיים של Service workers מסייע לתכנן את המעבר.
מגנים על תוכן פרטי ומתכוננים לאובדן אחסון
מחריגים מהמטמון אימות זהות, עמודי חשבון ותשובות API רגישות, אלא אם תכנון שנבדק בנפרד דורש אחרת. קל יותר לבדוק רשימת כתובות מותרות מאשר מנגנון ששומר כל בקשה שהצליחה. עוגייה או כותרת תגובה אינן הופכות טיפול גורף באמצעות Cache Storage לבטוח.
אם היישום שומר במכוון תוכן אישי, מתכננים יחד התנתקות מהחשבון, מעבר בין חשבונות ומחיקת נתונים. צריך גם להניח שהדפדפן עשוי לפנות משאבים שמורים. תמיכה ללא חיבור צריכה להסביר מה נשאר זמין ומה מחייב קישוריות. אסור להציג מחסור בנתונים כאילו פעולה הסתיימה בהצלחה.
בודקים מצבים שונים, לא רק טעינה עם מטמון מלא
משווים ביקור נקי, ביקור בשליטת הוורקר עם מאגר מלא, ביקור ללא חיבור ועדכון כאשר לשונית ישנה נשארת פתוחה. בודקים את תחום הפעולה והבקר של הוורקר, את הרשומות בפועל במאגר Cache Storage ואת מקור התשובות. השבתת מטמון HTTP בכלי הפיתוח אינה מוכיחה בפני עצמה שהבקשות עקפו גם את Cache Storage.
משתמשים בהקלטת ביצועים כדי לחקור אטיות ובמדידות שטח כדי לבדוק את חוויית המבקרים. גבולות התוצאה הטובה הם LCP של 2.5 s לכל היותר, INP של 200 ms לכל היותר וכן CLS של 0.1 לכל היותר, באחוזון 75 ובהפרדה בין נייד למחשב. ביקור מקומי חוזר ומהיר אינו מוכיח שהתפלגות מדידות השטח עומדת בגבולות האלה.
משאירים את הוורקר כאשר התועלת שלו ברורה. תוכן נכון, עדכונים צפויים והתאוששות אמינה הם חלק מהנדסת ביצועים. המדריך לנתוני שטח ולנתוני מעבדה עוזר לפרש כל תצפית בהקשר המתאים.
