Podczas porównania CometWeb z konkurentami jedna z badanych stron osiągnęła LCP 13,3 sekundy i ocenę 71 punktów w Lighthouse. CometWeb miał LCP 5,8 sekundy, ale ogólną ocenę 69 punktów. Gdybym porównał tylko punktację, mógłbym uznać pierwszą witrynę za lepszą mimo wolniejszego wyświetlania głównej treści.
Ten przypadek pokazuje, dlaczego benchmark wymaga porównywania tych samych metryk i podobnych typów stron. Porównanie obejmuje cztery serwisy i 20 przebiegów Lighthouse. Omawiam również warunki pomiaru i ograniczenia interpretacji wyników.
Czym jest benchmark strony internetowej
Benchmark strony to pomiar twojej witryny i stałego zestawu porównywalnych stron tą samą metodą, w tych samych warunkach, z zapisem, jak go wykonano.
Użyteczny benchmark odpowiada na trzy pytania:
- gdzie jesteś w tyle;
- o ile;
- czy ta różnica ma znaczenie dla stron, które zarabiają.
Krok 1: Ustal, czemu benchmark ma służyć
Najpierw zapisz pytanie, bo benchmark bez decyzji na końcu kończy jako raport, którego nikt pewnie nie użyje, a może nawet nie przeczyta.
- „Dlaczego konkurenci wyprzedzają nas na główne frazy kategorii?” Porównuj strony, które rankują na te frazy.
- „Czy nasz koszyk jest wolniejszy niż rynek?” Porównuj odpowiadający krok zamówienia, na urządzeniu, którego używa większość kupujących.
- „Czy po przebudowie jest gorzej?” Najpierw porównaj się tą samą metodą z poprzednią wersją własnej strony, a z innymi dopiero potem.
Moje pytanie było celowo wąskie, bo chciałem wiedzieć, czy cometweb.io/website-audit technicznie odstaje od stron, które rankują na frazy „website audit”. A jeśli tak, to w czym?
Krok 2: Dobierz konkurentów z wyników wyszukiwania
Konkurenci z prezentacji sprzedażowej i konkurenci w wyszukiwarce to często różne firmy. Do benchmarku SEO albo wydajności weź od trzech do pięciu domen, które powtarzają się w pierwszej dziesiątce dla ważnych dla ciebie fraz.
Więcej stron dodaje tylko pracy, a przy mniejszej liczbie łatwo pomylić jedną nietypową stronę z rynkiem. Zestaw trzymaj bez zmian aż do ponownego testu, bo podmiana konkurenta między pomiarami odbiera sens trendom.
Jak wybrałem trzy strony
Dwie frazy, „free website audit tool” i „website audit”, odczytałem przez API wyszukiwania (Stany Zjednoczone, dziesięć wyników).
| Strona | „free website audit tool” | „website audit” | Decyzja |
|---|---|---|---|
| seoptimer.com | 2 | 2 | Wybrana; nie dało się jej zmierzyć |
| thehoth.com/seo-audit-tool | 3 | 5 | Zmierzona |
| seositecheckup.com | 5 | 7 | Zmierzona |
| rankmath.com/tools/seo-analyzer | 6 | 10 | Rezerwa; zmierzona |
| cometweb.io/website-audit | poza top 10 | poza top 10 | Nasza strona |
Wynik API wyszukiwania to migawka z jednej lokalizacji w jednej chwili, więc posłużył mi tylko do wyboru stron.
Wyznacz rezerwę, zanim zobaczysz pierwsze liczby
Mój pierwszy wybór, SEOptimer, nie wczytał się w oknie testu. Lighthouse pokazał pustą stronę (NO_FCP), a dwa pojedyncze żądania zwróciły HTTP 525, więc jego miejsce zajął zapasowy kandydat, Rank Math.
Rezerwę wyznacz przed pomiarem, bo kto wybiera zastępstwo po obejrzeniu pierwszych liczb, łatwo dobiera porównanie, które mu schlebia.
Krok 3: Porównuj strony o tym samym szablonie i celu
Stronę główną zestawiaj ze stroną główną, kartę produktu z kartą produktu.
| Twoja strona | Porównaj z | Dlaczego |
|---|---|---|
| Strona główna | Strony główne konkurentów | Ta sama rola: wejście w markę i nawigacja |
| Kategoria lub lista | Strona kategorii rankująca na tę samą frazę | Ta sama intencja i podobna gęstość treści |
| Produkt lub usługa | Porównywalna karta produktu lub usługi | Ten sam typ szablonu i rola w konwersji |
| Artykuł | Artykuł rankujący na tę samą frazę | Ta sama intencja wyszukiwania |
| Krok koszyka lub rejestracji | Odpowiadający mu krok | To samo zadanie, często najcenniejsze |
Jedna strona na szablon to próba z witryny i tak opisz wynik. Kolejne dodaj, gdy szablon mocno się różni, np. przy długich i krótkich kartach produktów.
U mnie zestaw wyznaczyły rankujące adresy, czyli dwie strony narzędzia do audytu i strona główna, która jest wejściem do narzędzia. Moim odpowiednikiem jest strona usługi pod tę samą intencję.
Krok 4: Porównuj dane terenowe, a laboratoryjnymi tłumacz różnicę
Wyniki wydajności są dwojakiego rodzaju, a mieszanie ich to najczęstszy błąd benchmarku.
Dane terenowe Chrome UX Report (CrUX) publikuje według dokumentacji CrUX API jako 28-dniową średnią kroczącą z 75. percentylem jako wartością główną. Według metodologii CrUX dane ma tylko strona publicznie dostępna dla wyszukiwarek i często odwiedzana, więc mniejsi konkurenci mogą ich nie mieć wcale.
Dane laboratoryjne opisują inne wczytanie niż to, którego doświadczyli użytkownicy (web.dev). Szerzej piszę o tym w tekście o różnicach między danymi laboratoryjnymi a CrUX.
Core Web Vitals porównuj na wartościach terenowych z 75. percentyla, osobno dla urządzeń mobilnych i komputerów. Według web.dev progi to LCP do 2,5 sekundy, INP do 200 milisekund i CLS, czyli przesunięcia układu podczas wczytywania, do 0,1.
INP, czyli czas reakcji strony na interakcję, od 2024 r. jest stabilnym Core Web Vital w miejsce FID. Lighthouse go nie zmierzy, bo w laboratoryjnym wczytaniu nikt nie klika, więc przybliżeniem jest Total Blocking Time (TBT), czyli łączny czas blokowania głównego wątku.
| Sytuacja | Co porównać | Czego nie robić |
|---|---|---|
| Obie strony mają dane CrUX | Wartości terenowe p75 dla każdej klasy urządzeń | Układać ranking po wyniku Lighthouse |
| Konkurent nie ma danych CrUX | Metryki laboratoryjne w identycznych ustawieniach, oznaczone jako laboratoryjne | Traktować brak danych jako zero albo jako „dobrze” |
| Trzeba wyjaśnić różnicę | Ślady laboratoryjne: zasoby, czas blokowania, największy element | Pokazywać pojedynczy przebieg jako doświadczenie użytkownika |
Mój przykład ma same dane laboratoryjne, bo CrUX API wymaga klucza Google Cloud, którego przy tym pomiarze nie miałem, więc w karcie pole danych terenowych mówi „niezmierzone”.
Krok 5: Ustaw testy laboratoryjne tak, żeby dało się je porównać
Według dokumentacji punktacji Lighthouse większość zmienności wyniku i metryk wynika ze zmieniających się warunków, a nie z samego Lighthouse: testów A/B, trasowania ruchu w sieci, innego komputera, rozszerzeń przeglądarki. Dlatego dokumentacja proponuje traktować wydajność jako rozkład.
Przewodnik projektu o zmienności dodaje, że mediana z pięciu przebiegów jest mniej więcej dwa razy stabilniejsza niż jeden przebieg. Ostrzega też przed zbieraniem kilku raportów naraz na tej samej maszynie.
W praktyce:
- Testuj każdą stronę z tej samej lokalizacji, z tym samym profilem urządzenia i ograniczeniem sieci.
- Uruchamiaj każdy test kilka razy, na przemian między stronami, i porównuj mediany. Najlepszy i najgorszy przebieg zostaw w kolumnie min–maks.
- Testuj wszystkie strony w tym samym oknie czasowym, bo skrypty zewnętrzne i reklamy zmieniają się w ciągu dnia.
- Porównuj metryki, które wyjaśniają różnicę, czyli LCP, TBT i CLS, bo wynik zbiorczy je miesza.
Jak to zmierzyłem
| Ustawienie | Wartość |
|---|---|
| Narzędzie | Lighthouse 13.5.0 (wagi wyniku jak w konfiguracji domyślnej), Chrome for Testing 153 z Playwrighta, bez interfejsu, nowy profil w każdym przebiegu |
| Urządzenie i sieć | Domyślny profil mobilny: emulacja Moto G Power, symulowane ograniczanie z RTT 150 ms, ok. 1,6 Mb/s i spowolnieniem CPU 4× 6 |
| Przebiegi | 5 na stronę, rundy przeplatane i obracane, 8 s przerwy po każdym |
| Okno | 24 września 2026 r., 07:11–07:17 UTC |
| Raportowana wartość | Mediana z minimum i maksimum |
Zmierzyłem cztery strony, moją /website-audit i trzy strony rankujące z kroku 2, po pięć przebiegów, razem 20. Wszystkie liczby są laboratoryjne, z jednej maszyny, jednej lokalizacji sieciowej i sześciu minut jednego poranka.
Mierzyłem jedną stronę z każdej witryny. Nie oceniałem, co znajdują te narzędzia do audytu ani jak są przydatne, i nie podaję pozycji w wyszukiwarce.
Jeden słaby punkt: przebiegi szły po kolei, ale na tej samej maszynie działały inne procesy. Wszystkie ograniczenia, w tym Chromium bez interfejsu i przerwany pierwszy pomiar, wymienia metodologia.
Krok 6: Porównaj mediany LCP z pięciu przebiegów
Mediany laboratoryjnego LCP czterech stron rozciągały się od 2,2 do 13,6 s, a moja była druga, 3,6 s za Rank Math (5,8 s wobec 2,2 s).
Moja strona ma też najwolniejszy First Contentful Paint (FCP, pierwsze pojawienie się treści) z czterech (3,8 s), choć następna jest tuż za nią z 3,7 s. Wrócę do tego w kroku 9.
Wynik 71 przy LCP 13,3 s, 69 przy 5,8 s
Strona The HOTH ładowała się w medianie 13,3 s i dostała wynik 71, a moja przy 5,8 s dostała 69. W wyniku zbiorczym tamta strona jest więc nieco przede mną, choć na LCP jest 7,4 sekundy za mną.
Skąd ta różnica? Tłumaczą ją wagi z dokumentacji punktacji Lighthouse.
Strona The HOTH maluje pierwszą treść po 1,7 s i prawie nie ma przesunięć układu, więc to, co zyskuje szybkim pierwszym malowaniem, mniej więcej równoważy stratę na późnym LCP. Obie strony mają różne problemy, a wynik ukrywa oba.
Rozrzut LCP sięgał 886 ms, więc licz mediany
Moja strona różniła się o 886 ms między najszybszym a najwolniejszym przebiegiem LCP (od 5475 do 6362 ms), a strona Rank Math tylko o 4 ms. SEO Site Checkup dostał wyniki 59, 60, 60, 69 i 60. W jednym przebiegu pierwsza treść pojawiła się po 1,4 s, a w pozostałych po ok. 3,7 s, i wynik skoczył o dziewięć punktów.
Jeden przebieg dałby 60 albo 69, zależnie od szczęścia. Mediana z pięciu mówi 60, a rozrzut mówi, na ile jej ufać.
Waga strony różniła się dziesięciokrotnie
Waga strony przy zimnym wczytaniu wahała się od 193 kB do 2024 kB. Według danych Lighthouse na stronach The HOTH i SEO Site Checkup originy zewnętrzne przesłały 72% i 84% bajtów, u mnie ok. 2%, a u Rank Math zero. „Zewnętrzne” to originy, których Lighthouse nie przypisuje do podmiotu strony, więc liczy się tu też własne narzędzie firmy osadzone z innej domeny.
Krok 7: Porównaj też SEO, dostępność i bezpieczeństwo
Każdy obszar porównuj kontrolami, które na każdej stronie znaczą to samo.
| Obszar | Porównywalne kontrole | Na co uważać |
|---|---|---|
| Wydajność | Terenowe p75 LCP, INP, CLS; laboratoryjne LCP i Total Blocking Time; przesłane bajty | Mieszanie wartości terenowych i laboratoryjnych w jednej kolumnie |
| Techniczne SEO | Indeksowalność porównywanej strony, canonical, title i description, dane strukturalne, linki wewnętrzne do niej | Liczenie problemów bez oceny, czy dotyczą strony, która rankuje |
| Dostępność | Automatyczne błędy na tych samych szablonach; ścieżka klawiaturą przez kluczowe zadanie | Uznawanie mniejszej liczby błędów automatycznych za zgodność z WCAG |
| Bezpieczeństwo | HTTPS i konfiguracja TLS, nagłówki bezpieczeństwa, mieszana zawartość | Ocenianie braku nagłówka tak samo jak podatności możliwej do wykorzystania |
| Waga strony i ślad węglowy | Przesłane bajty przy pierwszej wizycie; szacunek CO₂e tą samą metodą | Porównywanie szacunków z różnych modeli lub wersji |
W technicznym SEO wszystkie cztery strony zwróciły 200 przez HTTPS, były indeksowalne i wskazywały same siebie jako canonical. Wszystkie miały też dane strukturalne JSON-LD, a tytuły od 43 do 71 znaków.
Dwie strony miały po dwa <h1> w HTML-u z serwera, a jedna oblała audyt Lighthouse crawlable-anchors. Podstawy, od których zależy, czy strona może rankować, miały w porządku wszystkie cztery.
Dostępność sprawdziłem wyłącznie automatycznie. Lighthouse przyznał mojej stronie 100 punktów, a pozostałym 94, 85 i 95. Na trzech stronach wykrył problemy z kontrastem kolorów. Każdy audyt jest zaliczony albo nie (dokumentacja punktacji dostępności), a automatyczne wykrywanie znajduje tylko część problemów (konfiguracja Lighthouse). Zgodność z WCAG sprawdza dopiero test ręczny z klawiaturą i czytnikiem ekranu, a ten krok pominąłem, więc moje 100 znaczy tylko tyle, że automat nic nie znalazł. Pełny przegląd opisuje poradnik audytu dostępności.
Nagłówki bezpieczeństwa: zapisuj wartość każdego nagłówka
| Nagłówek (jedna odpowiedź, jedna strona) | CometWeb | The HOTH | SEO Site Checkup | Rank Math |
|---|---|---|---|---|
| Strict-Transport-Security | max-age=15552000 | max-age=31536000 | brak | max-age=31536000; includeSubDomains |
| Content-Security-Policy | tylko upgrade-insecure-requests | frame-ancestors 'self' | brak | brak |
| X-Content-Type-Options | nosniff | brak | brak | brak |
| X-Frame-Options | SAMEORIGIN | brak | brak | brak |
| Referrer-Policy | strict-origin-when-cross-origin | brak | brak | brak |
| Permissions-Policy | jest | brak | brak | brak |
Licząc nagłówki, moja strona „wygrywa” sześć do dwóch, ale to liczenie mi schlebia. Moje CSP (Content-Security-Policy, lista dozwolonych źródeł treści) zawiera tylko upgrade-insecure-requests. Według MDN ta dyrektywa tylko podnosi adresy HTTP do HTTPS, a to, jakie skrypty mogą się wykonać, zostaje bez ograniczeń.
Brak nagłówka pokazuje różnicę w konfiguracji, a podatność trzeba wykazać osobno, więc zapisuj wartości zamiast ptaszków. Własną politykę sprawdzisz w naszym narzędziu do CSP.
Krok 8: Zapisz benchmark tak, żeby dało się go powtórzyć
Prowadź jeden wiersz na stronę i pomiar, z tymi polami:
- data i okno czasowe;
- witryna i strona z nazwą szablonu;
- rodzaj danych: terenowe (np. CrUX z 28 dni dla
PHONE) albo laboratoryjne (np. Lighthouse z profilem mobilnym); - narzędzie z wersją i ustawieniami ograniczania;
- liczba przebiegów i raportowana wartość;
- metryki;
- pozostałe obszary: indeksowalność, cel canonical, automatyczne błędy dostępności, nagłówki bezpieczeństwa;
- pole niezmierzone, np. „brak danych CrUX dla tej domeny”, które nigdy nie zostaje puste.
Ostatnie pole jest najważniejsze, bo „niezmierzone” i „zmierzone jako dobre” to różne ustalenia, a pusta komórka zamienia jedno w drugie.
Wypełniona karta z mojego przykładu
Ustawienia są takie jak w sekcji „Jak to zmierzyłem”, czyli tylko dane laboratoryjne i mediana z pięciu przebiegów.
| Pole | CometWeb | The HOTH | SEO Site Checkup | Rank Math |
|---|---|---|---|---|
| Strona | /website-audit | /seo-audit-tool/ | strona główna | /tools/seo-analyzer/ |
| LCP (min–maks) | 5,8 s (5,5–6,4) | 13,3 s (12,9–13,3) | 13,6 s (13,4–13,8) | 2,2 s (2,2–2,2) |
| FCP | 3,8 s | 1,7 s | 3,7 s | 1,1 s |
| TBT / CLS | 0 ms / 0,000 | 67 ms / 0,003 | 175 ms / 0,021 | 0 ms / 0,000 |
| Wynik wydajności (min–maks) | 69 (67–72) | 71 (71–72) | 60 (59–69) | 99 (99–99) |
| Przesłane / zewnętrzne | 582 kB / 10 kB | 2024 kB / 1454 kB | 1736 kB / 1467 kB | 193 kB / 0 kB |
| Żądania | 64 | 66 | 94 | 23 |
| Indeksowalna, canonical | tak, własny | tak, własny | tak, własny | tak, własny |
| Dostępność (automatycznie) | 100, bez błędów | 94, 2 audyty | 85, 4 audyty | 95, 2 audyty |
| Nagłówki bezpieczeństwa (z 6) | 6 (słabe CSP) | 2 | 0 | 1 |
| Niezmierzone | Dane terenowe, INP, ścieżka klawiaturą, ręczny WCAG, TLS, inne szablony | jw. | jw. | jw. |
Pełną kartę, z każdą wartością nagłówka i typem danych strukturalnych, znajdziesz w benchmark-record.csv, a jej kolumny skopiuj do własnego benchmarku.
Krok 9: Zamień różnice z benchmarku w krótką listę i zrób ponowny test
Kolejność różnic ustal według wartości strony i tego, jak bardzo jesteś w tyle. Dwie sekundy różnicy w LCP na stronie kategorii, która rankuje na główną frazę, są warte więcej niż dwadzieścia drobnych ostrzeżeń na stronie z regulaminem.
Co benchmark powiedział o mojej stronie
Benchmark wykluczył jedno wyjaśnienie, bo dwie strony z medianą laboratoryjnego LCP powyżej 13 sekund są w top 10 obu fraz. Moja ładowała się 5,8 s i nie trafiła do żadnego z nich, więc mojej nieobecności nie tłumaczy laboratoryjna szybkość. Zgadza się to z opisem Google w Understanding page experience: wyszukiwarka stara się pokazać najtrafniejszą treść także przy słabych wrażeniach ze strony.
Jedno uczciwe zastrzeżenie: wykluczenie jednego wyjaśnienia nie dowodzi innego, więc trafność i autorytet wymagają osobnej analizy. Techniczną krótką listę i tak dostałem, a najszybsza strona pokazuje, że laboratoryjne LCP 2,2 s jest tu osiągalne.
- Pierwsze malowanie. Mój FCP 3,8 s jest najwolniejszy z czterech, a według przebiegu diagnostycznego elementem LCP jest słowo „CometWeb” w logo. Serwer odpowiedział w 68 ms, więc praca leży w ścieżce renderowania. Lighthouse szacował 700 ms oszczędności na siedmiu arkuszach stylów blokujących renderowanie, ale najpierw potrzebuję ponownego pomiaru po zmianie układu, żeby ustalić, czy modyfikowanie arkuszy nadal jest uzasadnione.
- Content Security Policy. Nagłówek, który tylko podnosi adresy do HTTPS, zastąpię polityką ograniczającą źródła i przetestuję ją przed włączeniem.
- Reszta zostaje, bo TBT, CLS, waga zasobów zewnętrznych i podstawy indeksacji są w porządku.
Na marginesie: te 700 ms sprawdziłem tylko na stronie głównej, gdzie elementem LCP jest to samo logo, i odroczenie CSS dało tam tego samego dnia ok. 0,1 s. Więcej dało wycięcie JavaScriptu, który układ wspólny dla wszystkich stron ładował przed pierwszym renderem. Liczby z benchmarku są sprzed tej zmiany, a ile zyskał /website-audit, pokaże ponowny test.
Przykłady zmian dotyczących LCP i czasu blokowania opisuję w poradniku jak przyspieszyć stronę: 7 napraw z pomiarami.
Zrób ponowny test tą samą metodą
Po wdrożeniu poprawki zmierz te same strony tą samą metodą, klasą urządzeń i liczbą przebiegów. Mój ponowny test użyje bez zmian tego samego skryptu, czterech adresów i reguły rezerwy.
Benchmark konkurencji w CometWeb Insight
Wszystko powyżej zrobisz ręcznie, Lighthouse'em i arkuszem. Moduł Konkurencja w CometWeb Insight robi takie porównanie dla twojej domeny i maksymalnie trzech konkurentów:
- skanuje każdą domenę tym samym zestawem modułów: wydajność, SEO, dostępność, bezpieczeństwo i ekologia;
- pokazuje, gdzie prowadzisz, a gdzie masz techniczną lukę;
- śledzi dystans w czasie, bo każdy kolejny skan dopisuje punkt do trendu.
Insight mierzy strony, które skanuje, więc ruchu ani przychodów konkurentów nie szacuje. Daje za to te same kontrole na każdej domenie, czyli to, co w ręcznym benchmarku najtrudniej utrzymać.
Trzy wnioski
- Wynik zbiorczy miesza metryki. Strona The HOTH ładowała się 13,3 s i dostała 71 punktów, a moja przy 5,8 s tylko 69, więc porównuj LCP, TBT i CLS osobno.
- Metodę ustalasz przed pomiarem, bo rezerwa wybrana po obejrzeniu liczb dobiera porównanie, które schlebia. Mediana z pięciu przebiegów chroni przed jednym, który odjeżdża (u mnie o 886 ms).
- „Niezmierzone” to osobne ustalenie. Pusta komórka zamienia je w „zmierzone jako dobre”, więc wpisz, czego nie zmierzyłeś.
Przegrałem LCP 5,8 s do 2,2 s i wyszedłem z listą dwóch poprawek. W tym tygodniu wybierz trzy strony z top 10 dla swojej głównej frazy, zapisz rezerwę i zrób po pięć przebiegów na każdą. Jeśli wolisz, żeby porównanie liczyło się samo, załóż konto w CometWeb Insight.
Najczęstsze pytania
Jak często robić benchmark strony?
Przed większymi zmianami i po nich, takimi jak przebudowa, migracja czy nowy szablon, oraz w stałym rytmie dopasowanym do tego, jak często wdrażasz zmiany. Ponieważ CrUX używa 28-dniowego okna, porównanie danych terenowych co miesiąc to najkrótszy odstęp, który pokazuje pełne okno po zmianie.
Czy benchmark strony da się zrobić w PageSpeed Insights?
Tak, jeśli każdą stronę zmierzysz tak samo. PageSpeed Insights pokazuje dane terenowe z CrUX za ostatnie 28 dni, a gdy adres ma ich za mało, przechodzi na dane całej domeny albo nie pokazuje ich wcale. Część laboratoryjną liczy Lighthouse w symulowanym środowisku, więc zasady z kroku 5 zostają: kilka przebiegów na stronę, mediana i to samo okno czasowe. Ja użyłem Lighthouse lokalnie, bo anonimowe API PageSpeed Insights odpowiedziało „quota exceeded”.
Jak porównać ślad węglowy strony z konkurencją?
Policz każdą stronę tym samym modelem i tą samą wersją modelu. Punktem wyjścia są przesłane bajty przy pierwszej wizycie, które masz już z Lighthouse. Szacunków z różnych modeli albo wersji nie zestawiaj ze sobą. Artykuł o śladzie węglowym strony internetowej wyjaśnia, dlaczego wersja musi być wspólna, i ma kalkulator SWDM v4.
Jak porównać dostępność z konkurencją, skoro test automatyczny widzi tylko część problemów?
Zapisz osobno dwie rzeczy: automatyczne błędy na tych samych szablonach i wynik przejścia kluczowego zadania samą klawiaturą na każdej stronie. Przy przejściu klawiaturą sprawdź, czy każdy potrzebny element da się osiągnąć i obsłużyć, czy widać focus i czy nic go nie więzi. Test automatyczny obejmuje tylko część kryteriów WCAG. Co naprawdę oznacza poziom AA, opisuję w tekście WCAG 2.1: 4 zasady, poziom AA i różnice z 2.0 i 2.2.
Źródła
- Chrome for Developers, CrUX API: 28-dniowe okno, codzienne aktualizacje, p75, klasy urządzeń, klucz API.
- Chrome for Developers, metodologia CrUX: kwalifikowalność, uwzględniane przeglądarki.
- web.dev, Web Vitals: progi, 75. percentyl, INP i TBT.
- Chrome for Developers, Lighthouse performance scoring: zmienność i wagi metryk.
- Lighthouse na GitHubie, Score variability: mediana z pięciu przebiegów.
- Lighthouse na GitHubie, Throttling: domyślne symulowane ograniczanie.
- web.dev, Why lab and field data can be different: pamięć podręczna, urządzenie i sieć.
- Chrome for Developers, Lighthouse accessibility scoring: audyty zaliczone albo nie.
- MDN, CSP: upgrade-insecure-requests: zakres dyrektywy.
- Google Search Central, Understanding page experience: trafność a wrażenia ze strony.
- Google for Developers, About PageSpeed Insights: dane terenowe z CrUX za 28 dni, przejście na poziom domeny, Lighthouse w symulowanym środowisku.
Dane z testu: metodologia, karta benchmarku (CSV), wyniki przebiegów, dobór stron z wyników wyszukiwania, diagnoza naszej strony, skrypt, źródła