שמירה במטמון של קובץ שירות (service worker) ושמירה במטמון ב-HTTP

היתרונות והחסרונות של שימוש בלוגיקה עקבית או שונה של תפוגה בשכבות המטמון של ה-service worker ובשכבות המטמון של ה-HTTP.

Jonathan Chen

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

• תרחישים לדוגמה של שימוש במטמון של שירותי עבודה (service workers) ובמטמון של HTTP, וההבדלים ביניהם.
• היתרונות והחסרונות של שיטות שונות לתפוגת תוקף של מטמון של שירותי עובדים בהשוואה לשיטות רגילות של מטמון HTTP.

סקירה כללית של תהליך האחסון במטמון

ברמת העל, הדפדפן פועל לפי סדר האחסון במטמון הבא כששולחים בקשה למשאב:

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

שכבות שמירת נתונים במטמון

שמירת נתונים במטמון של קובץ שירות (service worker)

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

שליטה במטמון של קובץ השירות (service worker)

שירות העבודה מיירט בקשות HTTP באמצעות מאזינים לאירועים (בדרך כלל האירוע fetch). קטע הקוד הזה מדגים את הלוגיקה של אסטרטגיית שמירת נתונים ב-Cache לפי Cache-First.

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

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

אסטרטגיות שמירת מטמון ותרחישים לדוגמה של שירותי עבודה

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

יתרונות נוספים של שמירת פריטים במטמון של שירותי עבודה

בנוסף לבקרה מפורטת על הלוגיקה של שמירת הנתונים במטמון, שמירת הנתונים במטמון של קובץ השירות מספקת גם:

• יותר זיכרון ומקום אחסון למקור: הדפדפן מקצה משאבי מטמון HTTP לפי מקור. במילים אחרות, אם יש לכם כמה תת-דומיינים, כולם משתפים את אותו מטמון HTTP. אין ערובה לכך שהתוכן של המקור או הדומיין שלכם יישאר במטמון ה-HTTP למשך זמן רב. לדוגמה, משתמש יכול לנקות את המטמון באופן ידני בממשק המשתמש של הגדרות הדפדפן, או להפעיל טעינת דף מחדש באופן מלא. כשמשתמשים במטמון של שירות עובד, יש סיכוי גבוה הרבה יותר שהתוכן ששמור במטמון יישאר במטמון. מידע נוסף זמין במאמר אחסון מתמיד.
• גמישות רבה יותר ברשתות לא יציבות או בחוויית שימוש אופליין: במטמון ה-HTTP יש רק אפשרות בינארית: המשאב נשמר במטמון או לא. בעזרת שמירת נתונים במטמון של שירותי עבודה תוכלו לצמצם בקלות רבה יותר את הבעיות הקטנות (באמצעות האסטרטגיה 'stale-while-revalidate'), להציע חוויית שימוש מלאה אופליין (באמצעות האסטרטגיה 'Cache only') או אפילו משהו באמצע, כמו ממשקי משתמש מותאמים אישית שבהם חלקים מהדף מגיעים מהמטמון של שירות העבודה וחלקים מסוימים לא נכללים (באמצעות האסטרטגיה 'Set catch handler') במקרים המתאימים.

שמירת HTTP במטמון

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

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

שליטה בתוקף התגובה במטמון HTTP באמצעות כותרות תגובה של HTTP

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

אסטרטגיות שמירת מטמון ב-HTTP ותרחישי שימוש

שמירת נתונים במטמון של HTTP פשוטה הרבה יותר משמירת נתונים במטמון של קובץ שירות, כי שמירת נתונים במטמון של HTTP עוסקת רק בלוגיקה של תפוגת תוקף משאבים מבוססת-זמן (TTL). למידע נוסף על אסטרטגיות של אחסון במטמון של HTTP, אפשר לעיין בקטע באילו ערכים של כותרות תגובה כדאי להשתמש? ובקטע סיכום.

