Lista naprawcza Core Web Vitals

Lista kontrolna: Naprawa Core Web Vitals. Ramy czasowe: jeden dzień roboczy na potwierdzenie zakresu i diagnozy; od jednego do dziesięciu dni roboczych na typową poprawkę i wdrożenie, w zależności od tego, czy przyczyna leży w zasobie, współdzielonym szablonie, skrypcie zewnętrznym, domenie czy CDN. Weryfikacja polowa odbywa się zgodnie z ruchomym 28-dniowym oknem danych i jest planowana osobno. Właściciel: inżynier wydajności lub starszy inżynier front-end jest odpowiedzialny. Lider SEO technicznego posiada kryteria akceptacji polowej; właściciele platformy, projektu, analityki i produktu zatwierdzają zmiany w swoich systemach.

Ta lista kontrolna zamienia zdiagnozowany problem wydajnościowy w wdrożoną, zweryfikowaną danymi polowymi poprawkę. Core Web Vitals to rzeczywiste miary Google dotyczące ładowania, responsywności i stabilności wizualnej: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) i Cumulative Layout Shift (CLS). Time to First Byte (TTFB) i First Contentful Paint (FCP) to wspomagające metryki diagnostyczne. Są uwzględnione, ponieważ wolna odpowiedź lub pusta strona pochłania czas dostępny na osiągnięcie dobrego LCP.

Dlaczego ta lista kontrolna i dlaczego tutaj

Ta lista kontrolna korzysta z rejestru naprawczego z audytu wydajności i Core Web Vitals . Ta wcześniejsza faza identyfikuje zawodzącą metrykę, dotknięty URL i szablon, bazowy poziom rzeczywistych użytkowników, powtarzalne warunki laboratoryjne, podejrzewaną przyczynę, priorytet i właściciela. Naprawa zaczyna się dopiero po ustaleniu tych danych. W przeciwnym razie deweloper zostaje poproszony o „przyspieszenie strony" i naturalnie zmieni to, co narzędzie podświetli jako pierwsze, niezależnie od tego, czy jest to przyczyną problemu polowego.

Diagnoza musi zawęzić problem na trzech poziomach przed podjęciem działań: która metryka, który szablon i który element lub zadanie. Niepowodzenie TTFB w całej domenie wymaga naprawy platformy; LCP, który zawodzi tylko na stronach artykułów, może wynikać z ich komponentu hero; INP po otwarciu filtra produktów może pochodzić z jednego handlera zdarzeń; CLS na stronach promocyjnych może wynikać z niezarezerwowanego banera. Traktowanie tych problemów jako jednego prowadzi do szerokich zmian i niejasnej odpowiedzialności.

Kolejność ma znaczenie przy naprawie. TTFB jest nadrzędny: dopóki nie nadejdzie pierwszy bajt odpowiedzi, przeglądarka nie może odkryć normalnych zasobów HTML ani wyrenderować treści strony. Jeśli TTFB jest słaby, napraw generowanie odpowiedzi, buforowanie, przekierowania i dostarczanie brzegowe, zanim skompresujesz obraz LCP. Gdy czas odpowiedzi mieści się w budżecie, pracuj dalej przez odkrywanie zasobów, pobieranie zasobów, renderowanie, interakcje i stabilność układu.

Pominięcie tej listy kontrolnej sprawia, że audyt pozostaje jedynie raportem. Wykonywanie jej przed diagnozą prowadzi do gonienia objawów: kompresowania obrazu, gdy dominuje późne odkrywanie, lub odraczania skryptów, gdy źródłem problemu jest wolna domena.

Wejścia i wyjścia

Wyjścia pozwalają przyszłemu właścicielowi odtworzyć problem, zidentyfikować, co zostało wdrożone, oraz odróżnić akceptację laboratoryjną od potwierdzenia polowego.

Lista kontrolna

Wykonaj punkty 1–4 przed zmianami na produkcji. Punkty 5–8 wdrażają poprawkę w kolejności zależności. Punkty 9–11 oddzielają natychmiastową akceptację wdrożeniową od weryfikacji polowej.

1. Zablokuj zawodzącą metrykę, szablon i element

