סקירה כללית של העובדים

איך קובצי שירות (service workers) ו-web workers יכולים לשפר את הביצועים של האתר, ומתי להשתמש ב-web worker לעומת קובץ שירות.

Andrew Guan

Demián Renzulli

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

איך עובדים יכולים לשפר את האתר שלכם

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

בפיתוח אפליקציות ל-iOS או ל-Android, דפוס נפוץ שמאפשר לוודא שהשרשור הראשי של האפליקציה פנוי להגיב לאירועים של משתמשים הוא להעביר פעולות לשרשורים נוספים. למעשה, בגרסאות האחרונות של Android, חסימה של ה-thread הראשי למשך זמן רב מדי גורמת לקריסת האפליקציה.

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

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

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

מופעי worker של אינטרנט וקובצי שירות (service worker)

תכונות דומות

Web workers וקובצי שירות (service workers) הם שני סוגים של workers שזמינים לאתרים. יש להם כמה דברים משותפים:

• שניהם פועלים בשרשור משני, ומאפשרים להריץ קוד JavaScript בלי לחסום את השרשור הראשי ואת ממשק המשתמש.
• אין להם גישה לאובייקטים Window ו-Document, ולכן הם לא יכולים לקיים אינטראקציה ישירה עם ה-DOM, והגישה שלהם לממשקי API של הדפדפן מוגבלת.

הבדלים

אפשר לחשוב שרוב הדברים שאפשר להקצות ל-Web Worker אפשר לעשות ב-Service Worker, ולהפך, אבל יש הבדלים חשובים ביניהם:

• בניגוד ל-Web Workers, ‏Service Workers מאפשרים ליירט בקשות לאחזור מהרשת (באמצעות האירוע fetch) ולהאזין לאירועים של Push API ברקע (באמצעות האירוע push).
• דף יכול להפעיל כמה Web Workers, אבל Service Worker אחד שולט בכל הכרטיסיות הפעילות בהיקף שבו הוא נרשם.
• משך החיים של ה-web worker קשור באופן הדוק לכרטיסייה שאליה הוא שייך, ואילו מחזור החיים של ה-service worker לא תלוי בה. לכן, סגירת הכרטיסייה שבה פועל קובץ שירות (service worker) תסיים את הפעולה שלו, וקובץ שירות (service worker) יכול להמשיך לפעול ברקע, גם כשאין באתר כרטיסיות פתוחות פעילות.

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

תרחישים לדוגמה

ההבדלים בין שני סוגי ה-workers מצביעים על המצבים שבהם כדאי להשתמש בכל אחד מהם:

תרחישי השימוש של Web Workers קשורים בדרך כלל להעברת עבודה (כמו חישובים כבדים) לשרשור משני, כדי למנוע חסימה של ממשק המשתמש.

• דוגמה: הצוות שפיתח את משחק הווידאו PROXX רצה להשאיר את ה-thread הראשי פנוי ככל האפשר כדי לטפל בקלט של המשתמשים ובאנימציות. כדי לעשות את זה, הם השתמשו ב-Web Workers כדי להריץ את הלוגיקה של המשחק ואת תחזוקת המצב בשרשור נפרד.

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

דוגמה: באפליקציית PWA של פודקאסט, יכול להיות שתרצו לאפשר למשתמשים להוריד פרקים שלמים כדי להאזין להם אופליין. לשם כך, אפשר להשתמש ב-Service Worker, ובמיוחד ב-Background Fetch API. כך, אם המשתמש יסגור את הכרטיסייה בזמן שהפרק יורד, המשימה לא תופסק.

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

כלים וספריות

אפשר להטמיע תקשורת בין חלונות ו-workers באמצעות ממשקי API שונים ברמה נמוכה יותר. למזלנו, יש ספריות שמפשטות את התהליך הזה ומטפלות בתרחישים הנפוצים ביותר. בקטע הזה נסקור שתיים מהן, שמטפלות ב-window ל-web workers ול-service workers בהתאמה: Comlink ו-Workbox.

Comlink

‫Comlink היא ספריית RPC קטנה (1.6k) שמטפלת בהרבה פרטים בסיסיים כשיוצרים אתרים שמשתמשים ב-Web Workers. השתמשו בה באתרים כמו PROXX ו-Squoosh. כאן אפשר למצוא סיכום של המניעים ודוגמאות קוד.

Workbox

‫Workbox היא ספרייה פופולרית לבניית אתרים שמשתמשים ב-service workers. הוא כולל חבילה של שיטות מומלצות בנושאים כמו שמירה במטמון, מצב אופליין, סנכרון ברקע וכו'. המודול workbox-window מספק דרך נוחה להחליף הודעות בין ה-service worker לבין הדף.

מה עושים עכשיו

שאר המאמרים בסדרה הזו מתמקדים בדפוסים של תקשורת בין חלונות ל-Service Worker:

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

כדי לראות דוגמאות לתקשורת בין חלונות לבין Web Worker, אפשר לעיין במאמר שימוש ב-Web Worker להרצת JavaScript מחוץ לשרשור הראשי של הדפדפן.