Optymalizacja renderowania w przeglądarce: wyjaśnienie

Jak się czujesz, gdy strona ładuje się wieczność? Pewnie znasz to uczucie: strona w końcu się pojawia, a mimo to nie da się kliknąć ani przewinąć, bo w tle coś jeszcze mieli. 

A kiedy strona wreszcie zaczyna reagować, wyskakują szalone animacje i wszystko działa ociężale i tandetnie… Miałeś tak kiedyś? 

Ja miałem – i to niedawno. I co zaskakujące, nadal widuję to często, mimo że mamy dziś tyle narzędzi i praktyk do optymalizacji. 

Optymalizacja renderowania w przeglądarce to rozległy temat obejmujący wiele obszarów oraz narzędzi, technik i niezliczonych możliwości ulepszeń. 

Ten artykuł skupi się głównie na efektywnym dostarczaniu strony użytkownikowi końcowemu: na czasach ładowania, sposobach ich pomiaru oraz tym, jak je poprawiać z perspektywy frontend developera. 

Aspekty optymalizacji stron

Kwestie szybszego renderowania i lepszej responsywności po załadowaniu (wraz z szybszymi reakcjami na działania użytkownika i płynniejszymi animacjami) omówimy w osobnym wpisie na blogu. 

Na początek przyjrzyjmy się następującym aspektom optymalizacji strony:

Dlaczego warto optymalizować renderowanie strony

Cykl życia aplikacji – model RAIL 

Jak audytować stronę – dostępne wskaźniki i narzędzia

Techniki optymalizacji – rozwiązania i triki na przyspieszenie w czterech obszarach: environment, assets, build i delivery

*(Ponieważ optymalizacja renderowania i audytowanie bardzo się rozwinęły w ostatnich latach, nie omówię każdego tematu w detalach. Niektóre zagadnienia jedynie zasygnalizuję; tam, gdzie to możliwe, podlinkuję zewnętrzne źródła do dalszej lektury.) 

Dlaczego optymalizować renderowanie w przeglądarce? 

Powstało już sporo badań i publikacji o tym, jak ważna jest pamięć i różne metryki UX dla biznesu.

Mój kolega niedawno napisał świetny artykuł zbierający mnóstwo danych o tym, jak doświadczenie użytkownika na stronie wpływa na wiele kluczowych obszarów działalności firmy w internecie. 

Przeczytasz go tutaj. 

Oto kilka szybkich statystyk pokazujących, jak ważna stała się optymalizacja: 

Szybsze ładowanie: serwisy ładujące się w 5 sekund mają o 25% większą widoczność reklam, o 70% dłuższe sesje i o 35% niższy współczynnik odrzuceń. 

Pięć sekund to jednak nie ideał. Badanie z 2016 roku pokazało, że co drugi użytkownik mobilny oczekuje załadowania strony w mniej niż 2 sekundy, a aż 53% odwiedzających porzuci stronę, jeśli ładuje się dłużej niż 3 sekundy. 

W 2017 roku Google opublikowało raport o tym, jak wzrost czasu ładowania wpływa na współczynnik odrzuceń. W tym samym raporcie ankieta pokazała, że szybkość początkowego ładowania jest dla użytkowników najważniejszym czynnikiem UX. 

Jest aż 3 razy ważniejsza niż wygląd strony. Jest nawet ważniejsza niż łatwość odnalezienia informacji! Czas ładowania można też bezpośrednio powiązać z przychodami, jakie generuje strona w przeglądarce Chrome: 80% internautów jest skłonnych zapłacić więcej za dobre doświadczenie użytkownika.

Dość teorii. Przejdźmy do konkretów technicznych.

RAIL i cykl życia aplikacji

Gdy mówimy o ogólnej wydajności serwisu, warto odwołać się do modelu RAIL. RAIL zakłada 4 etapy w cyklu życia aplikacji (nie mylić z cyklem życia komponentu w popularnych frameworkach): response, animation, idle i load. 

