Testowanie strony internetowej — jak sprawdzić stronę, żeby wynik coś znaczył

Testowanie strony internetowej kończy się zwykle tak samo: ktoś wkleja adres do darmowego narzędzia, dostaje liczbę, a potem albo się cieszy, albo dzwoni do wykonawcy z pretensją.

Problem w tym, że ta liczba zwykle nic nie znaczy. Jest wynikiem jednego pomiaru, na symulowanym urządzeniu, w jednym przypadkowym momencie — i mierzy co innego niż to, na podstawie czego Google faktycznie ocenia Waszą stronę.

Ten tekst jest o tym, jak testować, żeby wynik coś znaczył. Jest dla Was, jeśli odbieracie stronę od wykonawcy, przygotowujecie ją do uruchomienia albo chcecie sprawdzić, czy ta, którą macie, działa tak, jak sądzicie.

Dlaczego jeden pomiar nic nie znaczy

Zacznijmy od rzeczy, której nie mówi żaden poradnik z listą narzędzi, a która przewraca sposób czytania każdego wyniku: ten sam test tej samej strony daje za każdym razem inną liczbę.

Rozrzut nie jest kosmetyczny. W naszej własnej procedurze pomiarowej — tej, którą stosujemy do walidacji każdej zmiany wydajnościowej w tym serwisie — przyjęliśmy wprost, że pojedynczy przebieg Lighthouse ma rozrzut rzędu dziesięciu punktów. To znaczy, że wynik 78 i wynik 88 mogą opisywać dokładnie tę samą stronę w tym samym stanie.

Stąd trzy reguły, które stosujemy u siebie i które warto przenieść do rozmowy z wykonawcą:

• Minimum pięć przebiegów, i bierzecie medianę — nie średnią. Średnia da się przesunąć jednym odstającym pomiarem; mediana nie.
• Ten sam adres, to samo urządzenie, ten sam moment. Porównywanie wyniku sprzed wdrożenia z komputera z wynikiem po wdrożeniu z telefonu nie jest porównaniem.
• Bez liczb sprzed i po to nie jest poprawka wydajności. U nas zmiana opisana jako przyspieszenie, która nie ma pomiaru przed i po, nie jest przyjmowana jako przyspieszenie.

Praktyczna konsekwencja dla Was jest natychmiastowa. Jeśli ktoś pokazuje Wam jeden zrzut ekranu z zielonym wynikiem jako dowód, że strona jest szybka — albo jeden z czerwonym jako dowód, że jest zepsuta — to nie jest dowód, tylko jeden losowy pomiar. Poproście o pięć.

Pomiar laboratoryjny i dane od prawdziwych użytkowników — dwie różne rzeczy

To jest rozróżnienie, którego nie rozumie większość właścicieli stron, a ono decyduje o tym, czy Wasz wynik ma jakikolwiek związek z oceną Google.

Pomiar laboratoryjny to Lighthouse i to, co widzicie w PageSpeed Insights jako wynik punktowy. Strona jest wczytywana na symulowanym urządzeniu, z symulowanym łączem, raz. To jest narzędzie diagnostyczne: mówi, co konkretnie spowalnia stronę i od czego zacząć. Jest do tego znakomite i po to go używajcie.

Dane od prawdziwych użytkowników to Chrome UX Report — zbiór, który, jak pisze dokumentacja Chrome, „odzwierciedla, jak rzeczywiści użytkownicy Chrome doświadczają popularnych miejsc w sieci". To nie jest symulacja: to Wasi odwiedzający, na swoich telefonach, na swoim zasięgu. I to na tych danych ocenia się progi, o których niżej — według Google na 75. percentylu wczytań, osobno dla telefonu i komputera.

Siedemdziesiąty piąty percentyl znaczy tyle: liczy się nie to, jak stronę widzi trzech najszybszych odwiedzających, tylko jak widzi ją ta wolniejsza jedna czwarta. Wasz test na dobrym łączu w biurze jest z definicji z tej szybszej strony rozkładu.

