הקטע Background services בכלי הפיתוח ל-Chrome הוא אוסף של כלים לממשקי ה-API של JavaScript, שמאפשרים לאתר שלכם לשלוח ולקבל עדכונים גם אם האתר לא פתוח אצל המשתמש. שירות הפועל ברקע דומה מבחינה פונקציונלית לתהליך ברקע.
בקטע שירותים הפועלים ברקע אפשר לנפות באגים בשירותים הבאים שפועלים ברקע:
כלי הפיתוח ל-Chrome יכולים לרשום ביומן אירועים של אחזור, סנכרון והתראות למשך שלושה ימים, גם אם כלי הפיתוח לא פתוחים. כך תוכלו לוודא שהאירועים נשלחים ומתקבלים כמו שצריך.
בנוסף לאירועים של שירות הפועל ברקע, כלי הפיתוח יכולים:
- להציג לכם דוחות ש-Chrome כבר שלח או עומד לשלוח באמצעות Reporting API.
- מאפשרת לכם לנפות באגים ולבדוק את המטמון לדף הקודם/הבא בלחיצה.
אחזור ברקע
Background Fetch API מאפשר לקובץ שירות להוריד באופן מהימן משאבים גדולים, כמו סרטים או פודקאסטים, כ<b>שירות הפועל ברקע</b>. כדי לרשום ביומן אירועים של אחזור נתונים ברקע למשך שלושה ימים, גם כשכלי הפיתוח לא פתוחים:
- פותחים את כלי הפיתוח בדף באמצעות Background Fetch API.
עוברים אל Application (אפליקציה) > Background services (שירותי רקע) > Background fetch (אחזור ברקע) ולוחצים על
Record (הקלטה).

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

כדי לראות את הפרטים של אירוע מסוים, לוחצים על האירוע בטבלה.
אפשר לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך שלושה ימים לכל היותר. כדי לעצור את ההקלטה, לוחצים על סמל העצירה
.
סינכרון ברקע
Background Sync API מאפשר ל-service worker אופליין לשלוח נתונים לשרת אחרי שהוא יוצר מחדש חיבור אינטרנט אמין. כדי לתעד אירועי סנכרון ברקע למשך שלושה ימים, גם כשכלי הפיתוח לא פתוחים:
- פותחים את כלי הפיתוח, למשל בדף ההדגמה הזה.
עוברים אל Application (אפליקציה) > Background services (שירותי רקע) > Background sync (סנכרון ברקע) ולוחצים על
Record (תיעוד).

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

כדי לראות את הפרטים של אירוע מסוים, לוחצים על האירוע בטבלה.
אפשר לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך שלושה ימים לכל היותר. כדי לעצור את ההקלטה, לוחצים על סמל העצירה
.
(ניסיוני) הקלות במעקב אחרי הפניה אוטומטית
ניסוי Bounce tracking mitigations ב-Chrome מאפשר לזהות ולמחוק את הסטטוס של אתרים שנראה שמבצעים מעקב באתרים שונים באמצעות הטכניקה של מעקב אחרי הפניה אוטומטית. אתם יכולים להפעיל באופן ידני אמצעים לצמצום המעקב ולראות רשימה של אתרים שהמצבים שלהם נמחקו.
כדי להפעיל הקלות במעקב:
- חסימת קובצי Cookie של צד שלישי ב-Chrome עוברים אל
> הגדרות >
פרטיות ואבטחה > קובצי Cookie ונתונים נוספים מאתרים >
חסימת קובצי Cookie של צד שלישי ומפעילים את האפשרות.
- ב-
chrome://flags, מגדירים את הניסוי Bounce tracking mitigations (הקלות במעקב אחרי הפניה אוטומטית) למצב Enabled With Deletion (מופעל עם מחיקה). - פותחים את כלי הפיתוח ועוברים אל Application (אפליקציה) > Background services (שירותי רקע) > Bounce tracking mitigations (אמצעים לצמצום מעקב אחרי הפניה אוטומטית).
- לוחצים על קישור להפניה אוטומטית ומחכים (10 שניות) עד ש-Chrome יתעד את ההפניה האוטומטית. בכרטיסייה בעיות מוצגת אזהרה לגבי מחיקת הסטטוס הקרובה.
- כדי למחוק את הסטטוס באופן מיידי, לוחצים על הפעלה מאולצת.
![]()
התראות
אחרי ש-service worker מקבל הודעת Push משרת, הוא משתמש ב-Notifications API כדי להציג את הנתונים למשתמש. כדי לרשום ביומן את ההתראות למשך שלושה ימים, גם כשכלי הפיתוח לא פתוחים:
- פתיחת כלי הפיתוח
עוברים אל Application (אפליקציה) > Background services (שירותי רקע) > Notifications (התראות) ולוחצים על
Record (הקלטה).

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