Ta kolejność nie odpowiada jednak temu, co faktycznie dzieje się przy otwieraniu nowej strony (w takim przypadku byłoby to LIAR: load, idle, animation i response).

 Pozostanę przy tej kolejności i omówię szczegóły oraz znaczenie poszczególnych etapów. 

Etap Loading to początkowe ładowanie strony. Im krótsze, tym lepiej. Różne źródła sugerują, że powinno to trwać maksymalnie od 1 do 5 sekund, jednak metryki Google klasyfikują wszystko powyżej 2,5 sekundy jako „wymaga poprawy”. 

To jeden z kluczowych parametrów z perspektywy UX. 

Etap Idle to czas po wstępnym załadowaniu, gdy użytkownik zastanawia się, co dalej. Strona czeka na interakcję, więc tu możemy dokończyć rzeczy odłożone z etapu ładowania (obrazy, wideo, sekcje komentarzy). 

Te zadania powinny być wykonywane w kawałkach po 50 ms, aby w chwili interakcji użytkownika reakcja miała priorytet nad tym, co dzieje się w tle. 

Aby Animations były płynne, pojedyncza klatka musi powstać w mniej niż 16 ms. W artykule o modelu RAIL na web.dev czytamy: 

W momentach wysokiego obciążenia, jak animacje, kluczem jest robić nic, gdzie się da, i absolutne minimum tam, gdzie się nie da. Gdy to możliwe, wykorzystaj 100 ms na response do wstępnych obliczeń kosztownych operacji, by zmaksymalizować szanse na 60 klatek na sekundę. 

Etap Response to reakcja na działanie użytkownika (np. kliknięcie przycisku, nawigacja) i powinna nastąpić w ciągu 100 ms. To maksymalny czas, który pozostaje niezauważalny – wrażenie jest wtedy natychmiastowe. 

Na diagramie wyżej Load i Idle oznaczono na niebiesko, a Animation i Response na zielono.  To dlatego, że Loading i Idle są jednorazowe dla każdej nowo ładowanej strony (w SPA mogą być jednorazowe dla całej aplikacji), a Animation i Response powtarzają się przy każdej interakcji.

Korzystanie z Google Web Vitals

Aby mierzyć wydajność serwisu i ocenić, czy, kiedy i gdzie wymaga optymalizacji, potrzebujemy narzędzi. Najlepiej uniwersalnych, by móc porównywać wyniki z innymi stronami w sieci. 

Google przejęło tu inicjatywę, tworząc Web Vitals. Web Vitals to inicjatywa Google dostarczająca ujednolicone wytyczne dla sygnałów jakości kluczowych dla świetnego UX w sieci. 

Choć istnieje wiele narzędzi do pomiaru i optymalizacji wydajności stron, Google postanowiło stworzyć takie, które każdy zrozumie i zastosuje. 

Powstał też podzbiór Core Web Vitals, który mierzy trzy aspekty UX: ładowanie, interaktywność i stabilność wizualną. 

Są one mierzone trzema metrykami:

Źródło: https://web.dev/vitals/ 

Largest Contentful Paint (LCP) – mierzy czas wstępnego ładowania. Jak widać, ładowanie powinno zmieścić się w 2,5 s. Dodatkowe 1,5 s (4 s łącznie) i UX uznawany jest już za słaby.

First Input Delay (FID) – mierzy interaktywność. Reakcja na działanie użytkownika powinna nastąpić w ciągu 100 ms. Powyżej tego progu strona jest odbierana jako „muląca”. 

Cumulative Layout Shift (CLS) – wskaźnik stabilności układu. Jeśli treść ładuje się skokami, wypychana przez obrazy lub reklamy pojawiające się po sekundach, to również słabe UX.

Pomiar Core Web Vitals z Lighthouse

Istnieje wiele sposobów mierzenia Core Web Vitals (i nie tylko). Tym, od którego powinien zacząć każdy developer, jest Lighthouse: automatyczne, open-source’owe narzędzie do pomiaru i raportowania wydajności oraz słabych punktów strony. 