Co: sprowadź ustalenie do jednej metryki, dotkniętego zestawu szablonów oraz nazwanego elementu, żądania, zadania lub zakresu serwera. Dlaczego: wynik ogólnostronowy nie identyfikuje wykonalnej pracy, a dwa URL-e mogą zawodzić z różnych powodów. Jak: połącz wartość p75 ze śladami i porównaj dotknięte i niezmienione szablony; nazwij element LCP i opóźnienie, interakcję INP i zadanie, element CLS i wyzwalacz lub ścieżkę żądania TTFB i stan pamięci podręcznej. Narzędzie: dane CrUX, ślad przeglądarki, wodospad, czasowanie serwera, inwentarz szablonów i tracker zgłoszeń. Gotowe, gdy: dowody potwierdzają „metryka X zawodzi na szablonie Y, ponieważ Z powoduje opóźnienie lub przesunięcie w warunkach C."

2. Potwierdź zakres za pomocą reprezentatywnych stron

Co: przetestuj ustalenie na typowym i najgorszym URL-u dla każdego zaangażowanego szablonu oraz jednej niezmienionej stronie kontrolnej. Dlaczego: naprawa jednej strony może ukryć współdzieloną wadę, podczas gdy globalna zmiana może być niepotrzebna, gdy jeden wariant treści powoduje problem. Jak: utrzymuj stałe warunki urządzenia, sieci, lokalizacji, zgody, logowania i pamięci podręcznej; porównaj użycie komponentów, wagę zasobów, czas odpowiedzi, aktywność stron trzecich i długość treści. Narzędzie: analityka, inwentarz szablonów, narzędzia wydajności przeglądarki, monitor żądań i macierz testowa. Gotowe, gdy: każdy szablon w zakresie jest oznaczony jako dotknięty lub kontrolny, każdy ma powtarzalne dowody, a zakres wdrożenia wskazuje komponent, trasę, rodzinę zasobów lub warstwę platformy, która musi się zmienić.

3. Ustal budżet i chroń wymagane zachowanie

Co: zdefiniuj liczbowy cel, ograniczenia regresji i funkcje, które muszą przetrwać. Dlaczego: „szybciej" nie ma granicy akceptacji, a usunięcie menedżera zgód, znacznika analitycznego, zachowania dostępności fokusu lub funkcji produktu może stworzyć mylące zaliczenie. Jak: ustaw cel na podstawie poniższej tabeli decyzyjnej, dodaj ostrzejszy wewnętrzny bufor, gdy powtarzane testy różnią się, oraz wymień krytyczne ścieżki i metryki nienależące do celu do ponownego przetestowania. Narzędzie: rejestr ustaleń, wymagania produktowe, plan analityczny, testy dostępności i budżet wydajności. Gotowe, gdy: zgłoszenie określa docelową metrykę i wartość, metodę akceptacji laboratoryjnej, metodę akceptacji polowej, chronione zachowania, dozwolone kompromisy, warunek wycofania i nazwanych zatwierdzających.

4. Sprawdź TTFB przed pracami front-endowymi

Co: zmierz TTFB w warunkach zimnej i gorącej pamięci podręcznej z lokalizacji istotnych dla odbiorców. Dlaczego: TTFB jest wliczany w każdy kolejny czas renderowania; praca front-endowa nie może odzyskać czasu już spędzonego na oczekiwaniu na HTML. Jak: podziel żądanie na DNS, połączenie, przekierowania, oczekiwanie CDN, obliczenia domeny, czas bazy danych lub zewnętrznego API oraz zachowanie strumieniowania, gdzie pozwala na to instrumentacja. Porównaj odpowiedzi z trafieniem i chybieniem w pamięci podręcznej i potwierdź, że personalizacja lub pliki cookie nie wyłączają nieoczekiwanie buforowania. Narzędzie: wodospad żądań, czasowanie serwera, logi CDN i domeny, profilowanie aplikacji i syntetyczne monitorowanie żądań. Gotowe, gdy: TTFB mieści się w uzgodnionym budżecie lub osobne blokujące ustalenie dotyczące platformy ma właściciela i jest zaplanowane. Nie rozpoczynaj dopracowywania LCP, dopóki słaby TTFB pozostaje niewyjaśniony.

5. Najpierw usuń opóźnienia serwera i dostarczania

