להגיב לבקשות ניווט בלי להמתין ברשת באמצעות קובץ שירות (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), וכל אחת מכתובות ה-URL האלה תואמת לקובץ HTML סטטי אחר, אחת השיטות המומלצות היא פשוט לשמור את כל קובצי ה-HTML במטמון ולהגיב לבקשות ניווט באמצעות ה-HTML המתאים שנשמר במטמון.
באמצעות מטמון, תוכלו לשמור את ה-HTML במטמון מראש ברגע שה-Service Worker מותקן, ולעדכן את ה-HTML ששמור במטמון בכל פעם שאתם בונים מחדש את האתר ופורסים מחדש את ה-Service Worker.
לחלופין, אם אתם מעדיפים להימנע משמירה מראש של כל ה-HTML – אולי כי המשתמשים נוטים לנווט רק לקבוצת משנה של כתובות URL באתר – תוכלו להשתמש באסטרטגיית שמירת זמן ריצה במטמון בזמן ריצה לא פעיל בזמן אימות מחדש. עם זאת, יש להיזהר בגישה הזו, כי כל מסמך HTML נשמר במטמון ומתעדכן בנפרד. השימוש בשמירה במטמון בזמן ריצה ל-HTML הוא המתאים ביותר אם יש לכם מספר קטן של כתובות URL שמבקרים בהן לעיתים קרובות על ידי אותה קבוצת משתמשים, ואם אתם מרגישים בנוח לאמת את כתובות ה-URL האלה בנפרד זו מזו.
אפליקציות של דף יחיד
אפליקציות אינטרנט מודרניות משתמשות לעיתים קרובות בארכיטקטורה של דף אחד. בגרסה הזו, JavaScript בצד הלקוח משנה את ה-HTML בתגובה לפעולות המשתמש. המודל הזה משתמש ב-History API כדי לשנות את כתובת ה-URL הנוכחית בזמן האינטראקציה של המשתמש עם אפליקציית האינטרנט, מה שמוביל בפועל לניווט "סימולציה". הניווטים הבאים עשויים להיות "מזויפים", אבל הניווט הראשוני אמיתי, ועדיין חשוב לוודא שהוא לא חסום ברשת.
למרבה המזל, אם אתם משתמשים בארכיטקטורה של דף אחד, יש דפוס פשוט לביצוע הניווט הראשוני מהמטמון: מעטפת האפליקציה. במודל הזה, ה-Service Worker מגיב לבקשות ניווט על ידי החזרת קובץ HTML יחיד שכבר נשמר מראש – בלי קשר לכתובת ה-URL המבוקשת. קוד ה-HTML צריך להיות גלוי לעין, ולהכיל, אולי, מדד טעינה כללי או תוכן שלד. אחרי שהדפדפן טוען את ה-HTML מהמטמון, קוד ה-JavaScript הקיים בצד הלקוח משתלט על הדף ומעבד את תוכן ה-HTML הנכון של כתובת ה-URL מבקשת הניווט המקורית.
תיבת העבודה מספקת את הכלים הנדרשים כדי ליישם את הגישה הזו. באמצעות navigateFallback
option תוכלו לציין באיזה מסמך HTML להשתמש כמעטפת של האפליקציה, יחד עם רשימת הרשאות ודחייה אופציונלית כדי להגביל את ההתנהגות הזו לקבוצת משנה של כתובות URL.
אפליקציות עם כמה דפים
אם שרת האינטרנט יוצר את ה-HTML של האתר באופן דינמי, או אם יש לכם יותר מכמה עשרות דפים ייחודיים, הרבה יותר קשה להימנע מהרשת בזמן הטיפול בבקשות ניווט. סביר להניח שהעצות בכל השאר רלוונטיות לכם.
אבל בקבוצת משנה מסוימת של אפליקציות מרובות דפים, ייתכן שתוכלו להטמיע קובץ שירות (service worker) שמשכפל באופן מלא את הלוגיקה שבה משתמשים בשרת האינטרנט כדי ליצור HTML. הדרך הטובה ביותר לעשות זאת היא לשתף מידע על ניתוב ותבניות בין סביבות השרת וה-Service Worker, ובמיוחד אם שרת האינטרנט משתמש ב-JavaScript (בלי להסתמך על תכונות שספציפיות ל-Node.js, כמו גישה למערכת קבצים).
אם שרת האינטרנט שלכם שייך לקטגוריה הזו, ואתם רוצים לבדוק גישה אחת להעברת יצירת HTML מהרשת ל-Service Worker, תוכלו להיעזר במדריך Beyond SPA: ארכיטקטורות חלופיות ל-PWA.
כל השאר
אם אתם לא יכולים להגיב לבקשות ניווט באמצעות HTML שנשמר במטמון, עליכם לבצע כמה פעולות כדי לוודא שהוספה של Service Worker לאתר (כדי לטפל בבקשות אחרות שלא קשורות ל-HTML) לא תאט בסופו של דבר את תהליך הניווט. אם תפעילו את קובץ השירות (service worker) בלי להגיב לבקשת ניווט, זמן האחזור יהיה קצר (כפי שמוסבר במאמר Building Faster and more ressible Apps with Service Worker). אפשר לצמצם את התקורה הזו על ידי הפעלת תכונה שנקראת טעינה מראש של ניווט, ולאחר מכן שימוש בתגובת הרשת שנטענה מראש בתוך הגורם המטפל באירועים של fetch.
תיבת העבודה מספקת ספרייה עוזרת שמזהה אם יש תמיכה בעומס מראש של ניווט, ואם כן, מפשטת את תהליך ההודעה ל-Service Worker להשתמש בתגובת הרשת.
צילום של Aaron Burden ב-UnFlood