Kiedyś dostępne w zakładce Audits w narzędziach deweloperskich, ostatnio zostało usunięte stamtąd i działa jako osobne rozszerzenie Chrome.

Jeśli audytujesz już działającą stronę, rozszerzenie nie jest konieczne. Narzędzie jest dostępne tutaj. Lighthouse obejmuje trzy opisane wyżej wskaźniki (LCP, FID, CLS) i kilka dodatkowych. 

Pokażę to na przykładzie:

Oto audyt Lighthouse uruchomiony dla losowo wybranej strony wraz z wynikami:

Źródło: https://web.dev/measure/ 

Widać cztery główne obszary, na których skupia się Lighthouse: Performance, Accessibility, Best Practices i SEO. Skoro naszym celem jest wydajność, rozbijmy ten wynik na czynniki pierwsze.

Na dole raportu znajdziesz sześć metryk definiujących różne aspekty wydajności. Oto one: 

Speed Index (SI) –  Porównanie indeksu szybkości Twojej strony z indeksami realnych witryn na podstawie danych z HTTP Archive. Więcej o Speed Index przeczytasz tutaj. 

Time to Interactive (TTI) – Mierzy czas do pełnej interaktywności. Uwzględnia m.in. FCP, rejestrowanie handlerów zdarzeń dla widocznych elementów oraz reakcje na działania użytkownika w granicach 50 ms.  Szczegóły metodologii znajdziesz tutaj. 

Total Blocking Time (TBT) – Ściśle powiązany z etapem Idle w modelu RAIL. Pokazuje łączny czas blokowania strony przez wykonywanie zadań w tle. Idealnie, pojedyncze kawałki pracy nie powinny przekraczać 50 ms. 

Trzeba dodać, że Lighthouse nie jest idealny. Z czasem użytkownicy odnotowali pewne niespójności, o których poczytasz na stronie Calibre oraz w tym wpisie na blogu. 

PageSpeed

Inne świetne narzędzie do pomiaru wydajności to PageSpeed od Google Developers. Jest proste: wklejasz URL strony do audytu i klikasz Analyze. Po chwili dostajesz raport z dwiema sekcjami i wyborem urządzenia. 

Zacznę od drugiej sekcji, Diagnose Performance Issues. Brzmi znajomo? Słusznie: wygląda jak Lighthouse. I faktycznie nim jest – PageSpeed korzysta z laboratoryjnych wyników Lighthouse jako części raportu. 

Super. A co, jeśli wynik jest przeciętny, a Ty nadal nie wiesz, co konkretnie zawodzi? Lighthouse pomoże. 

Po przewinięciu zobaczysz listę potencjalnych problemów w różnych obszarach wydajności wraz z możliwymi rozwiązaniami. Oznaczone i posortowane według wagi i wpływu na optymalizację. 

Pierwsza sekcja raportu jest najważniejsza, bo pokazuje RZECZYWISTE doświadczenie użytkowników na Twojej stronie. Na podstawie danych z faktycznych sesji użytkowników Chrome widzisz, jak strona zachowuje się w realnych warunkach, a nie tylko w „laboratorium” Lighthouse. 

Co więcej, możesz mierzyć to osobno na desktopie i na urządzeniach mobilnych.

W górnej części raportu PageSpeed zobaczysz wskaźnik, o którym jeszcze nie było mowy – FCP, czyli First Contentful Paint. 

FCP wskazuje moment, w którym użytkownik już widzi jakąś treść. To ważna metryka – kluczowe jest, by choć część zawartości pojawiła się możliwie szybko:

Źródło: https://pagespeed.web.dev/ 

Dość teorii i wskaźników. Przejdźmy do tego, co dla developerów jest najciekawsze: przyczyn słabych wyników i sposobów na poprawę. 

Optymalizacja w obszarach: Environment, Assets, Build i Delivery 

