תאריך פרסום: 20 בינואר 2025
החל מגרסה 133 של Chrome (פברואר 2025), כרטיסיות רקע שעומסות על המעבד וקיבלו אישור יישארו קפואות כשמצב החיסכון באנרגיה פועל. המטרה היא לצמצם את צריכת הסוללה של משתמשים שמסתמכים על התכונה 'חיסכון באנרגיה' ושכל אחוז מחיי הסוללה חשוב להם. כדי למזער את השיבושים, רק כרטיסיות ברקע שעומדות בקריטריונים ספציפיים ומציגות שימוש גבוה ב-CPU יקפאו.
מהו הקפאה?
ההקפאה משהה את ביצוע המשימות בדף אינטרנט. בין היתר, אסור:
- פונקציות טיפול באירועים (לדוגמה, קלט, רשת וחיישן)
- טיימרים
- פותרי Promise
ההקפאה שונה מהשלכה, שבה כרטיסייה פורקת מהזיכרון. כשמחזירים את המיקוד לכרטיסייה שהוקפאה, היא מפשירה באופן אוטומטי וכל המשימות שבתור מבוצעות בלי אובדן מצב.
אירועי ההקפאה וההמשך נשלחים כשדף מושהה או מופעל מחדש (ראו מסמכי התיעוד של Page Lifecycle API). האירועים האלה מאפשרים לדף לשחרר משאבים שלא בשימוש, להודיע לשרת שהדף מושהה או לתעד מדדים.
אילו דפים אפשר להקפיא?
ההקפאה תפעל בקבוצות של הקשר הגלישה.
בדרך כלל, קבוצת הקשר גלישה מורכבת מכרטיסייה אחת. עם זאת, כאשר משתמשים בממשקי API כמו window.open(), אפשר לשייך כמה כרטיסיות לאותה קבוצה.
כשמצב החיסכון באנרגיה מופעל, קבוצת הקשר של גלישה תוקפא אם היא עומדת בתנאים הבאים:
- כל הדפים בקבוצה היו מוסתרים ושתקתיים במשך יותר מחמש דקות.
- כל קבוצת משנה של מסגרות מאותו מקור בתוך הקבוצה היא 'מעמיסה על המעבד'.
- הקבוצה לא:
- לספק פונקציונליות של שיתוף מסך או שיחות וידאו (הזיהוי מתבצע באמצעות מיקרופון, מצלמה, צילום מסך/חלון/כרטיסייה או RTCPeerConnection עם RTCDataChannel 'פתוח' או MediaStreamTrack 'פעיל').
- שליטה במכשיר חיצוני (שזוהה באמצעות Web USB, Web Bluetooth, Web HID או Web Serial).
- להחזיק בנעילה של האתר או בחיבור ל-IndexedDB שחוסם פעולות מחוץ לקבוצה.
ההגדרה של 'עומסי עיבוד כבדים' עשויה להשתנות, אבל הכוונה היא להחריג לקוחות אימייל או צ'אט שהוגדרו בצורה יעילה, או אפליקציות יומן שיוצרות התראות.
הקפאה בו-זמנית של כל הכרטיסיות באותה קבוצת הקשר של גלישה מפחיתה את ההפרעה לאפליקציות שמשתמשות בחלונות קופצים, כמו כאלה שמיועדות לכתיבה של הודעות או להזנת פרטי כניסה.
איך אפשר להכין את האתר?
אם באתר שלכם אין פונקציונליות ברקע (לדוגמה, התראות, העלאות של קבצים או רענון תוכן), סביר להניח שההקפאה לא תשפיע עליו.
אם יש באתר פונקציונליות ברקע, כדאי לצמצם את השימוש שלו במעבד (CPU) ברקע כדי להימנע מהגדרה כאתר שמשתמש ב-CPU באופן אינטנסיבי, וכתוצאה מכך להימנע מקיפאון. ריכזנו כאן כמה טיפים:
- מומלץ להימנע משימוש בטיימרים לבדיקות תקופתיות של שינויים במצב.
- משתמשים ב-IntersectionObserver כדי לזהות מתי רכיב נכנס למסך.
- משתמשים ב-ResizeObserver כדי לזהות שינויים בגודל הרכיבים.
- כדי לעקוב אחרי שינויים ב-DOM, משתמשים ב-MutationObserver או בפונקציות קריאה חוזרת (callbacks) בהתאמה אישית של מחזור החיים של רכיבים.
- במקום שרת סקרים, כדאי להשתמש בשקעי אינטרנט, באירועים שנשלחים מהשרת, בהודעות דחיפה או באחזור של שידורים.
- משתמשים באירועים כמו timeupdate ו-ended לשינויים באודיו או בסרטון.
מומלץ גם להעביר את הפונקציונליות ברקע ל-service worker כדי שהיא לא תושפע מההקפאה. בנוסף לכך שהם לא מושפעים מקיפאון, לשירותי העבודה נדרשים פחות משאבי דפדפן. כדאי להשתמש באפשרויות הבאות:
- Push API להתראות
- Background Synchronization API או Web Periodic Background Synchronization API לאחזור עדכונים.
אתרים יכולים לבטל את ההשתתפות בהקפאה על ידי השתתפות בגרסת המקור לניסיון של BackgroundPageFreezeOptOut. תקופת הניסיון הזו תבוטל אחרי שנשיק ממשקי API חדשים להצהרה על משימות חשובות ברקע (לדוגמה, Progress Notification API).
אפשר לבדוק אם כרטיסייה מסוימת עומדת בדרישות להקפאה בכתובת chrome://discards. חשוב לזכור: גם אם כרטיסייה מסוימת עומדת בדרישות להקפאה, היא תוקפא ב-Chrome 133 רק אם היא צורכת הרבה משאבי מעבד והתכונה 'חיסכון באנרגיה' פעילה.
מה השלב הבא?
הקפאה של כרטיסיות ברקע חוסכת באנרגיה, וזה חשוב במיוחד למשתמשים שהפעילו את 'חיסכון באנרגיה'.
בנוסף, היא משפרת את הביצועים של כרטיסיות בחזית ומונעת סגירת כרטיסיות ברקע, במיוחד במכשירים עם מחסור במשאבים, על ידי הפחתת השימוש ב-CPU והגישה לזיכרון. לכן, ב-Chrome נרחיב את ההקפאה של הכרטיסיות למצבים נוספים (השינויים יפורסמו בכתובת blink-dev@chromium.org). כדי לעשות זאת עם הפרעה מינימלית לתרחישי שימוש ברקע, ממשקי API חדשים כמו Progress Notification API יאפשרו לדפים להצהיר על עבודה חשובה ברקע ולמנוע הקפאה.