ویدیو برای وب: حجم، سرعت و تصمیمی که قبل از آن می گیرید

آیا این صفحه اصلا به ویدیو نیاز دارد؟

موضع ما این است: بیشتر صفحه های کسب و کار نباید ویدیوی خودکار داشته باشند، و خیلی هایشان اصلا نباید ویدیو داشته باشند.

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

سه سوال، به همین ترتیب، تصمیم را می گیرند. اول، این ویدیو چه چیزی نشان می دهد که یک تصویر ثابت و دو جمله نشان نمی دهند؛ اگر جواب «حرکت» است، مثل یک دمو یا یک فرایند، ویدیو درست است. دوم، بازدیدکننده آن را می خواهد یا ما می خواهیم؛ کسی که آمده قیمت ببیند، ویدیوی معرفی شرکت را نمی خواهد. سوم، اگر پخش نشود چه چیزی از دست می رود؛ اگر جواب هیچ است، ویدیو تزیین است.

روی همین سایت، جواب همین سه سوال ما را به جایی رساند که در قالب سایت حتی یک تگ ویدیو وجود ندارد و شکل ها همه با HTML و CSS کشیده می شوند. ما ویدیو می فروشیم و ویدیوی خودمان جای دیگری است، نه در مسیر بارگذاری صفحه های فروش.

ویدیو دقیقا کجای سرعت صفحه را می زند؟

در دو نقطه، و فقط یکی از آنها همانی است که همه فکر می کنند.

نقطه اول حجم است و آشناست: بایت هایی که دانلود می شوند با بقیه منابع صفحه بر سر همان پهنای باند رقابت می کنند، و روی موبایل با اینترنت متوسط این رقابت را ویدیو می برد چون بزرگ تر است. نقطه دوم کمتر شناخته شده و مهم تر است: خود ویدیو می تواند عنصر LCP صفحه باشد. مستند web.dev می گوید عنصر video نامزد LCP است و برای آن، هرکدام زودتر باشد حساب می شود: زمان بارگذاری تصویر پوستر یا زمان نمایش اولین فریم.

یعنی اگر بزرگ ترین چیز بالای صفحه شما یک ویدیوست، معیاری که گوگل به عنوان تجربه صفحه اندازه می گیرد به آن گره خورده است. آستانه ای که web.dev برای LCP خوب می گوید ۲.۵ ثانیه یا کمتر است، در صدک ۷۵ ام بارگذاری ها، و بالای ۴ ثانیه ضعیف شمرده می شود.

نتیجه عملی دو خطی است. اگر ویدیو خودکار پخش نمی شود، حتما پوستر بگذارید، چون آن وقت به جای دانلود ویدیو، فقط یک تصویر بهینه شده روی مسیر LCP می نشیند. و اگر همان پوستر بزرگ ترین عنصر صفحه است، web.dev پیشنهاد می کند با fetchpriority="high" اولویتش را بالا ببرید.

یک تله که زیاد دیده می شود: پوستر بی کیفیت یا پوستری که خودش چند صد کیلوبایت است. پوستر یک تصویر معمولی است و همان قواعد بهینه سازی تصویر را دارد؛ اگر آن را فشرده نکنید، فقط جای مشکل را عوض کرده اید.

کدام تنظیم های تگ ویدیو واقعا اثر دارند؟

چهارتا، و بیشترین اثر مال همان یکی است که کمتر از همه تنظیم می شود: preload.

فصل ویدیوی web.dev برای پخشی که کاربر شروعش می کند، صریحا preload="none" را می گوید. همین یک صفت، سنگین ترین دانلود صفحه را از مسیر بارگذاری بیرون می برد.

پوستر دومی است. MDN می گوید اگر poster ندهید، تا آماده شدن اولین فریم هیچ چیز نشان داده نمی شود و بعد همان فریم اول به عنوان پوستر می نشیند؛ یعنی بدون پوستر یا یک مستطیل خالی دارید یا مجبورید فایل را زودتر بگیرید.

