Czym są Core Web Vitals?
Core Web Vitals, to w spolszczonej wersji „podstawowe wskaźniki internetowe”. Są one brane pod uwagę w ocenie serwisów. Aktualizacja ma na celu skupić uwagę webmasterów i właścicieli witryn na 3 wskaźnikach posiadających realny wpływ na UX.
- LCP (Largest Contentful Paint) – ładowanie
Określa czas ładowania największego elementu treści, zwykle bloku tekstu, grafiki lub wideo, powyżej linii zanurzenia (czyli na ekranie widocznym od razu po wczytaniu się strony w wyszukiwarce bez dodatkowych działań użytkownika).
https://web.dev/vitals/
Granica dla dobrego wyniku tego wskaźnika to 2,5 sekundy. Wartości powyżej są uznawane za wymagające poprawy, a jeśli przekraczają 4 sekundy – świadczą o słabej jakości serwisu.
- INP (Interaction to Next Paint)
Interaction to Next Paint to wskaźnik responsywności zastępujący First Input Delay. W skład podstawowych wskaźników internetowych wchodzi od 12 marca 2024.
https://web.dev/articles/inp
INP ocenia reakcję strony na interakcje użytkownika: kliknięcia myszką, dotknięcie ekranu dotykowego na urządzeniu, naciśnięcie klawisza na klawiaturze fizycznej i ekranowej. Wartość INP to najdłuższa zarejestrowana reakcja, która nie powinna przekraczać 200 milisekund.
- FID (First Input Delay) – interaktywność (wskaźnik zastąpiony przez Interaction to Next Paint).
Wskaźnik ten dotyczy opóźnienia reakcji witryny, jakiego doświadcza użytkownik przed możliwością wykonania pierwszej akcji. W prostych słowach mówimy tu o długości czasu, który musi minąć, aby elementy odpowiadały na działania internauty, np. kliknięcie bannera.
https://web.dev/vitals/
Nie powinno to trwać dłużej niż 100 milisekund, natomiast powyżej 300 możemy mówić już o kiepskim wyniku.
Dlaczego Google zdecydował się na zmianę? FID uwzględnia tylko pierwszą interakcję ze stroną, natomiast INP uwzględnia je wszystkie. Ocenia nie tylko „pierwsze wrażenie”, dzięki czemu wynik dotyczący responsywności jest bardziej wiarygodny.
- CLS (Cumulative Layout Shift) – stabilność wizualna
W tym wypadku mówimy o wszelkich przesunięciach treści na stronie internetowej. Na przykład zmianie jej układu podczas ładowania witryny, co w efekcie może doprowadzić do wykonania przez użytkownika niepożądanej dla niego akcji. Najczęściej to kliknięcie innego elementu niż zamierzał, ponieważ przyciski zmieniły swoje miejsce.
https://web.dev/vitals/
Stabilność wizualna powinna mieć wartość poniżej 0,1. Stronę z wynikiem powyżej 0,25 Google uzna za gorszą jakościowo od innych.
Inne wskaźniki internetowe – FCP, TTFB, TTI, TBT
Oprócz Core Web Vitals istnieją też inne metryki, na które warto spojrzeć. Ich wyniki często są powiązane zarówno z podstawowymi wskaźnikami, jak i mają wzajemny wpływ na siebie.
First Contentful Paint
Wskaźnik First Contentful Paint mierzy czas od rozpoczęcia ładowania strony do momentu, w którym renderowane są pierwsze elementy tekstowe i graficzne. To główna różnica między First Contentful Paint a Largest Contentful Paint – ta druga metryka pokazuje, ile czasu upłynęło do załadowania głównej zawartości strony ponad linią zanurzenia.
Renderowanie pierwszych elementów nie powinno trwać dłużej niż 1,8 sekundy.
Time to First Byte
Time to First Byte pokazuje, ile czasu potrzeba serwerowi, by odpowiedzieć na żądanie. Opóźnienia w czasie konfiguracji połączenia mają wpływ na First Contetful Paint i Largest Contentful Paint – czyli na czas ładowania pierwszych elementów tekstowych i graficznych oraz renderowanie największego elementu treści.
Dobrze by było, żeby TTFB wynosił 0,8 sekundy lub mniej, jednak nie jest to żelazna zasada. Warto zainteresować się tą metryką, gdy inne – ważniejsze wskaźniki (FCP i LCP) – mają słabsze wyniki.
Time to Interactive
Time to Interactive służy do pomiaru czasu responsywności strony. Daje więc informacje o tym, kiedy można realnie wejść w interakcje ze stroną. Strona internetowa wygląda na całkowicie załadowaną, widzimy np. przyciski, jednak po ich kliknięciu nie ma żadnej reakcji. Pozostaje nam czekać lub po prostu opuścić witrynę.
Problemem jest tutaj zwykle zablokowany główny wątek – a to spowodowane jest długim zadaniem, które wykonuje strona i nie ma możliwości, by go przerwać.
Czas interakcji na przeciętnym sprzęcie mobilnym nie powinien wynosić więcej niż 5 sekund. TTI najlepiej sprawdzać w audytach Lighthouse.
Total Blocking Time
Całkowity czas blokowania mierzy czas między załadowaniem pierwszych elementów na stronie (First Contentful Paint) a responsywnością strony (Time to Interactive), której główny wątek był zablokowany.
Porady ekspertki dotyczące CSS i JavaScript
Na co zwrócić uwagę pod względem JavaScript i CSS przygotowując się na optymalizację pod kątem Core Web Vitals? O to zapytałam osobę, która faktycznie zajmuje się programowaniem. Odpowiedzi otrzymałam od współtwórczyni SEMSTORM – Mileny Majchrzak.
Jak zadbać o poprawną optymalizację JavaScript?
W Core Web Vitals są trzy metryki, które musimy rozważyć.
Ze względu na LCP musimy zadbać o wszystkie te elementy, które wydłużają ładowanie strony. Z punktu widzenia JavaScript mogą to być:
- zbyt duże pliki JS,
- niepołączone pliki,
- fragmenty kodu blokujące rendering,
- umieszczenie wszystkich skryptów w sekcji head.
Ogólnie więc chodzi o to, aby po pierwsze – połączyć i scalić wiele plików w jeden, a także je zminimalizować. Dla stron, które mocno wykorzystują JS, mogą to być istotne usprawnienia. Połączenie plików natomiast powoduje, że zapytań do serwera idzie znacznie mniej, a więc całość jest szybciej renderowana.
Z drugiej strony najlepiej umieszczać tylko krytyczne skrypty na górze strony. Krytyczne, czyli takie, od których zależy logika serwisu. Wszystkie pozostałe – warto dodać na samym dole. W ten sposób ładują się już po pierwszych obrazkach czy innych multimediach, a więc nie wpływają negatywnie na wynik LCP.
Korzystne będzie też zoptymalizowanie elementów, które blokują renderowanie. Przede wszystkim (dla niektórych skryptów) należy rozważyć atrybuty async lub defer. Także JavaScript typu inline blokuje renderowanie.
Jeśli mamy problem z opóźnieniem reakcji strony, to musimy rozważyć dwa podstawowe scenariusze.
Po pierwsze opóźnienie może mieć miejsce, bo przeglądarka jeszcze nie „poradziła” sobie ze skryptami wczytywanymi podczas ładowania strony (np. tymi blokującymi renderowanie). Wtedy postępujemy dokładnie tak samo, jak poprzednio.
Istnieje jednak drugi element, który wpływa na INP – masywne event listenery, czyli fragmenty kodu, które „przyczepiają” się do linków, pól formularzy itd. i wykonują duże obliczenia.
Czasem dzieje się to nieumyślnie – np. developer, zamiast podłączyć listener do zbioru konkretnych linków, przyczepia go do wszystkich i przeliczenia (np. stylów czy animacji) są wtedy znacznie mniej wydajne.
Ogólna optymalizacja może polegać na:
- zmniejszeniu zbioru, do jakiego podczepiamy listener,
- zastosowaniu innych metod (np. dla animacji – CSS-ów, a nie JavaScript),
- ogólna optymalizacja kodu.
Mówiąc o JavaScript, nie możemy także zapomnieć o CLS. Dla przykładu tzw. layout shift wyzwalają nieumiejętne animacje elementów. Manual Core Web Vitals sugeruje w takim przypadku użycie CSS transform zamiast innych metod.
Również dynamicznie ładowana treść może generować layout shift, a także opóźnienie interakcji. W przypadku CLS, jeśli to możliwe – warto rezerwować uprzednio miejsce o określonych z góry wymiarach, a dopiero potem ładować skryptem tekst lub multimedia. Z punktu widzenia INP zadbaj o tzw. zwrotne zdarzenie. Np. jeśli wywołanie ajaxowe bardzo ingeruje w DOM lub wymaga skomplikowanych przeliczeń możesz podzielić zadania na część krytyczną i niekrytyczną Następnie wywołaj niekrytyczną w następnej klatce.
Co poprawić w kwestii CSS, aby zobaczyć efekty pod względem Core Web Vitals?
I tu także musimy podzielić odpowiedź na poszczególne metryki, z wyłączeniem INP, na który nie ma wpływu.
Jeśli weźmiemy pod uwagę INP, to podobnie jak w przypadku JavaScript – warto tutaj zadbać o takie elementy jak minifikacja i połączenie wielu plików w jeden.
Natomiast jeśli chodzi o CLS, to:
- W przypadku animacji CSS lepiej używać
transformniż ustawiaćwidth,heightczyposition. - Zamiast dodawać obrazkom i innym multimediom rozmiary przez CSS, to tam, gdzie możliwe warto zastosować atrybuty
widthiheight. Podobnie jest z reklamami czy iframe. - Dodać odpowiednie dyrektywy dla fontów (np.
<link rel=preload>).
Jak poprawić jakość strony internetowej – kilka kroków na start
Ustal priorytety
Przebadaj odpowiednio swoją stronę internetową w poszukiwaniu błędów i elementów do poprawy. W pierwszej kolejności możesz zająć się ekranem above the fold, ponieważ to właśnie on ma kluczowy wpływ na ocenę poszczególnych wskaźników.