ساخت وب بهتر: یوتیوب سریعتر

مطالعه موردی تغییراتی که تیم وب YouTube برای بهبود عملکرد، افزایش نرخ عبور Core Web Vitals و افزایش معیارهای کلیدی کسب‌وکار انجام داده است.

سریرام کریشنان
Sriram Krishnan

تیم Chrome اغلب در مورد "ساخت یک وب بهتر " صحبت می کند، اما این به چه معناست؟ تجربیات وب باید سریع ، در دسترس باشد و از قابلیت‌های دستگاه در لحظه‌ای که کاربران به آن بیشتر نیاز دارند استفاده کنند. Dogfooding بخشی از فرهنگ Google است، بنابراین تیم Chrome با YouTube شریک شده است تا درس‌های آموخته شده را در مجموعه جدیدی به نام «ساخت وب بهتر» به اشتراک بگذارد. بخش اول این مجموعه به چگونگی ایجاد تجربه وب سریع‌تر توسط YouTube می‌پردازد.

PageSpeed ​​Insights که داده‌های گزارش Chrome UX را نشان می‌دهد.
صفحه تماشای وب YouTube برای تلفن همراه که آستانه‌های Core Web Vitals را پشت سر می‌گذارد.

در YouTube، عملکرد به سرعت بارگذاری ویدیوها و سایر محتواها (مانند توصیه‌ها و نظرات) در صفحات وب مربوط می‌شود. عملکرد همچنین با سرعت واکنش YouTube به تعاملات کاربر مانند جستجو، کنترل پخش کننده، لایک ها و اشتراک گذاری ها اندازه گیری می شود.

بازارهای رو به رشد در حال توسعه، مانند برزیل، هند و اندونزی برای وب موبایل YouTube مهم هستند. از آنجایی که بسیاری از کاربران در این مناطق دستگاه‌های کندتر و پهنای باند شبکه محدودتری دارند، اطمینان از یک تجربه سریع و یکپارچه یک هدف حیاتی است.

برای ارائه یک تجربه فراگیر برای همه کاربران، YouTube تصمیم گرفت معیارهای عملکرد مانند Core Web Vitals را از طریق بارگذاری تنبل و نوسازی کد بهبود بخشد.

Core Web Vitals را بهبود بخشید

برای شناسایی زمینه‌های بهبود یافته، تیم YouTube از گزارش تجربه کاربر Chrome (CrUX) استفاده کرد تا ببیند کاربران واقعی چگونه صفحات نتایج جستجو و تماشای ویدیو را در تلفن همراه در این زمینه تجربه می‌کنند. آنها متوجه شدند که معیارهای Core Web Vitals آنها جای زیادی برای بهبود دارد، به طوری که متریک بزرگترین رنگ محتوایی (LCP) آنها در برخی موارد بین 4 تا 6 ثانیه زمان بندی می شود. این به طور قابل توجهی بالاتر از هدف آنها 2.5 ثانیه بود.

نمودارهای FCP و LCP که نرخ عبور صفحه تماشای YouTube و همچنین منبع YouTube را نشان می‌دهد.

برای شناسایی زمینه‌های بهبود، آن‌ها به Lighthouse مراجعه کردند تا صفحات تماشای YouTube را بررسی کنند و امتیاز Lighthouse ( آزمایشگاه ) پایین را با First Contentful Paint (FCP) 3.5 ثانیه و LCP 8.5 ثانیه نشان دادند.

گزارش فانوس دریایی برای YouTube Mobile.
کروم یک هدف 1.8 برای FCP و 2.5s برای LCP به عنوان استاندارد طلایی تعیین می کند. FCP و LCP به ترتیب در 3.5 ثانیه و 8.5 ثانیه به وضوح زرد و قرمز بودند.