כדי לראות את הפרטים של אירוע מסוים, לוחצים על האירוע בטבלה.
אפשר לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך שלושה ימים לכל היותר. כדי לעצור את ההקלטה, לוחצים על סמל העצירה
.
טעינות ספקולטיביות
טעינות ספקולטיביות מאפשרות טעינת דף כמעט מיידית על סמך כללי ספקולציה שהגדרתם. כך האתר יכול לבצע אחזור מראש ועיבוד מראש של רוב הדפים שאליהם המשתמשים מנווטים.
התכונה 'אחזור מראש' מאחזרת משאב מראש, והתכונה 'רינדור מראש' מרחיבה את הפעולה הזו ומרנדרת את הדף כולו בתהליך רינדור ברקע שמוסתר.
אפשר לנפות באגים בטעינות ספקולטיביות בקטע Application (אפליקציה) > Background services (שירותי רקע) > Speculative loads (טעינות ספקולטיביות). הקטע הזה כולל שלוש תצוגות:
- טעינות ספקולטיביות. המאפיין מכיל את הסטטוס הספקולטיבי של הדף הנוכחי, כתובת ה-URL הנוכחית, הדפים שהדף הנוכחי מנסה לטעון באופן ספקולטיבי והסטטוסים שלהם.
- כללים. החלונית Elements מכילה את קבוצות הכללים בדף הנוכחי ואת הסטטוס הכולל של ההשערות.
- ספקולציות. מכיל טבלה עם מידע על ניסיונות טעינה מראש והסטטוס שלהם. אם ניסיון נכשל, אפשר ללחוץ עליו בטבלה כדי לראות מידע מפורט ואת הסיבה לכישלון.
אפשר לנסות לנפות באגים בטעינה מראש בדף ההדגמה הזה של טעינה מראש:
פותחים את כלי הפיתוח בדף ועוברים אל Application (אפליקציה) > Background services (שירותי רקע) > Speculative loads (טעינות ספקולטיביות). אם לא רואים טעינות ספקולטיביות שהופעלו על ידי הדף, צריך לטעון אותו מחדש.

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

במקרה הזה, העיבוד מראש נכשל כי אין דף
/next3.htmlבאתר.אפשר גם לסנן את הטבלה בכרטיסייה Speculations. כדי לעשות זאת, מקלידים ערך בסרגל הסינון בחלק העליון או משתמשים באחד מהמסננים עם המקשים:
url:VALUE,action:VALUEאוaction:VALUE.
פותחים את הקטע כללים ולוחצים על סטטוס כדי לראות את קבוצת הכללים בתחתית. לחיצה על הקישור Rule set (קבוצת כללים) מעבירה אתכם לחלונית Elements (אלמנטים) ומראה לכם איפה מוגדר כלל הניחוש.

הוראות מפורטות יותר זמינות במאמר בנושא ניפוי באגים בכללי ניחוש.
העברת הודעות Push
כדי להציג למשתמש הודעת פוש, סוכן שירות צריך קודם להשתמש ב-API של Push Message כדי לקבל נתונים משרת. כש-Service Worker מוכן להציג את ההתראה, הוא משתמש ב-API של התראות. כדי לרשום ביומן הודעות פוש למשך שלושה ימים, גם כשכלי הפיתוח לא פתוחים:
- פותחים את כלי הפיתוח, למשל בדף ההדגמה הזה.
עוברים אל Application (אפליקציה) > Background services (שירותים ברקע) > Push Messaging (הודעות פוש) ולוחצים על
Record (תיעוד).

בדף ההדגמה, מעבירים את המתג Enable push notifications (הפעלת התראות פוש) למצב מופעל, לוחצים על Allow (אישור) כשמופיעה ההודעה, מקלידים הודעה ושולחים אותה. כלי הפיתוח רושמים בטבלה אירועים של התראות Push.

כדי לראות את הפרטים של אירוע מסוים, לוחצים על האירוע בטבלה.
אפשר לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך שלושה ימים לכל היותר. כדי לעצור את ההקלטה, לוחצים על סמל העצירה
.
Reporting API
יש שגיאות שמתרחשות רק בסביבת הייצור. אתם אף פעם לא רואים אותם באופן מקומי או במהלך הפיתוח, כי משתמשים, רשתות ומכשירים אמיתיים משנים את המשחק.
לדוגמה, נניח שהאתר החדש שלכם מסתמך על תוכנה של צד שלישי שמשתמשת ב-document.write() כדי לטעון סקריפטים קריטיים. משתמשים חדשים בכל העולם פותחים את האתר שלכם, אבל יכול להיות שהחיבור שלהם איטי יותר מזה שבדקתם איתו. בלי שתדעו, האתר שלכם מתחיל להציג שגיאות למשתמשים כי Chrome מתערב נגד document.write() ברשתות איטיות. לחלופין, כדאי לעקוב אחרי ממשקי API שהוצאו משימוש או שיוצאו משימוש בקרוב, שאולי נעשה בהם שימוש בבסיס הקוד שלכם.
Reporting API נועד לעזור לכם לעקוב אחרי קריאות ל-API שהוצאו משימוש, הפרות אבטחה בדף ועוד. אפשר להגדיר דוחות כמו שמתואר במאמר מעקב אחרי אפליקציית אינטרנט באמצעות Reporting API.
כדי לראות את הדוחות שנוצרו על ידי דף:
פותחים את כלי הפיתוח ועוברים אל Application (אפליקציה) > Background services (שירותים ברקע) > Reporting API (Reporting API).

