Benchmark strony: cometweb.io na tle trzech stron z wyników
To materiał do artykułu Benchmark strony: jak porównać ją z konkurencją. Chciałem sprawdzić, czy moja strona cometweb.io/website-audit technicznie odstaje od stron, które rankują na „website audit”, i jeśli tak, to w czym. Pomiar zrobiłem we wrześniu 2026 metodą opisaną w artykule.
Na co patrzyłem
Strony wybrałem z dwóch fraz, „free website audit tool” i „website audit”, w wynikach dla USA odczytanych przez API wyszukiwania Firecrawl. Lista posłużyła mi tylko do wyboru stron, bo pozycje zmieniają się z lokalizacją, urządzeniem i porą dnia. W top 10 obu fraz było sześć adresów.
Semrush i Ahrefs odłożyłem jako pełne pakiety SEO innej skali, a z reszty wziąłem trzy o najlepszej średniej pozycji: SEOptimer (2,0), The HOTH (4,0) i SEO Site Checkup (6,0). Rank Math (8,0) zapisałem jako rezerwę, zanim cokolwiek zmierzyłem. Mojej strony nie było w żadnym z tych top 10.
SEOptimer nie dał się zmierzyć. Pierwszy przebieg Lighthouse skończył się pustą stroną (NO_FCP), a dwa zwykłe żądania zwróciły HTTP 525, czyli według Cloudflare nieudane połączenie TLS z serwerem źródłowym. Wszedł więc Rank Math. Trzy próby w ciągu kilkunastu minut z jednej sieci nie mówią nic o tej stronie w innym czasie, dlatego SEOptimer nie ma w pakiecie żadnego wyniku.
Ta pierwsza próba skończyła się po jednej rundzie, a jej przebiegi dla pozostałych stron zostawiłem w osobnym pliku, poza medianami.
Każdą stronę najpierw pobrałem raz zwykłym żądaniem, żeby zapisać status, sześć nagłówków bezpieczeństwa i sekcję head z HTML-a serwera. Potem puściłem Lighthouse w domyślnym profilu mobilnym z symulowanym ograniczaniem sieci i procesora, pięć razy na stronę, w przeplatanych rundach z obracaną kolejnością.
Podaję medianę z pięciu przebiegów, a w nawiasie najniższą i najwyższą wartość. Przesłane bajty i podział na zasoby własne i zewnętrzne biorę z przebiegu, w którym suma bajtów jest medianą. Za zewnętrzne uznaję domeny, których Lighthouse nie przypisuje do właściciela strony, więc własne narzędzie firmy w osobnej domenie też się tu liczy. Od cudzych stron nie pobierałem niczego więcej.
Wyniki
| Strona | LCP | FCP | TBT | CLS | Wynik wydajności | Przesłane | Żądania | Bajty zewnętrzne |
|---|---|---|---|---|---|---|---|---|
| cometweb.io/website-audit | 5,8 s (5,5–6,4) | 3,8 s (3,6–4,2) | 0 ms (0–30) | 0,000 (0–0,006) | 69 (67–72) | 582 kB | 64 | 10 kB |
| thehoth.com/seo-audit-tool | 13,3 s (12,9–13,3) | 1,7 s (1,7–1,7) | 67 ms (48–74) | 0,003 | 71 (71–72) | 2024 kB | 66 | 1454 kB |
| seositecheckup.com | 13,6 s (13,4–13,8) | 3,7 s (1,4–3,7) | 175 ms (174–181) | 0,021 (0–0,021) | 60 (59–69) | 1736 kB | 94 | 1467 kB |
| rankmath.com/tools/seo-analyzer | 2,2 s (2,2–2,2) | 1,1 s (1,1–1,1) | 0 ms | 0,000 | 99 (99–99) | 193 kB | 23 | 0 kB |
kB to 1000 bajtów. Wszystkie wartości są laboratoryjne. Nagłówki bezpieczeństwa, kontrole SEO i automatyczne wyniki dostępności są w benchmark-record.csv.
Po benchmarku zrobiłem jeszcze jeden przebieg Lighthouse tylko dla mojej strony, żeby rozbić LCP na części i zobaczyć zasoby blokujące renderowanie. Ten przebieg nie wchodzi do median.
Czego te dane nie pokażą
- Danych od prawdziwych użytkowników. Nie miałem klucza do CrUX API, a darmowe API PageSpeed Insights odpowiedziało przekroczonym limitem, więc w pakiecie nie ma ani jednej wartości terenowej. INP w ogóle nie da się zmierzyć laboratoryjnie.
- Całych witryn. Zmierzyłem jedną stronę z każdej, z jednej sieci, w kilkuminutowym oknie jednego poranka, na Macu, na którym działały też inne procesy. Lighthouse odradza takie warunki, a symulowane ograniczanie zmniejsza ich wpływ tylko częściowo.
- Dostępności poza testami automatycznymi. Nie przechodziłem stron klawiaturą ani czytnikiem ekranu. TLS, ciasteczek i banerów zgody też nie sprawdzałem.
- Siły zabezpieczeń. Nagłówki zapisałem z jednej odpowiedzi i widać tylko, czy są. CSP może być obecne i prawie niczego nie blokować, a brak nagłówka nie dowodzi podatności. Liczbę
<h1>i JSON-LD czytałem z HTML-a przed uruchomieniem JavaScriptu. - Jakości samych narzędzi do audytu. Mierzyłem strony, a nie to, jak dobrze te narzędzia działają.
Pliki
Pola w plikach danych mają angielskie nazwy, wspólne dla obu wersji językowych.
benchmark-record.csv: wypełniona karta benchmarku dla czterech stronsummary.json: mediany użyte w artykulelighthouse-runs.json: wszystkie 20 przebiegów z ustawieniamiheaders-and-head.json: nagłówki i sekcja head każdej stronyserp-2026-09-24.json: listy wyników, z których wybrałem stronyexcluded-seoptimer.json: co się stało ze stroną SEOptimeraborted-run-1-lighthouse-runs.json: przerwana pierwsza próba, poza medianamicometweb-diagnosis.json: dodatkowy przebieg diagnostyczny mojej stronysources.json: źródła cytowane w artykulebenchmark.mjs.txt: skrypt pomiarudiagnose-own-page.mjs.txt: skrypt przebiegu diagnostycznegocharts.py.txt: skrypt wykresów
Skrypty mają końcówkę .txt, żeby build strony nie traktował ich jak kodu. Żeby to powtórzyć, zainstaluj lighthouse@13.5.0 i chrome-launcher@1.2.1, zmień nazwę na benchmark.mjs i uruchom CHROME_PATH=/sciezka/do/Chromium node benchmark.mjs. Liczby nie zgodzą się co do milisekundy, ale dopóki strony się nie zmienią, różnice powinny mieć ten sam rząd wielkości.