Core Web Vitals: LCP, INP i CLS

Moduł 4: Szybkość, urządzenia mobilne i https · Czas czytania: 13 minut

Cel lekcji: Po tej lekcji będą Państwo potrafili objaśnić trzy wskaźniki Core Web Vitals wraz z ich wartościami granicznymi, wskazać różnicę między danymi z terenu a danymi laboratoryjnymi, odczytać pomiar w PageSpeed Insights, usunąć najważniejsze przyczyny słabego wyniku oraz rzetelnie ocenić, jak duże znaczenie ma szybkość w wynikach wyszukiwania.

Kluczowe pojęcia: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75. percentyl, dane z terenu (CrUX), dane laboratoryjne (Lighthouse), PageSpeed Insights, raport Podstawowe wskaźniki internetowe w Search Console, TTFB, kompresja, width i height przy obrazach, loading="lazy", jakość strony (page experience)

Szybkość w trzech liczbach

„Czy moja strona jest szybka?” to mało precyzyjne pytanie. Google i twórcy przeglądarki Chrome zamienili je na trzy mierzalne pytania, czyli Core Web Vitals:

Kilka rzeczy, które warto dobrze zrozumieć:

• LCP mierzy moment, w którym pojawia się największy widoczny element. Zwykle jest to duże zdjęcie na górze strony (tzw. „hero”) lub duży blok tekstu. W przypadku Bloemenatelier Lotte jest to zdjęcie kompozycji kwiatowej na stronie głównej.
• INP uwzględnia wszystkie kliknięcia, dotknięcia i naciśnięcia klawiszy podczas wizyty i raportuje (prawie) najwolniejszą reakcję. 12 marca 2024 r. INP zastąpił starszy pomiar FID (First Input Delay), który dotyczył tylko pierwszego kliknięcia i tylko czasu oczekiwania przed jego przetworzeniem. Jeśli w starym artykule pojawia się FID, ta informacja jest nieaktualna.
• CLS nie jest czasem, lecz wynikiem bez jednostki. Rośnie, gdy elementy przesuwają się w trakcie czytania: chcą Państwo dotknąć przycisku, a w tej chwili powyżej pojawia się baner i dotykają Państwo czegoś innego.

75. percentyl

Strona „spełnia” Core Web Vitals, jeśli 75 procent wizyt uzyskuje dobry wynik we wszystkich trzech pomiarach, liczonych osobno dla urządzeń mobilnych i komputerów. Nazywa się to 75. percentylem. Oznacza to, że liczy się nie Państwa własny szybki komputer na światłowodzie, lecz doświadczenie większości odwiedzających, także tych ze starszym telefonem w sieci 4G.

Dane z terenu i dane laboratoryjne

Istnieją dwa rodzaje pomiarów i często dają one różne wyniki.

• Dane z terenu pochodzą od prawdziwych odwiedzających. Chrome (u użytkowników, którzy się na to zgadzają) anonimowo zbiera informacje o szybkości stron w raporcie Chrome User Experience Report (CrUX). PageSpeed Insights pokazuje dane z terenu z ostatnich 28 dni. Raport Podstawowe wskaźniki internetowe w Search Console korzysta z tego samego źródła. Jeśli strona ma zbyt mało odwiedzin, PageSpeed Insights pokazuje dane dla całej witryny (tzw. „origin”), a jeśli i tych jest za mało, danych z terenu nie ma.
• Dane laboratoryjne pochodzą z symulowanego testu w narzędziu Lighthouse: jednorazowe załadowanie strony na emulowanym telefonie średniej klasy i przy przeciętnym połączeniu. Lighthouse nie może zmierzyć INP (nikt niczego nie klika), dlatego podaje inne wartości, takie jak Total Blocking Time, które są jednak wskazówką co do INP.

Do oceny liczą się dane z terenu. Dane laboratoryjne pomagają znaleźć przyczyny i od razu po wprowadzeniu poprawki sprawdzić, czy działa, bez czekania 28 dni.

Jak duże ma to znaczenie?

W tej kwestii wiele się przesadza. Oto co sam Google pisze w dokumentacji dotyczącej jakości strony:

• „Core Web Vitals are used by our ranking systems”: wskaźniki te są więc brane pod uwagę.
• Nie istnieje osobny „sygnał jakości strony”. Inne elementy dobrej jakości strony (https, brak natrętnych wyskakujących okienek, wygoda na urządzeniach mobilnych) według Google nie podnoszą bezpośrednio pozycji, ale sprawiają, że strona jest przyjemniejsza w użyciu.
• „Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” Wolna strona z najlepszą odpowiedzią może więc mimo to znaleźć się na samej górze.
• Dążenie do idealnego wyniku wyłącznie ze względu na SEO według Google „może nie być najlepszym wykorzystaniem czasu”.

Wniosek: warto znaleźć się w zielonym albo przynajmniej w pomarańczowym obszarze, przede wszystkim dlatego, że odwiedzający rezygnują z wolnych lub „skaczących” stron. Pogoń za wzrostem z 90 do 100 punktów w Lighthouse niewiele daje w wynikach wyszukiwania.

Przyczyny, którymi mogą się Państwo zająć samodzielnie

Wolna pierwsza odpowiedź (TTFB)

Wszystko zaczyna się od chwili, w której dociera pierwszy bajt kodu HTML, czyli Time to First Byte. TTFB sam nie jest wskaźnikiem Core Web Vitals, ale przy wolnym TTFB dobry LCP jest prawie nieosiągalny. web.dev podaje jako wartość orientacyjną: dobry wynik to 0,8 sekundy lub mniej, słaby to ponad 1,8 sekundy. Przyczyny według web.dev: zbyt mała moc obliczeniowa hostingu, brak pamięci podręcznej (każda strona jest budowana od nowa, typowe dla WordPress bez wtyczki cache), przekierowania (lekcja 4.1) oraz odległy serwer bez CDN.

Ważna jest też kompresja: serwer powinien wysyłać HTML, CSS i JavaScript w postaci skompresowanej za pomocą gzip lub Brotli. Widać to po nagłówku Content-Encoding: gzip lub br. Niemal każdy hosting robi to domyślnie, ale błędne ustawienie lub stary serwer mogą ją wyłączyć.

Obrazy

Obrazy to najczęstsza przyczyna słabego LCP i CLS:

1. Zbyt duże. Zdjęcie o szerokości 4.000 pikseli i rozmiarze 5 MB w polu o szerokości 800 pikseli. Prosimy zmniejszać zdjęcia przed przesłaniem i używać nowoczesnego formatu, takiego jak WebP lub AVIF.

2. Brak szerokości i wysokości. Bez width i height przeglądarka nie wie, ile miejsca potrzebuje obraz, więc tekst pod nim przesuwa się, gdy obraz się załaduje. web.dev zaleca ustawianie width i height w każdym elemencie <img>:

   <img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">

3. Leniwe ładowanie najważniejszego zdjęcia. loading="lazy" sprawia, że obraz ładuje się dopiero wtedy, gdy pojawia się w polu widzenia. To dobre rozwiązanie dla zdjęć znajdujących się niżej, ale web.dev mówi jasno: obrazów widocznych od razu po otwarciu strony, a zwłaszcza obrazu LCP, NIE należy ładować leniwie. W przeciwnym razie przeglądarka zwleka właśnie ze zdjęciem, które decyduje o LCP.

Przesuwająca się treść i wolne reakcje

Inne przyczyny CLS według web.dev: czcionki, które podczas ładowania zmieniają rozmiar, reklamy i osadzone widżety, które same się powiększają, oraz treść wstawiana później nad istniejącą treścią (np. pasek cookie, który spycha stronę w dół, zamiast wyświetlać się nad nią). Słaby INP prawie zawsze wynika z nadmiaru JavaScriptu: ciężkich motywów, sliderów, widżetów czatu i skryptów śledzących firm zewnętrznych. Prosimy krytycznie przyjrzeć się każdej wtyczce i każdej osadzonej usłudze; tutaj mniej naprawdę znaczy więcej.

W praktyce: pomiar w PageSpeed Insights