Skoro wreszcie mówimy o optymalizacji, podam Ci teraz dziesięć rad, dzięki którym Twoja strona będzie błyskawiczna i już nigdy nie będziesz musiał jej optymalizować. 

Żartowałem. 

A właściwie – nie do końca. Co mam na myśli?

Powstało mnóstwo poradników o optymalizacji wydajności stron. Vitaly Friedman napisał świetny artykuł o praktykach optymalizacji renderowania stosowanych w 2021 roku. Nic dziwnego, że to 3-godzinna lektura. 

Przy tylu zmiennych w naszych środowiskach deweloperskich jest nieskończony potencjał na błędy. A może raczej: na kombinacje, które zadziałają w jednej aplikacji, ale w innej już nie. 

Nie będę więc powtarzał wszystkiego – to wymagałoby kolejnego, 3-godzinnego tekstu i cytowania mądrzejszych ode mnie. 

Zamiast tego podam listę rzeczy, które warto rozważyć przy optymalizacji, w czterech obszarach, na które frontend developer ma wpływ: environment, assets, build i delivery.

Environment 

Build tools – Grunt, Gulp, Webpack, Parcel, Rollup, Snowpack… Dopóki spełniasz cele utrzymania i wydajności, każda sensowna konfiguracja jest OK. Jeśli trudno Ci wybrać narzędzie lub ich zestaw, pamiętaj, że Webpack jest długo na rynku i oferuje wiele pluginów optymalizacyjnych. 

Framework – Angular, Vue, React, Svelte? Pamiętaj, że nowoczesne frameworki rzadko priorytetyzują słabsze urządzenia. I nie każda podstrona w SPA wymaga ładowania całego frameworka. Zobacz świetne case study Netflixa tutaj

Rendering – Server‑Side, Static, Streaming Server‑Side, Client‑Side… niezależnie od wyboru, najważniejsze jest skrócenie czasu między LCP a TTI.

Koszt bazowy wydajności – Zamiast stawiać na „goły” framework, możesz nie używać żadnego – albo wybrać opinionated rozwiązania takie jak Next.js, Nuxt.js itp. Oto fajne badanie o kosztach wydajności frameworków. 

Źródło: https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/

Assets

AVIF, AV1, WebP, WebM –  Nowoczesne formaty zdjęć i wideo potrafią drastycznie skrócić czasy ładowania. Wsparcie dla WebM i AVIF wciąż rośnie, ale jest na dobrej drodze.

Responsive images – Zawsze używaj obrazów responsywnych z `srcset`, `sizes` i elementem <picture>. Tła także mogą być responsywne – sprawdź właściwość CSS `image-set`. 

Web fonts, Google Fonts –  To duży temat. Więcej znajdziesz w tym artykule.

Brotli –  Obiecujący, bezstratny format kompresji danych. 

GIF-y –  Daruj sobie — są fatalne rozmiarowo. Zamiast nich używaj zapętlonych wideo HTML:

Źródło: https://www.smashingmagazine.com/2021/01/front-end-performance-2021-free-pdf-checklist/#defining-the-environment 

Build

JS modules, wzorzec module/nomodule (differential serving) –  Więcej w dokumentacji silnika V8 i na blogu Planete Performance.

Tree‑shaking, code‑splitting, scope‑hoisting –  Pewnie je znasz – to dziś standard w builderach takich jak Webpack. 

Web Worker – Aby zmniejszyć TTI, warto delegować część wstępnych obliczeń do Web Workera. 

Optymalizacja SPA – Większość frontendowców pracuje dziś z frameworkami SPA. Jest sporo rzeczy do poprawy wydajności, ale dla zwięzłości podlinkuję świetny, praktyczny artykuł z CSS‑Tricks. 

Identyfikacja i usuwanie nieużywanego CSS/JS – Skorzystaj z Chrome DevTools (narzędzie Coverage) albo z Puppeteer, który potrafi też m.in. przygotować prerenderowaną treść strony.

Partial hydration – Jeśli chcesz wejść głębiej, zacznij od case studies: tu dla Reacta i tu dla fanów Vue. 

