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

Każda rozmowa o vitals kończy się tym samym pytaniem: która strona? Ten raport odpowiada na nie, trzymają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 robot zmierzył na każdym adresie URL 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 zcrawlowany adres URL niesie 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 jest testem na stole warsztatowym pod nimi.

Zakładka możliwości poprawy wypisuje, co znalazł audyt i ile warta jest naprawa – milisekundy przy zasobach blokujących renderowanie, podpowiedziach preconnect i czasie odpowiedzi serwera; kibibajty przy zbyt dużych obrazach, formatach nowej generacji, mediach poza ekranem, nieużywanym JavaScript, niezminifikowanym CSS i czasie życia pamięci podręcznej. Każdy wiersz niesie 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, krytyczne łańcuchy żądań, element odpowiedzialny za Largest Contentful Paint oraz elementy, które przesuwają się po renderowaniu. Każdy ma podany cel, poniżej którego powinien się mieścić, 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 niesie 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 powierzchnia 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 żyją 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 dostarcza powierzchnię 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ć.