רישום של קובץ שירות (service worker)

שיטות מומלצות לתזמון הרישום של Service Worker.

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

באופן כללי, דחיית קובץ שירות (service worker) רישום עד שהדף הראשוני נטען, מספק את החוויה הטובה ביותר במיוחד משתמשים בניידים עם חיבורי רשת איטיים יותר.

תבנית סטנדרטיות לרישום נפוץ

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

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/service-worker.js');
}

לפעמים מלווה במספר הצהרות מסוג console.log() או קוד שמאתר עדכון להרשמה קודמת של Service Worker, כדי ליידע את המשתמשים לרענן את הדף. אבל אלה רק שינויים קלים את השורות הרגילות של הקוד.

אז האם יש הבדל בין navigator.serviceWorker.register? האם יש כאלה שיטות מומלצות שכדאי לפעול לפיהן? לא מפתיע (גם אם המאמר הזה לא מסתיים התשובה לשתי האפשרויות היא "כן!"

הביקור הראשון של משתמש

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

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

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

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

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

משפרים את הכלים הסטנדרטיים

הפתרון הוא לשלוט בהפעלת ה-Service Worker על ידי בחירה מתי להתקשר. navigator.serviceWorker.register() כלל אצבע פשוט הוא להמתין עד אחרי load event מופעלת בתאריך window, למשל:

if ('serviceWorker' in navigator) {
    window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');
    });
}

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

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

ביקורים נוספים

עד עכשיו התמקדנו בחוויה של הביקור הראשון, אבל איזו השפעה האם יש עיכוב ברישום של קובץ שירות (service worker) בביקורים חוזרים באתר? זה אולי יפתיע חלק מהאנשים, אבל לא אמורה להיות לכך השפעה.

כאשר קובץ שירות (service worker) רשום, הוא עובר דרך install וגם מחזור חיים אחד (activate) אירועים. לאחר הפעלת Service Worker, הוא יכול לטפל באירועי fetch עבור כל הביקורים הבאים באפליקציית האינטרנט שלך. ה-Service Worker מתחיל לפני מתבצעת בקשה לכל דף שנכלל בהיקף שלו, וזה הגיוני על כך. אם ה-Service Worker הקיים לא פעל לפני מבקר בדף, לא תהיה לו הזדמנות להשלים אירועים של fetch עבור בקשות ניווט.

כשיש קובץ שירות פעיל (service worker), לא משנה מתי מתקשרים navigator.serviceWorker.register(), או למעשה בין אם קוראים לו בכלל. אם לא משנים את כתובת ה-URL של הסקריפט של Service Worker, navigator.serviceWorker.register() הוא למעשה no-op בביקורים הבאים. בסוף הסרטון לא רלוונטית.

למה כדאי להירשם בשלב מוקדם

האם יש תרחישים שבהם רישום קובץ השירות (service worker) כבר התחיל הוא הגיוני? חשוב לזכור ש-Service Worker משתמש clients.claim() לשלוט בדף במהלך הביקור הראשון, וה-Service Worker מבצע זמן ריצה באופן אגרסיבי שמירה במטמון בתוך ה-handler של fetch. במצב כזה, יתרון בהפעלת קובץ השירות במהירות האפשרית, כדי לנסות לאכלס את המטמון של סביבת זמן הריצה במשאבים שאולי יהיו שימושיים בהמשך. אם המיקום אפליקציית האינטרנט שלכם נכללת בקטגוריה הזו, אז כדאי לחזור אחורה מוודאים שה-handler של install של ה-Service Worker לא מבקש משאבים שנלחמים ברוחב פס עם הבקשות של הדף הראשי.

בדיקה של דברים

דרך נהדרת לדמות ביקור ראשון היא לפתוח את אפליקציית האינטרנט ב-Chrome מצב פרטי window, ולבדוק את התנועה ברשת כלי פיתוח. כאינטרנט כדאי לטעון מחדש מופע מקומי של אפליקציית האינטרנט עשרות פעמים ביום. אבל אם תבקרו שוב באתר שלכם, Service Worker ומטמון מאוכלס באופן מלא, לא תקבלו את אותה חוויית שימוש שמשתמש חדש יקבל בקלות, ואפשר להתעלם מבעיה פוטנציאלית.

לפניכם דוגמה שממחישה את ההבדל בין תזמון הרישום יצרן. שני צילומי המסך צולמו במהלך הביקור בדוגמה אפליקציה ב- מצב פרטי משתמש בויסות נתונים (throttle) ברשת כדי לדמות חיבור איטי.

תנועה ברשת עם רישום מוקדם.

צילום המסך שלמעלה משקף את התנועה ברשת לאחר שינוי הדוגמה כדי לבצע רישום של קובצי שירות (service worker) בהקדם האפשרי. אפשר לראות בקשות מראש במטמון (הרשומות עם גלגל השיניים סמל לצדם, שמגיעה מה-handler של install של ה-Service Worker) לצד בקשות למשאבים אחרים הדרושים להצגת הדף.

תנועה ברשת עם רישום מאוחר.

בצילום המסך שלמעלה, הרישום של Service Worker התעכב עד לאחר הדף נטען. אפשר לראות שהבקשות להעברה מראש למטמון לא מתחילות עד המשאבים אוחזרו מהרשת, כך שאין כל מחלוקת לגבי רוחב פס. בנוסף, בגלל שחלק מהפריטים שאנחנו מעלים למטמון כבר נמצאים מטמון ה-HTTP של הדפדפן – הפריטים שהגודל שלהם הוא (from disk cache) – אנחנו יכולים לאכלס את המטמון של קובץ השירות בלי לעבור שוב ושוב.

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

סיכום

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

דרך פשוטה להבטיח לעכב את הבקשה הראשונית של קובץ השירות עד לאחר שהדף הראשון נטען, להשתמש בישויות הבאות:

if ('serviceWorker' in navigator) {
    window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');
    });
}