מקרה לדוגמה של שינויים שצוות YouTube Web ביצע כדי לשפר את הביצועים, להגדיל את שיעורי המעבר במדדי הליבה לבדיקת חוויית המשתמש באתר ולהביא לשיפור במדדים עסקיים מרכזיים.
צוות Chrome מדבר לעיתים קרובות על "בניית אינטרנט טוב יותר", אבל מה זה אומר? חוויות השימוש באינטרנט צריכות להיות מהירות, נגישות ולהשתמש ביכולות של מכשירים ברגעים שבהם המשתמשים זקוקים להן ביותר. ניסוי המוצר לפני הפצה הוא חלק מהתרבות של Google, ולכן צוות Chrome עבד בשותפות עם YouTube כדי לשתף את הלקחים שנלמדו לאורך הדרך, בסדרה חדשה שנקראת "בניית אינטרנט טוב יותר". החלק הראשון של הסדרה מסביר איך YouTube יצר חוויית אינטרנט מהירה יותר.
בניית אינטרנט מהיר יותר
ב-YouTube, המדד ביצועים מתייחס למהירות שבה סרטונים ותכנים אחרים נטענים בדפי אינטרנט, כמו המלצות ותגובות. הביצועים נמדדים גם לפי המהירות שבה YouTube מגיב לאינטראקציות של משתמשים כמו חיפוש, שליטה בנגן, לייקים ושיתופים.
צמיחה בשווקים מתפתחים כמו ברזיל, הודו ואינדונזיה חשובה ל-YouTube לנייד. מכיוון שלמשתמשים רבים באזורים האלה יש מכשירים איטיים יותר ורוחב פס מוגבל ברשת, אחד מהדברים החשובים ביצירת חוויית שימוש מהירה וחלקה הוא חיוני.
כדי לספק לכל המשתמשים חוויה שמעודדת את קבלת האחר, ב-YouTube אנחנו שואפים לשפר מדדי ביצועים כמו מדדי ליבה לבדיקת חוויית המשתמש באתר באמצעות טעינה עצלה ומודרניזציה של קוד.
שיפור מדדי הליבה לבדיקת חוויית המשתמש באתר
כדי לזהות תחומים שיש לשפר, צוות YouTube השתמש בדוח חוויית המשתמש ב-Chrome (CrUX) כדי לראות כיצד משתמשים אמיתיים חוו צפייה בסרטונים ודפי תוצאות חיפוש בנייד בשדה. החברה הבינה שהמדדים של מדדי הליבה לבדיקת חוויית המשתמש באתר היו זקוקים לשיפור רב, ובמקרים מסוימים, המדד המהירות שבה נטען רכיב התוכן הכי גדול (LCP) השתנה ל-4-6 שניות. זה היה גבוה באופן משמעותי מהיעד של 2.5 שניות.
כדי לזהות תחומים שצריך לשפר, הם נעזרו ב-Lighthouse כדי לבדוק את דפי הצפייה של YouTube, וכך חשפו ציון נמוך של Lighthouse (מעבדה) עם דירוג תוכן ראשוני (FCP) של 3.5 שניות ו-LCP של 8.5 שניות.
כדי לבצע אופטימיזציה של ה-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 אלפיות השנייה, במהלך בדיקת הביצועים בשיעור ה-Lab. ככל שנוספו אמצעי בקרה חדשים עם הזמן, הדפוס של אמצעי הבקרה המבוזר יגרום לעיתים קרובות ליחסי תלות מעגליים ולדליפות זיכרון, שישפיע לרעה על הביצועים של דף הצפייה.
כדי לפתור את הבעיות שנגרמו כתוצאה משליטה מבוזרת, הצוות עדכן את ממשק המשתמש של הנגן כך שיסנכרן את כל העדכונים, ולמעשה ארגן מחדש את הנגן לרכיב אחד ברמה עליונה שיעביר נתונים לילדים שלו. כך מובטח רק מחזור אחד של עדכון (עיבוד) בממשק המשתמש לכל שינוי במצב, ללא עדכונים בשרשרת. באירוע העברת סרגל ההתקדמות של הנגן החדש אין חישובי סגנון מחדש במהלך ההפעלה של ה-JavaScript, ועכשיו נדרשים רק 25% מהזמן של השחקן הישן.
המודרניזציה הזו של הקוד הובילה גם לשיפורים נוספים בביצועים, כמו שיפור זמני הטעינה של הצפייה במכשירים ישנים, פחות הפעלות שננטשו ופחות שגיאות לא חמורות.
סיכום
בגלל ההשקעה של YouTube בביצועים, דפי הצפייה נטענים מהר יותר כי 76% מכתובות האתרים לנייד ב-YouTube עוברים עכשיו את ערכי הסף של מדדי הליבה לבדיקת חוויית המשתמש באתר. במחשב, שיעור ה-LCP של שיעור ה-Lab בדף הצפייה קוצר מ-4.6 שניות בערך ל-1.6 שניות. ביצועי האינטראקציה והעיבוד של האתר, במיוחד בנגן הווידאו של YouTube, מבחינים בפחות זמן מ-75% פחות זמן בביצוע JavaScript מאשר בעבר.
השיפורים בביצועים של אתרי YouTube באינטרנט בשנה האחרונה שיפרו גם את המדדים העסקיים, כולל זמן צפייה ומשתמשים פעילים ביום (DAU). בעקבות הצלחת המאמצים האלה, אנחנו מתכננים להמשיך לחקור דרכים נוספות לבצע אופטימיזציה בעתיד.
בחלק השני של הסדרה, "בניית אינטרנט נגיש", מוסבר איך YouTube הפך את האתר לנגיש יותר למשתמשים בקוראי מסך.
עם תודות מיוחדות: גילברטו קוקי, לורן אוסואי, בנג'י בר, בו איי, בוגדן באלאס, קני טראן, מתיו סמית, פיל הארניש, לינה סהוני, ג'רמי וגנר, פיליפ וולטון, הארלין באטרה וצוותי YouTube ו-Chrome על תרומתם למשימה הזו.