Co: skoryguj wolną odpowiedź domeny, chybienia w pamięci podręcznej, przekierowania lub odległe dostarczanie. Dlaczego: te przyczyny opóźniają każdy element i często dotyczą wielu szablonów. Jak: usuń zbędne przekierowania; buforuj bezpieczny HTML i dane; zredukuj powolne zapytania do bazy danych lub API; przenieś pracę poza ścieżkę krytyczną; dostrój routing CDN i klucze pamięci podręcznej. Nigdy nie buforuj prywatnych odpowiedzi bez zatwierdzonego projektu. Narzędzie: profiler aplikacji, ślady zapytań, konfiguracja CDN, nagłówki odpowiedzi, monitorowanie i testowanie obciążenia. Gotowe, gdy: powtarzane testy zimne i gorące spełniają budżet, warianty pamięci podręcznej pozostają poprawne, błędy nie ulegają regresji, a priorytetowe URL-e zwracają zamierzoną odpowiedź bez dodatkowego przeskoku.

6. Napraw opóźnienie wykrywania, transferu i renderowania LCP

Co: skróć czas Largest Contentful Paint , czyli moment renderowania największego widocznego obrazu lub bloku tekstu. Dlaczego: zbyt duże hero są powszechne, ale późne wykrywanie, niski priorytet, blokujący CSS, JavaScript lub czcionki mogą dominować. Jak: serwuj prawidłowo dobrany responsywny obraz; nie leniwie ładuj zasobu LCP znajdującego się nad zakładką; udostępnij go w początkowym HTML; nadaj priorytet lub preloaduj tylko z dowodami; usuń blokowanie renderowania; używaj subsettowanych, buforowalnych czcionek z odpowiednim fallbackiem. Narzędzie: podział LCP, wodospad, inspekcja obrazów, raport pokrycia, ślad i porównanie wizualne. Gotowe, gdy: zamierzony element LCP jest spójny, jego dominujące opóźnienie spada, reprezentatywne strony spełniają budżet, a przepustowość, widoczność tekstu i renderowanie nie ulegają regresji.

7. Napraw INP w odpowiedzialnej interakcji

Co: zmniejsz opóźnienie interakcji odpowiedzialnej za słaby Interaction to Next Paint , czyli metrykę responsywności. Dlaczego: usuwanie arbitralnego JavaScriptu może nie dotknąć wolnego zdarzenia. Jak: oddziel opóźnienie wejścia, przetwarzania i prezentacji; przerwij długie zadania; usuń synchroniczną pracę; odłóż nieistotne skrypty zewnętrzne; unikaj wielokrotnego układu; zmniejsz przerenderowania; i ustępuj na rzecz malowania. Testuj na realistycznym sprzęcie z produkcyjnymi skryptami zewnętrznymi. Narzędzie: ślad interakcji, profil głównego wątku, wpisy długich zadań, profiler frameworka i realistyczne urządzenie. Gotowe, gdy: krytyczne interakcje działają, odpowiedzialne zadanie spełnia budżet powtarzalnego testu, zastępnik polowy jest udokumentowany, a zachowanie analityki, zgód, klawiatury i czytników ekranu nie ulega regresji.

8. Napraw CLS, rezerwując końcowy układ

Co: zapobiegaj przesunięciom przyczyniającym się do Cumulative Layout Shift , czyli wskaźnika niestabilności wizualnej. Dlaczego: obrazy, czcionki, reklamy, banery, elementy osadzone i komponenty asynchroniczne mogą przesuwać interfejs. Jak: ustaw wymiary nieodłączne lub aspect-ratio; zarezerwuj miejsca dla modułów dynamicznych; używaj kompatybilnych fallbacków czcionek; animuj za pomocą transformacji. Narzędzie: regiony przesunięcia układu, ślad, filmstrip, wizualne testy regresji i ograniczona przeglądarka. Gotowe, gdy: każde istotne skupisko przesunięć ma nazwane źródło, strony spełniają budżet CLS podczas ładowania i krytycznych interakcji, a zarezerwowana przestrzeń nie zasłania żadnych elementów sterujących.

9. Przetestuj ponownie cały zestaw metryk i chronione ścieżki

