ניתן להשיב לבקשות ניווט בלי לחכות ברשת באמצעות Service Worker.
בקשות ניווט הן בקשות למסמכי HTML שנוצרו על ידי הדפדפן בכל פעם שאתם מזינים כתובת URL חדשה בסרגל הניווט או לוחצים על קישור בדף שמעביר אתכם לכתובת URL חדשה. זו ההשפעה הגדולה ביותר של עובדי שירות על הביצועים: אם אתם משתמשים ב-Service Worker כדי להגיב לבקשות ניווט בלי לחכות לרשת, תוכלו לוודא שהניווטים מהירים בצורה אמינה, בנוסף לעמידות כשהרשת לא זמינה. זאת הזכייה הגדולה ביותר בביצועים כתוצאה מ-Service Worker, לעומת שמירה במטמון HTTP.
כפי שמפורט במדריך זיהוי משאבים שנטענים מהרשת, בקשת ניווט היא הבקשה הראשונה מבין בקשות רבות שעשויות להתבצע ב-"Waterfall" של התנועה ברשת. קוד ה-HTML שטוענים דרך בקשת ניווט מפעיל את התהליך של כל הבקשות האחרות למשאבי משנה כמו תמונות, סקריפטים וסגנונות.
בתוך handler של אירועים ב-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 באתר שלכם — אפשר להשתמש בשיטת לא פעיל בזמן אימות מחדש במטמון זמן הריצה. עם זאת, צריך להיזהר בגישה הזו, מכיוון שכל מסמך 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. הגישה הזו פועלת בצורה הטובה ביותר אם אפשר לשתף מידע על ניתוב ויצירת תבניות בין הסביבות של השרת לבין הסביבות של קובצי השירות, ובמיוחד אם שרת האינטרנט משתמש ב-JavaScript (בלי להסתמך על תכונות שספציפיות ל-Node.js, כמו גישה למערכת הקבצים).
אם שרת האינטרנט שלכם משתייך לקטגוריה הזו ואתם רוצים לבחון גישה אחת להעברה של יצירת HTML מהרשת אל ה-Service Worker, תוכלו להיעזר בהנחיות במאמר מעבר לספקי שירותים (SPA): ארכיטקטורות חלופיות ל-PWA.
כל השאר
אם אתם לא יכולים להגיב לבקשות ניווט באמצעות קובץ HTML ששמור במטמון, עליכם לבצע את הפעולות הנדרשות כדי לוודא שהוספת Service Worker לאתר (כדי לטפל בבקשות אחרות שאינן HTML) לא תאט את הניווטים. אם מפעילים את ה-Service Worker בלי להשתמש בו כדי להגיב לבקשת ניווט, יהיה זמן אחזור קצר (כפי שמוסבר במאמר בניית אפליקציות מהירות ועמידות יותר באמצעות Service Worker). אפשר לצמצם את התקורה הזו על-ידי הפעלת תכונה שנקראת טעינה מראש של ניווט, ואז שימוש בתשובה מהרשת שנטענה מראש בתוך הגורם המטפל באירועים של fetch.
תיבת העבודה מספקת ספרייה תומכת שמזהה אם יש תמיכה בטעינה מראש של ניווט, וכך מפשטת את התהליך של הנחיית ה-Service Worker להשתמש בתגובת הרשת.
צילום מאת אהרון בורדן ב-Un משתתפים