הסיפור של מה שנשלח, איך נמדדה ההשפעה והפשרות שנעשו.
רקע
אתם יכולים לחפש כמעט כל נושא ב-Google, ותוצג לכם דף עם תוצאות רלוונטיות ומשמעותיות שקל לזהות. סביר להניח שלא הבנתם שדף תוצאות החיפוש הזה, בתרחישים מסוימים, מוצג באמצעות רכיב טכנולוגי חזק באינטרנט שנקרא קובץ שירות (service worker).
כדי להשיק תמיכה ב-Service Workers בחיפוש Google בלי להשפיע לרעה על הביצועים, נדרשו עשרות מהנדסי תוכנה שעובדים במספר צוותים. זהו הסיפור של מה ששולחנו, איך נמדדו הביצועים ומה היו הפשרות שעשינו.
סיבות מרכזיות לבדוק את האפשרות של שימוש ב-Service Workers
הוספת שירות ל-worker לאפליקציית אינטרנט, כמו ביצוע כל שינוי ארכיטקטוני באתר, צריכה להתבצע מתוך מחשבה על קבוצה ברורה של יעדים. לצוות חיפוש Google היו כמה סיבות עיקריות לכך ששווה לבדוק את האפשרות של הוספת שירות עובד.
אחסון במטמון מוגבל של תוצאות חיפוש
צוות חיפוש Google מצא שמשתמשים מחפשים לעיתים קרובות את אותם מונחים יותר מפעם אחת בתקופה קצרה. במקום להפעיל בקשה חדשה לקצה העורפי רק כדי לקבל את אותן תוצאות, צוות החיפוש רצה לנצל את המטמון ולענות על הבקשות החוזרות באופן מקומי.
אי אפשר להתעלם מהחשיבות של עדכניות, ולפעמים משתמשים מחפשים את אותם מונחים שוב ושוב כי מדובר בנושא שמשתנה, והם מצפים לראות תוצאות עדכניות. השימוש ב-service worker מאפשר לצוות החיפוש להטמיע לוגיקה מפורטת כדי לשלוט במחזור החיים של תוצאות החיפוש שנשמרו במטמון המקומי, וכדי להשיג את האיזון המדויק ביותר בין מהירות לבין עדכניות, לדעתם, שמתאים למשתמשים.
חוויה משמעותית אופליין
בנוסף, צוות חיפוש Google רצה לספק חוויה משמעותית אופליין. כשמשתמש רוצה לקבל מידע על נושא מסוים, הוא רוצה לעבור ישירות לדף של חיפוש Google ולהתחיל לחפש, בלי לדאוג לגבי חיבור אינטרנט פעיל.
בלי עובד שירות, כניסה לדף החיפוש של Google במצב אופליין תוביל לדף השגיאה הרגיל של הרשת בדפדפן, והמשתמשים יצטרכו לזכור לחזור ולנסות שוב אחרי שהחיבור יחזור. באמצעות שירות עובד (service worker), אפשר להציג תגובה מותאמת אישית של HTML במצב אופליין ולאפשר למשתמשים להזין את שאילתה החיפוש באופן מיידי.
התוצאות לא יהיו זמינות עד שיהיה חיבור לאינטרנט, אבל ה-service worker מאפשר לדחות את החיפוש ולשלוח אותו לשרתים של Google ברגע שהמכשיר חוזר לאינטרנט באמצעות background sync API.
אחסון ושליחה חכמים יותר של JavaScript
מטרה נוספת הייתה לבצע אופטימיזציה של האחסון במטמון והטעינה של קוד ה-JavaScript הממוזג שמפעיל את הסוגים השונים של התכונות בדף תוצאות החיפוש. יש כמה יתרונות לחבילות JavaScript, שמתקבלים על הדעת כשאין מעורבות של שירות עובדים, ולכן צוות החיפוש לא רצה פשוט להפסיק את החבילות לגמרי.
צוות החיפוש הבין שאפשר להשתמש ביכולת של שירות העבודה לתייג גרסאות של קטעי JavaScript ברמת פירוט גבוהה ולשמור אותם במטמון בזמן הריצה, כדי לצמצם את כמות השינויים במטמון ולהבטיח שאפשר יהיה לשמור במטמון ביעילות קטעי JavaScript שיעשה בהם שימוש חוזר בעתיד. הלוגיקה בתוך ה-service worker יכולה לנתח בקשת HTTP יוצאת לאוסף (bundle) שמכיל כמה מודולים של JavaScript, ולענות עליה על ידי חיבור של כמה מודולים שנשמרו במטמון המקומי – כלומר, 'פירוק' של האוסף כאשר הדבר אפשרי. כך חוסכים את רוחב הפס של המשתמשים ומשפרים את רמת התגובה הכוללת.
יש גם יתרונות בביצועים של שימוש ב-JavaScript ששמור במטמון ומופעל על ידי שירות לעבודה ברקע: ב-Chrome, ייצוג של קוד בייט שעבר ניתוח של ה-JavaScript הזה מאוחסן ומשומש מחדש, וכך נדרשת פחות עבודה בסביבת זמן הריצה כדי להריץ את ה-JavaScript בדף.
אתגרים ופתרונות
ריכזנו כאן כמה מהאתגרים שהצוות נאלץ להתגבר עליהם כדי להשיג את היעדים שהציב לעצמו. חלק מהאתגרים האלה ספציפיים לחיפוש Google, אבל רבים מהם רלוונטיים למגוון רחב של אתרים שעשויים לשקול פריסה של שירותי עובדים.
בעיה: תקורה של קובץ שירות (service worker)
האתגר הגדול ביותר, והחסם האמיתי היחיד להשקת עובד שירות בחיפוש Google, היה לוודא שהוא לא עושה שום דבר שעלול להגדיל את זמן האחזור שנראה למשתמש. אנחנו ב-Google Search מתייחסים לביצועים מאוד ברצינות, ובעבר חסמנו השקות של פונקציונליות חדשה אם היא הוסיפה אפילו עשרות אלפיות השנייה לזמן האחזור של אוכלוסיית משתמשים מסוימת.
כשהצוות התחיל לאסוף נתוני ביצועים במהלך הניסויים הראשונים שלו, היה ברור שתהיה בעיה. ה-HTML שמוחזר בתגובה לבקשות ניווט לדף תוצאות החיפוש הוא דינמי, ומשתנה מאוד בהתאם ללוגיקה שצריכה לפעול בשרתי האינטרנט של חיפוש Google. בשלב זה אין דרך לשירות ה-worker לשכפל את הלוגיקה הזו ולהחזיר HTML שנשמר במטמון באופן מיידי. הדבר הטוב ביותר שהוא יכול לעשות הוא להעביר בקשות ניווט לשרתים האינטרנטיים לקצה העורפי, מה שמחייב בקשת רשת.
בלי קובץ שירות, הבקשה הזו לרשת מתבצעת מיד אחרי שהמשתמש מנווט. כשרושמים עובד שירות, תמיד צריך להפעיל אותו ולתת לו הזדמנות להריץ את מתעסקי האירועים fetch שלו, גם אם אין סיכוי שמתעסקי האחזור האלה יעשו משהו מלבד להתחבר לרשת. משך הזמן שנדרש להפעלה ולהרצה של קוד ה-service worker הוא זמן יתר מיותר שמתווסף לכל ניווט:
כתוצאה מכך, זמן האחזור של הטמעת ה-service worker ארוך מדי ולא מצדיק את היתרונות האחרים. בנוסף, הצוות גילה, על סמך מדידת זמני האתחול של שירות העבודה במכשירים אמיתיים, שיש חלוקה רחבה של זמני ההפעלה, וחלק מהמכשירים הניידים ברמה נמוכה נדרשים כמעט אותו זמן להפעלת שירות העבודה כמו הזמן הדרוש לשליחת בקשת הרשת ל-HTML של דף התוצאות.
פתרון: שימוש בטעינה מראש של ניווט
התכונה החשובה ביותר שאפשרה לצוות של חיפוש Google להמשיך בהשקה של שירות ה-worker היא טעינה מראש של ניווט. שימוש בטעינה מראש של ניווט הוא שיפור משמעותי בביצועים של כל עובד שירות שצריך להשתמש בתגובה מהרשת כדי לענות לבקשות ניווט. הוא מספק לדפדפן רמז להתחיל לשלוח את בקשת הניווט באופן מיידי, באותו זמן שבו ה-service worker מופעל:
כל עוד הזמן שנדרש להפעלת ה-service worker קצר מהזמן שנדרש לקבלת תגובה מהרשת, לא אמורה להיות עלות זמן אחזור נוספת שנגרמת על ידי ה-service worker.
צוות החיפוש גם היה צריך להימנע משימוש ב-service worker במכשירים ניידים ברמה נמוכה, שבהם זמן האתחול של ה-service worker עלול לחרוג מזמן הבקשה לניווט. מכיוון שאין כלל ברור לגבי מה נחשב למכשיר 'בסיסי', הם הגיעו להווריסטיקה של בדיקת נפח ה-RAM הכולל שמותקן במכשיר. כל מכשיר עם פחות מ-2GB של זיכרון נכלל בקטגוריה של מכשירי קצה נמוכים, שבהם זמן ההפעלה של שירות העבודה לא יהיה מקובל.
נפח האחסון הזמין הוא שיקול נוסף, כי הקבוצה המלאה של המשאבים שרוצים לשמור במטמון לשימוש עתידי יכולה להגיע לכמה מגה-בייט. ממשק navigator.storage מאפשר לדף החיפוש ב-Google לבדוק מראש אם יש סיכון לכך שהניסיונות לשמור נתונים במטמון ייכשל בגלל כישלונות במכסת האחסון.
כך, לצוות החיפוש יש כמה קריטריונים שבעזרתם הוא יכול לקבוע אם להשתמש ב-service worker או לא: אם משתמש נכנס לדף החיפוש של Google באמצעות דפדפן שתומך בעומס קדמי של ניווט, ויש לו לפחות 2GB של זיכרון RAM ומספיק מקום פנוי באחסון, service worker נרשם. דפדפנים או מכשירים שלא עומדים בקריטריונים האלה לא יקבלו שירות מ-service worker, אבל עדיין תהיה להם אותה חוויית שימוש בחיפוש Google שהייתה להם תמיד.
אחד מהיתרונות הנוספים של הרישום הסלקטיבי הוא היכולת לשלוח גרסת service worker קטנה ויעילה יותר. טירגוט לדפדפנים מודרניים למדי להרצת קוד ה-service worker מבטל את העלויות הנוספות של המרת קוד (transpilation) ו-polyfills בדפדפנים ישנים יותר. כך הצלחנו לחתוך כ-8 קילובייט של קוד JavaScript לא דחוס מהגודל הכולל של הטמעת ה-service worker.
בעיה: היקפי קובצי שירות (service worker)
אחרי שצוות החיפוש ערך מספיק ניסויים בזמן אחזור והיה בטוח ששימוש טעינה מראש של ניווט מספק להם דרך קיימת לשימוש ב-Service Worker ללא השפעה על זמן האחזור, החלו להופיע בעיות מעשיות מסוימות. אחת מהבעיות האלה קשורה לכללים של היקף של שירות ה-worker. היקף קובץ השירות קובע אילו דפים הוא יכול לשלוט בהם.
הגדרת ההיקף פועלת על סמך התחילית של נתיב כתובת ה-URL. בדומיינים שמארחים אפליקציית אינטרנט אחת, זה לא בעיה, כי בדרך כלל משתמשים רק בקובץ שירות (service worker) עם ההיקף המקסימלי של /, שיכול לשלוט בכל דף בדומיין.
אבל המבנה של כתובות ה-URL בחיפוש Google קצת יותר מורכב.
אם לקובץ השירות (service worker) יינתן ההיקף המקסימלי /, הוא יוכל לשלוט בכל דף שמתארח ב-/ (או ב-/ המקביל ברמה האזורית), ויש כתובות URL בדומיין הזה שאין להן שום קשר לחיפוש Google.www.google.com היקף הגבלה סביר יותר יהיה /search, שבעזרתו לפחות תוכלו להסיר כתובות URL שלא קשורות בכלל לתוצאות החיפוש.
לצערנו, גם נתיב כתובת ה-URL /search משותף בין סוגים שונים של תוצאות חיפוש ב-Google, ופרמטרי השאילתה של כתובת ה-URL קובעים איזה סוג ספציפי של תוצאת חיפוש יוצג. בחלק מהגרסאות האלה נעשה שימוש בבסיס קוד שונה לחלוטין מזה של דף התוצאות הרגיל של חיפוש באינטרנט. לדוגמה, חיפוש התמונות וחיפוש השופינג מוצגים שניהם בנתיב כתובת ה-URL /search עם פרמטרים שונים של שאילתות, אבל אף אחד מהממשקים האלה לא היה מוכן לשלוח חוויית משתמש משלו של שירותי עבודה (עדיין).
פתרון: יצירת מסגרת לניתוב ולשליחה
יש כמה הצעות שמאפשרות להשתמש במשהו יעיל יותר מתחילית נתיב כתובת URL כדי לקבוע את ההיקפים של קובצי השירות, אבל צוות חיפוש Google נתקע בפריסה של קובץ שירות שלא עשה כלום עבור קבוצת משנה של דפים שבשליטתו.
כדי לעקוף את הבעיה הזו, צוות החיפוש של Google פיתח מסגרת ייעודית לניתוב ולשליחה, שאפשר להגדיר אותה כך שתבדוק קריטריונים כמו הפרמטרים של השאילתה בדף הלקוח, ותשתמש בהם כדי לקבוע באיזה נתיב קוד ספציפי לעבור. במקום להטמיע כללים בקוד, המערכת תוכננה להיות גמישה ולאפשר לצוותים שמשתפים את מרחב כתובות ה-URL, כמו חיפוש תמונות וחיפוש שופינג, להוסיף בעתיד את הלוגיקה של שירות העובדים שלהם, אם הם יחליטו להטמיע אותו.
בעיה: תוצאות ומדדים מותאמים אישית
המשתמשים יכולים להיכנס לחיפוש Google באמצעות חשבונות Google שלהם, וחוויית השימוש שלהם בתוצאות החיפוש עשויה להיות מותאמת אישית על סמך נתוני החשבון הספציפיים שלהם. משתמשים מחוברים מזוהים באמצעות קובצי cookie בדפדפן ספציפיים, שהם תקן ותיק ונתמך באופן נרחב.
עם זאת, אחד החסרונות של שימוש בקובצי cookie בדפדפן הוא שהם לא חשופים בתוך קובץ שירות (service worker), ואין דרך לבדוק באופן אוטומטי את הערכים שלהם ולוודא שהם לא השתנו בגלל שהמשתמש התנתק או עבר לחשבון אחר. (יש מאמצים מתמשכים להעניק גישה לקובצי cookie לקובצי שירות, אבל נכון למועד כתיבת המאמר, הגישה הזו היא ניסיונית ואין לה תמיכה רחבה).
אי-התאמה בין התצוגה של ה-service worker לגבי המשתמש הנוכחי שמחובר לחשבון לבין המשתמש בפועל שמחובר לממשק האינטרנט של חיפוש Google עלולה להוביל לתוצאות חיפוש מותאמות אישית באופן שגוי או לשיוך שגוי של מדדים ורישום ביומן. כל אחד מתרחישי הכשל האלה יהיה בעיה רצינית לצוות חיפוש Google.
פתרון: שולחים קובצי cookie באמצעות postMessage
במקום להמתין להשקת ממשקי API ניסיוניים ולקבל גישה ישירה לקובצי ה-cookie של הדפדפן בתוך שירות העבודה, צוות חיפוש Google השתמש בפתרון זמני: בכל פעם שדף שנשלט על ידי שירות העבודה נטען, הדף קורא את קובצי ה-cookie הרלוונטיים ומשתמש ב-postMessage() כדי לשלוח אותם לשירות העבודה.
לאחר מכן, ה-service worker בודק את ערך קובץ ה-cookie הנוכחי מול הערך שהוא מצפה לו. אם יש אי-התאמה, הוא מבצע פעולות כדי למחוק מהאחסון את כל הנתונים הספציפיים למשתמש, וטעון מחדש את דף תוצאות החיפוש בלי התאמה אישית שגויה.
השלבים הספציפיים שה-service worker מבצע כדי לאפס את הדברים לקו בסיס הם ספציפיים לדרישות של חיפוש Google, אבל אותה גישה כללית עשויה להיות שימושית למפתחים אחרים שמתמודדים עם נתונים מותאמים אישית שמבוססים על קובצי cookie בדפדפנים.
בעיה: ניסויים ודינמיות
כפי שצוין, צוות חיפוש Google מסתמך במידה רבה על הפעלת ניסויים בסביבת הייצור ובדיקת ההשפעות של קוד ותכונות חדשים בעולם האמיתי, לפני שהוא מפעיל אותם כברירת מחדל. יכול להיות שזה יהיה קצת מאתגר עם שירות סטטי של עובד (service worker) שמסתמך במידה רבה על נתונים שנשמרו במטמון, כי לרוב צריך לתקשר עם שרת הקצה העורפי כדי להצטרף לניסויים או לצאת מהם.
פתרון: סקריפט של שירות עובד שנוצר באופן דינמי
הפתרון שהצוות בחר בו היה להשתמש בסקריפט של שירות עובד שנוצר באופן דינמי, שמותאם אישית על ידי שרת האינטרנט לכל משתמש בנפרד, במקום בסקריפט יחיד וסטטי של שירות עובד שנוצר מראש. מידע על ניסויים שעשויים להשפיע על התנהגות ה-service worker או על בקשות הרשת באופן כללי נכלל ישירות בסקריפטים המותאמים אישית של ה-service worker. כדי לשנות את קבוצות החוויות הפעילות של משתמש, משתמשים בשילוב של שיטות מסורתיות, כמו קובצי cookie בדפדפן, וגם בהצגת קוד מעודכן בכתובת ה-URL של ה-service worker הרשום.
שימוש בסקריפט של שירות מנוהל שנוצר באופן דינמי מאפשר גם לספק פתח מילוט במקרה הנדיר שבו יש באימплеменטציה של שירות מנוהל באג קטלני שצריך להימנע ממנו. התגובה הדינמית של ה-server worker עשויה להיות הטמעה של no-op, שמשביתה בפועל את ה-service worker לחלק מהמשתמשים הנוכחיים או לכל המשתמשים.
בעיה: תיאום עדכונים
אחת מהאתגרים הקשים ביותר שצריך להתמודד איתם כשפורסים שירותי עובדים בעולם האמיתי היא למצוא פשרה סבירה בין הימנעות מהשימוש ברשת לטובת המטמון, ובמקביל להבטיח שמשתמשים קיימים יקבלו עדכונים ושינויים קריטיים זמן קצר אחרי הפריסה בסביבת הייצור. האיזון הנכון תלוי בהרבה גורמים:
- האם אפליקציית האינטרנט היא אפליקציה של דף יחיד לטווח ארוך שהמשתמש משאיר פתוחה ללא הגבלת זמן, בלי לנווט לדפים חדשים.
- תדירות הפריסה של עדכונים לשרת האינטרנט בצד העורפי.
- האם המשתמש הממוצע יהיה מוכן להשתמש בגרסה מעט מיושנת של אפליקציית האינטרנט שלכם, או שהעדכניות היא העדיפות העליונה.
במהלך הניסויים עם שירותי העבודה, צוות חיפוש Google הקפיד להמשיך את הניסויים במהלך מספר עדכונים מתוזמנים לקצה העורפי, כדי לוודא שהמדדים וחוויית המשתמש יהיו דומים יותר למה שמשתמשים חוזרים יראו בסופו של דבר בעולם האמיתי.
פתרון: איזון בין עדכניות לשימוש במטמון
אחרי שבדקנו כמה אפשרויות הגדרה שונות, צוות חיפוש Google מצא שההגדרה הבאה מספקת את האיזון הנכון בין עדכניות לשימוש במטמון.
כתובת ה-URL של סקריפט ה-service worker מוצגת עם כותרת התגובה Cache-Control: private, max-age=1500 (1, 500 שניות או 25 דקות), ורשומה עם updateViaCache שמוגדר כ-'all' כדי לוודא שהכותרת תאושר. קצוות העורפי של חיפוש Google באינטרנט הם, כפי שאפשר לדמיין, קבוצה גדולה של שרתים שמפוזרים ברחבי העולם, וצריך להבטיח להם זמן פעולה תקינה של כמעט 100%. פריסה של שינוי שמשפיע על התוכן של סקריפט ה-service worker מתבצעת באופן מדורג.
אם משתמש ייכנס לקצה עורפי שעודכן, ולאחר מכן מנווט במהירות לדף אחר שמגיע לקצה עורפי שעדיין לא קיבל את גרסת ה-service worker המעודכנת, הוא יועבר בין הגרסאות כמה פעמים. לכן, אין חסרון משמעותי בכך שמבקשים מהדפדפן לבדוק אם יש סקריפט מעודכן רק אם חלפו 25 דקות מהבדיקה האחרונה. היתרון של ההסכמה להתנהגות הזו הוא צמצום משמעותי של התנועה שמתקבלת בנקודת הקצה (endpoint) שיוצרת באופן דינמי את הסקריפט של ה-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 קפדניות של שילובים שונים של אפשרויות להצגת מודעות, עד שמצאו את השילוב שהכי מתאים להם.
מפתחים שהתשתית לקצה העורפי שלהם מאפשרת להם לפרוס עדכונים מהר יותר, עשויים להעדיף שהדפדפן יבדוק אם יש סקריפט מעודכן של שירות העבודה (SW) בתדירות גבוהה ככל האפשר, על ידי התעלמות תמידית מהמטמון של HTTP.
אם אתם מפתחים אפליקציה של דף יחיד שהמשתמשים עשויים להשאיר פתוחה למשך זמן רב, סביר להניח ש-skipWaiting() לא תהיה הבחירה הנכונה בשבילכם. אם תאפשרו ל-service worker החדש להיכנס לפעולה בזמן שיש לקוחות לטווח ארוך, אתם עלולים להיתקל בחוסר עקביות במטמון.
נקודות עיקריות
כברירת מחדל, קובצי השירות לא תורמים לביצועים
הוספת קובץ שירות לאפליקציית האינטרנט שלכם מאפשרת להוסיף קטע נוסף של JavaScript שצריך לטעון ולהריץ לפני שאפליקציית האינטרנט תקבל תשובות לבקשות שלה. אם התגובות האלה מגיעות בסופו של דבר מהמטמון המקומי ולא מהרשת, העלות הנוספת של הפעלת ה-service worker בדרך כלל זניחה בהשוואה לשיפור בביצועים שמתקבל מהשימוש בשיטת 'מטמון קודם'. עם זאת, אם אתם יודעים ש-service worker תמיד צריך להתייעץ עם הרשת כשמטפל בבקשות ניווט, שימוש בחיוב מראש של ניווט הוא שיפור קריטי בביצועים.
קובצי שירות (service workers) הם (עדיין!) שיפור הדרגתי
התמיכה ב-Service Workers טובה הרבה יותר היום מאשר לפני שנה. כל הדפדפנים המודרניים כוללים עכשיו לפחות תמיכה מסוימת בשירותי עבודה, אבל לצערנו, יש תכונות מתקדמות של שירותי עבודה – כמו סנכרון ברקע וטעינה מראש של ניווט – שלא הושקו באופן אוניברסלי. עדיין מומלץ לבדוק את התכונות של קבוצת המשנה הספציפית של התכונות שאתם יודעים שאתם צריכים, ולרשום רק עובד שירות כשהן קיימות.
באופן דומה, אם אתם מריצים ניסויים בשטח ואתם יודעים שמכשירים ברמה נמוכה מניבים בסופו של דבר ביצועים נמוכים בגלל העומס הנוסף של שירות העבודה, תוכלו גם במקרים האלה להימנע מרישום של שירות עבודה.
כדאי להמשיך להתייחס לקובצי שירות כשיפור הדרגתי שמתווסף לאפליקציית אינטרנט כשכל התנאים המוקדמים מתקיימים, וכשקובץ השירות מוסיף משהו חיובי לחוויית המשתמש ולביצועי הטעינה הכוללים.
מדידה של כל דבר
הדרך היחידה לדעת אם לשליחת גרסת build של שירות ל-Service Worker הייתה השפעה חיובית או שלילית על חוויית המשתמשים היא לבצע ניסוי ולמדוד את התוצאות.
הפרטים הספציפיים של הגדרת מדידות משמעותיות תלויים בספק ניתוח הנתונים שבו אתם משתמשים ובאופן שבו אתם עורכים בדרך כלל ניסויים בהגדרת הפריסה. גישה אחת, שמשתמשת ב-Google Analytics לאיסוף מדדים, מפורטת במחקר המקרה הזה, שמבוסס על הניסיון בשימוש ב-service workers באפליקציית האינטרנט של Google I/O.
יעדים שאינם יעדים עסקיים
אמנם רבים בקהילת פיתוח האינטרנט משייכים קובצי שירות לאפליקציות אינטרנט מתקדמות, אבל פיתוח 'אפליקציית PWA של חיפוש Google' לא היה היעד הראשוני של הצוות. בשלב זה, אפליקציית האינטרנט של חיפוש Google לא מספקת מטא-נתונים באמצעות מניפסט של אפליקציית אינטרנט, וגם לא מעודדת את המשתמשים לעבור את תהליך ההוספה למסך הבית. צוות החיפוש מרוצה כרגע מהמשתמשים שמגיעים לאפליקציית האינטרנט שלהם דרך נקודות הכניסה המסורתיות לחיפוש Google.
במקום לנסות להפוך את חוויית השימוש באינטרנט של חיפוש Google לדבר שדומה לאפליקציה מותקנת, במהלך ההשקה הראשונית התמקדו בשיפור הדרגתי של האתר הקיים.
תודות
תודה לכל צוות הפיתוח של חיפוש Google באינטרנט על העבודה על הטמעת ה-service worker ועל שיתוף חומרי הרקע ששימשו לכתיבת המאמר הזה. תודה מיוחדת ל-Philippe Golle, Rajesh Rajannathan ו-R. שמואל קלצ'קו, אנדי מרטון, לאונרדו פניה, רחל שירר, גרג טרנו וקליי וולאם.
עדכון (אוקטובר 2021): מאז פרסום המאמר הזה במקור, צוות החיפוש של Google העריך מחדש את היתרונות והחסרונות של הארכיטקטורה הנוכחית של שירותי העבודה. קובץ השירות (service worker) שמתואר למעלה יוצא משימוש. ככל שתשתית האינטרנט של חיפוש Google תתפתח, הצוות עשוי לבחון מחדש את העיצוב של קובץ השירות.