זמני צבע CSS ומשקל עיבוד הדף

Colt McAnlis
Colt McAnlis
X דף הבית

מבוא

אם אתם שייכים לאנשים שמתעדכנים בדברים כמו איך דפדפנים פועלים, אתם כבר יודעים שלאחרונה פורסמו כמה מאמרים מדהימים שמפרטים את הכלי לרינדור GPU מואץ/פעולה מורכבת של Chrome. ראשית, עיבוד מואץ ב-Chrome: מודל השכבות הוא מבוא נהדר לאופן שבו Chrome משתמש במושג שכבות כדי לשרטט את הדף שלהן; ולמבט מעמיק יותר על יצירת מעבד GPU מואצת ב-Chrome, מתואר כיצד Chrome משתמש בשכבות אלה, לצד ה-GPU לעיבוד הדף שלך.

השאלה הפילוסופית

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

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

  • ליצור חבילה של דפי HTML נפרדים, שכל אחד מהם מכיל רכיב DOM יחיד ותמורה מסוימת של מאפייני CSS מצורפים אליו.
  • מריצים סקריפטים אוטומטיים מסוימים אשר בכל דף:
    • הפעל את Chrome
    • טעינת דף
    • להפיק תמונת סקיה לדף
    • להריץ כל תמונה של Skia שצולם דרך Skia benchmark כדי לקבל תזמונים
  • מגלים את כל התזמונים ומתפעלים מהמספרים. (החלק הזה חשוב...)

באמצעות ההגדרה הזו, אנחנו יוצרים חבילה של דפי HTML, שבה כל דף מכיל החלפה ייחודית של מאפייני CSS וערכים. לדוגמה, הנה שני קובצי HTML:

<style>
#example1 {
    background: url(foo.png) top left / 50% 60%;
    padding: 20px; 
    margin-top: 10px;
    margin-right: 20px; 
    text-align: center;
}
</style>
<div id="example1">WOAH</div>

דבר נוסף, שהוא מורכב יותר

<style>
#example1 {
    background-color:#eee;
    box-shadow: 1px 2px 3px 4px black;
    border-radius: 50%;
    background: radial-gradient(circle closest-corner, white, black);
    padding: 20px; 
    margin-top: 10px;
    margin-right: 20px; 
    text-align: center;
}
</style>
<div id="example1">WOAH</div>

למטה, כווריאציה של הדוגמה האחרונה, שבה אנחנו משנים רק את הערך הרדיאלי של ההדרגתיות:

<style>
#example1 
{
    background-color:#eee;
    box-shadow: 1px 2px 3px 4px black;
    border-radius: 50%;
    background: radial-gradient(farthest-side, white, black);
    padding: 20px; 
    margin-top: 10px;
    margin-right: 20px; 
    text-align: center;
}
</style>
<div id="example1" style="padding: 20px; margin-top: 10px;margin-right: 20px; text-align: center;">WOAH</div>

לאחר מכן כל דף נטען למופע רענן של Chrome (כדי לוודא שהתזמונים לא יושפעו באופן כלשהו ממצבים לא פעילים בטעינות מחדש של דפים), והמערכת משתמשת ב-Skia Picture (*.SKP) כדי לבדוק אילו פקודות Skia משמשות לצביעת הדף. לאחר שיוצרים קובצי SKP לכל קובץ HTML, אנחנו מריצים אצוות נוספת כדי לשלוח את קובצי *.SKP דרך האפליקציה Skia benchmark (שנבנתה מקוד המקור של Skya), ומפחיתה את הזמן הממוצע שנדרש לעיבוד הדף הזה.

הערכת הנתונים

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

תזמונים לכל התמורות בבדיקה

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

קודם כול אנחנו מוצאים הוכחה שפשוט יותר יקר לעיבוד נכסי CSS מסוימים בהשוואה לאחרים. לדוגמה, ציור הטלת צללית על רכיב DOM כרוך בפעולה מרובת ערוצים עם splines וסוגים אחרים של דברים מגעילים, בניגוד לשקיפות שאמורה להיות קלה יותר לרינדור.

הזמן שנדרש לציור רכיב שיש בו רק מאפיין CSS אחד

דבר שני, ומעניין יותר, לשילובים של מאפייני CSS יכול להיות זמן עיבוד ארוך יותר מאשר סך החלקים שלהם. מבחינתו של הצופה, זה קצת מוזר, ציפינו ש-A+B = C ולא 2.2C. לדוגמה, הוספה של box-shadow ושל border-radius-stroke :

תזמונים לכל התמורות בבדיקה

מה שבאמת מעניין הוא שזה לא רק הנכס box-shadow עצמו, אלא התמורות של הערך הספציפי הזה. לדוגמה, בהמשך מוצג קיבוץ של box-shadow : 50% ו-border-radius עם וריאציות של ערכים.

תזמונים לכל התמורות בבדיקה

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

מציאת משקל העיבוד של הדף

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

  1. תוכלו להשתמש במצב 'צבע רציף' של Chrome בכלי הפיתוח של Chrome, כדי להבין אילו נכסי CSS עולים לכם.
  2. שילוב ביקורות של CSS בתהליך בדיקת הקוד הקיים כדי לאתר בעיות בביצועים חפשו בשירות ה-CSS מקומות שבהם אתם משתמשים בדברים שידוע כי הם יקרים יותר, כמו צבעים הדרגתיים וצלליות. שאלו את עצמכם, "האם אני באמת צריך אותם כאן?"
  3. אם יש ספק, תמיד עדיף לשפר את הביצועים. יכול להיות שהמשתמשים לא יזכרו מה רוחב המרווח הפנימי בעמודות, אבל הם יזכרו את התחושה שלכם כשמבקרים באתר.

מחשבות אחרונות

אחד מהדברים המעניינים ביותר בניסוי הזה הוא שהתזמונים ימשיכו להשתנות בכל גרסה של Chrome (בתקווה להפוך למהירה יותר ;) תוכנת דפדפן היא אזור שטח שמשתנה כל הזמן. מה איטי היום, יכול להיות מהיר מחר. אפשר להסיר מהמאמר הזה את המידע כדי להימנע מהוספה של box-shadow: 1px 2px 3px 4px לרכיב שכבר יש לו border-radius:5. עם זאת, המסקנה החשובה יותר צריכה להיות שמאפייני CSS משפיעים ישירות על זמני הצבע של הדף.

קובצי עזר