Test strony internetowej – jak sprawdzić szybkość, działanie, dostępność i bezpieczeństwo

Test strony internetowej to sprawdzenie, czy witryna szybko się ładuje, działa poprawnie na różnych urządzeniach, jest dostępna dla osób z niepełnosprawnościami, bezpieczna i dobrze widoczna dla wyszukiwarek. W praktyce oznacza to sześć obszarów: wydajność (Core Web Vitals), działanie funkcji, zgodność z przeglądarkami, dostępność (WCAG), bezpieczeństwo i SEO. Większość z nich sprawdzisz darmowymi narzędziami w godzinę.

Poniżej znajdziesz checklistę testów z konkretnymi narzędziami i progami, które warto osiągnąć. Sprawdza się zarówno przed uruchomieniem nowej strony, jak i przy okresowym przeglądzie istniejącej.

1. Test wydajności: Core Web Vitals i czas ładowania

Google ocenia szybkość strony trzema wskaźnikami Core Web Vitals. Ich wartości mierzy się dla 75% wizyt (75. percentyl), osobno na telefonach i komputerach.

INP zastąpił w marcu 2024 r. wcześniejszy wskaźnik FID, więc starsze poradniki mogą być pod tym względem nieaktualne.

Jak testować:

1. Wpisz adres na pagespeed.web.dev (PageSpeed Insights). Górna sekcja pokazuje dane od prawdziwych użytkowników Chrome z ostatnich 28 dni (CrUX) — to one są ważne dla Google. Dolna to test laboratoryjny Lighthouse, przydatny do szukania przyczyn.
2. Ten sam test laboratoryjny uruchomisz lokalnie: w Chrome otwórz narzędzia deweloperskie (F12) → zakładka Lighthouse → zaznacz Performance → Analyze page load. Rób to w oknie incognito, bo rozszerzenia przeglądarki zaniżają wynik.
3. Do głębszej analizy — wykres kaskadowy (waterfall), testy z różnych lokalizacji i na wolnym łączu — użyj WebPageTest. Krok po kroku opisuje to nasz poradnik jak analizować wydajność strony w WebPageTest.

Najczęstsze przyczyny słabego wyniku to zbyt duże obrazy (bez formatów WebP/AVIF i atrybutów width/height), blokujący JavaScript i CSS, wolny czas odpowiedzi serwera (TTFB) i skrypty firm trzecich: czaty, piksele reklamowe, osadzone filmy. Przy ruchu z wielu krajów pomaga sieć CDN.

2. Testy funkcjonalne: formularze, koszyk, logowanie

Strona może być szybka i ładna, a jednocześnie nie przyjmować zamówień. Testy funkcjonalne sprawdzają, czy wszystko, co użytkownik ma zrobić, faktycznie działa.

Lista minimum do przejścia ręcznie:

• Formularze — wysyłka z poprawnymi danymi, z pustymi polami i z błędnym formatem (e-mail, telefon). Czy komunikaty błędów są zrozumiałe? Czy wiadomość faktycznie dociera na skrzynkę (sprawdź też folder spam)?
• Ścieżka zakupu — dodanie do koszyka, zmiana ilości, kod rabatowy, wybór dostawy, płatność w trybie testowym, e-mail z potwierdzeniem.
• Konto użytkownika — rejestracja, logowanie, reset hasła, wylogowanie.
• Wyszukiwarka i filtry — także zapytania bez wyników i z polskimi znakami.
• Linki — brak błędów 404. Do skanu całej strony wystarczy darmowa wersja Screaming Frog SEO Spider (do 500 adresów) albo polecenie npx linkinator https://twojadomena.pl --recurse.
• Strona błędu 404 — czy istnieje i pomaga wrócić do treści.

Powtarzalne scenariusze warto zautomatyzować. Playwright uruchamia testy w silnikach Chromium, Firefox i WebKit (Safari), więc za jednym razem sprawdzasz też zgodność przeglądarek:

// tests/kontakt.spec.js — uruchom: npx playwright test
import { test, expect } from '@playwright/test';

test('formularz kontaktowy wysyła wiadomość', async ({ page }) => {
  await page.goto('https://twojadomena.pl/kontakt/');
  await page.getByLabel('E-mail').fill('test@example.com');
  await page.getByLabel('Wiadomość').fill('Test formularza');
  await page.getByRole('button', { name: 'Wyślij' }).click();
  await expect(page.getByText('Dziękujemy')).toBeVisible();
});

Takie testy uruchamiaj na środowisku testowym (staging), nie na produkcji — inaczej zaśmiecisz bazę zamówień i skrzynkę obsługi klienta.

3. Zgodność z przeglądarkami i urządzeniami mobilnymi

Większość ruchu na typowych stronach pochodzi dziś z telefonów, więc test mobilny to nie dodatek, tylko podstawa.

1. W Chrome naciśnij F12, a potem Ctrl+Shift+M, aby włączyć tryb urządzeń. Sprawdź szerokości ok. 360, 390, 768 i 1440 pikseli.
2. Szukaj poziomego przewijania, nachodzących na siebie elementów, zbyt małych przycisków (cel dotyku powinien mieć wygodny rozmiar) i tekstu, który trzeba powiększać.
3. Sprawdź stronę na co najmniej jednym prawdziwym Androidzie i jednym iPhonie. Emulacja nie odda działania Safari na iOS, wirtualnej klawiatury ani wydajności słabszego telefonu.
4. Jeśli nie masz sprzętu, skorzystaj z usług z prawdziwymi urządzeniami w chmurze, np. BrowserStack lub LambdaTest (płatne, z okresem próbnym).

Google wycofał osobne narzędzie „Test zgodności z urządzeniami mobilnymi” w grudniu 2023 r. — do oceny służą teraz Lighthouse i raporty w Search Console.

4. Test dostępności (WCAG i Europejski akt o dostępności)

Dostępność to nie tylko dobra praktyka. Od 28 czerwca 2025 r. obowiązują przepisy wdrażające Europejski akt o dostępności (w Polsce ustawa z 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług). Obejmują one m.in. handel elektroniczny i usługi bankowe online; mikroprzedsiębiorstwa świadczące usługi są z tych obowiązków zwolnione. Punktem odniesienia w praktyce są wytyczne WCAG.

Szybki test:

1. Zainstaluj rozszerzenie axe DevTools lub WAVE i uruchom je na najważniejszych podstronach. Wykryją m.in. brak tekstów alternatywnych, za słaby kontrast, pola formularza bez etykiet i błędną strukturę nagłówków.
2. Przejdź stronę samą klawiaturą (Tab, Shift+Tab, Enter, spacja). Czy widzisz, gdzie jest fokus? Czy dasz radę otworzyć menu, zamknąć okno cookies i wysłać formularz?
3. Powiększ stronę do 200% i sprawdź, czy nic nie znika ani się nie nakłada.
4. Włącz czytnik ekranu (NVDA na Windows, VoiceOver na macOS/iOS, TalkBack na Androidzie) i odsłuchaj kluczową ścieżkę, np. zakup.

Automatyczne narzędzia wykrywają tylko część problemów — test klawiaturą i czytnikiem ekranu jest niezbędny. O projektowaniu interfejsów przyjaznych użytkownikom przeczytasz w tekście o prawach UX.

5. Test bezpieczeństwa strony

Podstawowy przegląd bezpieczeństwa zrobisz darmowymi narzędziami online:

• SSL Labs (ssllabs.com/ssltest) — ocena konfiguracji HTTPS: wersje TLS, łańcuch certyfikatów, słabe szyfry. Celuj w ocenę A lub A+.
• MDN HTTP Observatory (dawniej Mozilla Observatory) — sprawdza nagłówki bezpieczeństwa, takie jak Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options i ustawienia ciasteczek.
• Ręczny przegląd — czy panel administracyjny nie jest dostępny pod domyślnym adresem bez dodatkowej ochrony, czy wtyczki i CMS są aktualne, czy formularze mają ochronę przed spamem, czy kopie zapasowe działają i da się je odtworzyć.

