הקטע Background services בכלי הפיתוח ל-Chrome הוא אוסף של כלים לממשקי JavaScript API שמאפשרים לאתר שלכם לשלוח ולקבל עדכונים גם אם האתר לא פתוח אצל המשתמש. שירות הפועל ברקע דומה מבחינה פונקציונלית לתהליך ברקע.
בקטע שירותים הפועלים ברקע אפשר לנפות באגים בשירותים הבאים שפועלים ברקע:
כלי הפיתוח ל-Chrome יכולים לרשום ביומן אירועים של אחזור, סנכרון והתראות למשך שלושה ימים, גם אם כלי הפיתוח לא פתוחים. כך תוכלו לוודא שהאירועים נשלחים ומתקבלים כמו שצריך.
בנוסף לאירועים של שירות הפועל ברקע, כלי הפיתוח יכולים:
- הצגת דוחות ש-Chrome כבר שלח או עומד לשלוח באמצעות Reporting API.
- מאפשרת לכם לנפות באגים ולבדוק את המטמון לדף הקודם/הבא בלחיצה.
אחזור ברקע
Background Fetch API מאפשר ל-service worker להוריד באופן מהימן משאבים גדולים, כמו סרטים או פודקאסטים, כשירות הפועל ברקע. כדי לרשום ביומן אירועים של אחזור נתונים ברקע למשך שלושה ימים, גם כשכלי הפיתוח לא פתוחים:
- פותחים את כלי הפיתוח בדף שמשתמש ב-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 (הקלטה).
לוחצים על תזמון התראה ועל אישור כשמופיעה בקשה.
חכה עד שתופיע התראה. כלי הפיתוח רושמים את אירועי ההתראות בטבלה.
כדי לראות את הפרטים של אירוע מסוים, לוחצים עליו בטבלה.
אפשר לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך שלושה ימים לכל היותר. כדי לעצור את ההקלטה, לוחצים על
עצירה.
טעינות ספקולטיביות
טעינות ספקולטיביות מאפשרות טעינת דף כמעט מיידית על סמך כללי ספקולציה שאתם מגדירים. כך האתר יכול לבצע אחזור מראש וטרום-עיבוד של רוב הדפים שאליהם המשתמשים מנווטים.
התכונה Prefetch מאחזרת משאב מראש, והתכונה Prerender עושה צעד נוסף ומבצעת רינדור של הדף כולו בתהליך רינדור ברקע מוסתר.
אפשר לנפות באגים בטעינות ספקולטיביות בקטע Application (אפליקציה) > Background services (שירותי רקע) > Speculative loads (טעינות ספקולטיביות). הקטע הזה כולל שלוש תצוגות:
- טעינות ספקולטיביות. המאפיין מכיל את הסטטוס הספקולטיבי של הדף הנוכחי, כתובת ה-URL הנוכחית, הדפים שהדף הנוכחי מנסה לטעון באופן ספקולטיבי והסטטוסים שלהם.
- כללים. מכיל את קבוצות הכללים בדף הנוכחי בחלונית Elements ואת הסטטוס הכללי של ההשערות.
- ספקולציות. כולל טבלה עם מידע על ניסיונות טעינה מראש והסטטוס שלהם. אם ניסיון נכשל, אפשר ללחוץ עליו בטבלה כדי לראות מידע מפורט ואת הסיבה לכישלון.
אפשר לנסות לנפות באגים בטעינה מראש בדף ההדגמה הזה של טעינה מראש:
פותחים את כלי הפיתוח בדף ועוברים אל Application (אפליקציה) > Background services (שירותי רקע) > Speculative loads (טעינות ספקולטיביות). אם לא רואים טעינות ספקולטיביות שהופעלו על ידי הדף, צריך לטעון אותו מחדש.
דף הפתיחה של ההדגמה מבצע עיבוד מראש של שני דפים, ולא מצליח לבצע עיבוד מראש של דף אחד. לוחצים על הצגת כל הטעינות שמבוצעות מראש.
בקטע Speculations, בוחרים את הספקולציה עם הסטטוס Failure כדי לראות את Failure reason בקטע עם מידע מפורט בתחתית.
במקרה הזה, העיבוד מראש נכשל כי אין דף
/next3.htmlבאתר.פותחים את הקטע כללים ולוחצים על סטטוס כדי לראות את קבוצת הכללים בתחתית. לחיצה על הקישור Rule set (קבוצת כללים) מעבירה אתכם לחלונית Elements (אלמנטים) ומראה לכם איפה מוגדר כלל הניחוש.
הוראות מפורטות יותר זמינות במאמר בנושא ניפוי באגים בכללי ניחוש.
העברת הודעות Push
כדי להציג למשתמש הודעת פוש, סוכן שירות צריך קודם להשתמש ב-API של הודעת פוש כדי לקבל נתונים משרת. כש-Service Worker מוכן להציג את ההתראה, הוא משתמש ב-API של התראות. כדי לרשום הודעות פוש במשך שלושה ימים, גם כשכלי הפיתוח לא פתוחים:
- פותחים את כלי הפיתוח, למשל בדף ההדגמה הזה.
עוברים אל Application (אפליקציה) > Background services (שירותים ברקע) > Push Messaging (הודעות פוש) ולוחצים על
Record (תיעוד).
בדף ההדגמה, מעבירים את המתג Enable push notifications (הפעלת התראות פוש), לוחצים על Allow (אישור) כשמופיעה ההודעה, מקלידים הודעה ושולחים אותה. כלי הפיתוח רושמים בטבלה את האירועים של ההתראות בדחיפה.
כדי לראות את הפרטים של אירוע מסוים, לוחצים עליו בטבלה.
אפשר לסגור את כלי הפיתוח ולהשאיר את ההקלטה פועלת למשך שלושה ימים לכל היותר. כדי לעצור את ההקלטה, לוחצים על
עצירה.
Reporting API
חלק מהשגיאות מתרחשות רק בסביבת הייצור. אתם אף פעם לא רואים אותם באופן מקומי או במהלך הפיתוח, כי משתמשים, רשתות ומכשירים אמיתיים משנים את המשחק.
לדוגמה, נניח שהאתר החדש שלכם מסתמך על תוכנה של צד שלישי שמשתמשת ב-document.write() כדי לטעון סקריפטים קריטיים. משתמשים חדשים בכל העולם פותחים את האתר שלכם, אבל יכול להיות שהחיבור שלהם איטי יותר מזה שבדקתם איתו. בלי שתדעו, האתר שלכם מתחיל להפסיק לפעול אצלם כי Chrome מתערב נגד document.write() ברשתות איטיות. לחלופין, כדאי לעקוב אחרי ממשקי API שהוצאו משימוש או שיוצאו משימוש בקרוב, שאולי נעשה בהם שימוש בבסיס הקוד שלכם.
Reporting API נועד לעזור לכם לעקוב אחרי קריאות ל-API שהוצאו משימוש, הפרות אבטחה בדף ועוד. אפשר להגדיר דוחות כמו שמתואר במאמר מעקב אחרי אפליקציית אינטרנט באמצעות Reporting API.
כדי לראות את הדוחות שנוצרו על ידי דף:
- עוברים אל
chrome://flags/#enable-experimental-web-platform-features, מגדירים את Experimental Web Platform features (תכונות ניסיוניות של פלטפורמת האינטרנט) לEnabled (מופעל) ומפעילים מחדש את Chrome. פותחים את כלי הפיתוח ועוברים אל Application (אפליקציה) > Background services (שירותים ברקע) > Reporting API (Reporting API).
הכרטיסייה Reporting API מחולקת לשלושה חלקים:
- טבלת דוחות עם הפרטים הבאים על כל דוח:
- כתובת ה-URL שגרמה ליצירת הדוח
- סוג ההפרה
- סטטוס
- נקודת קצה יעד
- חותמת הזמן Generated at
- דיווח על גוף
- הקטע תצוגה מקדימה של גוף הדוח. כדי לראות תצוגה מקדימה של גוף הדוח, לוחצים על דוח בטבלת הדוחות.
- הקטע Endpoints (נקודות קצה) עם סקירה כללית של כל נקודות הקצה שהוגדרו בכותרת
Reporting-Endpoints.
סטטוס הדוח
בעמודה סטטוס אפשר לראות אם Chrome שלח את הדוח בהצלחה, עומד לשלוח אותו או נכשל בשליחה.
| סטטוס | תיאור |
|---|---|
Success |
הדפדפן שלח את הדוח ונקודת הקצה הגיבה עם קוד הצלחה (200 או קוד תגובה אחר שמציין הצלחה 2xx). |
Pending |
הדפדפן מנסה לשלוח את הדוח. |
Queued |
הדוח נוצר והדפדפן עדיין לא מנסה לשלוח אותו. דוח מופיע כ-Queued באחד משני המקרים הבאים:
|
MarkedForRemoval |
אחרי כמה ניסיונות (Queued), הדפדפן הפסיק לנסות לשלוח את הדוח ובקרוב יסיר אותו מרשימת הדוחות לשליחה. |
דוחות מוסרים אחרי זמן מה, בין אם הם נשלחו בהצלחה ובין אם לא.
סשנים שמוגבלים למכשירים
פרטי כניסה לסשן לפי מכשיר (DBSC) הוא Web API ופרוטוקול בין סוכני משתמשים ושרתים, שמטרתו למנוע גניבת קובצי Cookie. הוא מאפשר לסוכן משתמש להצהיר על בעלות על מפתח פרטי שמאוחסן בצורה מאובטחת.
כדי לראות את הסשנים שמוגבלים למכשיר, את ההגדרות שלהם ואת האירועים:
- פותחים את כלי הפיתוח בדף שמשתמש ב-DBSC.
- עוברים אל Application (אפליקציה) > Background services (שירותי רקע) > Device bound sessions (סשנים שקשורים למכשיר).
בסרגל הצד שמימין, מרחיבים את האתר כדי לראות את הסשנים הפעילים שלו. בוחרים סשן כדי לראות את ההגדרה שלו.
בטבלה אירועים מתועדים אירועי DBSC: יצירה, רענון, אתגר וסיום. כדי לשמור את רשימת האירועים גם כשעוברים בין דפים, מסמנים את התיבה check_box Preserve log (שמירת היומן).
בטבלה אירועים, בוחרים אירוע כדי לראות את הפרטים שלו.
אם אירוע נכשל, תופיע ההודעה
Errorבעמודה תוצאה. בוחרים את האירוע שנכשל כדי לראות את הפרטים שלו, את קוד השגיאה של התגובה ואת סיבת הכשל.
בקטע סשנים שמוגבלים למכשירים בסרגל הצד יכול להיות שיוצגו הבעיות הבאות:
- סשנים שהופסקו: מסומנים בקו חוצה ובסמל של מסד נתונים מושבת בסרגל הצד.
- אירועים שנכשלו: מסומנים בסמל אזהרה. האלמנט No session (ללא סשן) מתעד אירועים שנכשלו ושקושרו לאתר אבל לא לסשן מוכר.