כרטיסיות רקע ב-Chrome 57

כרטיסיות ברקע יכולות להשפיע לרעה באופן משמעותי על ביצועי הדפדפן, במיוחד על חיי הסוללה. כדי להפחית את הסיכון, בשנים האחרונות החיל ב-Chrome הגבלות שונות על כרטיסיות רקע. לאחרונה ביצענו כמה פעולות כדי לשפר את הנושא, והמסמך הזה מספק סקירה כללית של המדיניות בנושא ב-Chrome. מסמך זה מתמקד בתיאור כללי המדיניות הנוכחיים ב-Chrome 57. במסמך הזה מפורטת האסטרטגיה לטווח הארוך ותוכניות נוספות.

אופטימיזציה של אפליקציה לרקע

מפתחי אתרים צריכים לדעת שלמשתמשים יש לעיתים קרובות הרבה כרטיסיות פתוחות ברקע, וזה יכול להשפיע באופן משמעותי על צריכת החשמל ועל חיי הסוללה. מומלץ להימנע ככל האפשר מביצוע פעולות ברקע, אלא אם הן חיוניות כדי לספק חוויית משתמש מסוימת. צריך להשתמש ב-Page visibility API כדי לזהות מתי הדף נמצא ברקע ולהשהות את כל העבודה הלא הכרחית, כמו עדכונים חזותיים.

בחלק מהאתרים, האופטימיזציה הפשוטה הזו יכולה להפחית את השימוש במעבד (CPU) ב-75%:

var doVisualUpdates = true;

document.addEventListener('visibilitychange', function(){
    doVisualUpdates = !document.hidden;
});

function update() {
    if (!doVisualUpdates) {
    return;
    }
    doStuff();
}

מדיניות

requestAnimationFrame()

בהתאם למסמכי העזרה, Chrome לא קורא ל-requestAnimationFrame() כשדף נמצא ברקע. ההתנהגות הזו קיימת מאז 2011.

יישור הטיימר ברקע

החל מ-Chrome 11, כל טיימר עצמאי פועל לא יותר מפעם בשנייה. Chrome מפעיל את הטיימרים האלה בקבוצות פעם בשנייה, כדי לוודא שמספר ההפעלות של התהליכים יהיה מינימלי. דפים שמופעל בהם אודיו נשמעים נחשבים לגלויים למשתמשים ופטורים מויסות נתונים (throttle) של הטיימר ברקע. הפטור נמשך כמה שניות אחרי הפסקת האודיו, כדי לאפשר לאפליקציות להוסיף את טראק האודיו הבא לתור.

חשוב לדעת: האודיו נחשב לקולני רק כשסמל האודיו מופיע ב-Chrome. שידורי אודיו שקטים לא מקבלים פטור.

ויסות נתונים (throttling) של טיימר ברקע שמבוסס על תקציב

התכונה הזו מופיעה ב-Chrome 57, והיא הרחבה נוספת של מנגנון התאמת הטיימרים, שמציבה מגבלה נוספת על השימוש ב-CPU של הטיימרים ברקע. כך זה עובד:

• לכל כרטיסייה ברקע יש תקציב זמן (בשניות) להפעלת טיימרים ברקע.
• דף כפוף למגבלות של תקציב הזמן אחרי 10 שניות ברקע.
• משימת טיימר יכולה לפעול רק אם תקציב הזמן אינו שלילי.
• אחרי שהטיימר מופעל, זמן הריצה שלו ינוכה מהתקציב.
• התקציב מתחדש כל הזמן עם הזמן (הוא מוגדר כרגע לקצב של 0.01 שניות לשנייה). שימו לב שאפשר לשנות את קצב יצירת התקציב מחדש מכיוון ב-Chrome נאספים יותר נתונים על ההתנהגות של ויסות הנתונים (throttle).

יש כמה החרגות אוטומטיות מהאילוץ הזה:

• אפליקציות שמפעילות אודיו נחשבות לחזית ולא מוגבלות.
• אפליקציות עם חיבורים בזמן אמת (WebSockets ו-WebRTC), כדי למנוע את סגירת החיבורים האלה לפני תום הזמן הקצוב לתפוגה. הכלל להפעלת טיימרים פעם בשנייה עדיין חל במקרים האלה.

חשוב לזכור שהמנגנון הזה משתמש בזמן חולף, ולא בזמן מעבד. מדובר באומדן טוב של זמן ה-CPU, והוא מאפשר להעניש חסימה של ה-thread הראשי למשך זמן רב.

לבסוף, חשוב לזכור שאם משתמשים במשימות ארוכות ברקע, יכול להיות שהאפליקציה תוגבל למשך זמן רב מאוד (עד פי 100 ממשך המשימה). כדאי לפצל את העבודה לקטעים של 50 אלפיות השנייה או פחות, בהתאם להנחיות לביצועים, ולהשתמש במאזין visibilityChange כדי להימנע מביצוע עבודה מיותרת ברקע.

ביטולי הסכמה

הדגל --disable-background-timer-throttling ב-Chrome מיועד למקרים לדוגמה כמו הפעלת חבילות בדיקות וחישובים כבדים אחרים שאושרו על ידי המשתמשים.