Cache‑Control – Caching to nic nowego, ale gdy wejdziesz głębiej, odkryjesz „część podwodną góry lodowej”. Istnieje wiele strategii i pułapek przy ustawianiu, jak przeglądarka powinna keszować zasoby. Na szybki start zajrzyj tutaj. Bardziej zaawansowanym polecam ten artykuł o tym, kiedy sieć bywa szybsza niż cache.

Biblioteki third‑party – Krótko: im mniej, tym lepiej. Według thirdpartyweb.today biblioteki stron trzecich odpowiadają za 57% całego wykonywania JS. Jeśli już musisz ich użyć, najlepiej self‑hostować.

Źródło: thirdpartyweb.today 

Delivery

Lazy loading – Oprócz używania defer lub async dla skryptów, native lazy‑loading jest już wspierane przez wszystkie przeglądarki (dla obrazów; iFrame’y będą wspierane wkrótce). 

Intersection Observer – Zgodnie z definicją: Intersection Observer API umożliwia asynchroniczne obserwowanie zmian przecinania się elementu docelowego z elementem nadrzędnym lub viewportem dokumentu. Prościej: dzięki Intersection Observer możemy precyzyjnie kontrolować elementy, które za chwilę wejdą w kadr. W połączeniu z lazy‑loadingiem to bardzo mocne narzędzie. Jeśli nie używałeś go wcześniej, tu znajdziesz fajny przykład wdrożenia.

Content‑visibility – Gdy wszystkie przeglądarki będą to wspierać, wdrożymy lazy‑loading całych sekcji strony czystym CSS. Jeśli masz długi ekran główny (wiele sekcji itp.), dobrym pomysłem będzie renderowanie ich tuż przed pojawieniem się w kadrze. Tu świetny przykład, jak wykorzystać to do przyspieszenia LCP. 

Critical CSS – Standardem jest dziś wydzielanie lub oznaczanie CSS „above the fold” i dołączanie go w sekcji <head>. 

Service Worker – Może drastycznie skrócić czas kolejnych wejść, korzystając z keszowanych zasobów

Rendering performance – Aby strona była responsywna w odczuciu, musimy pamiętać o procesie renderowania klatek i odpowiednio go optymalizować. To jednak osobny, obszerny temat – opublikujemy o nim oddzielny artykuł, skupiony na fazach Animation i Response modelu RAIL.

Connection‑aware components – Możesz korzystać z rozwijających się API przeglądarek i renderować komponenty w zależności od przepustowości łącza użytkownika (zob. obiekt navigator.connection). To bardzo przydatne, gdy uruchamiasz globalną aplikację dla użytkowników z łączami od bardzo wolnych po ultraszybkie:

Źródło: https://dev.to/addyosmani/loading-web-pages-fast-on-a-20-feature-phone-8h6 

Proaktywna i reaktywna optymalizacja przeglądarki

Powyższa lista może na początku przytłaczać. Możesz zapytać: czy aby uzyskać topową wydajność, muszę przejść przez każdy punkt i osobno go sprawdzić? 

Choć dobrze mieć te punkty z tyłu głowy, optymalizacja powinna być mieszanką podejścia proaktywnego i reaktywnego. Część rzeczy jest oczywista i warto o nich pamiętać już podczas pisania kodu. 

Należą do nich zarządzanie zależnościami, SSR, praca z assetami, fontami, tree‑shaking, biblioteki third‑party, caching i lazy‑loading. Włączone w codzienną praktykę znacząco zwiększają szanse na wysokie wyniki w każdej analizie wydajności. 

Jeśli mimo to wyniki nie zadowalają, wymienione narzędzia wskażą słabe punkty aplikacji, abyś mógł je później zoptymalizować (Webpack, CDN, SSR, differential serving, partial hydration, opóźnione importy, deferred rendering, Critical CSS, Service Worker itd.). 