Nagłówki odpowiedzi sprawdzisz też z terminala:

curl -sI https://twojadomena.pl | grep -iE 'strict-transport|content-security|x-content-type|x-frame|referrer-policy'

Głębszy test podatności (np. na Cross-Site Scripting czy SQL injection) wykonasz skanerem ZAP, który ma tryb automatycznego skanu. Na dużych lub krytycznych serwisach to jednak praca dla specjalistów — o tym, jak wyglądają profesjonalne testy bezpieczeństwa IT, piszemy osobno.

Uwaga: Aktywnie skanuj wyłącznie strony, których jesteś właścicielem albo na których test masz pisemną zgodę. Skan podatności cudzego serwisu może zostać uznany za próbę ataku, a sam skaner potrafi obciążyć serwer lub wypełnić formularze śmieciowymi danymi — dlatego najlepiej uruchamiaj go na kopii testowej.

6. Test SEO i poprawności kodu

Techniczne SEO to w dużej mierze sprawdzenie, czy wyszukiwarka może stronę znaleźć, zrozumieć i zaindeksować:

1. Google Search Console — dodaj i zweryfikuj domenę, prześlij mapę witryny (sitemap.xml), sprawdź raport indeksowania stron oraz Core Web Vitals. Narzędzie Sprawdzanie adresu URL pokaże, jak Google widzi konkretną podstronę.
2. Plik robots.txt — upewnij się, że po przeniesieniu strony z wersji testowej nie blokuje całej witryny (Disallow: /) i że w kodzie nie został meta tag noindex.
3. Crawl całej strony — Screaming Frog pokaże zduplikowane i brakujące tytuły, opisy, nagłówki H1, przekierowania łańcuchowe i błędy 404.
4. Dane strukturalne — sprawdź je w Teście wyników z elementami rozszerzonymi Google.
5. Walidacja HTML — validator.w3.org wskaże błędy w kodzie. Nie każdy błąd szkodzi, ale niedomknięte znaczniki potrafią zepsuć układ w części przeglądarek.

7. Test obciążenia: czy strona wytrzyma ruch

Przed kampanią reklamową, premierą produktu czy wyprzedażą sprawdź, jak serwer zachowuje się przy wielu jednoczesnych użytkownikach. Popularne narzędzia to k6, Apache JMeter i Locust. Prosty scenariusz w k6:

// obciazenie.js — uruchom: k6 run obciazenie.js
import http from 'k6/http';
import { sleep, check } from 'k6';

export const options = { vus: 50, duration: '2m' };

export default function () {
  const res = http.get('https://staging.twojadomena.pl/');
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(1);
}

Obserwuj czas odpowiedzi (szczególnie 95. percentyl) i odsetek błędów. Zaczynaj od małej liczby użytkowników i zwiększaj ją stopniowo. Testu obciążenia nie uruchamiaj na serwerze współdzielonym bez zgody hostingodawcy — dla niego wygląda to jak atak DDoS. Jeśli boisz się prawdziwych ataków, rozważ ochronę na poziomie WAF lub CDN.

Jak często testować stronę

Nie każdy test trzeba robić codziennie. Rozsądny harmonogram dla małej i średniej strony:

• Przy każdym wdrożeniu zmian: testy funkcjonalne kluczowych ścieżek (formularze, koszyk, logowanie) i szybki test Lighthouse zmienionych podstron.
• Co miesiąc: przegląd Search Console (indeksowanie, Core Web Vitals), skan linków, aktualizacje CMS i wtyczek.
• Co kwartał: test dostępności, przegląd nagłówków bezpieczeństwa i SSL, test na prawdziwych telefonach.
• Przed dużymi kampaniami: test obciążenia i sprawdzenie kopii zapasowych.

Zapisuj wyniki — choćby w arkuszu z datą, narzędziem i najważniejszymi wartościami. Dzięki temu po aktualizacji motywu czy dodaniu nowej wtyczki od razu zobaczysz, co się pogorszyło, zamiast zgadywać.