Zacznij od ścieżek, a nie od średniej dla całej witryny
Wypisz trzy do pięciu ścieżek, gdzie opóźnienie ma wyraźny koszt dla klienta lub operacji: wejście na stronę kampanii, znalezienie produktu, wysłanie formularza kontaktowego, logowanie się lub zakończenie zgłoszenia do wsparcia. Dla każdej opisz początek, użyteczny rezultat, główną klasę urządzenia oraz stronę lub interakcję, która musi działać dobrze.
Nadaj każdej ścieżce własny wiersz budżetu. Panel może zawierać więcej kodu niż publiczny artykuł, ale jego akcja filtrowania potrzebuje celu responsywności. Strona bogata w media może akceptować większe obrazy, ale potrzebuje limitu dla głównego widocznego obrazu. To zapobiega zniknięciu krytycznej ścieżki w uśrednieniu dla całego źródła.
Nazwij, co odwiedzający może zobaczyć lub zrobić, na przykład przeczytać ofertę, zobaczyć wynik lub otrzymać potwierdzenie formularza.
Cache’owanie może istotnie zmienić koszt zasobów, więc zapisz, czy budżet dotyczy pierwszej wizyty, wizyty powtarzanej, czy obu.
Wybierz wyniki i kontrolowalne wejścia
Używaj zarówno metryk wynikowych, jak i ograniczeń wejściowych. Google opisuje Largest Contentful Paint (LCP) jako miarę ładowania; Interaction to Next Paint (INP) jako responsywność interakcji; i Cumulative Layout Shift (CLS) jako stabilność wizualną. Zalecane wartości uznane za dobre 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 dla 75. percentyla, rozpatrywane oddzielnie dla mobilnych i desktopowych.
Dodaj limity, które wcześnie ujawnią przyczynę: początkowy JavaScript, obrazy potrzebne przed główną treścią, całkowity transfer dla ścieżki, żądania zewnętrzne oraz znany kosztowny widget. Śledź skompresowane rozmiary transferu konsekwentnie. Diagnostyka taka jak Time to First Byte może pomóc w badaniu powolnego ładowania, ale sama w sobie nie jest wynikiem ważnym dla klienta.
Użyj LCP, gdy ścieżka zależy od pojawienia się głównej treści.
Użyj polowych danych INP dla wyszukiwania, filtrowania, menu i realizacji, a proxy laboratoryjne tylko przed pojawieniem się danych polowych.
Ogranicz początkową trasę i największych sprawców, aby właściciele wiedzieli, co musi się zmienić po przekroczeniu limitu.
Ustal liczby na podstawie Twojej bazy
Zrób bazowe pomiary dla każdej ścieżki. W PageSpeed Insights rozróżnij dane polowe Chrome User Experience Report (CrUX), które agregują doświadczenia rzeczywistych użytkowników Chrome, od danych laboratoryjnych Lighthouse, które są testem kontrolowanym. Dane polowe sprawdzają doświadczenie docierające do użytkowników; testy laboratoryjne czynią zmianę powtarzalną przed wydaniem.
Segmentuj przynajmniej według mobilnych i desktopowych oraz, jeśli to możliwe, według krytycznego szablonu lub URL. PageSpeed Insights może przejść z danych URL do danych origin, a niektóre strony nie mają danych CrUX. Oznacz taki przypadek jako bazę laboratoryjną i dodaj pomiar real-user dla istotnych ścieżek. Zachowuj URL testu, profil urządzenia i sieci, stan cache, datę i wersję narzędzia przy każdej bazie.
Wybierz cel, który poprawi bazę w zaplanowanym kroku, a następnie przetestuj go w reprezentatywnych warunkach. Budżet, który blokuje normalne wydania, zostanie obchodzony; taki wyższy niż obecne doświadczenie nie chroni nikogo.
75. percentyl to wartość, poniżej lub równa której znajduje się 75% zaobserwowanych doświadczeń; to nie jest średnia.
Uczyń budżet regułą wydania
Przechowuj budżet w wersjonowanym, przeglądalnym miejscu obok kodu lub listy kontrolnej wydania. Każdy wiersz potrzebuje ścieżki, metryki, profilu testu lub populacji, progu ostrzegawczego, progu błędu, właściciela, metody pomiaru i drogi wyjątku. MDN zaleca poziomy ostrzegawcze i błędów: ostrzeżenie wspiera proaktywne planowanie, podczas gdy błąd to górna granica z zauważalnym negatywnym skutkiem.
Automatyzuj rzetelne kontrole. Bundler może odrzucić zbyt duży asset lub punkt wejścia; webpack obsługuje maksymalne limity assetów i punktów wejścia oraz produkcyjne wskazówki błędów. Uruchamiaj powtarzalne testy laboratoryjne dla dotkniętej ścieżki w pull requestach lub kandydatach do wydania. Zachowuj metryki polowe do weryfikacji po wydaniu i priorytetyzacji zamiast zawodnej bramy builda.
Gdy limit zawiedzie, zmniejsz zasób, odłóż nieistotny kod, zmień doświadczenie, podziel wydanie lub zatwierdź wyjątek. Nie podnoś potajemnie progu, by przejść build.
Zapisz właściciela produktu i technicznego, wpływ na klienta, datę wygaśnięcia i zadanie naprawcze przed wydaniem.
Zablokuj powtarzalny próg błędu na chronionej ścieżce; powiadamiaj i zbadaj progi ostrzegawcze.
Weryfikuj i naprawiaj po uruchomieniu
Waga strony nie prognozuje pełnego doświadczenia. Kolejność żądań, blokujące renderowanie prace, możliwości urządzenia, warunki sieciowe, cache i zewnętrzni dostawcy również mają znaczenie. Zachowuj ograniczenia wejść, by wyłapać wzrosty, i miary wynikowe, by sprawdzić, czy ścieżka jest użyteczna. Interfejs W3C Resource Timing ujawnia timingi zasobów oraz rozmiary transferu, zakodowane i zdekodowane do głębszej diagnostyki. Szczegóły timingu cross-origin mogą być ograniczone przez timing permissions, więc niepełny waterfall nie dowodzi braku kosztu ze strony zewnętrznej.
Przeglądaj wyniki polowe po istotnych zmianach szablonu, platformy, tagów marketingowych lub ruchu. Jeśli LCP się pogorszy, sprawdź odpowiedź serwera, zasób LCP i prace blokujące renderowanie. Jeśli INP się pogorszy, przeanalizuj rzeczywiste interakcje; Lighthouse nie może zmierzyć INP, ponieważ nie ma wejścia użytkownika, choć Total Blocking Time jest proxy laboratoryjnym. Użyj proaktywnego procesu optymalizacji SIU, by triage’ować przekroczenie, ustabilizować ścieżkę krytyczną i zweryfikować poprawkę w tym samym kontekście pomiarowym.
Wygasłe wyjątki szybko ujawniają tymczasowe długi wydajnościowe, które stały się stałe.