מקרה לדוגמה של שינויים שצוות האינטרנט של YouTube ביצע כדי לשפר את הביצועים, להגדיל את שיעורי המסירה של מדדי הליבה לבדיקת חוויית המשתמש באתר ולשפר את המדדים העסקיים העיקריים.
צוות Chrome מדבר לעיתים קרובות על 'יצירת אינטרנט טוב יותר', אבל מה המשמעות של המשפט הזה? חוויית השימוש באינטרנט צריכה להיות מהירה ונגישות, ולכלול יכולות של מכשירים ברגעים שבהם המשתמשים צריכים אותה הכי הרבה. ניסוי המוצר לפני הפצה (dogfood) הוא חלק מהתרבות של 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 אלפיות השנייה במהלך הרצות של בדיקות הביצועים במעבדה. ככל שנוספו אמצעי בקרה חדשים לאורך זמן, התבנית של בקרה מבוזרת גרמה לעיתים קרובות לקשרי תלות מעגליים ולדליפות זיכרון, שהשפיעו לרעה על הביצועים של דף הצפייה.
כדי לפתור את הבעיות שנובעות מבקרה מבוזרת, הצוות עדכן את ממשק המשתמש של הנגן כדי לסנכרן את כל העדכונים. למעשה, הנגן עובר עיבוד מחדש לרכיב אחד ברמה העליונה, שיעביר נתונים לצאצאים שלו. כך מובטח מחזור אחד של עדכון (עיבוד) ממשק המשתמש לכל שינוי במצב, ומבטלים עדכונים בשרשור. לאירוע Touch-move של הנגן החדש לא כולל חישובים מחדש של סגנון במהלך הפעלת JavaScript, ועכשיו נדרש רק 25% מהזמן של הנגן הישן.
המודרניזציה של הקוד הובילה גם לשיפורים נוספים בביצועים, כמו זמני טעינה קצרים יותר של סרטונים במכשירים ישנים, פחות הפסקות של הפעלות וירידה במספר השגיאות הלא קטלניות.
תוצאות ואופטימיזציות
כתוצאה מההשקעה של YouTube בביצועים, דפי הצפייה נטענים מהר יותר, ו-76% מכתובות ה-URL של האתר לנייד של YouTube עומדות עכשיו בערכי הסף של מדדי Core Web Vitals בשטח. במחשב, זמן ה-LCP במעבדה של דף הצפייה ירד מ-4.6 שניות בערך ל-1.6 שניות. לביצועי האינטראקציות והרינדור של האתר, בייחוד בנגן הווידאו של YouTube, מפחיתים את הזמן שהוקדש לביצוע JavaScript בשיעור של עד 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 על התרומה שלהם לעבודה הזו.