برای بهینه‌سازی FCP و LCP، تیم YouTube چندین آزمایش را انجام داد که منجر به دو اکتشاف بزرگ شد.

  1. اولین کشف این بود که آنها می توانند با حرکت دادن HTML برای پخش کننده ویدیو به بالای اسکریپتی که پخش کننده ویدیو را تعاملی می کند، عملکرد را بهبود بخشند. آزمایشات آزمایشگاهی نشان داد که این می تواند FCP و LCP را از 4.4 ثانیه به 1.1 ثانیه بهبود بخشد.

  2. کشف دوم این بود که LCP فقط تصاویر پوستر عنصر <video> را در نظر می گیرد نه فریم های خود جریان ویدئو. YouTube به طور سنتی برای سریع‌ترین زمان تا زمانی که ویدیو شروع به پخش می‌کند، بهینه‌سازی می‌شود، بنابراین برای بهبود LCP، تیم شروع به بهینه‌سازی سرعت ارائه تصویر پوستر خود نیز کرد. آن‌ها چند تنوع از تصاویر پوستر را آزمایش کردند و تصویری را انتخاب کردند که بهترین امتیاز را در تست کاربر داشت. در نتیجه این کار، هر دو FCP و LCP بهبود قابل توجهی نشان دادند، با LCP میدانی از 4.6 ثانیه به 2.0 ثانیه بهبود یافت.

تماشای صفحه آزمایش LCP برای وب تلفن همراه که کنترل، آزمایش A (تصویر کوچک تصویر) و آزمایش B (تصویر کوچک سیاه) را نشان می‌دهد.
در آزمایشگاه، ما شاهد بهبود FCP و LCP از 4.4 به 1.1 ثانیه پس از فرود این تغییر بودیم. آزمایش A: استفاده از تصویر کوچک ویدیوی واقعی در صفحاتی که ویدیو در آن‌ها متوقف می‌شود به خوبی کار می‌کند، اما برای صفحات ویدیویی با پخش خودکار مانند صفحه تماشا، در مطالعات کاربر ضعیف عمل می‌کند. همچنین باعث کاهش کاربران فعال شد. آزمایش B: استفاده از یک تصویر پوستر سیاه و سفید جامد بهترین نتایج را در مطالعات کاربر نشان داد. کاربران دریافتند که انتقال از سیاه یکپارچه به فریم اول ویدیو، تجربه ای کمتر دردسرساز برای پخش خودکار ویدیوها است.
تصویر بندانگشتی سیاه در ژوئیه 2021 برای همه کاربران وب تلفن همراه به کار گرفته شد که نشان دهنده بهبود قابل توجهی در FCP و LCP است، همانطور که در تجزیه و تحلیل RUM بالا مشاهده می شود.
تصویر کوچک سیاه در ژوئیه 2021 برای همه کاربران وب تلفن همراه به کار گرفته شد که نشان دهنده بهبود قابل توجهی در FCP و LCP است، همانطور که در تجزیه و تحلیل RUM بالا مشاهده می شود.

در حالی که این بهینه‌سازی‌ها LCP را بهبود می‌بخشد، تیم احساس می‌کرد که تعریف فعلی معیار LCP، از دیدگاه کاربر، زمانی که «محتوای اصلی» صفحه بارگیری شده بود - که هدف LCP است، به‌طور کامل ثبت نمی‌شود.

برای رفع این نگرانی‌ها، اعضای تیم YouTube با اعضای تیم Chrome همکاری کردند تا راه‌هایی را بررسی کنند که معیار LCP می‌تواند برای رسیدگی به موارد استفاده آنها بهبود یابد. پس از در نظر گرفتن امکان‌سنجی و تأثیر چند گزینه، تیم‌ها به پیشنهادی رسیدند تا زمان رنگ‌آمیزی اولین فریم یک عنصر ویدیویی را به عنوان کاندید LCP در نظر بگیرند.

هنگامی که این تغییر در Chrome رخ می دهد، تیم YouTube برای ادامه کار خود برای بهینه سازی LCP هیجان زده می شود. و نسخه به روز شده متریک به این معنی است که این بهینه سازی ها تأثیر مستقیم تری بر تجربیات کاربر واقعی خواهند داشت.

مدولارسازی با بارگذاری تنبل

صفحات یوتیوب شامل ماژول های زیادی بود که مشتاقانه بارگذاری شدند. برای بهینه سازی نحوه رندر شدن بیش از 50 مؤلفه، تیم یک مؤلفه برای نقشه ماژول JS ساخت که به مشتری می گوید کدام ماژول ها را بارگیری کند. با علامت‌گذاری اجزا به‌عنوان تنبل، ماژول‌های JS دیرتر بارگذاری می‌شوند و زمان بارگذاری اولیه صفحه و مقدار جاوا اسکریپت استفاده نشده ارسال‌شده به مشتری کاهش می‌یابد.

