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