Wideo w hero bez rachunku za transfer

Jest cała kategoria stron, w których produktem jest ruch. DJ, sala weselna, studio produkcyjne, siłownia, zespół. Pokazujesz zdjęcie i opisujesz rzecz. Pokazujesz trzy sekundy sali i tą rzeczą jesteś.

Stąd ciągle wracająca prośba „dajmy wideo w hero” i stąd to, że w praktyce prawie zawsze kończy się źle. Typowy efekt to strona ze słabymi wynikami wydajności, realny koszt transferu po stronie odwiedzających i najmocniejszy element serwisu w roli powodu, dla którego wszystko mieli się wolno.

Nie musi tak być. Rozwiązaniem nie jest mniejszy plik. Rozwiązaniem jest brak pliku.

Dlaczego jeden MP4 jest problemem, a nie rozwiązaniem

Wrzucenie pojedynczego MP4 do hero oznacza, że jedno kodowanie odpowiada za wszystkich odwiedzających. To zadanie niewykonalne:

• Zakoduj pod monitor na biurku, a średniej klasy Android na LTE w pociągu czeka, potem czeka jeszcze chwilę, a potem coś widzi.

• Zakoduj pod telefon, a materiał wygląda blado na tych ekranach, na których miał największą szansę zadziałać.

• W obu przypadkach przeglądarka musi zbuforować sensowny kawałek, zanim odtwarzanie ruszy płynnie, i pobiera ten kawałek z początku pliku, w pełnej jakości, niezależnie od tego, czy łącze to udźwignie.

Do tego dochodzi rzecz, której nie widać w raporcie Lighthouse: osoba na pakiecie z limitem, która odbija po czterech sekundach, i tak zapłaciła za tyle pliku, ile przeglądarka zdążyła pobrać.

Każde pokrętło, które można przekręcić przy pojedynczym pliku, czyli rozdzielczość, bitrate i długość, jest wyborem między dwiema grupami odwiedzających. Strumieniowanie adaptacyjne nie rozstrzyga tego wyboru, tylko go usuwa.

Czym naprawdę jest dostawa adaptacyjna

Zamiast jednego pliku przygotowujesz drabinę: ten sam materiał zakodowany kilka razy, od małej wersji o niskim bitrate po Full HD. Każdą wersję tniesz następnie na krótkie, kilkusekundowe segmenty, a plik playlisty opisuje, co istnieje.

W HLS tą playlistą jest .m3u8. Zbudowanie drabiny to zadanie dla FFmpega i jego miejsce jest w pipelinie kompilacji albo przetwarzania zasobów, a nie w obsłudze żądania. Uruchamia się raz na materiał, nie raz na odwiedzającego.

Podczas odtwarzania player robi coś, czego zwykły znacznik <video> nie potrafi: mierzy rzeczywistą przepustowość w miarę pobierania segmentów i na tej podstawie wybiera wersję dla kolejnego segmentu. Zachowanie przy słabym łączu to więc nie „buforowanie przez sześć sekund”, tylko „zejście niżej i granie dalej”.

Trzy konsekwencje, które warto powiedzieć wprost:

• Odtwarzanie startuje z niskiego szczebla. Pierwsza klatka pojawia się szybko, a jakość rośnie w miarę tego, jak player rozpoznaje możliwości łącza. Wolny start rzuca się w oczy znacznie bardziej niż dwie pierwsze sekundy w niższej jakości.

• Schodzi tak samo jak wchodzi. To fragment, który ma znaczenie w prawdziwych sieciach komórkowych, gdzie pasmo jest nie tyle niskie, co nierówne. Player, który potrafi tylko wchodzić wyżej, zatnie się przy pierwszym wejściu do windy.

• Pobierane są wyłącznie oglądane segmenty. Ktoś, kto przewija dalej po trzech sekundach, pobrał trzy sekundy. Nie początek źródła 1080p.

Podział między przeglądarkami, który trzeba obsłużyć

Safari i iOS odtwarzają HLS natywnie. Wystarczy podać elementowi <video> adres .m3u8 i działa, razem z własną logiką adaptacyjną platformy.

Cała reszta potrzebuje playera w JavaScripcie, standardowo HLS.js, który przez Media Source Extensions sam podaje segmenty do elementu wideo.

Poprawna implementacja wygląda więc tak: najpierw sprawdzasz natywne wsparcie dla HLS, używasz go tam, gdzie jest, a bibliotekę playera ładujesz tylko wtedy, kiedy go nie ma. Ładowanie biblioteki bezwarunkowo oznacza wysłanie paczki kodu do użytkowników iOS, których przeglądarka i tak by jej nie potrzebowała, czyli akurat na tej platformie, na której chciałeś oszczędzić bajty.

Obraz startowy robi więcej, niż się wydaje

Strumień rozwiązuje odtwarzanie. Nie rozwiązuje pierwszego wyświetlenia, bo nawet szybki pierwszy segment dzieli od widza jedna podróż po sieci.

Hero potrzebuje więc obrazu startowego, a ten obraz jest niemal na pewno twoim elementem Largest Contentful Paint. Potraktuj go jak element LCP:

• Podaj go jako AVIF albo WebP z zapasowym JPEG, w rozmiarze dobranym do okna przeglądarki, a nie raz na najszerszy ekran, jaki obsługujesz.

• Nie ładuj go leniwie. Jest nad linią zgięcia, jest kandydatem na LCP, a loading="lazy" na nim to najczęstszy sposób, w jaki zespoły same przesuwają sobie LCP o sekundę.

• Leniwe niech zostanie samo wideo. Obraz się rysuje, strumień rusza, a przejęcie następuje w momencie, w którym pierwszy segment da się zdekodować.

• Dopasuj obraz startowy do pierwszej klatki. Jeśli widocznie się różnią, przejęcie wygląda jak usterka, a nie jak początek odtwarzania.

Przy właściwej kolejności wideo przestaje rywalizować z Core Web Vitals, bo mierzonym elementem jest obraz, nad którym masz pełną kontrolę.

Uszanuj sygnały, które odwiedzający już wysłał

Dwa z nich są tanie i notorycznie pomijane:

• prefers-reduced-motion to realna prośba o dostępność, a nie przełącznik preferencji. Uszanuj ją, pokazując obraz startowy i nie odtwarzając materiału automatycznie.

• Save-Data, a tam, gdzie jest dostępna, również preferencja ograniczonego transferu, mówi ci, że odwiedzający jest na łączu albo pakiecie, przy którym twoje hero nie jest priorytetem. Pokaż obraz startowy, a odtworzenie zostaw jako świadomy wybór.

W obu przypadkach strona schodzi do wersji, która nadal działa i nadal wygląda jak to, co sprzedaje, i to jest cały argument za tym, żeby mieć mocny obraz startowy.

Kiedy warto

Nie zawsze. Trzysekundowa pętla abstrakcyjnego gradientu nie potrzebuje drabiny bitrate'ów, tylko mniejszego pliku albo animacji.

Warto wtedy, kiedy to materiał jest argumentem: kiedy osoba decydująca, czy cię zatrudnić, decyduje na podstawie tego, jak wygląda sala. W takim przypadku wideo nie jest ozdobą, która musi się obronić ze swojej wagi. Jest stroną i zasługuje na pipeline, dzięki któremu ładuje się tak, jakby nią nie było.

Zbudowaliśmy dokładnie takie rozwiązanie w portfolio DJ-a, gdzie pierwszy ekran to autentyczne nagrania z imprez, a większość odwiedzających przychodzi z telefonu: