ביצועי הרינדור

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

Paul Lewis

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

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

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

הערה לגבי קצבי הרענון של המכשיר

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

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

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

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

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

עם זאת, היעדים משתנים בהתאם לסוג העבודה שאתם מנסים לבצע. עמידה בסף של 10 אלפיות השנייה היא קריטית לאנימציות, שבהן האובייקטים במסך עוברים אינטרפולציה על פני סדרה של פריימים בין שתי נקודות. כשמדובר בשינויים נפרדים בממשק המשתמש – כלומר, מעבר ממצב אחד למצב אחר בלי תנועה ביניהם – מומלץ לבצע את השינויים האלה במסגרת זמן שמרגישה מיידית למשתמש. במקרים כאלה, 100 אלפיות השנייה הוא נתון שמצוין לעיתים קרובות, אבל הסף "טוב" של מדד ה-INP הוא 200 אלפיות השנייה או פחות, כדי להתאים למגוון רחב יותר של מכשירים עם יכולות שונות.

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

צינור עיבוד הנתונים של הפיקסלים

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

איור של צינור עיבוד הנתונים המלא של הפיקסלים.

• ‫JavaScript: בדרך כלל משתמשים ב-JavaScript כדי לטפל בעבודה שתגרום לשינויים חזותיים בממשק המשתמש. לדוגמה, הפונקציה animate של jQuery, מיון של קבוצת נתונים או הוספה של רכיבי DOM לדף. עם זאת, JavaScript לא הכרחי כדי להפעיל שינויים חזותיים: אנימציות CSS, מעברי CSS ו-Web Animations API יכולים להוסיף אנימציה לתוכן הדף.
• חישובי סגנון: התהליך שבו המערכת קובעת אילו כללי CSS חלים על אילו רכיבי HTML, על סמך סלקטורים תואמים. לדוגמה, .headline הוא דוגמה לסלקטור ב-CSS שחל על כל רכיב HTML עם ערך מאפיין class שמכיל מחלקה של headline. לאחר מכן, כשהכללים ידועים, הם מוחלים והסגנונות הסופיים של כל רכיב מחושבים.
• פריסה: אחרי שהדפדפן יודע אילו כללים חלים על רכיב, הוא יכול להתחיל לחשב את הגיאומטריה של הדף, למשל כמה מקום הרכיבים תופסים ואיפה הם מופיעים במסך. מודל הפריסה של האינטרנט אומר שרכיב אחד יכול להשפיע על רכיבים אחרים. לדוגמה, הרוחב של הרכיב <body> בדרך כלל משפיע על המימדים של רכיבי הצאצא שלו לאורך כל העץ, כך שהתהליך יכול להיות די מורכב לדפדפן.
• ציור: ציור הוא תהליך של מילוי פיקסלים. הוא כולל ציור של טקסט, צבעים, תמונות, גבולות, צללים ובעצם כל היבט חזותי של הרכיבים אחרי שהפריסה שלהם בדף חושבה. בדרך כלל הציור נעשה על כמה משטחים, שלרוב נקראים שכבות.
• הרכבה: מכיוון שחלקים מהדף עשויים להיות משורטטים בכמה שכבות, צריך להחיל אותם על המסך בסדר הנכון כדי שהדף יעובד כצפוי. זה חשוב במיוחד לרכיבים שחופפים לרכיב אחר, כי טעות עלולה לגרום לכך שרכיב אחד יופיע מעל רכיב אחר באופן שגוי.

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

יכול להיות ששמעתם את המונח "רסטריזציה" בהקשר של "צביעה". הסיבה לכך היא שציור הוא למעשה שתי משימות:

1. יצירת רשימה של בקשות להזזת פריטים גרפיים.
2. ממלא את הפיקסלים.

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

לא תמיד תצטרכו לגעת בכל חלק בצינור עיבוד הנתונים בכל פריים. למעשה, יש שלוש דרכים שבהן הצינור בדרך כלל פועל עבור פריים נתון כשמבצעים שינוי חזותי, באמצעות JavaScript,‏ CSS או Web Animations API.

1. JS / CSS > סגנון > פריסה > צביעה > קומפוזיציה

אם משנים מאפיין של "פריסה", כמו מאפיין שמשנה את הגיאומטריה של רכיב, למשל רוחב, גובה או מיקום (כמו מאפייני ה-CSS‏ left או top), הדפדפן צריך לבדוק את כל שאר הרכיבים ולבצע "הזרמה חוזרת" של הדף. צריך לצבוע מחדש את כל האזורים המושפעים, ולשלב מחדש את האלמנטים הצבועים הסופיים.

2. JS / CSS > סגנון > צבע > קומפוזיט

אם שיניתם מאפיין "paint-only" של רכיב ב-CSS, למשל מאפיינים כמו background-image,‏ color או box-shadow, שלב הפריסה לא נדרש כדי לבצע עדכון חזותי בדף. כשמדלגים על שלב הפריסה (אם אפשר), נמנעים מעבודת פריסה שעלולה להיות יקרה, ושיכולה להוסיף זמן אחזור משמעותי ליצירת הפריים הבא.

3. ‫JS / CSS > סגנון > מורכב

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

הערה: אם אתם רוצים ליצור אנימציות עם ביצועים גבוהים במהירות, קראו את המאמר היצמדות למאפיינים של compositor-only וניהול מספר השכבות.

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

בואו נבחן את החלקים השונים של צינור עיבוד הנתונים. נבחן את הבעיות הנפוצות ונסביר איך לאבחן ולפתור אותן.

אופטימיזציה של עיבוד הדפדפן

הביצועים חשובים למשתמשים, וכדי ליצור חוויות משתמש טובות, מפתחי אתרים צריכים ליצור אתרים שמגיבים במהירות לאינטראקציות של המשתמשים ומוצגים בצורה חלקה. פול לואיס, מומחה לביצועים, כאן כדי לעזור לכם להיפטר מבעיות בממשק (jank) וליצור אפליקציות אינטרנט ששומרות על ביצועים של 60 FPS. בסיום הקורס יהיו לכם הכלים הדרושים כדי ליצור פרופילים של אפליקציות ולזהות את הגורמים לביצועי עיבוד (rendering) לא אופטימליים. בנוסף, תלמדו על צינור עיבוד הנתונים (pipeline) של הדפדפן ותגלו דפוסים שיעזרו לכם לבנות אתרים מהירים שמשתמשים ייהנו מהם.

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