הקטע Background services (שירותי רקע) בכלי הפיתוח ל-Chrome הוא אוסף כלים ל-JavaScript API שמאפשר לאתר לשלוח ולקבל עדכונים גם כשהמשתמש לא פותח את האתר. שירות ברקע דומה מבחינה פונקציונלית לתהליך ברקע.
בקטע שירותים שפועלים ברקע אפשר לנפות באגים בשירותים הבאים שפועלים ברקע:
כלי הפיתוח ל-Chrome יכולים לתעד ביומן אירועי אחזור, סנכרון והתראות למשך שלושה ימים, גם כשכלי הפיתוח לא פתוח. כך תוכלו לוודא שהאירועים נשלחים ומתקבלים כמצופה.
בנוסף לאירועי שירות ברקע, כלי הפיתוח יכולים:
- להציג דוחות ש-Chrome כבר שלח או עומד לשלוח באמצעות Reporting API.
- מאפשרים לנפות באגים ולבדוק את התכונה 'מטמון לדף הקודם/הבא' בלחיצה אחת.
אחזור ברקע
Background Fetch API מאפשר ל-service worker להוריד משאבים גדולים, כמו סרטים או פודקאסטים, באופן מהימן כשירות ברקע. כדי לתעד ביומן אירועי אחזור ברקע למשך שלושה ימים, גם כשכלי הפיתוח לא פתוח:
- פותחים את כלי הפיתוח, למשל בדף הדגמה הזה.
עוברים אל Application (אפליקציה) > Background services (שירותי רקע) > Background fetch (אחזור ברקע), ולוחצים על
Record (הקלטה).
בדף הדמו, לוחצים על אחסון נכסים באופן מקומי. הפעולה הזו מפעילה פעילות של אחזור ברקע. כלי הפיתוח מתעדים את האירועים בטבלה.
לוחצים על אירוע כדי להציג את הפרטים שלו במקום שמתחת לטבלה.
אפשר לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך שלושה ימים לכל היותר. כדי לעצור את ההקלטה, לוחצים על
עצירה.
סינכרון ברקע
Background Sync API מאפשר לסוכנות שירות אופליין לשלוח נתונים לשרת ברגע שהיא מחדשת חיבור אינטרנט מהימן. כדי לתעד ביומן אירועי סנכרון ברקע למשך שלושה ימים, גם כשכלי הפיתוח לא פתוח:
- פותחים את כלי הפיתוח, למשל בדף הדגמה הזה.
עוברים אל אפליקציה > שירותי רקע > סנכרון ברקע ולוחצים על
הקלטה.
בדף הדגמה, לוחצים על Register background sync (רישום סנכרון ברקע) כדי לרשום את ה-service worker המתאים, ולוחצים על Allow (אישור) כשמופיעה בקשה.
רישום של קובץ שירות (service worker) הוא פעילות סנכרון ברקע. כלי הפיתוח מתעדים את האירועים בטבלה.
לוחצים על אירוע כדי להציג את הפרטים שלו במקום שמתחת לטבלה.
אפשר לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך שלושה ימים לכל היותר. כדי לעצור את ההקלטה, לוחצים על
עצירה.
(ניסיוני) הקלות במעקב אחר עזיבה מהדף הראשון
הניסוי אמצעי מיטיגציה למעקב אחר נטישה ב-Chrome מאפשר לזהות ולמחוק את המצב של אתרים שנראה שהם מבצעים מעקב באתרים שונים באמצעות שיטת המעקב אחר נטישה. אתם יכולים לאלץ באופן ידני הפחתת מעקב ולראות רשימה של אתרים שהסטטוסים שלהם נמחקו.
כדי לאלץ את ההקלות במעקב:
- חסימת קובצי Cookie של צד שלישי ב-Chrome עוברים אל
> הגדרות > 
פרטיות ואבטחה > קובצי cookie ונתונים נוספים מאתרים > 
חסימת קובצי cookie של צד שלישי ומפעילים את האפשרות. - בדף
chrome://flags, מגדירים את הניסוי הקלות במעקב אחר עזיבה מהדף הראשון למצב מופעל עם מחיקה. - פותחים את DevTools, למשל בדף הדגמה, ועוברים אל Application > Background services > Bounce tracking mitigations.
- בדף הדגמה, לוחצים על קישור של נטישה ומחכים (10 שניות) עד שמערכת Chrome תתעד את הנטישה. בכרטיסייה בעיות מופיעה אזהרה על המחיקה הקרובה של המצב.
- לוחצים על Force run כדי למחוק את המצב באופן מיידי.
התראות
אחרי שסוכנות שירות מקבלת הודעת דחיפה משרת, היא משתמשת ב-API של התראות כדי להציג את הנתונים למשתמש. כדי לתעד את ההתראות למשך שלושה ימים, גם כשכלי הפיתוח לא פתוחים:
- פותחים את כלי הפיתוח, למשל בדף הדגמה הזה.
עוברים אל Application (אפליקציה) > Background services (שירותי רקע) > Notifications (התראות) ולוחצים על
Record (הקלטה).
בדף הדגמה, לוחצים על תזמון התראה ואז על אישור כשמופיעה בקשה.
מחכים להופעת ההתראה. אירועי ההתראות מתועדים בטבלה ב-DevTools.
לוחצים על אירוע כדי להציג את הפרטים שלו במקום שמתחת לטבלה.
אפשר לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך שלושה ימים לכל היותר. כדי לעצור את ההקלטה, לוחצים על
עצירה.
טעינות ספקולטיביות
טעינות ספקולטיביות מאפשרות טעינה כמעט מיידית של דפים על סמך כללי ספקולציות שאתם מגדירים. כך האתר יוכל לבצע טעינה מראש ולבצע עיבוד מראש של רוב הדפים שמבקרים מנווטים אליהם.
אחזור מראש מאחזר משאב מראש, ורינדור מראש הולך צעד קדימה ומרינדור את הדף כולו בתהליך רינדור מוסתר ברקע.
אפשר לנפות באגים בטעינות ספקולטיביות בקטע Application (אפליקציה) > Background services (שירותי רקע) > Speculative loads (טעינות ספקולטיביות). הקטע מכיל שלוש תצוגות:
- טעינות ספקולטיביות. מכיל את הסטטוס הספקולטיבי של הדף הנוכחי, את כתובת ה-URL הנוכחית, את הדפים שהדף הנוכחי מנסה לטעון באופן ספקולטיבי ואת הסטטוסים שלהם.
- כללים. מכילה את קבוצות הכללים בדף הנוכחי בחלונית Elements ואת הסטטוס הכללי של השערות.
- ספקולציות. הטבלה מכילה מידע על ניסיונות טעינה ספקולטיביים ועל הסטטוסים שלהם. אם ניסיון מסוים נכשל, אפשר ללחוץ עליו בטבלה כדי לראות מידע מפורט וסיבה לכישלון.
אתם יכולים לנסות לנפות באגים בטעינות ספקולטיביות בדף הדגמה הזה:
פותחים את DevTools בדף ועוברים אל Application > Background services > Speculative loads. אם לא מוצגות טעינות ספקולטיביות שהדף יזם, צריך לטעון אותו מחדש.
בדף ההתחלה של ההדגמה, שני דפים עוברים עיבוד מראש, ודף אחד לא עובר עיבוד מראש. לוחצים על הצגת כל הטעינות שמבוצעות מראש.
בקטע ספקולציות, בוחרים את הספקולציה עם הסטטוס כישלון כדי לראות את הקטע סיבה לכישלון עם מידע מפורט בתחתית המסך.
במקרה כזה, העיבוד מראש נכשל כי אין דף
/next3.htmlבאתר.פותחים את הקטע Rules (כללים) ולוחצים על Status (סטטוס) כדי לראות את קבוצת הכללים בתחתית המסך. לחיצה על הקישור Rule set (קבוצת כללים) תעביר אתכם לחלונית Elements (אלמנטים), שבה תוכלו לראות איפה מוגדר כלל השערות הספקולטיביות.
הדרכה מפורטת יותר זמינה במאמר ניפוי באגים של כללי השערות.
העברת הודעות Push
כדי להציג התראה לדחוף למשתמש, סוכנות שירות צריכה קודם להשתמש ב-API של הודעות דחיפה כדי לקבל נתונים משרת. כשה-service worker מוכן להציג את ההתראה, הוא משתמש ב-API של Notifications. כדי לתעד הודעות דחיפה למשך שלושה ימים, גם כש-DevTools לא פתוח:
- פותחים את כלי הפיתוח, למשל בדף הדגמה הזה.
עוברים אל Application (אפליקציה) > Background services (שירותי רקע) > Push Messaging (הודעות דחיפה) ולוחצים על
Record (הקלטה).
בדף הדגמה, מחליפים את המצב של האפשרות הפעלת התראות דחיפה, לוחצים על אישור כשמופיעה בקשה, מקלידים הודעה ושולחים אותה. אירועי התראות הדחיפה מתועדים בטבלה ב-DevTools.
לוחצים על אירוע כדי להציג את הפרטים שלו במקום שמתחת לטבלה.
אפשר לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך שלושה ימים לכל היותר. כדי לעצור את ההקלטה, לוחצים על
עצירה.
Reporting API
חלק מהשגיאות מתרחשות רק בסביבת הייצור. אתם אף פעם לא רואים אותם באופן מקומי או במהלך הפיתוח, כי משתמשים, רשתות ומכשירים אמיתיים משנים את המשחק.
לדוגמה, נניח שהאתר החדש שלכם מסתמך על תוכנה של צד שלישי שמשתמשת ב-document.write() כדי לטעון סקריפטים קריטיים. משתמשים חדשים מכל העולם פותחים את האתר שלכם, אבל יכול להיות שהחיבורים שלהם איטיים יותר מאלה שבהם בדקתם. ללא ידיעתכם, האתר שלכם מתחיל להשתבש אצלם כי Chrome מתערב נגד document.write() ברשתות איטיות. לחלופין, כדאי לעקוב אחרי ממשקי API שהוצאו משימוש או שיוצאו משימוש בקרוב, שעשויים להופיע בקוד הבסיסי שלכם.
Reporting API נועד לעזור לכם לעקוב אחרי קריאות ל-API שהוצאו משימוש, הפרות אבטחה בדף ועוד. אפשר להגדיר דיווח כפי שמתואר במאמר מעקב אחרי אפליקציית האינטרנט באמצעות Reporting API.
כדי להציג את הדוחות שנוצרו על ידי דף:
- עוברים אל
chrome://flags/#enable-experimental-web-platform-features, מגדירים את האפשרות תכונות ניסיוניות של פלטפורמת אינטרנט למופעלת ומפעילים מחדש את Chrome. פותחים את DevTools ועוברים אל Application (אפליקציה) > Background services (שירותי רקע) > Reporting API (Reporting API). לדוגמה, אפשר לעיין בדוחות בדף הדמו הזה.
הכרטיסייה Reporting API מחולקת לשלושה חלקים:
- הטבלה דוחות עם הפרטים הבאים לגבי כל דוח:
- כתובת ה-URL שגרמה ליצירת הדוח
- סוג ההפרה
- סטטוס הדוח
- נקודת הקצה Destination
- חותמת הזמן Generated at
- גוף הדוח
- קטע התצוגה המקדימה של גוף הדוח. כדי לראות תצוגה מקדימה של גוף הדוח, לוחצים על הדוח בטבלת הדוחות.
- הקטע Endpoints (נקודות קצה) עם סקירה כללית של כל נקודות הקצה שהוגדרו בכותרת
Reporting-Endpoints.
סטטוס הדוח
בעמודה סטטוס מצוין אם Chrome שלח את הדוח בהצלחה, עומד לשלוח אותו או נכשל.
| סטטוס | תיאור |
|---|---|
Success |
הדפדפן שלח את הדוח ונקודת הקצה השיבה עם קוד הצלחה (200 או קוד תשובה אחר של הצלחה 2xx). |
Pending |
הדפדפן מנסה לשלוח את הדוח. |
Queued |
הדוח נוצר והדפדפן עדיין לא מנסה לשלוח אותו. דוח מופיע כ-Queued באחד משני המקרים הבאים:
|
MarkedForRemoval |
אחרי כמה ניסיונות חוזרים (Queued), הדפדפן הפסיק לנסות לשלוח את הדוח, ובקרוב הוא יוסר מרשימת הדוחות לשליחה. |
הדוחות יוסרו אחרי זמן מה, גם אם הם נשלחו בהצלחה וגם אם לא.