I teraz zastrzeżenie, które dotyczy większości polskich stron firmowych, a prawie nigdy nie pada. Do CrUX trafiają tylko te adresy, które spełniają kryteria kwalifikacji — strona musi być publicznie dostępna i, cytując dokumentację, musi mieć „wystarczająco dużą liczbę odwiedzających, żeby utworzyć statystycznie istotny zbiór danych". Google nie podaje, ile to jest.

Praktycznie: jeśli Wasza strona ma mały ruch, danych od użytkowników po prostu nie ma. W PageSpeed Insights zobaczycie wtedy sam wynik laboratoryjny i nic poza nim. To nie jest usterka i nie znaczy, że strona jest zła — znaczy, że jedyny pomiar, jaki macie, jest tym diagnostycznym, i trzeba go czytać jako wskazówkę, a nie jako ocenę.

Tak wygląda to dla tego artykułu, który ma mały ruch — sekcja danych od użytkowników kończy się na „Brak danych”, a pod nią jest już tylko pomiar laboratoryjny:

Trzy liczby, które mierzy Google, i ich progi

Core Web Vitals to trzy metryki. Progi są konkretne i publikowane, więc nie ma powodu zgadywać (web.dev, stan na 9 września 2026):

Dwie rzeczy warte zapamiętania. INP zastąpił wcześniejszą metrykę FID i jest stabilną metryką od 2024 roku — jeśli w czyjejś ofercie albo raporcie widzicie FID, ten dokument jest nieaktualny. I druga: CLS nie dotyczy szybkości. Mierzy, czy treść skacze pod palcem — czyli sytuację, w której klikacie przycisk, a w tej samej chwili doładowuje się baner i klikacie coś innego. To jest metryka o irytacji, nie o czasie, i najczęściej to ona psuje wynik stronom, które „przecież ładują się szybko".

Każda z trzech psuje się zwykle z innego powodu i warto to wiedzieć, zanim zaczniecie zgadywać:

• LCP wywala najczęściej jedno duże zdjęcie na górze strony — to, które ma robić wrażenie. Zwykle jest w złym formacie i w rozdzielczości przygotowanej na monitor, a wczytuje się na telefonie.
• INP psuje nadmiar skryptów: wtyczki, narzędzia marketingowe, czaty, banery zgód. Każde z osobna jest małe, razem zajmują procesor dokładnie w tym momencie, w którym ktoś próbuje kliknąć.
• CLS psuje treść bez zarezerwowanego miejsca — obrazek, baner albo reklama, która doładowuje się później i przesuwa wszystko pod spodem.

Zauważcie, że dwa z trzech powodów to nie jest wina „strony", tylko rzeczy do niej dołożonych po wdrożeniu. To najczęstszy powód, dla którego strona z czasem zwalnia, choć nikt jej nie ruszał.

Jeśli chcecie zobaczyć te trzy liczby dla własnego adresu, mamy test szybkości strony, który pokazuje je z danych prawdziwych użytkowników, jeśli Google ma ich dość dla Twojej strony, a obok osobno test laboratoryjny. Samą optymalizacją — czyli tym, co zrobić, gdy wyniki są złe — zajmujemy się osobno.

Sprawdzenie strony internetowej przed uruchomieniem — cztery rzeczy

Większość kosztownych błędów widać na pół godziny przed publikacją, jeśli wiadomo, gdzie patrzeć. Cztery rzeczy w kolejności od najdroższej pomyłki:

1. Czy strona w ogóle może być zaindeksowana. Najdroższy błąd wdrożeniowy w tej kategorii to zostawienie na produkcji blokady indeksowania z etapu testów. Strona działa, wygląda dobrze i jest niewidoczna dla wyszukiwarki. Sprawdzenie zajmuje minutę: w Search Console, narzędzie do sprawdzania adresu URL.

2. Czy adresy się zgadzają. Jeśli nowa strona zastępuje starą, każdy stary adres musi prowadzić do odpowiednika. To jest jedyna pozycja na tej liście, której zaniedbanie kosztuje trwale — utracone pozycje nie wracają same.

3. Czy formularze docierają. Osobna sekcja niżej, bo to jedyny test, którego nie zrobi żadne narzędzie.

