מענה לבקשות ניווט בלי להמתין לרשת באמצעות שירות עובד (service worker).
בקשות ניווט הן בקשות למסמכי HTML שהדפדפן שולח בכל פעם שמזינים כתובת URL חדשה בסרגל הניווט או לוחצים על קישור בדף שמובילה לכתובת URL חדשה. כאן קובצי השירות משפיעים בצורה המשמעותית ביותר על הביצועים: אם משתמשים בקובץ שירות כדי להגיב לבקשות ניווט בלי להמתין לרשת, אפשר להבטיח שהניווטים יהיו מהירים ואמינים, וגם עמידים במקרים שבהם הרשת לא זמינה. זוהי השיפור הגדול ביותר בביצועים שמגיע משימוש בקובץ שירות, בהשוואה למה שאפשר להשיג באמצעות אחסון במטמון של HTTP.
כפי שמפורט במדריך זיהוי משאבים שנטענו מהרשת, בקשת ניווט היא הראשונה מבין בקשות רבות שעשויות להתבצע ב'מפל' של תעבורת הנתונים ברשת. קובץ ה-HTML שאתם טוענים באמצעות בקשת ניווט מפעיל את זרימת כל שאר הבקשות למשאבי משנה כמו תמונות, סקריפטים וסגנונות.
בתוך פונקציית הטיפול באירועים fetch של עובד השירות, אפשר לקבוע אם בקשה היא ניווט על ידי בדיקת המאפיין 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 הנוכחית בזמן שהמשתמש יוצר אינטראקציה עם אפליקציית האינטרנט, וכתוצאה מכך מתבצעת 'סימולציה' של ניווט. יכול להיות שהניווטים הבאים יהיו 'מזויפים', אבל הניווט הראשוני הוא אמיתי ועדיין חשוב לוודא שהוא לא חסום ברשת.
למרבה המזל, אם אתם משתמשים בארכיטקטורה של דף יחיד, יש תבנית פשוטה שאפשר לפעול לפיה כדי להציג את הניווט הראשוני מהמטמון: הקליפה של האפליקציה. במודל הזה, ה-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 ששמור במטמון, עליכם לנקוט פעולות כדי לוודא שהוספת שירות ל-worker לאתר (כדי לטפל בבקשות אחרות שאינן HTML) לא תגרום להאטה של הניווט. הפעלת קובץ השירות בלי להשתמש בו כדי להגיב לבקשת ניווט תוביל לזמן אחזור קצר (כפי שמוסבר במאמר פיתוח אפליקציות מהירות ועמידות יותר באמצעות Service Worker). כדי לצמצם את התקורה הזו, אפשר להפעיל את התכונה טעינה מראש של ניווט ואז להשתמש בתגובה מהרשת שהוטענה מראש בתוך פונקציית הטיפול באירוע fetch.
ב-Workbox יש ספריית עזר שמזהה אם יש תמיכה בטעינה מראש של ניווט, ואם כן, מפשטת את התהליך של הנחיה לקובץ השירות להשתמש בתגובת הרשת.
צילום: Aaron Burden ב-Unsplash