Zrozum, co każda miara ci mówi
Largest Contentful Paint, czyli LCP, mierzy moment wyrenderowania największego obrazu lub bloku tekstu w początkowym widoku. Interaction to Next Paint, czyli INP, mierzy responsywność wizyty przez jej najwolniejszą kwalifikującą się interakcję. Cumulative Layout Shift, czyli CLS, mierzy nieoczekiwane widoczne przesunięcia w trakcie wizyty.
Opublikowane przez Google cele doświadczenia to: LCP równe lub poniżej 2,5 sekundy, INP równe lub poniżej 200 milisekund oraz CLS równe lub poniżej 0,1. Oceniaj je na 75. percentylu ładowań strony, oddzielnie dla urządzeń mobilnych i desktopów. Używaj tych celów, aby skoncentrować pracę, a nie jako gwarancji rankingu czy powodu do ignorowania wolniejszych użytkowników.
Główna zawartość pojawia się późno; sprawdź serwer, wykrywanie zasobów, pobieranie i ścieżkę renderowania.
Kliknięcie, dotknięcie lub naciśnięcie klawisza czeka zbyt długo na wizualną odpowiedź; źródłem może być osadzona ramka.
Zawartość przesuwa się nieoczekiwanie; zwróć szczególną uwagę na przesunięcia w pobliżu kontrolek, formularzy i pozycji czytania.
Niech dane z pola ustalą priorytet, a testy laboratoryjne go wyjaśnią
Dane z pola pochodzą z rzeczywistych wizyt, obejmujących prawdziwe urządzenia, sieci, lokalizacje, stany pamięci podręcznej i zachowanie. Dane z Chrome User Experience Report pojawiają się w PageSpeed Insights i Search Console, gdy jest wystarczająca ilość danych. Własne monitorowanie rzeczywistych użytkowników może dodać kontekst widoków stron; zbieraj tylko niezbędną telemetrię i unikaj treści wprowadzanych przez klientów.
Dane laboratoryjne to powtarzalny test w wybranych warunkach. Są przydatne do izolowania zmiany w wydaniu i odczytywania śladu (trace), ale nie mogą reprezentować każdego odwiedzającego. Lighthouse nie może zmierzyć prawdziwego INP bez rzeczywistej interakcji, więc jego Total Blocking Time jest diagnostycznym zamiennikiem. Gdy wyniki się różnią, użyj danych z pola do ustalenia priorytetu, a danych labowych do dochodzenia przyczyny.
Zapisz, czy dane dotyczą poziomu URL-a czy domeny (origin) oraz czy są dla mobilnych czy desktopowych.
Zapisz datę, grupę stron, urządzenie, rozkład, ustawienia testu i ostatnie wydania razem z bazą odniesienia.
Priorytetyzacja według zasięgu, szkody w zadaniu, dowodów i odwracalności
Nie zaczynaj od najniższego numeru w pulpicie. Uszereguj kandydatów według liczby dotkniętych wizyt, ważności zadania odwiedzającego, powtarzalności w szablonie oraz tego, czy zmiana może być odizolowana i wycofana. To czyni optymalizację Core Web Vitals działaniem operacyjnym zamiast pogoń za wynikiem.
Brakujący wymiar obrazu w udostępnionym szablonie może być lepszą pierwszą zmianą niż spekulatywna przebudowa front-endu. Mniej powszechna interakcja w koszyku może mieć wyższy priorytet, jeśli blokuje dokonanie zakupu. Łącz dowody z metryk z opiniami z pomocy technicznej, obserwacją lejków i przeglądem dostępności.
Powtarzające się problemy zaobserwowane w polu na ważnych szablonach z jasnym, niskoryzykownym środkiem zaradczym.
Pomysły architektoniczne bez zmierzonego problemu użytkownika lub ścieżki wycofania; zachowaj je jako hipotezy.
Napraw LCP, skracając ścieżkę do głównej zawartości
Zidentyfikuj element LCP dla danej grupy stron i urządzeń. Zbadaj początkową odpowiedź HTML, kiedy przeglądarka odkrywa element, ile czasu zajmuje pobranie jego zasobu i co blokuje renderowanie. Wysoki czas odpowiedzi serwera (TTFB) może uczynić osiągnięcie celu LCP nierealistycznym nawet przy dobrze zoptymalizowanym zasobie hero.
Utrzymuj odkrywalność głównej zawartości na wczesnym etapie, gdy pasuje to do projektu. Nie stosuj leniwego ładowania (lazy-loading) dla obrazu, który jest elementem LCP. Dla stron opartych na obrazach użyj odpowiednio dobranego rozmiaru i formatu pliku z jawnie określonymi wymiarami. Testuj preloady i reguły dostarczania: wczesne żądanie ma sens tylko wtedy, gdy nie konkuruje z ważniejszą pracą.
Sprawdź przekierowania, pracę serwera, zachowanie pamięci podręcznej i bliskość dostawy; może to wymagać zaangażowania właściciela aplikacji lub hostingu.
Sprawdź, czy renderowanie po stronie klienta, skrypty lub CSS opóźniają wykrycie głównego tekstu lub obrazu.
Spraw, by interakcje były responsywne, a układy przewidywalne
Dla INP odtwórz powolny przebieg w śladzie przeglądarki. Rozdziel opóźnienie wejścia, przetwarzanie zdarzeń i opóźnienie prezentacji. Długie zadania głównego wątku, ciężkie obsługiwacze, kosztowne renderowanie i częste przeliczanie układu (layout thrashing) mogą każdy opóźniać następne renderowanie. Wykonuj pracę wizualną potrzebną do kolejnej klatki w pierwszej kolejności; odłóż nieistotne zapisy, analitykę lub aktualizacje poboczne tam, gdzie wymagania produktu na to pozwalają.
Dla CLS znajdź poruszające się elementy zamiast zgadywać na podstawie sumy. Zarezerwuj miejsce dla obrazów, wideo, reklam, osadzonych treści i ramek za pomocą wymiarów lub CSS-owego współczynnika proporcji. Sprawdź ładowanie fontów i wstrzykiwaną zawartość. Nie ukrywaj koniecznego komunikatu zgody, błędu lub informacji o dostępności tylko po to, by polepszyć wynik; nadaj temu stabilną lokalizację.
Odkładanie pracy może zmienić czasowanie aplikacji. Przetestuj regresje stanu, walidacji i zachowania klawiatury.
Przewiń przez obszary ładowane leniwie i osadzone; test tylko podczas ładowania może przeoczyć późniejsze przesunięcia.
Wdrażaj ulepszenia bezpiecznie i potwierdzaj je
Zmiany wydajności mogą wpływać na skrypty, cache, renderowanie, osadzenia lub konfigurację dostarczania. Etapuj zmianę, porównaj zdefiniowaną ścieżkę testową z bazą odniesienia i udokumentuj instrukcję wycofania. Dla płatności, konta lub przepływów regulowanych zaangażuj odpowiednich recenzentów ds. bezpieczeństwa, zgodności i dostępności przed zmianą embedów, walidacji lub obsługi danych. To jest wskazówka edukacyjna, a nie ocena zgodności.
Po wydaniu porównaj tę samą ścieżkę laboratoryjną i obserwuj porównywalne segmenty z pola przez ich normalne okno raportowania. Sprawdź niezamierzone efekty, takie jak ukryty błąd lub nieczytelny interfejs. Status Is UP wspiera proaktywne optymalizowanie dostępności przez cykliczne kontrole, jasne przypisanie właścicieli naprawy i gotowość do wycofania między incydentami.
Powiąż każdą zmianę z grupą stron, metryką, właścicielem, dowodem testowym, kompromisem i instrukcją wycofania.
Nie ogłaszaj sukcesu po jednym syntetycznym przebiegu; potwierdź właściwy wzorzec rzeczywistych użytkowników.