העברת קובצי שירות (service worker) אל חיפוש Google

הסיפור על המוצרים שנשלחו, על האופן שבו מדד ההשפעה נמדד ועל הפשרות שבוצעו.

רקע

חפשו ב-Google כמעט כל נושא, ויוצג לכם דף שאפשר לזהות בו בקלות את התוצאות הרלוונטיות והמשמעותיות. מה שכנראה לא מבינים הוא שדף תוצאות החיפוש הזה, בתרחישים מסוימים, מוצג על ידי תכונה חזקה של טכנולוגיית אינטרנט שנקראת service worker.

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

סיבות עיקריות לחיפוש עובדים עם שירות (service worker)

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

שמירה מוגבלת של תוצאות חיפוש במטמון

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

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

חוויה משמעותית אופליין

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

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

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

שמירה במטמון והצגה של JavaScript בצורה חכמה יותר

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

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

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

אתגרים ופתרונות

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

הבעיה: תקורה של קובץ שירות (service worker)

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

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

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

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

פתרון: שימוש בטעינה מראש של ניווט

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

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

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

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

כתוצאה מכך, לצוות החיפוש נשארו כמה קריטריונים של קריטריונים שיוכלו לקבוע אם להשתמש ב-Service Worker: אם משתמש מגיע לדף של חיפוש Google באמצעות דפדפן שתומך בטעינה מראש של ניווט, עם זיכרון RAM בנפח של 2 ג'יגה בייט לפחות ומספיק נפח אחסון פנוי, אז רשום קובץ שירות (service worker). לדפדפנים או למכשירים שלא עומדים בקריטריונים האלה לא יוגדר קובץ שירות (service worker), אבל הם עדיין יקבלו את אותה חוויית שימוש בחיפוש Google כמו תמיד.

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

הבעיה: היקפים של קובץ השירות (service worker)

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

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

אם קובץ השירות (service worker) היה מקבל את ההיקף המקסימלי של /, הוא יוכל לשלוט בכל דף שמתארח ב-www.google.com (או בדף המקביל לאזור), ויש כתובות URL בדומיין הזה שלא קשורות לחיפוש Google. היקף סביר ומגביל יותר יהיה /search, שלפחות כתובות URL לא יהיו קשורות כלל לתוצאות החיפוש.

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

פתרון: יצירת מסגרת שיגור וניתוב

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

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

הבעיה: תוצאות ומדדים מותאמים אישית

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

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

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

פתרון: שליחת קובצי cookie באמצעות postMessage

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

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

השלבים הספציפיים שה-Service Worker מבצע כדי לאפס דברים לבסיס הנתונים הם ספציפיים לדרישות של חיפוש Google, אבל אותה גישה כללית יכולה להועיל למפתחים אחרים שמטפלים בנתונים מותאמים אישית שהושגו באמצעות קובצי cookie של דפדפנים.

הבעיה: ניסויים ודינמיקה

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

פתרון: סקריפט של Service Worker שנוצר באופן דינמי

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

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

הבעיה: תיאום העדכונים

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

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

במהלך ניסויים עם קובצי שירות (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 דקות מאז הבדיקה האחרונה, ואין לו חיסרון משמעותי. החיסרון של הבעת הסכמה להתנהגות זו הוא צמצום משמעותי בתעבורה שמגיעה מנקודת הקצה שיוצרת באופן דינמי את הסקריפט של 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 היא לא בהכרח פתרון שמתאים לכולם – היא נבעה מבדיקה קפדנית של שילובים שונים של אפשרויות הצגה שונות, עד שהם מצאו מה הכי מתאים להם. מפתחים שהתשתית העורפית שלהם מאפשרת לפרוס עדכונים מהר יותר עשויים להעדיף שהדפדפן יחפש סקריפט מעודכן של Service Worker בתדירות גבוהה ככל האפשר, על ידי התעלמות תמיד מהמטמון של HTTP. אם אתם בונים אפליקציה עם דף אחד שהמשתמשים עשויים להשאיר פתוחה לפרק זמן ארוך, השימוש ב-skipWaiting() הוא כנראה לא האפשרות המתאימה לכם – אתם עלולים להיתקל בחוסר עקביות במטמון אם תאפשרו ל-Service Worker החדש להפעיל את ה-Service Worker כשיש לקוחות לטווח ארוך.

מסקנות עיקריות

כברירת מחדל, Service Workers אינם ניטרליים מבחינת הביצועים

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

ה-Service Workers (עדיין!) הם שיפור הדרגתי

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

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

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

מודדים הכול

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

הפרטים הספציפיים להגדרת מדידות משמעותיות תלויים בספק ניתוח הנתונים שבו אתם משתמשים ובאופן שבו אתם בדרך כלל מבצעים ניסויים בהגדרת הפריסה. אחת מהגישות – שימוש ב-Google Analytics לאיסוף מדדים, מפורטת במקרה לדוגמה על סמך חוויית השימוש ב-Service Workers באפליקציית האינטרנט של Google I/O.

לא יעדים

רבים מחברי קהילת הפיתוח באינטרנט משייכים עובדי שירות ל-Progressive Web Apps, אך פיתוח PWA של חיפוש Google לא היה המטרה הראשונית של הצוות. אפליקציית האינטרנט של חיפוש Google לא מספקת כרגע מטא-נתונים באמצעות מניפסט של אפליקציית אינטרנט, וגם לא מעודדת את המשתמשים לבצע את תהליך ההוספה למסך הבית. צוות החיפוש מרוצה כרגע ממשתמשים שמגיעים לאפליקציית האינטרנט שלהם דרך נקודות הכניסה המסורתיות לחיפוש Google.

במקום לנסות להפוך את חוויית האינטרנט של חיפוש Google לגרסה המקבילה לציפייה מאפליקציה מותקנת, התמקדנו בתהליך ההשקה הראשוני היה בשיפור האתר הקיים.

אישורים

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

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