Jeśli chcesz zobaczyć ścieżkę optymalizacji landing page’u dużej marki modowej, zerknij na ten film nagrany przez Addy’ego Osmaniego, jednego z topowych specjalistów Google ds. optymalizacji.

Możesz też wyjść poza kod i serwer i zajrzeć do konfiguracji na poziomie przeglądarki, by zoptymalizować Google Chrome. Dla wielu osób samo przejrzenie ustawień Chrome wystarcza, by odkryć opcje takie jak akceleracja sprzętowa czy flaga pozwalająca nadpisać listę programowego renderingu. Na niektórych maszynach akceleracja sprzętowa zrzuca pracę na GPU i faktycznie pomaga Chrome płynniej renderować złożone strony; na innych wprowadza „jank” i artefakty. W takich przypadkach wyłączenie akceleracji w ustawieniach Chrome może sprawić, że przeglądarka będzie stabilniejsza i przewidywalniejsza przy stronach bogatych w animacje czy grafikę.

Do bardziej zaawansowanej diagnostyki Google Chrome ma wbudowany Menedżer zadań (Shift+Esc), który pokazuje, które karty, rozszerzenia i procesy zużywają najwięcej CPU i pamięci podczas ładowania strony. Dzięki temu łatwiej wychwycić rozszerzenie z Chrome Web Store, które obniża wydajność, nawet jeśli Twój kod i serwer są już zoptymalizowane. Połączenie rozsądnej „higieny” rozszerzeń z dobrą konfiguracją przeglądarki daje dodatkową warstwę kontroli nad realną wydajnością – komplementarną wobec wszystkich optymalizacji renderowania i dostarczania opisanych wcześniej. 

Podsumowanie

Mam nadzieję, że jest już jasne, jak kluczowe jest dostarczanie świetnego doświadczenia użytkownika. Po omówieniu dwóch pierwszych etapów modelu RAIL powinno być też jasne, jak podejść do ładowania strony i jak najszybciej dostarczyć użytkownikom treść, po którą przyszli.

Przeszliśmy również przez Lighthouse i PageSpeed – narzędzia, które pomagają zidentyfikować czynniki utrudniające responsywność strony. Następnie odwołaliśmy się do skondensowanej „ściągawki” z technikami optymalizacji, które możesz zastosować, by ten cel osiągnąć. 

Pamiętaj, że opisane tu tematy to jedynie wierzchołek góry lodowej. Mam jednak nadzieję, że temat jest na tyle ciekawy, by zachęcić Cię do dalszych eksploracji opisanych technik – i że dzięki temu Twoje umiejętności optymalizacji serwisów zauważalnie wzrosną.

Miłego kodowania!

Często zadawane pytania

Dlaczego powolne ładowanie strony jest tak szkodliwe dla biznesu w sieci?

Szybkość działania strony bezpośrednio przekłada się na zaangażowanie użytkowników i wyniki biznesowe firmy. Badania wykazują, że serwisy, które ładują się w czasie do 5 sekund, mogą liczyć na o 25% większą widoczność reklam, o 70% dłuższe sesje oraz o 35% niższy współczynnik odrzuceń. Co więcej, aż 53% użytkowników urządzeń mobilnych porzuci witrynę, jeśli jej ładowanie potrwa dłużej niż 3 sekundy. Dla internautów szybkość początkowego ładowania jest najważniejszym czynnikiem wpływającym na doświadczenie użytkownika (UX) – okazuje się ona aż trzykrotnie ważniejsza niż sam wygląd strony i istotniejsza niż łatwość wyszukiwania informacji. Dodatkowo aż 80% użytkowników deklaruje gotowość do zapłacenia większej kwoty za korzystanie z usług platformy oferującej lepsze i płynniejsze wrażenia z użytkowania.

Czym charakteryzują się poszczególne etapy w modelu RAIL?

