Audyt strony internetowej i raporty Lighthouse: panel, w którym agencja pokazuje pracę techniczną

Każda rozmowa o Core Web Vitals kończy się tym samym pytaniem: która strona? Ten raport odpowiada na nie, zestawiając dwa pomiary obok siebie. Percentyl z danych terenowych to to, czego realnie doświadczyli odwiedzający – Largest Contentful Paint, Interaction to Next Paint i Cumulative Layout Shift w 75. percentylu, zestawione z własnymi progami dobrego i słabego wyniku od Google. Audyt laboratoryjny to to, co Lighthouse zmierzył na każdym adresie URL z listy w kontrolowanych warunkach, na żądanie, w dniu wdrożenia poprawki. Jedno mówi, czy witryna przechodzi test; drugie mówi, który szablon za to odpowiada.

Tabela audytowanych stron to miejsce, w którym to zestawienie staje się widoczne. Każdy audytowany adres URL ma swoje cztery wyniki obok własnego laboratoryjnego LCP i CLS, a pierścień ocen liczy, ile stron przechodzi bez zastrzeżeń, ile wymaga poprawy, a ile nie przechodzi – więc „strona wydaje się wolna” zamienia się w zlecenie pracy, które nazywa szablon, ruch za nim stojący i winną metrykę. Trendy na poziomie całej witryny i podział na urządzenia, które publikuje Google, mają swoje miejsce w raporcie Search Console; ta strona to test stanowiskowy pod nimi.

Zakładka możliwości poprawy wypisuje, co znalazł audyt i ile warta jest naprawa – milisekundy przy zasobach blokujących renderowanie i czasie odpowiedzi serwera; kibibajty przy dostarczaniu obrazów, nieużywanym JavaScript, niezminifikowanym CSS i czasie życia pamięci podręcznej. Każdy wiersz zawiera obszar, do którego należy, i wagę wyliczoną z rozmiaru oszczędności, więc wycenę dewelopera i priorytet agencji można argumentować tą samą listą, a nie dwoma różnymi eksportami.

Diagnostyka stoi obok jako wyjaśnienie, a nie kolejna lista zadań: rozmiar DOM, praca głównego wątku, czas wykonania JavaScript, liczba żądań, waga transferu oraz stojące za nimi pomiary laboratoryjne, takie jak First Contentful Paint, Largest Contentful Paint, Speed Index i Total Blocking Time. Każdy ma podany swój cel i proste zdanie o tym, dlaczego to ma znaczenie – zwykle to różnica między raportem, który klient przekazuje swojemu deweloperowi, a takim, który wraca z pytaniami.

Zautomatyzowane testy dostępności są pogrupowane tak, jak naprawdę wycenia się naprawę – według wpływu. Krytyczne ustalenia, takie jak nieopisane pola formularzy i obrazy bez tekstu alternatywnego, stoją osobno od poważnych, jak błędy kontrastu i linki bez nazwy, a te z kolei osobno od umiarkowanych, jak rozmiar obszarów dotykowych, kolejność nagłówków i kolejność fokusu. Każdy wiersz zawiera liczbę elementów, których dotyczy, więc wycena powstaje z liczb, a nie z niejasnej obietnicy poprawy dostępności.

Raport jest celowo szczery co do tego, co obejmuje zautomatyzowany przebieg. Te testy wyłapują ułamek barier, które znajduje ręczna kontrola, i raport mówi to wprost – co chroni agencję przed sytuacją, w której klient czyta czysty wynik jako certyfikat zgodności. Użyty dobrze, to najtańszy pierwszy przebieg, jaki istnieje: usuwa mechaniczne błędy, zostawia udokumentowany ślad tego, co i kiedy naprawiono, i zostawia ręcznej kontroli znacznie mniejszy obszar do przejrzenia.

Dziesięć testów crawlowania i znaczników działa jako lista zaliczone-niezaliczone, z jednym zdaniem opisującym, co znalazł crawler: elementy tytułu, opisy meta, linki możliwe do zcrawlowania, deklaracje kanoniczne, adnotacje hreflang, poprawny plik robots, atrybuty alt przy obrazach, czytelne rozmiary czcionek, odstępy między obszarami dotykowymi i poprawność danych strukturalnych. Nad tabelą stoi liczba zbiorcza, więc pierwsze, co widać, to ile z dziesięciu testów jest czystych, a ile to otwarta praca.

To jest audyt on-page, a nie raport indeksowania – to, co crawler potrafi odczytać na stronie, a nie to, co Google zdecydował się zachować. Te dwa pytania są różne i mają różne miejsce; dlatego pokrycie, zapytania i wyświetlenia znajdują się w raporcie Search Console, a ta strona zostaje przy znacznikach. Czytanie obu razem to typowy wzorzec: najpierw napraw to, co zgłasza tutejszy audyt, potem obserwuj przez kolejne tygodnie, jak reaguje pokrycie i pozycja.

Każdy audyt jest ograniczony do jednego klienta przez przełącznik w przestrzeni roboczej i prezentowany w barwach Twojej agencji, więc ta sama struktura obsługuje przegląd styczniowy i czerwcowy. Wyniki, vitals, możliwości, diagnostyka, dostępność i kontrole techniczne zachowują swoje miejsca między zleceniami, co zamienia porównanie miesiąc do miesiąca w czytanie tej samej sekcji dwa razy, zamiast godzenia dwóch inaczej zbudowanych dokumentów. Przestrzeń robocza daje miejsce do przeglądu; konfiguracja źródła danych pozostaje osobnym krokiem.

To właśnie powtarzalność zamienia pracę techniczną w coś, co klient przedłuża. Deweloper widzi uszeregowaną listę poprawek z szacowaną oszczędnością; opiekun klienta widzi cztery wyniki, jedną liczbę kondycji i strony za nią stojące – a obaj patrzą na ten sam raport. Zespoły spędzają czas na decydowaniu, co naprawić dalej, zamiast budować od nowa układ prezentacji, a audyt przestaje być zleceniem, którego nikt nie lubi pisać.