להגיב לבקשות ניווט בלי לחכות לרשת, באמצעות קובץ שירות (service worker).
בקשות ניווט הן בקשות למסמכי HTML שהדפדפן שולח בכל פעם שמזינים כתובת URL חדשה בסרגל הניווט, או כשלוחצים על קישור בדף שמעביר לכתובת URL חדשה. כאן יש ל-Service Workers את ההשפעה הגדולה ביותר על הביצועים: אם משתמשים ב-Service Worker כדי להגיב לבקשות ניווט בלי להמתין לרשת, אפשר לוודא שהניווט מהיר באופן עקבי, וגם גמיש כשהרשת לא זמינה. זהו היתרון הגדול ביותר בביצועים שנובע מ-Service Worker, בהשוואה למה שאפשר לעשות עם שמירת HTTP במטמון.
כפי שמפורט במדריך זיהוי משאבים שנטענים מהרשת, בקשת ניווט היא הראשונה מבין בקשות רבות שעשויות להתבצע ב"מפל המים" של התנועה ברשת. קוד ה-HTML שנטען באמצעות בקשת ניווט מפעיל את התהליך של כל שאר הבקשות למשאבי משנה כמו תמונות, סקריפטים וסגנונות.
בתוך הגורם המטפל באירועים fetch של קובץ ה-Service Worker, אפשר לבדוק אם בקשה היא ניווט על ידי בדיקת המאפיין request.mode ב-FetchEvent. אם הוא מוגדר ל-'navigate',
אז זו בקשת ניווט.
ככלל, אל תשתמשו ב-Cache-Control headers לטווח ארוך כדי לשמור במטמון את תגובת ה-HTML לבקשת ניווט. בדרך כלל, צריך למלא אותן דרך הרשת, באמצעות Cache-Control: no-cache, כדי לוודא שה-HTML, יחד עם שרשרת הבקשות הבאות לאחזור מהרשת, עדכני (במידה סבירה). אם המשתמשים יצטרכו לגשת לרשת בכל פעם שהם עוברים לדף חדש, יכול להיות שהניווט יהיה איטי. לכל הפחות, זה אומר שהיא לא תהיה מהירה באופן עקבי.
גישות שונות לארכיטקטורות
לא תמיד קל להבין איך להגיב לבקשות ניווט בלי להשתמש ברשת. הגישה הנכונה תלויה מאוד בארכיטקטורה של האתר ובמספר כתובות ה-URL הייחודיות שהמשתמשים עשויים לנווט אליהן.
אין פתרון אחד שמתאים לכולם, אבל ההנחיות הכלליות הבאות יעזרו לכם להחליט איזו גישה הכי מתאימה לכם.
אתרים סטטיים קטנים
אם אפליקציית האינטרנט שלכם כוללת מספר קטן יחסית (למשל, כמה עשרות) של כתובות URL ייחודיות, וכל אחת מכתובות ה-URL האלה תואמת לקובץ HTML סטטי אחר, גישה אחת שאפשר להשתמש בה היא פשוט לשמור במטמון את כל קובצי ה-HTML האלה, ולהגיב לבקשות ניווט באמצעות קובץ ה-HTML המתאים שנשמר במטמון.
באמצעות שמירה מראש במטמון, אתם יכולים לשמור את ה-HTML במטמון מראש, ברגע ש-Service Worker מותקן, ולעדכן את ה-HTML שנשמר במטמון בכל פעם שאתם בונים מחדש את האתר ופורסים מחדש את Service Worker.
לחלופין, אם אתם מעדיפים להימנע משמירה מראש במטמון של כל קובצי ה-HTML – אולי כי המשתמשים נוטים לנווט רק לקבוצת משנה של כתובות URL באתר – אתם יכולים להשתמש באסטרטגיית שמירה במטמון בזמן ריצה מסוג stale-while-revalidate. חשוב להיזהר עם הגישה הזו, כי כל מסמך HTML נשמר במטמון ומתעדכן בנפרד. השימוש בשמירה במטמון בזמן ריצה ל-HTML מתאים במיוחד אם יש לכם מספר קטן של כתובות URL שאותה קבוצת משתמשים מבקרת בהן לעיתים קרובות, ואם אתם מרגישים בנוח עם אימות מחדש של כתובות ה-URL האלה באופן עצמאי זו מזו.
אפליקציות של דף יחיד
ארכיטקטורה של דף יחיד משמשת לעיתים קרובות באפליקציות אינטרנט מודרניות. באתר כזה, קוד JavaScript בצד הלקוח משנה את ה-HTML בתגובה לפעולות של המשתמשים. המודל הזה משתמש ב-History API כדי לשנות את כתובת ה-URL הנוכחית כשהמשתמש יוצר אינטראקציה עם אפליקציית האינטרנט, וכך נוצר ניווט "מדומה". יכול להיות שהניווטים הבאים יהיו "מזויפים", אבל הניווט הראשוני הוא אמיתי, ועדיין חשוב לוודא שהוא לא חסום ברשת.
למרבה המזל, אם אתם משתמשים בארכיטקטורה של דף יחיד, יש דפוס פשוט שאפשר לפעול לפיו כדי להציג את הניווט הראשוני מהמטמון: מעטפת האפליקציה (app shell). במודל הזה, ה-service worker מגיב לבקשות ניווט על ידי החזרת אותו קובץ HTML יחיד שכבר נשמר במטמון מראש – ללא קשר לכתובת ה-URL המבוקשת. ה-HTML הזה צריך להיות בסיסי, ולכלול, למשל, אינדיקטור טעינה כללי או תוכן שלד. אחרי שהדפדפן טוען את ה-HTML הזה מהמטמון, ה-JavaScript הקיים בצד הלקוח משתלט ויוצר את תוכן ה-HTML הנכון לכתובת ה-URL מבקשת הניווט המקורית.
ב-Workbox יש את הכלים שצריך כדי ליישם את הגישה הזו. navigateFallback
option מאפשר לציין באיזה מסמך HTML להשתמש בתור מעטפת האפליקציה, וגם רשימת היתרים ורשימת חסימות אופציונליות כדי להגביל את ההתנהגות הזו לקבוצת משנה של כתובות ה-URL.
אפליקציות עם כמה דפים
אם שרת האינטרנט יוצר את ה-HTML של האתר באופן דינמי, או אם יש לכם יותר מכמה עשרות דפים ייחודיים, הרבה יותר קשה להימנע מהרשת כשמטפלים בבקשות ניווט. ההמלצות בקטע כל השאר כנראה רלוונטיות לכם.
אבל בקבוצת משנה מסוימת של אפליקציות עם כמה דפים, יכול להיות שתוכלו להטמיע קובץ שירות (service worker) שמשכפל באופן מלא את הלוגיקה שמשמשת בשרת האינטרנט ליצירת HTML. השיטה הזו פועלת הכי טוב אם אתם יכולים לשתף מידע על ניתוב ותבניות בין השרת לסביבות של ה-Service Worker, ובמיוחד אם שרת האינטרנט שלכם משתמש ב-JavaScript (בלי להסתמך על תכונות ספציפיות ל-Node.js, כמו גישה למערכת הקבצים).
אם שרת האינטרנט שלכם נכלל בקטגוריה הזו ואתם רוצים לבדוק גישה אחת להעברת יצירת ה-HTML מהרשת אל ה-service worker, ההנחיות במאמר מעבר לאפליקציות SPA: ארכיטקטורות חלופיות ל-PWA יכולות לעזור לכם להתחיל.
כל השאר
אם אתם לא יכולים להגיב לבקשות ניווט באמצעות HTML שנשמר במטמון, אתם צריכים לוודא שהוספת Service Worker לאתר (כדי לטפל בבקשות אחרות, שאינן HTML) לא תאט את הניווט. הפעלת ה-service worker בלי להשתמש בו כדי להגיב לבקשת ניווט תגרום לזמן אחזור קצר (כפי שמוסבר במאמר Building Faster, More Resilient Apps with Service Worker). כדי לצמצם את התקורה הזו, אפשר להפעיל תכונה שנקראת טעינה מראש של ניווט, ואז להשתמש בתגובה מהרשת שנטענה מראש בתוך גורם מטפל באירועים של fetch.
ב-Workbox יש ספריית עזר שמזהה אם יש תמיכה בטעינה מראש של ניווט, ואם כן, מפשטת את התהליך שבו קובץ השירות משתמש בתגובה מהרשת.