Co: porównaj kandydata do wdrożenia z zamrożoną bazą w identycznych warunkach, a następnie przetestuj na produkcji. Dlaczego: poprawa jednej metryki może zaszkodzić innej: odroczenie JavaScriptu może poprawić LCP, ale pogorszyć pierwszą interakcję, a agresywna zmiana czcionki może poprawić czas malowania, ale stworzyć przesunięcie układu. Jak: wykonaj kilka kontrolowanych próbek, porównaj zadeklarowaną statystykę, a nie najlepszy przebieg, przejrzyj ślady, przetestuj chronione ścieżki, zweryfikuj poprawność odpowiedzi oraz przetestuj dotknięte i kontrolne szablony. Narzędzie: Lighthouse lub równoważne narzędzie laboratoryjne, narzędzia wydajności przeglądarki, monitor żądań, testy wizualne i funkcjonalne oraz lista kontrolna wdrożenia. Gotowe, gdy: docelowa metryka spełnia budżet laboratoryjny zgodnie z zadeklarowaną metodą powtarzalnego przebiegu, TTFB/FCP/LCP/INP/CLS nie wykazują krytycznej regresji, chronione zachowanie przechodzi, produkcja serwuje zamierzoną zmianę, a wycofanie nie jest uruchomione.

10. Oznacz wdrożenie adnotacją i zaplanuj przegląd polowy

Co: zapisz znacznik czasu wdrożenia, zmieniony zakres, docelową metrykę, oczekiwany kierunek i daty przeglądu polowego. Dlaczego: CrUX używa ruchomego 28-dniowego okna, więc doświadczenia sprzed wdrożenia pozostają w raportowanym p75 po wdrożeniu. Bez adnotacji zespół może zbyt wcześnie uznać dobrą poprawkę za nieskuteczną lub późniejsze zmiany przypisać niewłaściwemu wdrożeniu. Jak: dołącz wersję produkcyjną do ustalenia, natychmiast sprawdź błędy, zapisz wczesne odczyty polowe bez traktowania ich jako ostateczne i zaplanuj właściciela do przeglądu odpowiednio odświeżonego okna. Narzędzie: dziennik wdrożeń, tracker zgłoszeń, CrUX, AmICited Web Vitals i monitorowanie. Gotowe, gdy: zgłoszenie jest oznaczone jako Zaakceptowane laboratoryjnie, adnotacja wdrożeniowa i natychmiastowe dowody są dołączone, a nazwany właściciel i data kalendarzowa istnieją dla weryfikacji polowej.

11. Zweryfikuj na podstawie danych polowych i zamknij lub otwórz ponownie

Co: porównaj dane polowe p75 po odpowiednim odświeżeniu ruchomego okna. Dlaczego: rzeczywiste urządzenia użytkowników, sieci, geografia, zachowanie pamięci podręcznej, stany zgody i interakcje nie mogą być odwzorowane przez jeden przebieg laboratoryjny. Jak: użyj tego samego poziomu CrUX — URL lub domena — tej samej metryki i porównywalnego zakresu odbiorców; uwzględnij częściowe wdrożenie i inne wydania; sprawdź reprezentantów szablonów, nie polegając wyłącznie na zagregowanej domenie. Jeśli wynik nie spełnia celu, porównaj bieżący ślad z oryginalnym opisem przyczyny i otwórz ponownie diagnozę, zamiast dodawać niepowiązane poprawki. Narzędzie: AmICited Web Vitals, historia CrUX, adnotacje wdrożeniowe, segmenty analityczne i pakiet dowodowy. Gotowe, gdy: cel spełnia uzgodniony próg p75 i zakres z odnotowanymi ograniczeniami — wtedy status zmienia się na Zweryfikowane polowo; lub zgłoszenie zostaje wyraźnie otwarte ponownie z nowymi dowodami, właścicielem i kolejną hipotezą.

Narzędzia w AmICited

Otwórz AmICited Web Vitals , aby wyświetlić LCP, INP, CLS, FCP i TTFB z CrUX dla swojej domeny i śledzonych konkurentów. Użyj go podczas diagnozy, aby przechwycić bazę polową, oraz po wdrożeniu, aby zweryfikować zmienny wynik polowy. Pusta wartość oznacza niewystarczające kwalifikowane dane polowe, a nie zero ani zaliczenie. Widok produktu wspiera ocenę; ślady, czasowanie serwera i profile przeglądarki wciąż identyfikują przyczynę.