با این حال، پس از اجرای بارگذاری تنبل، تیم متوجه اثر آبشاری شد که اجزای بارگذاری شده تنبل و وابستگی‌های آن‌ها در زمان‌های کمتر از حد بهینه بارگذاری می‌شوند.

برای حل این مشکل، تیم حداقل مجموعه ای از اجزای مورد نیاز در یک view را تعیین کرد و آنها را در یک درخواست شبکه دسته بندی کرد. نتایج بهبود سرعت صفحه، کاهش زمان تجزیه جاوا اسکریپت و در نهایت زمان رندر اولیه بهتر بود.

مدیریت دولتی در سراسر اجزا

یوتیوب به دلیل کنترل های پخش کننده خود، به خصوص در دستگاه های قدیمی تر، با مشکلات عملکردی مواجه بود. تجزیه و تحلیل کد نشان داد که پخش کننده که به کاربران اجازه می دهد ویژگی هایی مانند سرعت پخش و پیشرفت را کنترل کنند، در طول زمان بیش از حد کامپوننت شده است.

پخش‌کننده و کنترل‌های YouTube به تصویر کشیده شد
پخش کننده ویدیوی YouTube به کاربران امکان می دهد سرعت پخش را کنترل کنند، پیشرفت را دنبال کنند، بخش ها را رد کنند و موارد دیگر. وقتی کاربر روی یک کنترل خاص ضربه می‌زند، تغییر وضعیت باید به کنترل‌های دیگر منتقل شود، مثلاً ضربه کاربر روی نوار پیشرفت باید با کنترل‌هایی مانند پخش، زیرنویس‌ها و غیره به اشتراک گذاشته شود.

هر رویداد حرکت لمسی نوار پیشرفت باعث دو محاسبه مجدد سبک اضافی شد و 21.17 میلی ثانیه در طول اجرای آزمایش عملکرد در آزمایشگاه طول کشید. با اضافه شدن کنترل‌های جدید در طول زمان، الگوی کنترل غیرمتمرکز اغلب باعث وابستگی‌های دایره‌ای و نشت حافظه می‌شود که بر عملکرد صفحه تماشا تأثیر منفی می‌گذارد.

رویداد 21.17 میلی‌ثانیه در جدول زمانی عملکرد نشان داده شده است.
Chrome DevTools با عملکرد 4 برابری کاهش سرعت CPU.

برای رفع مشکلات ناشی از کنترل غیرمتمرکز، تیم رابط کاربری بازیکن را به‌روزرسانی کرد تا همه به‌روزرسانی‌ها را همگام‌سازی کند، و اساساً پخش‌کننده را به یک مؤلفه سطح بالا تبدیل می‌کند که داده‌ها را به فرزندانش منتقل می‌کند. این تنها یک چرخه به‌روزرسانی (رندر) رابط کاربری را برای هر تغییر وضعیت تضمین می‌کند و به‌روزرسانی‌های زنجیره‌ای را حذف می‌کند. رویداد حرکت لمسی نوار پیشرفت بازیکن جدید در طول اجرای جاوا اسکریپت هیچ گونه محاسبه مجدد سبکی ندارد و اکنون تنها به 25 درصد زمان پخش کننده قدیمی نیاز دارد.

کاهش زمان در رویدادهای نشان داده شده در جدول زمانی عملکرد.

این نوسازی کد همچنین منجر به بهبود عملکرد اضافی مانند بهبود زمان بارگذاری ساعت در دستگاه‌های قدیمی، پخش‌های رها شده کمتر و کاهش تعداد خطاهای غیرمرگبار شد.

نتایج و بهینه سازی ها

در نتیجه سرمایه‌گذاری YouTube در عملکرد، صفحات تماشا بسیار سریع‌تر بارگیری می‌شوند و 76 درصد از URLهای وب‌سایت تلفن همراه YouTube اکنون از آستانه‌های معیاری Core Web Vitals در این زمینه عبور می‌کنند. در دسکتاپ، LCP آزمایشگاهی برای صفحه تماشا از تقریباً 4.6 ثانیه به 1.6 ثانیه کاهش یافت. عملکرد تعامل و رندر سایت، به ویژه در پخش کننده ویدیوی 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 برای مشارکت در این کار