4. Czy strona działa na telefonie w realnych warunkach. Też osobna sekcja, bo „działa na telefonie" znaczy co innego w podglądzie, a co innego w tramwaju.

Pełną listę do odhaczenia mamy w checkliście przedstartowej. Jeśli natomiast sprawdzacie stronę, która działa od dawna i chcecie wiedzieć, co z nią jest nie tak, to jest inna robota — nazywa się audytem i opisaliśmy ją osobno, łącznie z tym, kiedy nie warto go zamawiać.

Testowanie strony www na telefonie — podgląd to nie jest test

Tu tkwi najczęstsza pomyłka i jest ona techniczna, nie organizacyjna: tryb urządzenia mobilnego w przeglądarce nie jest telefonem. Zmienia szerokość okna i deklarowany typ urządzenia, ale liczy nadal Wasz procesor, Wasze łącze i Waszą pamięć podręczną. Strona, która w tym podglądzie działa gładko, na czteroletnim telefonie w słabym zasięgu może być czymś zupełnie innym.

Ma to znaczenie większe, niż się wydaje, bo Google indeksuje strony wersją mobilną — do indeksowania i pozycjonowania używana jest wersja pobrana agentem smartfonowym. Wersja na dużym ekranie może więc wyglądać znakomicie i nie mieć na to wpływu.

Test, który realnie coś mówi, wygląda tak i zajmuje kwadrans:

• Weźcie prawdziwy telefon, najlepiej nie swój. Najwięcej problemów widać na sprzęcie, którego nikt w zespole nie używa — starszym, z mniejszą pamięcią.
• Wyłączcie wi-fi. Testujcie na danych komórkowych, najlepiej poza biurem.
• Przejdźcie ścieżkę klienta, nie stronę główną. Wejście, oferta, kontakt, wysłanie zapytania. Strona główna prawie zawsze jest najlepiej dopracowana i najmniej mówi.
• Jedną ręką. Jeśli do wysłania zapytania potrzebne są dwie ręce i powiększanie, formularz jest do poprawy niezależnie od tego, co pokazuje jakikolwiek wynik punktowy.

Formularz — jedyny test, którego nie zrobi żadne narzędzie

Żadne narzędzie nie sprawdzi, czy zapytanie od klienta do Was dociera. Trzeba wysłać prawdziwe i sprawdzić trzy punkty, bo każdy z nich potrafi zawieść osobno i po cichu.

1. Czy wiadomość dochodzi do skrzynki, a nie do spamu. To jest najczęstsza cicha awaria: formularz działa, pokazuje podziękowanie, a wiadomość ląduje w folderze, do którego nikt nie zagląda. Sprawdźcie skrzynkę i folder spam, a jeśli zapytania idą na adres zbiorczy, sprawdźcie, czy ktokolwiek go faktycznie czyta.

2. Czy klient dostaje potwierdzenie. Z perspektywy piszącego brak potwierdzenia jest nieodróżnialny od awarii. Część osób wysyła zapytanie drugi raz, część rezygnuje i pisze do kogoś innego. Automatyczne potwierdzenie jest tanie i usuwa całą tę klasę strat.

3. Czy zabezpieczenie antyspamowe nie blokuje prawdziwych ludzi. To jest awaria najtrudniejsza do zauważenia, bo u Was wszystko działa — testujecie ze swojego biura, ze swojego adresu. Mechanizmy typu reCAPTCHA czy Turnstile potrafią odrzucać zapytania od osób korzystających z VPN-a, ze starszej przeglądarki albo z internetu mobilnego o dzielonym adresie. Nie zobaczycie tego w żadnym raporcie, bo zablokowane zapytanie nie zostawia śladu po Waszej stronie. Test: poproście kogoś spoza firmy, z telefonu, przez dane komórkowe.

Warto to powtarzać cyklicznie, a nie raz po wdrożeniu — formularze psują się same, przy zmianie hostingu, wygaśnięciu klucza albo aktualizacji wtyczki. Tym właśnie zajmuje się monitoring.

Odbiór strony od wykonawcy — co sprawdzić, zanim podpiszecie

To jest moment, w którym testowanie ma największą wartość i najkrótszy termin przydatności. Po odbiorze i zapłacie ostatniej raty każda poprawka staje się nową rozmową; przed odbiorem jest częścią umowy.

