הסיפור על מה שנשלח, איך נמדדה ההשפעה ומה היו הפשרות שנעשו.
פורסם: 20 ביוני 2019
כשמחפשים נושא כלשהו ב-Google, מוצג דף עם תוצאות רלוונטיות ומשמעותיות שקל לזהות. מה שסביר להניח לא הבנתם הוא שדף תוצאות החיפוש הזה, בתרחישים מסוימים, מוצג על ידי טכנולוגיית אינטרנט מתקדמת שנקראת קובץ שירות (service worker).
כדי להשיק תמיכה ב-Service Worker בחיפוש Google בלי לפגוע בביצועים, נדרשו עשרות מהנדסים שעבדו בכמה צוותים. זהו סיפור על מה שפורסם, איך נמדדו הביצועים ועל אילו פשרות נעשו.
סיבות עיקריות לשימוש ב-Service Workers
כשמוסיפים Service Worker לאפליקציית אינטרנט, בדיוק כמו כשמבצעים שינוי ארכיטקטוני באתר, צריך להגדיר מראש יעדים ברורים. צוות חיפוש Google מצא כמה סיבות עיקריות לכך שכדאי לבדוק את האפשרות להוסיף Service Worker.
שמירת תוצאות חיפוש במטמון באופן מוגבל
צוות חיפוש Google גילה שלרוב המשתמשים מחפשים את אותם מונחים יותר מפעם אחת בפרק זמן קצר. במקום להפעיל בקשת קצה עורפית חדשה רק כדי לקבל את אותן תוצאות, צוות החיפוש רצה לנצל את היתרונות של שמירת נתונים במטמון ולמלא את הבקשות החוזרות באופן מקומי.
אי אפשר להתעלם מהחשיבות של רעננות, ולפעמים משתמשים מחפשים את אותם מונחים שוב ושוב כי מדובר בנושא מתפתח, והם מצפים לראות תוצאות רעננות. השימוש ב-service worker מאפשר לצוות החיפוש להטמיע לוגיקה מפורטת כדי לשלוט במשך החיים של תוצאות חיפוש שנשמרו במטמון באופן מקומי, ולהשיג את האיזון המדויק בין מהירות לבין עדכניות, שלדעתם הכי מועיל למשתמשים.
חוויה משמעותית במצב אופליין
בנוסף, צוות חיפוש Google רצה לספק חוויה משמעותית במצב אופליין. כשמשתמש רוצה לקבל מידע על נושא מסוים, הוא רוצה לעבור ישירות לדף של חיפוש Google ולהתחיל לחפש, בלי לדאוג לגבי חיבור אינטרנט פעיל.
בלי service worker, אם משתמשים ינסו להיכנס לדף החיפוש של Google כשהם במצב אופליין, הם יופנו לדף השגיאה הרגיל של הדפדפן, והם יצטרכו לזכור לחזור ולנסות שוב כשהחיבור שלהם יתחדש. בעזרת service worker, אפשר להציג תגובת HTML מותאמת אישית במצב אופליין ולאפשר למשתמשים להזין את שאילתת החיפוש שלהם באופן מיידי.
התוצאות יהיו זמינות רק כשהמכשיר יתחבר לאינטרנט, אבל ה-service worker מאפשר לדחות את החיפוש ולשלוח אותו לשרתים של Google ברגע שהמכשיר יחזור למצב אונליין באמצעות background sync API.
שמירה במטמון והצגה של JavaScript בצורה חכמה יותר
סיבה נוספת הייתה לבצע אופטימיזציה של השמירה במטמון והטעינה של קוד JavaScript מודולרי שמפעיל את סוגי התכונות השונים בדף תוצאות החיפוש. יש כמה יתרונות לאיגוד של JavaScript שלא רלוונטיים כשאין מעורבות של Service Worker, ולכן צוות החיפוש לא רצה להפסיק את האיגוד לגמרי.
צוות החיפוש חשד שאפשר לצמצם את כמות השינויים במטמון ולהבטיח ש-JavaScript שנעשה בו שימוש חוזר בעתיד יוכל להיכנס למטמון בצורה יעילה. זאת באמצעות היכולת של Service Worker ליצור גרסאות של נתחי JavaScript קטנים ולשמור אותם במטמון בזמן הריצה. הלוגיקה בתוך ה-Service Worker יכולה לנתח בקשת HTTP יוצאת לחבילה שמכילה כמה מודולים של JavaScript, ולמלא אותה על ידי הרכבה של כמה מודולים שנשמרו במטמון באופן מקומי – למעשה, ביטול האגד (unbundling) כשזה אפשרי. כך נחסך רוחב פס למשתמשים ומשתפרת רמת התגובה הכוללת.
יש גם יתרונות בביצועים של שימוש ב-JavaScript שנשמר במטמון ומסופק על ידי service worker: ב-Chrome, ייצוג מנותח של קוד בייט של ה-JavaScript הזה נשמר ונעשה בו שימוש חוזר, וכך נדרשת פחות עבודה בזמן הריצה כדי להריץ את ה-JavaScript בדף.
אתגרים ופתרונות
אלה רק חלק מהמכשולים שהיה צריך להתגבר עליהם כדי להשיג את המטרות שהוגדרו לצוות. חלק מהאתגרים האלה ספציפיים לחיפוש Google, אבל רבים מהם רלוונטיים למגוון רחב של אתרים שאולי שוקלים הטמעה של Service Worker.
בעיה: תקורה של קובץ שירות (service worker)
האתגר הגדול ביותר, והגורם היחיד שמונע את ההשקה של Service Worker בחיפוש Google, היה לוודא שהוא לא עושה שום דבר שעלול להגדיל את זמן האחזור שנתפס על ידי המשתמש. צוות חיפוש Google מתייחס לביצועים ברצינות רבה, ולכן בעבר חסם השקות של פונקציות חדשות אם הן הוסיפו אפילו עשרות מילי-שניות של חביון נוסף לאוכלוסיית משתמשים מסוימת.
כשהצוות התחיל לאסוף נתוני ביצועים במהלך הניסויים הראשונים, היה ברור שתהיה בעיה. קוד ה-HTML שמוחזר בתגובה לבקשות ניווט לדף תוצאות החיפוש הוא דינמי, והוא משתנה מאוד בהתאם ללוגיקה שצריכה לפעול בשרתי האינטרנט של החיפוש. בשלב הזה, אין דרך לשכפל את הלוגיקה הזו ב-service worker ולהחזיר HTML ששמור במטמון באופן מיידי. הפעולה הכי טובה שאפשר לעשות היא להעביר בקשות ניווט לשרתי האינטרנט של העורף, מה שמחייב בקשת רשת.
בלי service worker, בקשת הרשת הזו מתרחשת מיד כשמשתמש עובר לדף אחר. כשרושמים service worker, תמיד צריך להפעיל אותו ולאפשר לו להריץ את מטפלי האירועים fetch שלו, גם אם אין סיכוי שמטפלי האחזור האלה יעשו משהו חוץ מלהתחבר לרשת. כמות הזמן שנדרשת כדי להפעיל את קוד ה-ServiceWorker היא תקורה טהורה שנוספת לכל ניווט:
החיסרון הזה של השהיה ביישום של Service Worker גדול מדי, ולא מצדיק את היתרונות האחרים. בנוסף, הצוות גילה שעל סמך מדידת זמני האתחול של Service Worker במכשירים מהעולם האמיתי, יש פיזור רחב של זמני ההפעלה, ובחלק מהמכשירים הניידים הנמוכים, לוקח כמעט אותו זמן להפעיל את Service Worker כמו הזמן שנדרש כדי לבצע את בקשת הרשת עבור ה-HTML של דף התוצאות.
פתרון: שימוש בטעינה מראש של ניווט
התכונה החשובה ביותר שאפשרה לצוות חיפוש Google להתקדם בהשקת service worker היא טעינה מראש של ניווט. שימוש בטעינה מראש של ניווט הוא שיפור משמעותי בביצועים של כל Service Worker שצריך להשתמש בתגובה מהרשת כדי למלא בקשות ניווט. היא מספקת לדפדפן רמז להתחיל לשלוח את בקשת הניווט באופן מיידי, במקביל להפעלת ה-ServiceWorker:
כל עוד משך הזמן שנדרש להפעלת ה-service worker קצר יותר ממשך הזמן שנדרש לקבלת תגובה מהרשת, לא אמור להיות עיכוב שנובע מה-service worker.
צוות החיפוש היה צריך גם להימנע משימוש ב-Service Worker במכשירים ניידים נמוכים, שבהם זמן האתחול של ה-Service Worker יכול להיות ארוך יותר מבקשת הניווט. מכיוון שאין כלל ברור לגבי מה נחשב למכשיר 'נמוך', הם הגיעו לשיטה היוריסטית של בדיקת זיכרון ה-RAM הכולל שמותקן במכשיר. כל מכשיר עם פחות מ-2 גיגה-בייט זיכרון נכנס לקטגוריית המכשירים הנמוכה שלהם, שבה זמן ההפעלה של Service Worker לא יהיה מקובל.
שיקול נוסף הוא נפח האחסון הזמין, כי יכול להיות שקבוצת המשאבים המלאה שצריך לשמור במטמון לשימוש עתידי תגיע לכמה מגה-בייט. ממשק navigator.storage מאפשר לדף של חיפוש Google לגלות מראש אם הניסיונות שלו לשמור נתונים במטמון עלולים להיכשל בגלל חריגה ממכסת האחסון.
כך נותרו לצוות החיפוש כמה קריטריונים שבהם הוא יכול להשתמש כדי לקבוע אם להשתמש ב-service worker: אם משתמש מגיע לדף חיפוש Google באמצעות דפדפן שתומך בטעינה מראש של ניווט, ויש לו לפחות 2 גיגה-בייט של זיכרון RAM ומספיק נפח אחסון פנוי, אז נרשם service worker. דפדפנים או מכשירים שלא עומדים בקריטריונים האלה לא יקבלו service worker, אבל עדיין יוכלו ליהנות מחוויית השימוש בחיפוש Google כמו תמיד.
יתרון נוסף של הרישום הסלקטיבי הזה הוא האפשרות לשלוח service worker קטן ויעיל יותר. טירגוט של דפדפנים מודרניים יחסית להרצת קוד service worker מבטל את התקורה של טרנספילציה ו-polyfills בדפדפנים ישנים יותר. בסופו של דבר, הפעולה הזו קיצצה כ-8 קילובייט של קוד JavaScript לא דחוס מהגודל הכולל של ההטמעה של Service Worker.
בעיה: היקפי קובץ השירות (service worker)
אחרי שצוות החיפוש ערך מספיק ניסויים בנושא זמן האחזור והיה בטוח ששימוש בטעינה מראש של ניווט מציע נתיב אפשרי וניטרלי מבחינת זמן האחזור לשימוש ב-service worker, התחילו לצוץ כמה בעיות מעשיות. אחת מהבעיות האלה קשורה לכללי ההיקף של Service Worker. ההיקף של קובץ שירות (service worker) קובע באילו דפים הוא יכול לשלוט.
הגדרת היקף פועלת על סמך תחילית נתיב כתובת ה-URL. בדומיינים שמארחים אפליקציית אינטרנט אחת, זו לא בעיה, כי בדרך כלל משתמשים בקובץ שירות עם הטווח המקסימלי של /, שיכול לשלוט בכל דף בדומיין.
אבל המבנה של כתובות ה-URL בחיפוש Google קצת יותר מורכב.
אם קובץ השירות יקבל את הטווח המקסימלי של /, הוא יוכל להשתלט על כל דף שמארח את www.google.com (או את המקבילה האזורית), ויש כתובות URL בדומיין הזה שלא קשורות לחיפוש Google. היקף סביר ומגביל יותר יהיה /search, שלפחות יסיר כתובות URL שלא קשורות בכלל לתוצאות החיפוש.
לצערנו, גם נתיב כתובת ה-URL /search משותף בין סוגים שונים של תוצאות חיפוש ב-Google, ופרמטרים של שאילתת כתובת URL קובעים איזה סוג ספציפי של תוצאת חיפוש מוצג. חלק מהטעמים האלה משתמשים בבסיסי קוד שונים לחלוטין מדף התוצאות הרגיל של חיפוש האינטרנט. לדוגמה, גם חיפוש תמונות וגם חיפוש קניות מוצגים בנתיב כתובת ה-URL /search עם פרמטרים שונים של שאילתות, אבל אף אחד מהממשקים האלה לא היה מוכן להשקה של חוויית משתמש משלו עם Service Worker (עדיין).
פתרון: יצירת מסגרת לשליחה ולניתוב
יש הצעות מסוימות שמאפשרות להשתמש במשהו חזק יותר מקידומות של נתיבי כתובות URL כדי לקבוע את היקפי השליטה של Service Worker, אבל צוות חיפוש Google לא הצליח לפרוס Service Worker שלא עשה כלום עבור קבוצת משנה של דפים שהוא שלט בהם.
כדי לעקוף את הבעיה הזו, צוות חיפוש Google יצר מסגרת מותאמת אישית לשליחה ולניתוב, שאפשר להגדיר אותה כך שתבדוק קריטריונים כמו פרמטרים של שאילתות בדף הלקוח, ותשתמש בהם כדי לקבוע באיזה נתיב קוד ספציפי להשתמש. במקום להגדיר כללים באופן קשיח, המערכת נבנתה כך שתהיה גמישה ותאפשר לצוותים שמשתפים את מרחב כתובות ה-URL, כמו חיפוש תמונות וחיפוש שופינג, להוסיף בהמשך את הלוגיקה של Service Worker משלהם, אם הם יחליטו להטמיע אותה.
בעיה: תוצאות ומדדים מותאמים אישית
המשתמשים יכולים להיכנס לחיפוש Google באמצעות חשבונות Google שלהם, וחוויית החיפוש שלהם עשויה להיות מותאמת אישית על סמך נתוני החשבון הספציפיים שלהם. משתמשים מחוברים מזוהים באמצעות קובצי Cookie ספציפיים בדפדפן, שהוא תקן ותיק ונתמך באופן נרחב.
אבל יש גם חיסרון בשימוש בקובצי Cookie בדפדפן: הם לא נחשפים בתוך קובץ שירות (service worker), ואין דרך לבדוק באופן אוטומטי את הערכים שלהם ולוודא שהם לא השתנו בגלל שהמשתמש יצא מהחשבון או עבר לחשבון אחר. (יש מאמץ מתמשך להוסיף גישה לקובצי Cookie ל-Service Workers, אבל בזמן כתיבת המאמר, הגישה הזו היא ניסיונית ולא נתמכת באופן נרחב).
חוסר התאמה בין התצוגה של העובד בשירות לגבי המשתמש שמחובר כרגע לבין המשתמש שמחובר בפועל לממשק האינטרנט של חיפוש Google עלול להוביל לתוצאות חיפוש מותאמות אישית שגויות או למדדים ולרישום ביומן שגויים. כל אחד מתרחישי הכשל האלה יהיה בעיה חמורה עבור צוות חיפוש Google.
פתרון: שליחת קובצי Cookie באמצעות postMessage
במקום לחכות להשקת ממשקי API ניסיוניים שיספקו גישה ישירה לקובצי ה-Cookie של הדפדפן בתוך Service Worker, צוות חיפוש Google בחר בפתרון זמני: בכל פעם שנטען דף שמנוהל על ידי Service Worker, הדף קורא את קובצי ה-Cookie הרלוונטיים ומשתמש ב-postMessage() כדי לשלוח אותם ל-Service Worker.
לאחר מכן, ה-service worker בודק את ערך קובץ ה-Cookie הנוכחי מול הערך שהוא מצפה לו. אם יש אי התאמה, הוא מבצע פעולות כדי למחוק מהאחסון שלו את כל הנתונים שספציפיים למשתמש, וטוען מחדש את דף תוצאות החיפוש בלי התאמה אישית שגויה.
השלבים הספציפיים ש-Service Worker מבצע כדי לאפס את הדברים למצב בסיסי הם ספציפיים לדרישות של חיפוש Google, אבל יכול להיות שהגישה הכללית הזו תהיה שימושית למפתחים אחרים שעובדים עם נתונים מותאמים אישית שמבוססים על קובצי Cookie בדפדפנים.
בעיה: ניסויים ודינמיות
כמו שציינו, הצוות של חיפוש Google מסתמך במידה רבה על הרצת ניסויים בסביבת ייצור ובדיקת ההשפעות של קוד ותכונות חדשים בעולם האמיתי לפני הפעלתם כברירת מחדל. זה יכול להיות קצת מאתגר עם worker סטטי של שירות שמסתמך במידה רבה על נתונים במטמון, כי כדי להוסיף משתמשים לניסויים ולהסיר אותם מהם צריך בדרך כלל תקשורת עם השרת העורפי.
פתרון: סקריפט של Service Worker שנוצר באופן דינמי
הפתרון שבו השתמש הצוות היה ליצור סקריפט של Service Worker שנוצר באופן דינמי, בהתאמה אישית על ידי שרת האינטרנט לכל משתמש בנפרד, במקום סקריפט סטטי יחיד של Service Worker שנוצר מראש. מידע על ניסויים שעשויים להשפיע על ההתנהגות של ה-service worker או על בקשות לרשת באופן כללי נכלל ישירות בסקריפטים המותאמים אישית של ה-service worker. שינוי של קבוצות החוויות הפעילות של משתמש מתבצע באמצעות שילוב של טכניקות מסורתיות, כמו קובצי Cookie בדפדפן, וגם באמצעות הצגת קוד מעודכן בכתובת ה-URL של Service Worker הרשום.
שימוש בסקריפט של Service Worker שנוצר באופן דינמי גם מקל על יצירת מנגנון חילוץ למקרה הלא סביר שבו הטמעה של Service Worker כוללת באג קטלני שצריך להימנע ממנו. תגובת ה-server worker הדינמית יכולה להיות יישום no-op, שמשבית למעשה את ה-service worker עבור חלק מהמשתמשים הנוכחיים או כולם.
בעיה: תיאום עדכונים
אחד האתגרים הקשים ביותר בהטמעה של service worker בשירותים בעולם האמיתי הוא למצוא איזון סביר בין הימנעות מהרשת לטובת המטמון, לבין הבטחה שהמשתמשים הקיימים יקבלו עדכונים ושינויים חשובים זמן קצר אחרי שהם יוטמעו בסביבת הייצור. האיזון הנכון תלוי בהרבה גורמים:
- אם אפליקציית האינטרנט שלכם היא אפליקציה ארוכת טווח של דף יחיד שהמשתמש משאיר פתוחה ללא הגבלת זמן, בלי לעבור לדפים חדשים.
- מהו קצב הפריסה של עדכונים לשרת האינטרנט של הקצה העורפי.
- האם משתמש ממוצע יסכים להשתמש בגרסה מעט מיושנת של אפליקציית האינטרנט, או שהעדכניות היא בראש סדר העדיפויות.
במהלך הניסויים עם Service Workers, הצוות של חיפוש Google הקפיד להמשיך להריץ את הניסויים במספר עדכונים מתוזמנים של ה-Backend, כדי לוודא שהמדדים וחוויית המשתמש יתאימו יותר למה שמשתמשים חוזרים יראו בסופו של דבר בעולם האמיתי.
פתרון: איזון בין רענון לבין שימוש במטמון
אחרי בדיקה של מספר אפשרויות הגדרה שונות, צוות חיפוש Google גילה שההגדרה הבאה מספקת את האיזון הנכון בין עדכניות לבין ניצול מטמון.
כתובת ה-URL של סקריפט ה-Service Worker מוגשת עם כותרת התגובה Cache-Control: private, max-age=1500 (1,500 שניות, או 25 דקות), והיא רשומה עם updateViaCache שהערך שלה הוא all כדי לוודא שהכותרת תכובד. כמו שאפשר לשער, ה-Backend של חיפוש Google באינטרנט הוא קבוצה גדולה של שרתים שמפוזרים ברחבי העולם, ונדרש זמן פעולה רציפה של כמעט 100%. פריסת שינוי שישפיע על התוכן של סקריפט ה-service worker מתבצעת באופן הדרגתי.
אם משתמש מגיע לקצה העורפי שעודכן, ואז מנווט במהירות לדף אחר שמגיע לקצה העורפי שעדיין לא קיבל את ה-service worker המעודכן, הוא יגיע למצב שבו הוא עובר בין הגרסאות כמה פעמים. לכן, אין חיסרון משמעותי בהוראה לדפדפן לבדוק אם יש סקריפט מעודכן רק אם עברו 25 דקות מאז הבדיקה האחרונה. היתרון בהסכמה להתנהגות הזו הוא צמצום משמעותי של התנועה שמתקבלת בנקודת הקצה שיוצרת באופן דינמי את הסקריפט של Service Worker.
בנוסף, מוגדרת כותרת ETag בתגובת ה-HTTP של סקריפט ה-Service Worker, כדי להבטיח שכאשר מתבצעת בדיקת עדכון אחרי 25 דקות, השרת יוכל להגיב ביעילות עם תגובת HTTP 304 אם לא בוצעו עדכונים ל-Service Worker שנפרס בינתיים.
חלק מהאינטראקציות באפליקציית האינטרנט של חיפוש Google משתמשות בניווטים בסגנון אפליקציה של דף יחיד (כלומר, באמצעות History API), אבל ברוב המקרים, חיפוש Google היא אפליקציית אינטרנט מסורתית שמשתמשת בניווטים 'אמיתיים'. ההחלטה הזו מתקבלת כשהצוות מחליט שיהיה יעיל להשתמש בשתי אפשרויות שמאיצות את מחזור החיים של העדכון של Service Worker:
clients.claim()
ו-
skipWaiting().
לחיצה על רכיבים בממשק של חיפוש Google בדרך כלל מובילה לניווט למסמכי HTML חדשים. הפעלת skipWaiting מבטיחה ש-service worker מעודכן יוכל לטפל בבקשות הניווט החדשות האלה מיד אחרי ההתקנה. באופן דומה, קריאה ל-clients.claim() פירושה של-service worker המעודכן יש סיכוי להתחיל לשלוט בכל דפי חיפוש Google הפתוחים שלא נשלטים, אחרי הפעלת ה-service worker.
הגישה שבה השתמשו בחיפוש Google היא לא בהכרח פתרון שמתאים לכולם – היא הייתה תוצאה של בדיקות A/B קפדניות של שילובים שונים של אפשרויות הצגה, עד שנמצא השילוב שהניב את התוצאות הכי טובות.
מפתחים שהתשתית שלהם מאפשרת להם לפרוס עדכונים מהר יותר, עשויים להעדיף שהדפדפן יבדוק אם יש סקריפט מעודכן של Service Worker בתדירות גבוהה ככל האפשר, על ידי התעלמות תמיד ממטמון ה-HTTP.
אם אתם מפתחים אפליקציה של דף יחיד שהמשתמשים עשויים להשאיר פתוחה למשך זמן ארוך, כנראה ששימוש ב-skipWaiting() לא מתאים לכם – אתם עלולים להיתקל בחוסר עקביות במטמון אם תאפשרו להפעיל את ה-service worker החדש בזמן שיש לקוחות לטווח ארוך.
נקודות עיקריות
כברירת מחדל, קובצי שירות (service worker) לא משפיעים על הביצועים
הוספה של קובץ שירות (service worker) לאפליקציית האינטרנט שלכם כוללת הוספה של קטע JavaScript נוסף שצריך לטעון ולהפעיל לפני שאפליקציית האינטרנט מקבלת תשובות לבקשות שלה. אם התגובות האלה מגיעות ממטמון מקומי ולא מהרשת, בדרך כלל התקורה של הפעלת ה-service worker זניחה בהשוואה לשיפור הביצועים שמתקבל מגישה של 'מטמון קודם'. אבל אם אתם יודעים ש-service worker תמיד צריך לבדוק את הרשת כשמטפלים בבקשות ניווט, שימוש בטעינה מראש של ניווט הוא שיפור משמעותי בביצועים.
קובצי שירות (service worker) הם (עדיין!) שיפור מתקדם
התמיכה ב-service worker היום טובה בהרבה ממה שהייתה אפילו לפני שנה. כל הדפדפנים המודרניים כוללים עכשיו לפחות תמיכה מסוימת ב-Service Workers, אבל לצערנו, יש תכונות מתקדמות של Service Workers – כמו סנכרון ברקע וטעינה מראש של ניווט – שלא מוטמעות באופן אוניברסלי. עדיין מומלץ לבדוק את התכונות של קבוצת המשנה הספציפית של התכונות שאתם צריכים, ולרשום את ה-service worker רק אם התכונות האלה קיימות.
באופן דומה, אם הפעלתם ניסויים בפועל ואתם יודעים שמכשירים חלשים מתפקדים בצורה גרועה עם התקורה הנוספת של Service Worker, אתם יכולים להימנע מרישום של Service Worker גם בתרחישים האלה.
כדאי להמשיך להתייחס ל-service workers כאל שיפור מתקדם שמתווסף לאפליקציית אינטרנט כשכל התנאים המוקדמים מתקיימים, וש-service worker מוסיף משהו חיובי לחוויית המשתמש ולביצועים הכוללים של הטעינה.
מדידת כל הנתונים
הדרך היחידה לדעת אם שליחת Service Worker השפיעה באופן חיובי או שלילי על חוויית המשתמש היא לבצע ניסוי ולמדוד את התוצאות.
הפרטים הספציפיים של הגדרת מדידות משמעותיות תלויים בספק שירותי הניתוח שבו אתם משתמשים, ובאופן שבו אתם בדרך כלל מבצעים ניסויים בהגדרת הפריסה שלכם. אחת הגישות, שבה נעשה שימוש ב-Google Analytics כדי לאסוף מדדים, מפורטת במקרה השימוש הזה שמבוסס על חוויית השימוש ב-service workers באפליקציית האינטרנט של Google I/O.
לא שערים
אף על פי שרבים בקהילת פיתוח האתרים משייכים קובצי שירות לאפליקציות אינטרנט מתקדמות, בניית PWA של חיפוש Google לא הייתה מטרה ראשונית של הצוות. אפליקציית האינטרנט של חיפוש Google לא מספקת מטא-נתונים במניפסט של אפליקציית אינטרנט, והיא גם לא מעודדת את המשתמשים לעבור את תהליך ההוספה למסך הבית. צוות החיפוש מרוצה מהמשתמשים שמגיעים לאפליקציית האינטרנט שלו דרך נקודות הכניסה הקלאסיות לחיפוש Google.
במקום לנסות להפוך את חוויית השימוש באתר של חיפוש Google למקבילה של מה שאפשר לצפות מאפליקציה מותקנת, המטרה של הגרסה הראשונית הייתה לשפר בהדרגה את האתר הקיים.
תודות
תודה לכל צוות פיתוח האינטרנט של חיפוש Google על העבודה שלהם בנושא הטמעה של Service Worker, ועל שיתוף חומר הרקע ששימש לכתיבת המאמר הזה. תודה מיוחדת לפיליפ גול (Philippe Golle), לרג'ש ג'גנאתן (Rajesh Jagannathan), ל-R. סמואל קלאצ'קו, אנדי מרטון, לאונרדו פניה, רייצ'ל שירר, גרג טרונו וקליי וולאם.
עדכון (אוקטובר 2021): מאז פרסום המאמר הזה, צוות חיפוש Google העריך מחדש את היתרונות והחסרונות של ארכיטקטורת Service Worker הנוכחית שלו. קובץ השירות (service worker) שמתואר למעלה יוצא משימוש. כשתשתית האינטרנט של חיפוש Google תתפתח, הצוות עשוי לחזור לתכנון של Service Worker.