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

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

מומלץ מאוד להשתמש ב-Workbox כדי להימנע מלהמציא את הגלגל מחדש. לדוגמה, אפשר לרשום נתיבי כתובות URL של משאבים באמצעות שורה אחת של קוד ביטוי רגולרי.
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
אסטרטגיות שמירה במטמון של Service Worker ותרחישי שימוש
בטבלה הבאה מפורטות אסטרטגיות נפוצות של שמירת נתונים במטמון באמצעות Service Worker, והמקרים שבהם כל אסטרטגיה שימושית.
| אסטרטגיות | הסבר על רענון | תרחישים לדוגמה |
|---|---|---|
| רשת בלבד | התוכן חייב להיות עדכני בכל שלב. |
|
| החיבור לרשת חוזר למטמון | מומלץ להציג את התוכן החדש. עם זאת, אם הרשת נכשלת או לא יציבה, אפשר להציג תוכן קצת ישן. |
|
| Stale-while-revalidate | אפשר להציג תוכן שנשמר במטמון באופן מיידי, אבל בעתיד צריך להשתמש בתוכן מעודכן שנשמר במטמון. |
|
| קודם מטמון, אחר כך רשת | התוכן לא קריטי ואפשר להציג אותו מהמטמון כדי לשפר את הביצועים, אבל מדי פעם צריך לבדוק אם יש עדכונים ב-service worker. |
|
| מטמון בלבד | התוכן משתנה לעיתים רחוקות. |
|
יתרונות נוספים של שמירת נתונים במטמון באמצעות Service Worker
בנוסף לשליטה מדויקת בלוגיקה של שמירת הנתונים במטמון, שמירת נתונים במטמון של Service Worker מספקת גם:
- יותר זיכרון ונפח אחסון למקור: הדפדפן מקצה משאבי מטמון HTTP על בסיס מקור. במילים אחרות, אם יש לכם כמה תת-דומיינים, כולם חולקים את אותו מטמון HTTP. אין ערובה לכך שהתוכן של המקור או הדומיין שלכם יישאר במטמון ה-HTTP למשך זמן רב. לדוגמה, משתמש יכול למחוק את המטמון על ידי ניקוי ידני של ממשק המשתמש של הגדרות הדפדפן, או על ידי הפעלה של טעינה מחדש של דף. כשמשתמשים במטמון של Service Worker, הסבירות שהתוכן שנשמר במטמון יישאר במטמון גבוהה הרבה יותר. מידע נוסף זמין במאמר בנושא אחסון קבוע.
- גמישות גבוהה יותר ברשתות לא יציבות או בחוויות אופליין: במטמון HTTP יש רק שתי אפשרויות: המשאב נשמר במטמון או שלא. באמצעות שמירת נתונים במטמון של Service Worker, אפשר לצמצם בקלות רבה יותר בעיות קלות (באמצעות האסטרטגיה stale-while-revalidate), להציע חוויה מלאה במצב אופליין (באמצעות האסטרטגיה Cache only) או אפילו משהו באמצע, כמו ממשקי משתמש בהתאמה אישית עם חלקים בדף שמגיעים מהמטמון של Service Worker וחלקים מסוימים שמוחרגים (באמצעות האסטרטגיה Set catch handler) במקרים המתאימים.
שמירה במטמון של HTTP
בפעם הראשונה שדפדפן טוען דף אינטרנט ומשאבים שקשורים אליו, הוא שומר את המשאבים האלה במטמון ה-HTTP שלו. מטמון HTTP מופעל בדרך כלל אוטומטית על ידי דפדפנים, אלא אם משתמש הקצה השבית אותו באופן מפורש.
שימוש במטמון HTTP פירושו להסתמך על השרת כדי לקבוע מתי לשמור משאב במטמון וכמה זמן.
שליטה בתפוגה של מטמון HTTP באמצעות כותרות תגובת HTTP
כששרת מגיב לבקשת דפדפן למשאב, השרת משתמש בכותרות תגובת HTTP כדי להגיד לדפדפן כמה זמן הוא צריך לשמור את המשאב במטמון. מידע נוסף מופיע במאמר כותרות תגובה: הגדרת שרת האינטרנט.
אסטרטגיות לשמירה במטמון של HTTP ותרחישי שימוש
שמירה במטמון של HTTP היא הרבה יותר פשוטה משמירה במטמון של service worker, כי שמירה במטמון של HTTP מתייחסת רק ללוגיקה של תפוגת משאבים מבוססת-זמן (TTL). במאמרים אילו ערכים של כותרות תגובה כדאי להגדיר? ומניעת בקשות מיותרות ברשת באמצעות מטמון HTTP (סיכום) אפשר לקרוא מידע נוסף על אסטרטגיות של שמירת נתונים במטמון HTTP.
תכנון הלוגיקה של תפוגת המטמון
בקטע הזה מוסבר מהם היתרונות והחסרונות של שימוש בלוגיקה עקבית של תפוגה בשכבות של מטמון Service Worker ומטמון HTTP, וגם מהם היתרונות והחסרונות של שימוש בלוגיקה נפרדת של תפוגה בשכבות האלה.
לוגיקה עקבית של תפוגה לכל שכבות המטמון
כדי להמחיש את היתרונות והחסרונות, נבחן 3 תרחישים: לטווח ארוך, לטווח בינוני ולטווח קצר.
| תרחישים | שמירה במטמון לטווח ארוך | שמירה במטמון לטווח בינוני | שמירת נתונים במטמון לטווח קצר |
|---|---|---|---|
| אסטרטגיית שמירה במטמון של קובצי שירות (service worker) | מטמון, חזרה לרשת | Stale-while-revalidate | הרשת חוזרת למטמון |
| אורך חיים (TTL) של מטמון קובץ שירות (service worker) | 30 ימים | יום אחד | 10 דקות |
| HTTP cache max-age | 30 ימים | יום אחד | 10 דקות |
תרחיש: שמירה במטמון לטווח ארוך (מטמון, חזרה לרשת)
- כשמשאב במטמון תקף (עד 30 ימים): ה-service worker מחזיר את המשאב במטמון באופן מיידי בלי לגשת לרשת.
- כשמשאב במטמון לא בתוקף (עברו יותר מ-30 יום): ה-service worker עובר לרשת כדי לאחזר את המשאב. בדפדפן אין עותק של המשאב במטמון ה-HTTP, ולכן הוא פונה לצד השרת כדי לקבל את המשאב.
חיסרון: בתרחיש הזה, שמירת נתונים במטמון של HTTP מספקת פחות ערך כי הדפדפן תמיד יעביר את הבקשה לצד השרת כשהמטמון יפוג בקובץ ה-service worker.
תרחיש: שמירת נתונים במטמון לטווח בינוני (Stale-while-revalidate)
- כשמשאב במטמון תקף (עד יום אחד): ה-service worker מחזיר את המשאב מהמטמון באופן מיידי, ועובר לרשת כדי לאחזר את המשאב. בדפדפן יש עותק של המשאב במטמון ה-HTTP שלו, ולכן הוא מחזיר את העותק הזה לקובץ ה-service worker.
- כשמשאב במטמון פג תוקף (אחרי יותר מיום): ה-service worker מחזיר את המשאב במטמון באופן מיידי, ועובר לרשת כדי לאחזר את המשאב. בדפדפן אין עותק של המשאב במטמון ה-HTTP, ולכן הוא עובר לצד השרת כדי לאחזר את המשאב.
חיסרון: קובץ השירות (service worker) דורש ניקוי מטמון נוסף כדי לבטל את המטמון של HTTP, כדי לנצל את שלב האימות מחדש בצורה הטובה ביותר.
תרחיש: שמירה במטמון לטווח קצר (הרשת חוזרת למטמון)
- כשמשאב במטמון תקף (עד 10 דקות): ה-service worker עובר לרשת כדי לאחזר את המשאב. בדפדפן יש עותק של המשאב במטמון ה-HTTP שלו, ולכן הוא מחזיר אותו לקובץ ה-service worker בלי לעבור לצד השרת.
- כשמשאב במטמון פג תוקף (> 10 דקות): ה-service worker מחזיר את המשאב במטמון באופן מיידי, ועובר לרשת כדי לאחזר את המשאב. בדפדפן אין עותק של המשאב במטמון ה-HTTP, ולכן הוא עובר לצד השרת כדי לאחזר את המשאב.
חיסרון: בדומה לתרחיש של שמירת נתונים במטמון לטווח בינוני, קובץ השירות (service worker) דורש לוגיקה נוספת של ניקוי המטמון כדי לעקוף את מטמון ה-HTTP, במטרה לאחזר את המשאב העדכני מצד השרת.
Service worker בכל התרחישים
בכל התרחישים, המטמון של קובץ השירות (service worker) עדיין יכול להחזיר משאבים ששמורים במטמון כשהרשת לא יציבה. מצד שני, קשה להסתמך על מטמון HTTP כשהרשת לא יציבה או לא פעילה.
לוגיקה שונה של תפוגת מטמון בשכבות של מטמון service worker ו-HTTP
כדי להמחיש את היתרונות והחסרונות, נבחן שוב תרחישים לטווח ארוך, לטווח בינוני ולטווח קצר.
| תרחישים | שמירה במטמון לטווח ארוך | שמירה במטמון לטווח בינוני | שמירת נתונים במטמון לטווח קצר |
|---|---|---|---|
| אסטרטגיית שמירה במטמון של קובצי שירות (service worker) | מטמון, חזרה לרשת | Stale-while-revalidate | הרשת חוזרת למטמון |
| אורך חיים (TTL) של מטמון קובץ שירות (service worker) | 90 ימים | 30 ימים | יום אחד |
| HTTP cache max-age | 30 ימים | יום אחד | 10 דקות |
תרחיש: שמירה במטמון לטווח ארוך (מטמון, חזרה לרשת)
- כשמשאב במטמון תקף במטמון של קובץ השירות (עד 90 ימים): קובץ השירות מחזיר את המשאב במטמון באופן מיידי.
- כשמשאב שמור במטמון פג תוקף במטמון של Service Worker (אחרי יותר מ-90 ימים): ה-Service Worker עובר לרשת כדי לאחזר את המשאב. בדפדפן אין עותק של המשאב במטמון ה-HTTP שלו, ולכן הוא עובר לצד השרת.
יתרונות וחסרונות:
- יתרון: המשתמשים מקבלים תגובה מיידית כי ה-service worker מחזיר משאבים ששמורים במטמון באופן מיידי.
- יתרון: ל-service worker יש שליטה מדויקת יותר על מועד השימוש במטמון ועל מועד הבקשה של גרסאות חדשות של משאבים.
- חיסרון: נדרשת אסטרטגיית שמירה במטמון של Service Worker שמוגדרת היטב.
תרחיש: שמירה במטמון לטווח בינוני (Stale-while-revalidate)
- כשמשאב במטמון תקף במטמון של קובץ השירות (עד 30 ימים): קובץ השירות מחזיר את המשאב במטמון באופן מיידי.
- כשמשאב שמור במטמון פג במטמון של Service Worker (אחרי יותר מ-30 יום): ה-Service Worker עובר לרשת כדי לאחזר את המשאב. בדפדפן אין עותק של המשאב במטמון HTTP, ולכן הוא עובר לצד השרת.
יתרונות וחסרונות:
- יתרון: המשתמשים מקבלים תגובה מיידית כי ה-service worker מחזיר משאבים ששמורים במטמון באופן מיידי.
- יתרון: ה-service worker יכול לוודא שבקשת הבא לכתובת URL מסוימת תשתמש בתגובה חדשה מהרשת, בזכות האימות מחדש שמתבצע "ברקע".
- חיסרון: נדרשת אסטרטגיית שמירה במטמון של Service Worker שמוגדרת היטב.
תרחיש: שמירה במטמון לטווח קצר (התקשורת חוזרת למטמון)
- כשמשאב במטמון תקף במטמון של Service Worker (עד יום אחד): ה-Service Worker עובר לרשת כדי לאחזר את המשאב. הדפדפן מחזיר את המשאב ממטמון ה-HTTP אם הוא נמצא שם. אם הרשת לא פעילה, קובץ השירות מחזיר את המשאב מהמטמון של קובץ השירות
- כשמשאב במטמון של Service Worker פג תוקף (> יום אחד): ה-Service Worker עובר לרשת כדי לאחזר את המשאב. הדפדפן מאחזר את המשאבים דרך הרשת כי תוקף הגרסה ששמורה במטמון ה-HTTP פג.
יתרונות וחסרונות:
- יתרון: כשהרשת לא יציבה או לא פועלת, ה-service worker מחזיר משאבים שנשמרו במטמון באופן מיידי.
- חיסרון: קובץ השירות (service worker) דורש ניקוי מטמון נוסף כדי לבטל את המטמון של HTTP ולבצע בקשות מסוג 'קודם רשת'.
סיכום
בגלל המורכבות של השילוב בין תרחישי שמירת נתונים במטמון, אי אפשר ליצור כלל אחד שיכסה את כל המקרים. עם זאת, על סמך הממצאים בסעיפים הקודמים, יש כמה הצעות שכדאי לבדוק כשמתכננים את אסטרטגיות המטמון:
- הלוגיקה של שמירת נתונים במטמון של Service Worker לא צריכה להיות עקבית עם הלוגיקה של תפוגת שמירת נתונים במטמון של HTTP. אם אפשר, כדאי להשתמש בלוגיקה של תפוגה ארוכה יותר בקובץ שירות (service worker) כדי להעניק לקובץ השירות יותר שליטה.
- לשמירת נתונים במטמון באמצעות HTTP יש עדיין תפקיד חשוב, אבל היא לא אמינה כשהרשת לא יציבה או לא פעילה.
- כדאי לבדוק מחדש את אסטרטגיות הקאשינג של כל משאב כדי לוודא שאסטרטגיית הקאשינג של Service Worker מספקת את הערך שלה, בלי להתנגש עם מטמון ה-HTTP.