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

Colt McAnlis
Colt McAnlis
X דף הבית

מבוא

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

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

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

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

  • יצירת חבילה של דפי HTML נפרדים, שבכל אחד מהם יש אלמנט DOM יחיד ויש לו מצורף רצף מסוים של מאפייני CSS.
  • מריצים סקריפט אוטומציה כלשהו, שבכל דף:
    • הפעל את Chrome
    • טעינת דף
    • יצירת Skia Picture לדף
    • מריצים כל תמונה של 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>

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

<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‏ (*.SKP) נלקחת כדי להעריך אילו פקודות של Skia משמשות לציור הדף. אחרי שיוצרים קובצי SKP לכל קובץ HTML, מריצים קבוצה נוספת כדי לדחוף את קובצי ה-*.SKP דרך אפליקציית Skia Benchmark (שנוצרה מקוד המקור של Skia), שמפיקה את הזמן הממוצע שנדרש לעיבוד הדף.

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

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

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

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

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

קובצי עזר