پخش خودکار سومی است و بیشتر یک تصمیم است تا یک تنظیم. web.dev می نویسد autoplay فقط وقتی باید استفاده شود که لازم باشد و از یک نیاز قابل پیش بینی کاربر بیاید. MDN هم یادآوری می کند که مرورگرهای امروزی پخش خودکار ویدیوی صدادار را می بندند، پس ویدیوی خودکاری که صدا دارد در عمل پخش نمی شود.

و جایگزینی گیف چهارمی است، که تنها جایی است که پخش خودکار تقریبا همیشه درست است. اگر یک انیمیشن کوتاه تکرار شونده می خواهید، به جای GIF یک ویدیوی بی صدا با autoplay و muted و loop بگذارید. web.dev برای همین حالت پیشنهاد می کند نوار صدا را با پرچم -an در ffmpeg کاملا حذف کنید، چون حذف نوار صدا حجم فایل را کم می کند.

یک نکته که در فهرست ها نمی آید: این چهار تنظیم روی فایلی که بد کدگذاری شده کار نمی کنند. رزولوشن را به اندازه ای برسانید که واقعا نمایش داده می شود؛ فرستادن یک فایل ۱۰۸۰ پیکسلی برای قابی که روی موبایل ۳۶۰ پیکسل عرض دارد، هیچ کدام از این صفت ها جبرانش نمی کند.

فایل را کجا میزبانی کنیم: سرور خودمان یا یک پلتفرم؟

هر دو انتخاب معتبرند و برای دو موقعیت متفاوت اند؛ چیزی که آنها را جدا می کند کنترل در برابر بار است.

وقتی فایل را خودتان می دهید، همه چیز دست شماست: نه پخش کننده کس دیگری، نه اسکریپت اضافه، نه لوگو و پیشنهاد ویدیوی بعدی، و هیچ داده ای از بازدیدکننده جای دیگری نمی رود. هزینه اش هم روشن است: پهنای باند و ترافیک همان سروری را می خورد که HTML سایت را می دهد، و ویدیوی بلند روی هاست اشتراکی همان جایی است که این تصمیم می شکند.

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

قاعده ای که ما استفاده می کنیم ساده است: هر چیز کوتاه تر از حدود ده ثانیه که تزیینی یا نمایشی است، فایل خودمان با پخش خودکار بی صدا؛ هر چیزی که بلند است و کسی می نشیند تماشا کند، پلتفرم با یک تصویر پوستر و بارگذاری تنبل، تا اسکریپت پخش کننده فقط بعد از کلیک بیاید.

و یک تله فنی که هر دو حالت را می زند: قرار دادن ویدیو داخل صفحه ای که خودش کش صفحه دارد. فایل ویدیو از کش HTML نمی آید و مسیر خودش را دارد، پس نمره سرعتی که با ابزار می گیرید ممکن است ویدیو را کامل نشان ندهد. برای همین بعد از هر تغییر، صفحه را یک بار با شبکه محدود شده در ابزار توسعه دهنده مرورگر باز کنید و ببینید چه چیزی واقعا دانلود می شود.

نمره ۹۰ یعنی چه و چه چیزی را نمی گوید؟

نمره کارایی لایت هاوس بین ۰ تا ۱۰۰ است و مستند خود کروم باندهایش را این طور می گوید: ۰ تا ۴۹ ضعیف، ۵۰ تا ۸۹ نیازمند بهبود، و ۹۰ تا ۱۰۰ خوب. عددی که ما هدف می گیریم همان مرز پایینی باند سبز است، یعنی ۹۰.

حالا چیزی که این نمره نمی گوید، و مهم تر از خود نمره است. لایت هاوس یک آزمایش آزمایشگاهی است: یک بار، روی یک دستگاه شبیه سازی شده، با یک شبکه شبیه سازی شده. کاربران واقعی شما روی گوشی های متفاوت و شبکه های متفاوت اند و آن چیزی است که در داده میدانی دیده می شود، نه در این نمره.

برای ویدیو این تفاوت بزرگ تر از حد معمول است، چون رفتار کاربر بخشی از معادله است. یک صفحه با ویدیوی preload="none" در آزمایشگاه عالی نمره می گیرد، چون هیچ کس کلیک نمی کند. تجربه واقعی کسی که کلیک می کند در آن نمره اصلا نیست.

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