הקטע שירותים ברקע בכלי הפיתוח ל-Chrome הוא אוסף של כלים לממשקי ה-API של JavaScript, שמאפשרים לאתר לשלוח ולקבל עדכונים גם כשהאתר לא פתוח אצל המשתמש. שירות שפועל ברקע דומה לתהליך של רקע מסוים.
בקטע שירותים ברקע אפשר לנפות באגים בשירותי הרקע הבאים:
כלי הפיתוח ל-Chrome יכולים לתעד אירועים של אחזור, סנכרון והתראות במשך שלושה ימים, גם כשכלי הפיתוח לא פתוחים. כך תוכלו לוודא שהאירועים נשלחים ומתקבלים כמצופה.
בנוסף לאירועי שירות שפועלים ברקע, כלי הפיתוח יכולים:
- להציג לכם דוחות ש-Chrome כבר שלח או עומד לשלוח באמצעות Reporting API.
- אתם יכולים לנפות באגים ולבדוק את התכונה 'מטמון לדף הקודם/הבא' בקליק אחד.
אחזור ברקע
Background Fetch API מאפשרת ל-service worker להוריד באופן מהימן משאבים גדולים, כמו סרטים או פודקאסטים, כשירות רקע. כדי לתעד אירועי אחזור ברקע במשך שלושה ימים, גם כשכלי הפיתוח לא פתוחים:
- פותחים את כלי הפיתוח, למשל, בדף ההדגמה הזה.
עוברים אל אפליקציה > שירותים ברקע > אחזור ברקע ולוחצים על
רשומה.
בדף ההדגמה, לוחצים על Store assets Local (אחסון נכסים באופן מקומי). מצב זה מפעיל פעילות אחזור מסוימת ברקע. כלי הפיתוח מתעדים את האירועים בטבלה.
לוחצים על אירוע כלשהו כדי להציג את הפרטים שלו במרחב המשותף שמתחת לטבלה.
אתם יכולים לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך עד שלושה ימים. כדי לעצור את ההקלטה, לוחצים על
עצירה.
סינכרון ברקע
Background Sync API מאפשר ל-service worker במצב אופליין לשלוח נתונים לשרת, אחרי שיהיה לו חיבור אמין לאינטרנט. כדי לתעד אירועי סנכרון ברקע במשך שלושה ימים, גם כשכלי הפיתוח לא פתוחים:
- פותחים את כלי הפיתוח, למשל, בדף ההדגמה הזה.
עוברים אל אפליקציה > שירותים ברקע > סנכרון ברקע ולוחצים על
הקלטה.
בדף ההדגמה יש ללחוץ על Register background sync (רישום סנכרון ברקע) כדי לרשום את קובץ השירות (service worker) המתאים ולוחצים על אישור כשתתבקשו.
רישום קובץ שירות (service worker) הוא פעילות סנכרון ברקע. כלי הפיתוח מתעדים את האירועים בטבלה.
לוחצים על אירוע כלשהו כדי להציג את הפרטים שלו במרחב המשותף שמתחת לטבלה.
אתם יכולים לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך עד שלושה ימים. כדי לעצור את ההקלטה, לוחצים על
עצירה.
(ניסיוני) הקלות במעקב אחר עזיבה מהדף הראשון
ניסוי של הקלות במעקב אחר עזיבה מהדף הראשון ב-Chrome מאפשר לזהות ולמחוק את המצב של האתרים שנראה שמבצעים מעקב חוצה-אתרים באמצעות שיטת המעקב אחר עזיבה מהדף הראשון. אפשר לאכוף באופן ידני הקלות במעקב ולראות רשימה של אתרים שהמצבים שלהם נמחקו.
כדי לאלץ הקלות במעקב:
- חסימת קובצי Cookie של צד שלישי ב-Chrome עוברים אל
ומפעילים אותו > הגדרות > 
פרטיות ואבטחה > קובצי cookie ונתונים נוספים מאתרים > 
חסימת קובצי cookie של צד שלישי. - ב-
chrome://flags, מגדירים את הניסוי של הקלות במעקב אחר עזיבה למצב מופעל עם מחיקה. - פותחים את כלי הפיתוח, למשל, בדף ההדגמה, ועוברים אל Application > Background services > הקלות במעקב אחר עזיבה מהדף הראשון.
- בדף ההדגמה, לוחצים על קישור שחוזר על עצמו וממתינים (10 שניות) עד ש-Chrome יתעד את ההחזרה. בכרטיסייה בעיות מוצגות אזהרות על מחיקת המצב הקרוב.
- לוחצים על אילוץ הפעלה כדי למחוק את המצב באופן מיידי.
התראות
אחרי ש-service worker קיבל הודעת Push משרת, הוא משתמש ב-Notifications API כדי להציג את הנתונים למשתמש. כדי לתעד את ההתראות במשך שלושה ימים, גם כשכלי הפיתוח לא פתוחים:
- פותחים את כלי הפיתוח, למשל, בדף ההדגמה הזה.
עוברים אל Application (אפליקציה) > Background services (שירותים ברקע) > Notifications (הודעות) ולוחצים על
Record (רשומה).
בדף ההדגמה, לוחצים על תזמון התראה ועל אישור כשתוצג הבקשה לכך.
ממתינים להופעת ההתראה. כלי הפיתוח מתעדים את אירועי ההתראות בטבלה.
לוחצים על אירוע כלשהו כדי להציג את הפרטים שלו במרחב המשותף שמתחת לטבלה.
אתם יכולים לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך עד שלושה ימים. כדי לעצור את ההקלטה, לוחצים על
עצירה.
טעינות ספקולטיביות
טעינות ספקולטיביות מאפשרות טעינת דף כמעט מיידית על סמך כללי ספקולציות שאתם מגדירים. כך אפשר לבצע שליפה מראש (prefetch) של האתר ולעבד מראש את הדפים שאליהם המשתמשים מועברים הכי הרבה.
שליפה מראש (prefetch) מאחזרת משאב מראש, ועיבוד מראש מתקדם צעד אחד קדימה ומעבדת את כל הדף בתהליך מוסתר של כלי רינדור ברקע.
אפשר לנפות באגים בטעינות ספקולטיביות בקטע אפליקציה > שירותים ברקע > טעינות ספקולטיביות. הקטע מכיל שלוש תצוגות:
- טעינות ספקולטיביות. מכיל את הסטטוס הספקולטיבי של הדף הנוכחי, כתובת ה-URL הנוכחית, הדפים שהדף הנוכחי מנסה לטעון באופן ספקולטיבי והסטטוסים שלהם.
- כללים. מכילה את קבוצות הכללים בדף הנוכחי בחלונית Elements ואת הסטטוס הכללי של ההשערות.
- ספקולציות. מכילה טבלה עם מידע על ניסיונות טעינה ספקולטיבית והסטטוסים שלהם. אם הניסיון נכשל, אפשר ללחוץ עליו בטבלה כדי לראות מידע מפורט ואת הסיבה לכשל.
אפשר לנסות לנפות באגים בטעינות ספקולטיביות בדף ההדגמה הזה:
פותחים את כלי הפיתוח בדף ועוברים אל אפליקציה > שירותים ברקע > טעינות ספקולטיביות. אם לא ניתן לראות טעינות ספקולטיביות שהופעלו על ידי הדף, יש לטעון אותו מחדש.
בדף הפתיחה של ההדגמה מתבצע עיבוד מראש של שני דפים, והעיבוד מראש נכשל. לוחצים על הצגת כל הטעינות שמבוצעות מראש.
בקטע Speculations (ספקולציות), בוחרים את הטעינות שמבוצעות עם הסטטוס Failure כדי לראות את הקטע Failure (הסיבה לכישלון) עם מידע מפורט בתחתית המסך.
במקרה הזה, העיבוד מראש נכשל כי אין דף
/next3.htmlבאתר.פותחים את הקטע כללים ולוחצים על הסטטוס כדי להציג את קבוצת הכללים שהוגדרה למטה. לחיצה על הקישור קבוצת כללים תעביר אתכם לחלונית רכיבים ותציג את המיקום שבו מוגדר כלל הטעינות מראש.
הדרכה מפורטת יותר זמינה במאמר כללי ספקולציות לניפוי באגים.
העברת הודעות Push
כדי להציג התראות למשתמש, service worker צריך קודם להשתמש ב-Push Message API כדי לקבל נתונים משרת. כשה-Service Worker מוכן להציג את ההתראה, הוא משתמש ב-Notifications API. כדי לרשום הודעות בדחיפה למשך שלושה ימים, גם כשכלי הפיתוח לא פתוחים:
- פותחים את כלי הפיתוח, למשל, בדף ההדגמה הזה.
עוברים אל Application (אפליקציה) > Background services (שירותים ברקע) > Push Messaging (שליחת הודעות בדחיפה) ולוחצים על
Record (הקלטה).
בדף ההדגמה, מחליפים את מצב האפשרות הפעלת התראות, לוחצים על אישור כשמופיעה בקשה, מקלידים הודעה ושולחים אותה. כלי הפיתוח מתעדים אירועי דחיפה של התראות לטבלה.
לוחצים על אירוע כלשהו כדי להציג את הפרטים שלו במרחב המשותף שמתחת לטבלה.
אתם יכולים לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך עד שלושה ימים. כדי לעצור את ההקלטה, לוחצים על
עצירה.
Reporting API
חלק מהשגיאות קורות רק בסביבת הייצור. אף פעם לא תראו אותם באופן מקומי או במהלך הפיתוח כי משתמשים, רשתות ומכשירים אמיתיים משנים את המשחק.
לדוגמה, נניח שהאתר החדש מסתמך על תוכנת צד שלישי שמשתמשת ב-document.write() כדי לטעון סקריפטים קריטיים. משתמשים חדשים בכל רחבי העולם פותחים את האתר שלכם, אבל יכול להיות שיש להם חיבורים איטיים יותר ממה שבדקתם. לא ידוע לכם, האתר שלכם מתחיל לפרוץ בגלל שChrome מתנגד נגד document.write() ברשתות איטיות. לחלופין, מומלץ לעקוב אחרי ממשקי API שהוצאו משימוש או שיצאו משימוש בקרוב.
Reporting API נועד לעזור לכם לעקוב אחר קריאות ל-API שהוצאו משימוש, הפרות אבטחה של הדף ועוד. אפשר להגדיר דיווח כמו שמתואר במאמר מעקב אחר אפליקציית האינטרנט באמצעות Reporting API.
כדי להציג את הדוחות שנוצרו על ידי דף:
- עוברים אל
chrome://flags/#enable-experimental-web-platform-features, מגדירים את תכונות ניסיוניות של פלטפורמת האינטרנט למצב מופעל ומפעילים מחדש את Chrome. פותחים את כלי הפיתוח ועוברים אל Application (אפליקציה) > Background Services (שירותים ברקע) > Reporting API (ממשק API לדיווח). לדוגמה, אפשר לעיין בדוחות בדף ההדגמה הזה.
הכרטיסייה Reporting API מחולקת לשלושה חלקים:
- הטבלה Reports (דוחות) עם הפרטים הבאים לגבי כל דוח:
- כתובת ה-URL שגרמה ליצירת הדוח
- סוג ההפרה
- סטטוס הדוח
- נקודת קצה (endpoint) יעד
- חותמת זמן נוצרה
- דיווח על גוף
- קטע התצוגה המקדימה גוף הדוח. כדי לראות תצוגה מקדימה של גוף הדוח, לוחצים על דוח בטבלת הדוחות.
- הקטע Endpoints מכיל סקירה כללית של כל נקודות הקצה שהוגדרו בכותרת
Reporting-Endpoints.
סטטוס דוח
בעמודה סטטוס אפשר לראות אם הדוח נשלח בהצלחה על ידי Chrome, עומד לשלוח אותו או נכשל.
| סטטוס | תיאור |
|---|---|
Success |
הדפדפן שלח את הדוח ונקודת הקצה השיבה עם קוד הצלחה (200 או קוד אחר לתגובת הצלחה 2xx). |
Pending |
הדפדפן מנסה לשלוח את הדוח. |
Queued |
הדוח נוצר והדפדפן עדיין לא מנסה לשלוח אותו. הדוח מופיע בתור Queued באחד משני המקרים הבאים:
|
MarkedForRemoval |
לאחר ניסיון חוזר למשך זמן מה (Queued), הדפדפן הפסיק לשלוח את הדוח ובקרוב הוא יסיר אותו מרשימת הדוחות לשליחה. |
דוחות מוסרים לאחר זמן מה, גם אם הם נשלחו בהצלחה וגם אם לא.