תכנון הלוגיקה של תפוגת התוקף במטמון

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

ב-Glitch הבא אפשר לראות איך שמירת נתונים במטמון של שירותים עובדים ושמירת נתונים במטמון של HTTP פועלים בתרחישים שונים:

לוגיקה עקבית של תפוגה לכל שכבות המטמון

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

תרחיש: שמירה במטמון לטווח ארוך (מטמון, חזרה לרשת)

• כשמשאב ששמור במטמון תקף (עד 30 יום): ה-service worker מחזיר את המשאב ששמור במטמון באופן מיידי בלי להתחבר לרשת.
• כשתוקף המשאב ששמור במטמון פג (יותר מ-30 יום): ה-service worker עובר לרשת כדי לאחזר את המשאב. בדפדפן אין עותק של המשאב במטמון ה-HTTP שלו, ולכן הוא עובר אל המשאב בצד השרת.

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

תרחיש: אחסון במטמון לטווח בינוני (Stale-while-revalidate)

• כשמשאב ששמור במטמון תקף (עד יום אחד): ה-service worker מחזיר את המשאב ששמור במטמון באופן מיידי, וממשיך לרשת כדי לאחזר את המשאב. בדפדפן יש עותק של המשאב במטמון ה-HTTP שלו, ולכן הוא מחזיר את העותק הזה לקובץ השירות.
• כשפג התוקף של משאב ששמור במטמון (יותר מיום אחד): ה-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) (פחות מ-90 יום): קובץ השירות מחזיר את המשאב ששמור במטמון באופן מיידי.
• כשתוקף המשאב שנשמר במטמון פג במטמון של ה-service worker (יותר מ-90 יום): ה-service worker עובר לרשת כדי לאחזר את המשאב. אין בדפדפן עותק של המשאב במטמון ה-HTTP שלו, ולכן הוא עובר לצד השרת.

יתרונות וחסרונות:

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

תרחיש: אחסון במטמון לטווח קצר (Stale-while-revalidate)

• כשמשאב ששמור במטמון תקף במטמון של קובץ השירות (service worker) (עד 30 יום): קובץ השירות מחזיר את המשאב ששמור במטמון באופן מיידי.
• כשתוקף המשאב ששמור במטמון של ה-service worker פג (יותר מ-30 יום): ה-service worker יוצא לרשת כדי לאחזר את המשאב. אין לדפדפן עותק של המשאב במטמון ה-HTTP שלו, ולכן הוא עובר לצד השרת.

יתרונות וחסרונות:

• יתרון: המשתמשים מקבלים תגובה מיידית כי ה-service worker מחזיר משאבים שנשמרו במטמון באופן מיידי.
• יתרון: בעזרת תיקוף מחדש שמתבצע 'ברקע', ה-service worker יכול לוודא שבבקשה הבאה לכתובת URL מסוימת תהיה תגובה חדשה מהרשת.
• חיסרון: נדרשת אסטרטגיית מטמון מוגדרת היטב לשירות העובד.

תרחיש: אחסון במטמון לטווח קצר (הרשת חוזרת למטמון)

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

יתרונות וחסרונות:

• יתרון: כשהרשת לא יציבה או מושבתת, ה-service worker מחזיר משאבים שנשמרו במטמון באופן מיידי.
• חיסרון: כדי לבטל את ההגדרה של מטמון ה-HTTP ולשלוח בקשות מסוג 'Network first', נדרש קובץ שירות (service worker) עם קוד נוסף לביטול האחסון במטמון.

סיכום

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

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

מידע נוסף

• אמינות הרשת
• מניעת בקשות מיותרות ברשת באמצעות מטמון HTTP
• Codelab בנושא מטמון HTTP
• מדידת ההשפעה של שירותי ה-Worker על הביצועים בפועל
• Cache-Control לעומת Expires
• הסבר על מטמון: בדיקה, ניקוי והשבתה של מטמון