Prosimy wejść na pagespeed.web.dev, wpisać adres strony głównej i kliknąć Analizuj. Pojawią się dwie karty (Komórka i Komputer). Na górze widać ocenę Core Web Vitals na podstawie danych z terenu, jeśli są dostępne. Pod nią znajduje się test Lighthouse z wynikiem i listą „Diagnostyka” z konkretnymi punktami, np. o obrazach większych niż potrzeba lub o obrazie LCP ładowanym leniwie (dokładne nazwy zmieniają się wraz z nowymi wersjami Lighthouse). Warto zacząć od karty Komórka: tam wyniki są zwykle gorsze, a Google ocenia najpierw wersję mobilną (lekcja 4.2).

Jeśli Państwa witryna jest dodana do Search Console (moduł 2), prosimy zajrzeć również do sekcji Wrażenia, Podstawowe wskaźniki internetowe. Widać tam grupy podobnych stron wraz z ich stanem, także dla stron, których Państwo sami nie testowali.

Strona utworzona w AI Builder ustawia szerokość i wysokość obrazów o znanych wymiarach, ładuje pierwsze zdjęcie na stronie od razu i z priorytetem (fetchpriority="high"), a pozostałe leniwie, oraz podczas publikacji tworzy wersję dużych zdjęć o szerokości 800 pikseli. W WordPress najbardziej pomagają wtyczka cache i zmniejszanie obrazów; kurs WordPress omawia to szerzej w module 6. U innych kreatorów stron i firm hostingowych działa to podobnie: przyciski są inne, przyczyny te same.

Podsumowanie

• Core Web Vitals to LCP (dobry do 2,5 s), INP (dobry do 200 ms, od marca 2024 r. zamiast FID) i CLS (dobry do 0,1), mierzone na 75. percentylu osobno dla każdego rodzaju urządzenia.
• O ocenie decydują dane z terenu (CrUX, 28 dni); dane laboratoryjne (Lighthouse) pomagają znaleźć przyczyny.
• Google wykorzystuje Core Web Vitals w rankingu, ale trafność ma pierwszeństwo: idealny wynik nie jest celem samym w sobie.
• Największe korzyści: szybka odpowiedź serwera z pamięcią podręczną i kompresją, małe obrazy z width i height, brak leniwego ładowania najważniejszego zdjęcia, mniej JavaScriptu firm zewnętrznych.

Quiz

Zadanie

Zadanie A4.3: Szybka odpowiedź i lekkie obrazy. Prosimy wpisać adres strony. Program trzykrotnie mierzy czas do pierwszego bajtu (TTFB) z naszego serwera i bierze wartość środkową, sprawdza, czy HTML jest wysyłany w postaci skompresowanej (gzip, Brotli lub zstd), liczy obrazy bez width i height oraz sprawdza, czy najważniejszy obraz na górze strony nie jest ładowany z loading="lazy". Uwaga: jest to pomiar z jednego miejsca, a nie pomiar Państwa odwiedzających. Nie mają Państwo własnej strony? Prosimy użyć www.wikipedia.org.

Zadanie D4.3: Państwa Core Web Vitals. Prosimy uruchomić PageSpeed Insights dla strony głównej i jednej innej ważnej strony, najpierw na karcie Komórka. Dla każdej strony prosimy zanotować: czy są dane z terenu (dla strony czy dla całej witryny), wartości LCP, INP i CLS z danych z terenu, wynik Lighthouse oraz element, który Lighthouse wskazuje jako element LCP. Prosimy wybrać jedną poprawkę, która Państwa zdaniem przyniesie najwięcej, i wyjaśnić dlaczego.

Więcej informacji

• web.dev, Web Vitals: https://web.dev/articles/vitals
• web.dev, Largest Contentful Paint (LCP): https://web.dev/articles/lcp
• web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
• web.dev, Cumulative Layout Shift (CLS): https://web.dev/articles/cls
• web.dev, Time to First Byte (TTFB): https://web.dev/articles/ttfb
• web.dev, Browser-level image lazy loading: https://web.dev/articles/browser-level-image-lazy-loading
• Google Search Central, Understanding page experience in Google Search results: https://developers.google.com/search/docs/appearance/page-experience
• PageSpeed Insights, About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
• Pomoc Search Console, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520