Użyj Performance Impact , aby połączyć dowody wydajności na poziomie strony z pozycją cytowania i zidentyfikować wartościowe wolne strony. To powiązanie pomaga w ustalaniu priorytetów napraw, ale nie dowodzi, że sama wydajność spowodowała określony wynik cytowania. Zachowaj kontekst trafności, treści, autorytetu i wdrożenia podczas interpretowania zmian.

Aby zapoznać się z przepływem pracy w produkcie, postępuj zgodnie z instrukcją Jak sprawdzić swoje Core Web Vitals w AmICited . Samouczek wyjaśnia, gdzie pojawiają się metryki i jak działają porównania z konkurencją; ta lista kontrolna reguluje diagnozę, implementację i akceptację.

Zasady decyzyjne: co oznacza wynik zły

Używaj 75. percentyla, w skrócie p75, dla decyzji polowych: 75% kwalifikowanych zarejestrowanych doświadczeń jest na tej wartości lub poniżej. Wartość graniczna należy do lepszego pasma. LCP, INP i CLS określają status Core Web Vitals; TTFB i FCP to miary wspomagające używane do szeregowania i diagnozowania pracy.

Stosuj te zasady w kolejności:

1. Limit czasu, błąd serwera, nieprawidłowa odpowiedź lub przerwana krytyczna ścieżka blokują wdrożenie niezależnie od wyniku metryki.
2. Słaby TTFB jest nadrzędny względem LCP i jest naprawiany jako pierwszy. Nie twórz rozwiązania opartego wyłącznie na obrazie, gdy serwer już pochłonął większość budżetu malowania.
3. Słabe metryki polowe mają wyższy priorytet niż metryki wymagające poprawy. W obrębie jednego pasma priorytetyzuj współdzielone przyczyny szablonowe, ruch i krytyczne ścieżki biznesowe.
4. Pusta wartość polowa na poziomie URL-a jest nieznana. Używaj dowodów laboratoryjnych i udokumentowanego zastępnika, ale nie zmieniaj etykiety z nieznane na dobre.
5. Jeden przechodzący przebieg laboratoryjny to za mało. Zadeklaruj profil urządzenia/sieci i metodę powtarzalnego przebiegu przed testowaniem.
6. Poprawka jest Zaakceptowana laboratoryjnie, gdy wdrożone zachowanie i testy kontrolowane przechodzą. Jest Zweryfikowana polowo dopiero po tym, jak porównywalne zmienne dane polowe spełnią uzgodniony próg.
7. Jeśli dane domeny przechodzą, ale szablon o wysokim ruchu zawodzi, wynik szablonu jest wiążący dla tego zakresu. Agregacja nie może wymazać skoncentrowanego problemu użytkowników.

Produkt końcowy: pakiet naprawczy i weryfikacyjny

Przekaż jedno zgłoszenie lub wpis w rejestrze na źródło problemu, z zakresami podrzędnymi, gdy jedna przyczyna dotyka kilku szablonów. Użyj arkusza kalkulacyjnego, trackera zgłoszeń lub dokumentu inżynieryjnego, ale zachowaj następujące pola:

Identyfikator ustalenia i główna metryka:
Źródło polowe: URL | Domena
p75, pasmo i 28-dniowe okno:
Dotknięte szablony i reprezentatywne URL-e:
Szablon kontrolny i URL:
Element, interakcja, żądanie lub zakres serwera:
Opis przyczyny i linki do dowodów:
Profil laboratoryjny i baza powtarzalnego przebiegu:
Cel, ograniczenia i chronione ścieżki:
Wybrana naprawa i odrzucone alternatywy:
Właściciel inżynieryjny, zatwierdzający i zależności:
Identyfikator wdrożenia/wersji i znacznik czasu wdrożenia:
Natychmiastowe wyniki produkcyjne i laboratoryjne:
Właściciel przeglądu polowego CrUX i data:
Porównywalny wynik polowy i ograniczenia:
Próg monitorowania i reguła ponownego otwarcia:
Status: Otwarte | Wdrażane | Zaakceptowane laboratoryjnie | Zweryfikowane polowo | Ponownie otwarte | Zaakceptowane ryzyko