הכרטיסייה Reporting API מחולקת לשלושה חלקים:
- טבלת דוחות עם הפרטים הבאים על כל דוח:
- כתובת ה-URL שגרמה ליצירת הדוח
- סוג ההפרה
- סטטוס
- נקודת קצה של יעד
- חותמת הזמן Generated at
- דיווח על Body
- הקטע גוף הדוח בתצוגה המקדימה. כדי לראות תצוגה מקדימה של גוף הדוח, לוחצים על דוח בטבלת הדוחות.
- בקטע Endpoints (נקודות קצה) מוצגת סקירה כללית של כל נקודות הקצה שהוגדרו בכותרת
Reporting-Endpoints.
סטטוס הדוח
בעמודה סטטוס אפשר לראות אם Chrome שלח את הדוח בהצלחה, עומד לשלוח אותו או נכשל בשליחה.
| סטטוס | תיאור |
|---|---|
Success |
הדפדפן שלח את הדוח ונקודת הקצה השיבה עם קוד הצלחה (200 או קוד תגובה אחר שמציין הצלחה 2xx). |
Pending |
הדפדפן מנסה לשלוח את הדוח. |
Queued |
הדוח נוצר, אבל הדפדפן עדיין לא מנסה לשלוח אותו. דוח מופיע כ-Queued באחד משני המקרים הבאים:
|
MarkedForRemoval |
אחרי כמה ניסיונות (Queued), הדפדפן הפסיק לנסות לשלוח את הדוח ובקרוב הוא יוסר מרשימת הדוחות לשליחה. |
הדוחות מוסרים אחרי זמן מה, בין אם הם נשלחו בהצלחה ובין אם לא.
ההקשר של דוח הקריסה
באמצעות Reporting API, אתם יכולים להגדיר את האתר שלכם כך שדוחות על קריסות יישלחו לנקודת קצה של שרת crash-reporting או default. דוח קריסה יכול לכלול ממשק CrashReportContext שמאפשר לכם לתעד נתונים שרירותיים שקשורים לקריסה בזוגות של מפתח/ערך עבור הקשר הגלישה הנוכחי ברמה העליונה.
בכרטיסייה Application (אפליקציה) > Background services (שירותים ברקע) > Reporting API (API של דיווח) > Crash Report Context (הקשר של דוח קריסה), אפשר לבדוק את נתוני ההקשר של הקריסה ולסנן לפי מפתח או ערך בסרגל הסינון בחלק העליון.

סשנים שמוגבלים למכשירים
Device Bound Session Credentials (DBSC) הוא Web API ופרוטוקול בין סוכני משתמשים ושרתים, שמטרתו למנוע גניבת קובצי Cookie. הוא מאפשר לסוכן משתמש לאשר שהוא מחזיק במפתח פרטי שמאוחסן בצורה מאובטחת.
כדי לראות את הסשנים שמוגבלים למכשיר, את ההגדרות שלהם ואת האירועים:
- פותחים את כלי הפיתוח בדף שמשתמש ב-DBSC.
- עוברים אל Application (אפליקציה) > Background services (שירותי רקע) > Device bound sessions (סשנים שקשורים למכשיר).
בסרגל הצד שמימין, מרחיבים את האתר כדי לראות את הסשנים הפעילים שלו. בוחרים סשן כדי לראות את ההגדרה שלו.

בטבלה אירועים מתועדים אירועי DBSC: יצירה, רענון, אתגר וסיום. כדי לשמור את רשימת האירועים במהלך הניווט בין הדפים, מסמנים את התיבה check_box Preserve log (שמירת היומן).
בטבלה אירועים, בוחרים אירוע כדי לראות את הפרטים שלו.
אם אירוע נכשל, ההודעה
Errorתופיע בעמודה תוצאה. בוחרים את האירוע שנכשל כדי לראות את הפרטים שלו, את קוד השגיאה של התגובה ואת סיבת הכשל.
בקטע סשנים שמוגבלים למכשירים בסרגל הצד יכול להיות שיוצגו הבעיות הבאות:
- סשנים שהופסקו: מסומנים בקו חוצה ובסמל של מסד נתונים מושבת בסרגל הצד.
- אירועים שנכשלו: מודגשים באמצעות סמל אזהרה. האלמנט No session (ללא סשן) מתעד אירועים שנכשלו ושקושרו לאתר אבל לא לסשן מוכר.