כיצד עובדי אינטרנט ו-service worker יכולים לשפר את ביצועי האתר שלך, ומתי להשתמש ב-Web worker ומתי להשתמש ב-service worker
סקירה כללית זו מסבירה כיצד עובדי אינטרנט ו-service worker יכולים לשפר את ביצועי האתר שלך, ומתי להשתמש ב-Web Worker לעומת Service Worker. המשך לקרוא את שאר הסדרה הזו כדי להכיר דפוסים ספציפיים של תקשורת חלון ו-Service Worker.
כיצד עובדים יכולים לשפר את האתר שלך
הדפדפן משתמש ב-thread אחד (ה-thread הראשי) כדי להריץ את כל ה-JavaScript בדף אינטרנט, וגם כדי לבצע משימות כמו רינדור הדף וביצוע איסוף אשפה. הרצה של קוד JavaScript מוגזם יכולה לחסום את ה-thread הראשי, לעכב מהדפדפן לבצע את המשימות האלה ולהוביל לחוויית משתמש גרועה.
בפיתוח של אפליקציות ל-iOS ול-Android, דפוס נפוץ להבטיח שה-thread הראשי של האפליקציה יישאר פנוי כדי להגיב לאירועי משתמש הוא להפחית את העומס לשרשורים נוספים. למעשה, בגרסאות האחרונות של Android, חסימה של ה-thread הראשי למשך זמן רב מדי גורם לקריסת אפליקציה.
באינטרנט, JavaScript תוכנן סביב העיקרון של שרשור יחיד, ואין לו יכולות שנדרשות כדי להטמיע מודל ריבוי שרשורים כמו זה שיש לאפליקציות, כמו זיכרון משותף.
למרות המגבלות האלה, אפשר להשיג דפוס דומה באינטרנט באמצעות שימוש בעובדים שמריצים סקריפטים בשרשורי רקע, וכך הם יכולים לבצע משימות בלי להפריע ל-thread הראשי. Worker הוא היקף של JavaScript במלואו שפועל בשרשור נפרד, ללא זיכרון משותף.
בפוסט הזה תלמד על שני סוגים שונים של עובדים (עובדי אינטרנט ועובדי שירות), את הדמיון וההבדלים ביניהם ואת הדפוסים הנפוצים ביותר לשימוש בהם באתרי ייצור.
![תרשים שמוצגים בו שני קישורים בין האובייקט window (חלון ראווה) ל-Web worker ול-Service Worker.](https://web.dev/static/articles/workers-overview/image/diagram-showing-links-be-3f8d21126eb87.png?authuser=5&hl=he)
עובדי אינטרנט ו-service worker
תכונות דומות
עובדי אינטרנט ועובדי שירות הם שני סוגים של עובדים שזמינים לאתרים. יש להם כמה דברים במשותף:
- שתיהן פועלות ב-thread משני, וכך קוד JavaScript יכול לפעול בלי לחסום את ה-thread הראשי ואת ממשק המשתמש.
- אין להם גישה לאובייקטים
Window
ו-Document
, ולכן הם לא יכולים לתקשר עם ה-DOM ישירות, והגישה שלהם לממשקי ה-API של הדפדפן מוגבלת.
הבדלים
אפשר לחשוב שאת רוב הדברים שאפשר להאציל ל-Web worker אפשר לבצע גם ב-service worker ולהיפך, אבל יש הבדלים חשובים ביניהם:
- בניגוד ל-Web Workers, קובצי שירות (service worker) מאפשרים ליירט בקשות רשת (באמצעות האירוע
fetch
) ולהאזין לאירועי Push API ברקע (דרך האירועpush
). - בדף יכול להיות מספר עובדי אינטרנט, אבל קובץ שירות (service worker) אחד שולט בכל הכרטיסיות הפעילות בהיקף שאליו הוא רשום.
- משך החיים של עובד האינטרנט מקושר היטב לכרטיסייה שאליה הוא שייך, ומחזור החיים של ה-service worker אינו תלוי בו. לכן, סגירת הכרטיסייה שבה פועל Web Worker תסגור את הכרטיסייה, בעוד ש-Service Worker יכול להמשיך לפעול ברקע, גם אם אין באתר כרטיסיות פעילות.
תרחישים לדוגמה
ההבדלים בין שני סוגי העובדים מצביעים על מצבים שבהם כדאי להשתמש באחד מהם:
כדי להימנע מחסימה של ממשק המשתמש, תרחישים לדוגמה של עובדי אינטרנט קשורים בדרך כלל לטעינת עבודות (כמו חישובים כבדים) ל-thread משני.
![תרשים עם קישור מהאובייקט window לעובד אינטרנט.](https://web.dev/static/articles/workers-overview/image/diagram-showing-link-th-27e9ed5676ba6.png?authuser=5&hl=he)
- דוגמה: הצוות שיצר את משחק הווידאו PROXX רצה להשאיר את ה-thread הראשי כמה שיותר פנוי כדי לטפל בקלט ובאנימציות של המשתמשים. כדי לעשות זאת, הם השתמשו ב-Webwork כדי להריץ את הלוגיקה של המשחק ואת תחזוקת המצב בשרשור נפרד.
![צילום מסך של משחק הווידאו PROXX.](https://web.dev/static/articles/workers-overview/image/a-screenshot-the-videoga-d7cb8cb8a682c.png?authuser=5&hl=he)
משימות של Service Workers בדרך כלל קשורות יותר לפעולה כשרת proxy של רשת, טיפול במשימות רקע ועוד, כמו שמירה במטמון ואופליין.
![צילום מסך של משחק הווידאו PROXX.](https://web.dev/static/articles/workers-overview/image/a-screenshot-the-videoga-e3257857d928d.png?authuser=5&hl=he)
לדוגמה: באפליקציית PWA של פודקאסט, ייתכן שתרצו לאפשר למשתמשים להוריד פרקים שלמים כדי להאזין להם במצב אופליין. לשם כך ניתן להשתמש ב-Service Worker, ובמיוחד ב-Background Fetch API. כך, אם המשתמש סוגר את הכרטיסייה בזמן הורדת הפרק, לא צריך להפריע למשימה.
![צילום מסך של אפליקציית PWA של פודקאסט.](https://web.dev/static/articles/workers-overview/image/a-screenshot-a-podcast-p-910200b097c52.png?authuser=5&hl=he)
כלים וספריות
ניתן להטמיע את תקשורת החלון והעובדים באמצעות ממשקי API שונים ברמה נמוכה יותר. למרבה המזל, קיימות ספריות שמפשטות את התהליך הזה, שמתאימות במיוחד לתרחישי השימוש הנפוצים ביותר. בחלק הזה נסביר על שניים מהם מטפלים בחלון לעובדי אינטרנט ול-service worker בהתאמה: Comlink ו-Workbox.
![צילום מסך של משחק הווידאו PROXX.](https://web.dev/static/articles/workers-overview/image/a-screenshot-the-videoga-1d6073255f591.png?authuser=5&hl=he)
קישור
Comlink היא ספריית RPC קטנה (1.6 אלף) שמטפלת בפרטים בסיסיים רבים בבניית אתרים שמשתמשים ב-Web Workers. השתמשו בה באתרים כמו PROXX ו-Squoosh. כאן תוכלו למצוא סיכום של המטרות שלו ושל דוגמאות הקוד.
Workbox
Workbox היא ספרייה פופולרית ליצירת אתרים שמשתמשים ב-Service Workers. הוא כולל מספר שיטות מומלצות לגבי קבצים כמו שמירה במטמון, שימוש אופליין, סנכרון ברקע וכו'. המודול workbox-window
מספק דרך נוחה להחליף הודעות בין Service Worker לבין הדף.
השלבים הבאים
שאר סדרה זו מתמקד בדפוסים עבור תקשורת חלון ו-Service Worker:
- מדריך ציווי לשמירה במטמון: קריאה ל-Service Worker מהדף כדי לשמור מראש משאבים (למשל בתרחישים של שליפה מראש).
- עדכוני שידור: קריאה לדף מ-Service Worker כדי לקבל עדכונים חשובים (לדוגמה, אם יש גרסה חדשה של האתר).
- תקשורת דו-כיוונית: האצלת משימה ל-service worker (למשל, הורדה משמעותית) ועדכון הדף על ההתקדמות.
במאמר שימוש ב-Web work כדי להפעיל JavaScript מה-thread הראשי של הדפדפן, תוכלו למצוא דפוסים של תקשורת חלון או אינטרנט.