Dołącz ślady, wodospady, zakresy serwera, nagrania przesunięć, profile interakcji, wyniki testów i adnotację wdrożeniową. Zaakceptowane ryzyko wymaga zakresu, powodu, osoby zatwierdzającej, daty ważności i wyzwalacza monitorowania; nie jest zaliczeniem.

Pakiet jest zaakceptowany, gdy inny inżynier może odtworzyć oryginalny problem, zidentyfikować, dlaczego ta zmiana go rozwiązuje, potwierdzić, co trafiło na produkcję, i powtórzyć porównanie polowe bez pytania oryginalnego badacza o odtworzenie pracy.

Co może pójść źle

Optymalizacja przed wyizolowaniem przyczyny. Generyczna kompresja i usuwanie skryptów zastępują diagnozę. Najpierw wymagaj dowodów na metrykę-szablon-element.

Kompresowanie hero, gdy domena jest wolna. Mniejszy obraz nie może się wyrenderować, zanim nadejdzie HTML. Najpierw zmierz i napraw TTFB, gdy przekracza budżet.

Naprawianie niewłaściwego przesunięcia. CLS może pochodzić z reklamy, banera zgody, czcionki, elementu osadzonego lub hydratowanego komponentu. Nazwij źródło przesunięcia.

Odraczanie każdego skryptu. Bezładne odraczanie może zepsuć kolejność zgód, analitykę, nawigację, formularze lub pierwszą interakcję. Zmień odpowiedzialną ścieżkę wykonania i przetestuj regresyjnie wymagane zachowanie.

Weryfikacja jednego URL-a po wdrożeniu współdzielonego szablonu. Wybrany przykład może przechodzić, podczas gdy cięższy wariant treści lub inna konfiguracja komponentu wciąż zawodzi. Testuj typowe, rozbudowane i kontrolne strony.

Odczyt danych na poziomie domeny jako zaliczenia szablonu. Zdrowe strony o dużym ruchu mogą maskować słaby szablon kategorii, artykułu lub produktu. Utrzymuj diagnozę i akceptację na najwęższym wiarygodnym zakresie.

Zamykanie w dniu wdrożenia. Natychmiastowe testy ustanawiają akceptację laboratoryjną. Nie zastępują one ruchomego okna danych polowych.

Czekanie 28 dni na odkrycie zepsutego wdrożenia. Potwierdzenie polowe wymaga czasu, ale kody statusu, błędy, ścieżki, stabilność wizualna i kontrolowane metryki są sprawdzane natychmiast. Zmienne dane nie są wymówką do pominięcia kontroli jakości wdrożenia.

Następna faza: ciągłe monitorowanie i iteracja

Przekaż rejestr weryfikacji polowej, adnotację wdrożeniową, dotknięte szablony, ograniczenia i progi do [ciągłego odświeżania i iteracji](/seo-playbook/process/phases/continuous-refresh-and-iteration/. Potrzebuje on stabilnej bazy, aby późniejsze zmiany treści, mediów, szablonów, kampanii i zewnętrznych skryptów można było porównywać, a nie odkrywać na nowo jako niewyjaśnione zmiany.

Następny właściciel rejestruje, kto monitoruje każdy próg, gdzie znajdują się dowody, jak często są przeglądane i co ponownie otwiera naprawę. Nowa słaba metryka, powtarzający się trend wymagający poprawy w całkowicie odświeżonym oknie, zmieniony element LCP, nowa wolna interakcja lub wydanie szablonu, które zmienia zdiagnozowaną ścieżkę, powinny otworzyć listę kontrolną od punktu 1. Nie powtarzaj automatycznie poprzedniej poprawki: ta sama metryka może zawodzić z powodu innego elementu po przeprojektowaniu.

Przekazanie jest zakończone, gdy status polowy jest wyraźny, każde zaakceptowane ograniczenie ma właściciela i datę przeglądu, a monitorowanie może połączyć regresję z szablonem i wdrożeniem. Jeśli weryfikacja polowa pozostaje w toku, następny właściciel otrzymuje zaplanowaną datę przeglądu, a zgłoszenie pozostaje jako Zaakceptowane laboratoryjnie, a nie zamknięte.

FAQ

FAQ dotyczące naprawy Core Web Vitals