Model RAIL dzieli cykl życia aplikacji na cztery kluczowe etapy: response, animation, idle oraz load. Etap Loading dotyczy początkowego ładowania strony, które powinno zająć maksymalnie od 1 do 5 sekund, choć wytyczne Google określają czas powyżej 2,5 sekundy jako wymagający poprawy. Etap Idle to okres bezczynności, w którym strona czeka na interakcję użytkownika; w tym czasie aplikacja powinna wykonywać odłożone zadania, takie jak ładowanie obrazów czy wideo, w małych porcjach do 50 ms. Etap Animations odpowiada za płynność ruchu, wymagając generowania pojedynczej klatki w czasie poniżej 16 ms dla zachowania standardu 60 klatek na sekundę. Ostatni etap, Response, odnosi się do natychmiastowej reakcji na działanie użytkownika, która musi nastąpić w ciągu 100 ms, aby była postrzegana jako natychmiastowa i płynna.

Jakie główne wskaźniki wchodzą w skład Core Web Vitals?

Wskaźniki Core Web Vitals to opracowany przez Google zestaw metryk służących do oceny kluczowych aspektów doświadczenia użytkownika, takich jak ładowanie, interaktywność oraz stabilność wizualna. Pierwszym z nich jest Largest Contentful Paint (LCP), który mierzy czas potrzebny na załadowanie głównej zawartości strony, a optymalny wynik powinien wynosić poniżej 2,5 sekundy. Drugim parametrem jest First Input Delay (FID), oceniający interaktywność poprzez pomiar czasu reakcji witryny na pierwsze kliknięcie lub działanie użytkownika, gdzie pożądana wartość nie powinna przekraczać 100 ms. Trzecim wskaźnikiem jest Cumulative Layout Shift (CLS), który określa stabilność wizualną układu strony. CLS mierzy, czy elementy na ekranie nie przesuwają się niespodziewanie w trakcie ładowania, na przykład pod wpływem opóźnionego pojawiania się obrazów czy reklam, co negatywnie wpływa na odbiór witryny.

W jaki sposób można zmierzyć parametry Core Web Vitals?

Do mierzenia wskaźników Core Web Vitals najlepiej wykorzystać automatyczne, darmowe narzędzie open-source o nazwie Lighthouse, rekomendowane przez Google. Służy ono do audytowania wydajności, dostępności, poprawności praktyk deweloperskich oraz SEO stron internetowych. Narzędzie to analizuje witrynę i generuje szczegółowy raport zawierający oceny poszczególnych obszarów oraz konkretne wskazówki dotyczące elementów wymagających poprawy. Choć kiedyś Lighthouse był integralną częścią zakładki Audits w narzędziach deweloperskich przeglądarki Chrome, obecnie można z niego korzystać jako z osobnego rozszerzenia lub poprzez dedykowaną stronę internetową przeznaczoną do pomiarów. Lighthouse mierzy nie tylko podstawowe wskaźniki Core Web Vitals, takie jak LCP, FID i CLS, ale również dodatkowe metryki wydajnościowe, dostarczając twórcom stron wszechstronnej wiedzy o stanie optymalizacji ich kodu i zasobów sieciowych.

Czym są wskaźniki Speed Index, TTI oraz TBT w raportach wydajności?

Wskaźniki te stanowią rozszerzenie analizy wydajności witryny w raportach Lighthouse. Speed Index (SI) określa, jak szybko treść strony staje się widoczna podczas jej ładowania, porównując te dane z bazą HTTP Archive. Time to Interactive (TTI) mierzy czas, po którym strona osiąga pełną interaktywność, co oznacza, że wyrenderowała już kluczowe elementy, zarejestrowała obsługę zdarzeń i reaguje na działania użytkownika w czasie do 50 ms. Z kolei Total Blocking Time (TBT) wskazuje łączny czas, w którym strona była zablokowana przez zadania wykonywane w tle, uniemożliwiając natychmiastową interakcję z użytkownikiem. Wartość ta jest bezpośrednio związana z fazą Idle w modelu RAIL i pozwala ocenić, jak skutecznie rozbito długie zadania skryptów na mniejsze porcje nieprzekraczające 50 ms.