Sześć rzeczy, w tej kolejności, wszystkie do sprawdzenia przez Was, nie przez wykonawcę:

• Zapytanie z formularza dochodzi i macie na to dowód. Wysłane z zewnątrz, z cudzego telefonu, przez dane komórkowe. Trzy punkty z sekcji wyżej.
• Strona jest widoczna dla wyszukiwarki. Blokada indeksowania z etapu testów zdjęta — sprawdzone w Search Console, nie na słowo.
• Stare adresy prowadzą do nowych. Jeśli to zastępstwo poprzedniej strony, sprawdźcie kilkanaście najważniejszych adresów ręcznie. Nie „czy są przekierowania", tylko czy konkretne stare adresy otwierają właściwe nowe podstrony.
• Pięć pomiarów, nie jeden, i macie ich medianę zapisaną. To jest Wasz punkt odniesienia na przyszłość — bez niego za rok nie udowodnicie, że coś zwolniło.
• Ścieżka klienta przeszła na prawdziwym telefonie, poza biurem.
• Dostępy są na Was. Domena, hosting, konto administratora, licencje. To nie jest test, ale sprawdza się to w tym samym momencie i z tego samego powodu: później bywa to rozmowa, a nie ustawienie. Rozkładamy to szerzej przy warstwie edytora.

Rzecz, o którą warto poprosić wprost i która nic nie kosztuje: listę tego, czego wykonawca świadomie nie zrobił. Każde wdrożenie ma takie pozycje — odłożone na później, uzgodnione ustnie, wycięte z zakresu. Spisane są informacją. Niespisane wracają za pół roku jako spór o to, co było w cenie.

Które trzy uwagi z pięćdziesięciu mają znaczenie

Każde narzędzie diagnostyczne produkuje długą listę i to jest jego największa wada: lista sugeruje, że wszystko na niej jest do zrobienia. Nie jest.

Trzy pytania, które przycinają ją do rzeczy istotnych:

Czy to widzi odwiedzający? Uwaga o formacie obrazków na stronie głównej dotyczy każdego wchodzącego. Uwaga o nagłówku serwera dotyczy nikogo, kogo znacie. Zacznijcie od pierwszej kategorii.

Czy to dotyczy telefonu? Skoro indeksowanie idzie wersją mobilną, a wolniejsza ćwiartka odwiedzających rozstrzyga o ocenie, to problem widoczny tylko na komputerze jest niżej na liście niż problem widoczny tylko na telefonie.

Czy to się powtarza, czy zdarzyło się raz? Tu wraca reguła pięciu pomiarów: uwaga, która pojawia się w jednym przebiegu na pięć, jest szumem. Ta, która jest w każdym, jest usterką.

Po tym przycięciu z pięćdziesięciu uwag zostaje zwykle trzy do pięciu, które warto zlecić — i to jest lista, z którą idzie się do wykonawcy. Nie z raportem.

Kiedy wystarczy sprawdzić samemu, a kiedy zlecić

Samodzielnie zrobicie więcej, niż się wydaje, i warto to wykorzystać, zanim ktokolwiek wystawi fakturę. Cztery rzeczy z listy wyżej plus pięć przebiegów pomiaru to jest realna diagnoza w dwie godziny, bez żadnej wiedzy technicznej.

Zlecenie ma sens w trzech sytuacjach: gdy strona ma przynosić zapytania i ich nie przynosi, a nie wiecie dlaczego; gdy odbieracie duże wdrożenie i potrzebujecie kogoś po swojej stronie; i gdy wynik pomiaru jest zły, a nie wiecie, która z przyczyn jest ta kosztowna — bo narzędzie wypisze pięćdziesiąt uwag i nie powie, które trzy mają znaczenie.

Czego zlecenie nie załatwi: jeśli problem jest w treści albo w ofercie, żaden test techniczny go nie pokaże. Zielona strona bez zapytań to nie jest problem wydajności — to jest pytanie o pomiar tego, co ludzie na niej robią, i zaczyna się gdzie indziej, bo od danych, a nie od narzędzi.