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

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

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

מפתחי אתרים צריכים לשים לב שלרוב יש הרבה כרטיסיות פתוחות ברקע, ויכולה להיות לכך השפעה משמעותית על צריכת החשמל ועל חיי הסוללה. יש לצמצם את היקף העבודה ברקע, אלא אם אין חובה לספק חוויית משתמש מסוימת. כדאי להשתמש בממשק ה-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 מריץ את הטיימרים האלה באצוות פעם שנייה, כדי לוודא שמספר תהליכי התעוררות בתהליך נשאר מינימלי. דפים שמשמיעים אודיו מושמע נחשבים כגלויים למשתמשים, ופטורים מהגבלת טיימר ברקע. ניתן לפטור למשך כמה שניות אחרי שהאודיו נפסק, כדי לאפשר לאפליקציות להוסיף את טראק האודיו הבא לתור.

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

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

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

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

יש כמה פטורים אוטומטיים מהגבלת רוחב פס:

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

שימו לב שהמנגנון הזה משתמש בזמן קיר ולא בזמן מעבד (CPU). זה אומדן טוב לזמן המעבד (CPU), והוא חוסם את ה-thread הראשי למשך זמן רב.

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

ביטולי הסכמה

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