Wydajność

Wydajność to ostatnio dość popularny temat w środowisku webdevowym. Z jakiegoś powodu (ekhm, Google, ekhem) nagle wszyscy chcą, żeby ich strony WWW były jak najbardziej wydajne. Ale czy faktycznie wydajność jest aż tak istotna?

Można na problem spojrzeć z szerszej perspektywy. Bo wydajność nie dotyka jedynie kwestii tego, jak szybko strona się wczytuje. Wydajna strona jest bardziej dostępna. Strona, która zużywa tylko tyle zasobów, ile potrzebuje, jest także przyjaźniejsza środowisku, ponieważ powoduje mniejszą emisję dwutlenku węgla. Wydajność dotyka też kwestii urządzeń. Nigdy nie wiadomo, z jakiego urządzenia korzysta osoba użytkownicza. Co więcej, nierówności ekonomicznie mogą powodować spore różnice między możliwościami poszczególnych urządzeń. Do tego dochodzi jeszcze kwestia tego, że ludzie niekoniecznie często kupują nowe urządzenia. Odpowiednie podejście do wydajności pozwoli nam się jednak nie martwić nawet o te słabsze i starsze. Może także przedłużyć czas pracy na baterii. Wreszcie, wydajna strona zdecydowanie polepsza doświadczenie osoby użytkowniczej (bo nikt nie lubi czekać minutę na wczytanie się artykułu w Sieci). W takim ujęciu wydajność okazuje się tak naprawdę kwestią etyczną i jednym z fundamentów dobrze działającej strony WWW.

No i wreszcie - wydajność jest dobra także dla biznesu. Na web.dev można znaleźć sporo studiów przypadków, pokazujących, jak poprawa wydajności wpłynęła pozytywnie na zyski stron WWW. Innymi słowy: wydajność jest dobra na wszystko!

Sieć

Istnieje pewien paradoks: im większe prędkości jest w stanie osiągać Internet, tym mniej wydajny ostatecznie jest (jeśli nikt jeszcze tego paradoksu nie nazwał, zaklepuję go sobie jako Paradoks Comandeera!). Choć brzmi to całkowicie absurdalnie, to powód jest dość prosty: rosnąca prędkość Internetu sprawia, że przesyłane są większe ilości danych. Jako osoby webdeveloperskie mamy poczucie, że możemy sobie pozwolić na więcej.

Co niekoniecznie jest prawdą. Prędkość to nie wszystko. Bardzo ważnym czynnikiem jest choćby koszt połączenia. Im wyższy, tym większa szansa, że osoba użytkownicza nie będzie chciała odwiedzać strony WWW, która wymaga zaciągnięcia połowy biblioteki Kongresu. Do tego dochodzi kwestia stabilności połączenia. Tak, 5G jest niezwykle szybkie na papierze. W praktyce prędkość może być niższa. Albo osoba użytkownicza właśnie jedzie pociągiem i ma dostęp jedynie do rwącego się połączenia 3G. W takim wypadku nasza strona zaciągająca 20 MB niekoniecznie będzie dla niej pozytywnym doświadczeniem.

Dlatego warto ograniczać ilość przesyłanych danych. W idealnym wypadku – do 14 KB. Ale to raczej utopijna wizja. Wszystko zależy od konkretnego przypadku. Wbrew pozorom często można wyciąć sporo, nie zmieniając wyglądu strony w żaden dostrzegalny sposób. A czasami wycięcie kilku obrazków może wręcz podnieść czytelność.

Vitals

Istnieje spora liczba wskaźników, których zadaniem jest określanie wydajności stron WWW. Jednak najpopularniejszymi obecnie są prawdopodobnie Web Vitals. To zestaw kilku metryk, opracowanych przez Google i używanych m.in. w Lighthouse’ie. Są wykorzystywane także jako jeden z czynników rankingowych w wyszukiwarce Google. To sprawiło, że – chcąc, nie chcąc – więcej osób zainteresowało się wydajnością i zaczęło optymalizować strony WWW.

Metryki wchodząc w skład Web Vitals ciągle ewoluują, żeby jak najlepiej mierzyć wydajność strony WWW. Na chwilę obecną istnieją trzy podstawowe wskaźniki:

I choć takie metryki są pomocne w określeniu, nad czym wypada popracować, nie można zapominać, że wciąż to są wyłącznie syntetyczne wskaźniki. Nawet jeśli się osiągnie perfekcyjne wyniki w Core Web Vitals, niekoniecznie oznacza to, że strona jest wydajna. Ot, podobnie do zgodności ze standardem WCAG – to jeszcze nie oznacza, że strona jest dostępna. Wskaźniki i standardy to tylko wskazówki. Stosowanie się do nich zdecydowanie pomaga w osiągnięciu konkretnego celu (np. bycia wydajnym lub dostępnym), ale nie powinno stanowić celu samo w sobie. Ostatecznie to, ile zdobędziemy punkcików, absolutnie nie obchodzi naszej osoby użytkowniczej. Ją obchodzi wyłącznie dobrze działająca strona WWW.

Niemniej Chrome Team chwali się, że Web Vitals zaoszczędziło osobom użytkowniczym ponad 10 tysięcy lat, przyśpieszając wczytywanie się stron WWW. Rick Viscomi dodaje, że Sieć jest szybsza z roku na rok. Tylko że wszystkie te wyliczenia oparte są na syntetycznych wskaźnikach – więc warto je brać z lekką poprawką. Aczkolwiek ogólny trend jest dość optymistyczny.

Techniki

Na sam koniec warto przyjrzeć się kilku technikom, które pozwolą podnieść wydajność naszej strony WWW. Dobre podsumowanie podstawowych można znaleźć w kursie wydajności na web.dev. Wśród nich wymienić można:

Inną optymalizacją może być upewnienie się, że stosujemy najnowsze technologie. Przykładem może być protokół HTTP/3, który w niektórych przypadkach pozwoli przyśpieszyć prędkość pobierania zasobów przez przeglądarkę osoby użytkowniczej. Jednak najszybsze są te zasoby, których nie trzeba pobierać. Dlatego warto używać zarówno inline’owanie zasobów, jak i agresywne cache’owanie. To, które z nich będzie lepsze w naszym przypadku, zależy już od… naszego przypadku. Więc zawsze należy sprawdzić to empirycznie.

Ale samo wczytywanie strony to przecież dopiero początek. Równie ważne jest to, aby strona działała wydajnie i płynnie, bez “chrupnięć”. Celem powinno być renderowanie w 60 klatkach lub więcej. To oznacza, że kod JS nie może blokować głównego wątku przeglądarki (czyli tego odpowiedzialnego za renderowanie strony) na dłużej niż 16 ms (albo 8 ms, jeśli celujemy w 120 fps-ów). Jeśli musimy wykonać jakieś dłuższe zadanie, to należy je albo podzielić, albo przerzucić do workera.

Źródła

Dodatkowe materiały