מחקר מקרה על השינויים שבוצעו על ידי צוות האינטרנט של YouTube כדי לשפר את הביצועים, להגדיל את שיעורי העמידה במדדי הליבה לבדיקת חוויית המשתמש באתר ולשפר מדדים עסקיים חשובים.
צוות Chrome מדבר לעיתים קרובות על 'יצירת אינטרנט טוב יותר', אבל מה המשמעות של המשפט הזה? חוויות אינטרנט צריכות להיות מהירות, נגישות ולהשתמש ביכולות המכשיר ברגעים שבהם המשתמשים זקוקים לכך הכי הרבה. שימוש עצמי הוא חלק מהתרבות של Google, ולכן צוות Chrome שיתף פעולה עם YouTube כדי לשתף את הלקחים שלמדנו לאורך הדרך בסדרה חדשה בשם 'יצירת אינטרנט טוב יותר'. בחלק הראשון של הסדרה נסביר איך YouTube יצרה חוויית שימוש מהירה יותר באינטרנט.
ב-YouTube, ביצועים מתייחסים למהירות הטעינה של סרטונים ותוכן אחר – כמו המלצות ותגובות – בדפי אינטרנט. הביצועים נמדדים גם לפי המהירות שבה YouTube מגיב לאינטראקציות של משתמשים, כמו חיפוש, שליטה בנגן, לייקים ושיתוף.
שווקים מתפתחים בצמיחה, כמו ברזיל, הודו ואינדונזיה, חשובים לאינטרנט לנייד של YouTube. מכיוון שלמשתמשים רבים באזורים האלה יש מכשירים איטיים ורוחבי פס מוגבלים ברשת, חשוב מאוד להבטיח חוויית שימוש מהירה וחלקה.
כדי לספק חוויה כוללת לכל המשתמשים, הצוות של YouTube החליט לשפר את מדדי הביצועים, כמו מדדי הליבה לבדיקת חוויית המשתמש באתר (Core Web Vitals), באמצעות טעינת נתונים בזמן אמת (lazy-loading) ומודרניזציה של הקוד.
שיפור מדדי הליבה לבדיקת חוויית המשתמש באתר
כדי לזהות תחומים לשיפור, צוות YouTube השתמש בדוח על חוויית המשתמש ב-Chrome (CrUX) כדי לראות איך משתמשים אמיתיים חווים את דפי הצפייה בסרטונים ואת דפי תוצאות החיפוש בנייד בשטח. הם הבינו שיש מקום לשיפור משמעותי במדדי הליבה לבדיקת חוויית המשתמש באתר, ובמקרים מסוימים מדד המהירות שבה נטען רכיב התוכן הכי גדול (LCP) היה 4-6 שניות. הזמן הזה היה גבוה בהרבה מהיעד של 2.5 שניות.
כדי לזהות תחומים לשיפור, הם השתמשו ב-Lighthouse כדי לבדוק את דפי הצפייה ב-YouTube. התוצאה הייתה ציון נמוך ב-Lighthouse (lab) עם זמן של 3.5 שניות להצגת תוכן ראשוני (FCP) ו-8.5 שניות ל-LCP.
כדי לבצע אופטימיזציה של FCP ו-LCP, צוות YouTube ערך כמה ניסויים, שהובילו לשני תגליות גדולות.
התגלית הראשונה הייתה שהם יכולים לשפר את הביצועים על ידי העברת ה-HTML של נגן הווידאו מעל הסקריפט שמאפשר לנגן הווידאו להיות אינטראקטיבי. בדיקות מעבדה הראו שאפשר לשפר את משך הזמן של FCP ו-LCP מ-4.4 שניות ל-1.1 שניות.
התגלית השנייה הייתה ש-LCP מביאה בחשבון רק את התמונות של רכיבי הפוסטרים של
<video>
, ולא פריימים מהסטרימינג של הסרטון עצמו. בעבר, מערכת YouTube ביצעה אופטימיזציה כדי לקצר את הזמן עד שהסרטון מתחיל לפעול. כדי לשפר את ה-LCP, הצוות התחיל לבצע אופטימיזציה גם של המהירות שבה הוא יכול להעביר את תמונת הפוסטרים. הם ניסו כמה וריאציות של תמונות פוסטרים ובחרו את התמונה שקיבלה את הציון הגבוה ביותר בבדיקות המשתמשים. כתוצאה מהעבודה הזו, חל שיפור משמעותי גם ב-FCP וגם ב-LCP, כאשר זמן הטעינה של נכס LCP השתפר מ-4.6 שניות ל-2.0 שניות.
האופטימיזציות האלה אמנם שיפרו את המדד LCP, אבל הצוות הרגיש שההגדרה הנוכחית של המדד LCP לא מתעדת באופן מלא, מנקודת המבט של המשתמש, מתי 'התוכן הראשי' של הדף נטען – וזה המטרה של המדד LCP.
כדי לטפל בבעיות האלה, חברים בצוות YouTube עבדו בשיתוף עם חברים בצוות Chrome כדי למצוא דרכים לשפר את מדד LCP כדי לטפל בתרחיש לדוגמה שלהם. אחרי שבחנו את ההיתכנות וההשפעה של כמה אפשרויות, הצוותים הגיעו להצעה: להתייחס לזמן הצביעה של הפריים הראשון של רכיב וידאו כאפשרות ל-LCP.
אחרי שהשינוי הזה ייכנס לתוקף ב-Chrome, צוות YouTube ישמח להמשיך את העבודה על אופטימיזציה ל-LCP. בנוסף, הגרסה המעודכנת של המדד תאפשר לאופטימיזציות האלה להשפיע בצורה ישירה יותר על חוויות המשתמשים האמיתיות.
מודולריות עם טעינה מדורגת
דפי YouTube הכילו הרבה מודולים שנטענו באופן מיידי. כדי לבצע אופטימיזציה של האופן שבו נערך עיבוד של יותר מ-50 רכיבים, הצוות יצר מפה של רכיבים למודולים של JS, שתעיד ללקוח אילו מודולים לטעון. סימון רכיבים כרכיבים 'לא פעילים' יגרום לטעינת המודולים של ה-JS מאוחר יותר, וכך יפחית את זמן הטעינה הראשוני של הדף ואת כמות ה-JavaScript שאינו בשימוש שנשלח ללקוח.
עם זאת, אחרי הטמעת הטעינה האיטית, הצוות הבחין בתופעת מפל, שבה רכיבים שנטענו באיטיות והיחסים התלויים שלהם נטענו בזמנים לא אופטימליים.
כדי לפתור את הבעיה, הצוות קבע את קבוצת הרכיבים המינימלית שנדרשת בתצוגה, וקיבצם בבקשת רשת אחת. התוצאות היו שיפור במהירות הדף, קיצור זמן הניתוח של JavaScript ובסופו של דבר זמני רינדור ראשוניים טובים יותר.
ניהול המצב ברכיבים שונים
ב-YouTube היו בעיות בביצועים בגלל אמצעי הבקרה של הנגן, במיוחד במכשירים ישנים יותר. ניתוח הקוד הראה שהנגן, שמאפשר למשתמשים לשלוט בתכונות כמו מהירות ההפעלה וההתקדמות, עבר חלוקה לרכיבים מיותרת לאורך זמן.
כל אירוע של תנועה במגע בסרגל התקדמות גרם לשני חישובים נוספים של סגנונות, ונמשך 21.17 אלפיות השנייה במהלך הרצות של בדיקות הביצועים במעבדה. ככל שנוספו אמצעי בקרה חדשים לאורך זמן, התבנית של בקרה מבוזרת גרמה לעיתים קרובות לקשרי תלות מעגליים ולדליפות זיכרון, שהשפיעו לרעה על הביצועים של דף הצפייה.
כדי לפתור את הבעיות שנובעות מבקרה מבוזרת, הצוות עדכן את ממשק המשתמש של הנגן כדי לסנכרן את כל העדכונים. למעשה, הנגן עובר רה-פירמנטציה לרכיב אחד ברמה העליונה, שיעביר נתונים לצאצאים שלו. כך מובטח מחזור אחד של עדכון (עיבוד) ממשק המשתמש לכל שינוי במצב, ומבטלים עדכונים בשרשור. באירוע המגע-הזזה החדש בסרגל ההתקדמות של הנגן אין חישובים מחדש של סגנונות במהלך ביצוע ה-JavaScript, והוא דורש עכשיו רק 25% מהזמן שנדרש בנגן הישן.
המודרניזציה של הקוד הובילה גם לשיפורים נוספים בביצועים, כמו זמני טעינה קצרים יותר של סרטונים במכשירים ישנים, פחות הפסקות של הפעלות וירידה במספר השגיאות הלא קטלניות.
תוצאות ואופטימיזציות
כתוצאה מההשקעה של YouTube בביצועים, דפי הצפייה נטענים מהר יותר, ו-76% מכתובות ה-URL של האתר לנייד של YouTube עומדות עכשיו בערכי הסף של מדדי Core Web Vitals בשטח. במחשב, זמן ה-LCP במעבדה של דף הצפייה ירד מ-4.6 שניות ל-1.6 שניות. זמן הביצוע של JavaScript באתר, במיוחד בנגן הווידאו של YouTube, קצר ב-75% בהשוואה לעבר.
השיפורים בביצועים של YouTube באינטרנט במהלך השנה האחרונה הובילו גם לשיפור במדדים העסקיים, כולל זמן הצפייה ומספר המשתמשים הפעילים מדי יום. על סמך ההצלחה של המאמצים האלה, אנחנו מתכננים להמשיך לבחון דרכים נוספות לביצוע אופטימיזציה בעתיד.
תודה מיוחדת ל-Gilberto Cocchi, Lauren Usui, Benji Bear, Bo Aye, Bogdan Balas, Kenny Tran, Matthew Smith, Phil Harnish, Leena Sahoni, Jeremy Wagner, Philip Walton, Harleen Batra וצוותים של YouTube ו-Chrome על התרומה שלהם לעבודה הזו.