Jak zdiagnozować wolną stronę w 30 minut? Narzędzia 2026

Klasyczna pułapka: raport laboratoryjny pokazuje wynik 95/100, a klient nadal skarży się, że strona się wlecze. Ocena laboratoryjna mierzy jedno uruchomienie na szybkim łączu i pustym cache. Twoi klienci otwierają stronę na trzyletnim telefonie, z zasięgiem LTE na skraju miasta i pełnym cache przeglądarki. Poniżej kolejność diagnostyki, która w pół godziny wskazuje realne wąskie gardło.

Krok 1: dane polowe, nie laboratorium 📊

Zacznij od sekcji danych użytkowników w PageSpeed Insights oraz od raportu Core Web Vitals w Search Console. Te liczby pochodzą od osób, które faktycznie odwiedziły witrynę w ostatnich 28 dniach, i pokazują rozkład: jaki procent sesji ma dobry LCP, INP i CLS.

Jeżeli dane polowe są dobre, a laboratoryjne złe, optymalizujesz coś, czego użytkownicy nie odczuwają. Jeżeli jest odwrotnie, masz problem z konkretną grupą urządzeń lub regionów, którego test laboratoryjny nigdy nie pokaże.

Krok 2: podział na konkretne metryki 🎯

• LCP powyżej 2,5 s: winowajcą jest zwykle obraz hero, brak atrybutów priorytetu, zbyt duży plik albo wolny serwer.
• INP powyżej 200 ms: problemem jest JavaScript blokujący główny wątek, zbyt wiele nasłuchów zdarzeń i skrypty firm trzecich.
• CLS powyżej 0,1: elementy przeskakują, bo obrazy nie mają zarezerwowanych wymiarów, a banery i czcionki wstawiają się po pierwszym renderze.
• TTFB powyżej 800 ms: nie optymalizuj frontendu. Najpierw serwer: OPcache, cache obiektowy, zapytania do bazy, warstwa CDN.

Krok 3: serwer, zanim dotkniesz kodu 🖥️

Zanim zaczniesz przebudowywać frontend, sprawdź czas odpowiedzi serwera na kilku podstronach, najlepiej z zewnętrznego narzędzia w kilku lokalizacjach. Własny OPcache, kompresja Brotli, poprawne nagłówki cache dla plików statycznych i HTTP/2 rozwiązują większość problemów z TTFB bez zmiany ani jednej linii szablonu.

Czego szukać w JavaScript i zasobach zewnętrznych 🧩

• Długie zadania: każdy blok pracy dłuższy niż 50 ms opóźnia reakcję na kliknięcie. Podziel logikę i odłóż inicjalizację do momentu po pierwszym renderze.
• Skrypty firm trzecich: mapy, czaty, piksele reklamowe i widgety opinii potrafią odpowiadać za większość opóźnienia interakcji. Ładuj je leniwie, po interakcji użytkownika.
• Zdjęcia bez wymiarów: brak width i height powoduje przeskakiwanie układu i psuje CLS, nawet przy szybkim serwerze.
• Zbyt wiele fontów: każdy dodatkowy krój i grubość to kolejne żądanie. Ogranicz się do dwóch rodzin i formatu WOFF2 z lokalnym hostingiem.

Wydajność to nie jednorazowy projekt, a proces: po każdej zmianie w szablonie mierz te same metryki polowe i porównuj trend tydzień do tygodnia. Zobacz powiązaną ofertę: Tworzenie szybkich stron internetowych lub skontaktuj się po darmową wycenę.