Dlaczego strona ładuje się wolno: diagnoza krok po kroku

Część przewodnika: Strona internetowa dla małej firmy, kompletny przewodnik

„Wolna strona” może oznaczać cztery różne problemy

Użytkownik może długo czekać na pierwszą odpowiedź, widzieć pusty ekran, patrzeć na gotową stronę, która nie reaguje, albo próbować kliknąć przycisk przesunięty przez późno załadowany element. Każdy przypadek ma inną metrykę i inne rozwiązanie.

Metryka	Co opisuje	Dobry wynik w danych field
TTFB	Czas do pierwszego bajtu odpowiedzi	orientacyjnie do 0,8 s
LCP	Wyświetlenie największego obrazu lub bloku tekstu w początkowym widoku	do 2,5 s
INP	Opóźnienie najgorszej typowej interakcji do kolejnego odmalowania	do 200 ms
CLS	Suma nieoczekiwanych przesunięć układu	do 0,1

LCP, INP i CLS tworzą Core Web Vitals. Klasyfikację ocenia się na 75. percentylu wizyt, czyli nie na jednym szybkim komputerze właściciela. Aktualne progi i metodologię opisuje web.dev.

TTFB nie jest Core Web Vital. Jest metryką diagnostyczną poprzedzającą renderowanie. web.dev podaje 0,8 s jako orientacyjny cel, ale zaznacza, że architektura strony wpływa na interpretację wyniku. Szybki dokument nie pomoże, jeśli kluczowa treść pojawia się dopiero po wykonaniu dużej aplikacji JavaScript.

Dane laboratoryjne i terenowe to nie to samo

PageSpeed Insights może pokazać dwa rodzaje danych:

• field data, pochodzące z Chrome User Experience Report, czyli zagregowanych rzeczywistych wizyt kwalifikujących się użytkowników Chrome;
• lab data, generowane przez Lighthouse podczas kontrolowanego testu na określonej konfiguracji urządzenia i sieci.

Dane field odpowiadają na pytanie „czego doświadczali użytkownicy w ostatnim okresie?”. Laboratorium pomaga odpowiedzieć „co w tej konkretnej próbie blokowało stronę?”. Nie każda mała lub nowa witryna ma wystarczające dane CrUX, a wyniki URL-a mogą zostać zastąpione danymi całego originu.

Różnice są normalne. Użytkownicy mają inne urządzenia, połączenia, lokalizacje, stan cache, zgody na skrypty i sposoby interakcji. Lighthouse zwykle nie kliknie wszystkich elementów, więc może nie zauważyć problemu INP albo późnego CLS. Szczegółowo wyjaśnia to artykuł Why lab and field data can be different.

Nie oceniaj wdrożenia na podstawie jednego wyniku 99 ani jednego wyniku 45. Zapisz kilka powtarzalnych testów, porównuj tę samą stronę i konfigurację, a efekt potwierdź trendem w danych rzeczywistych.

TTFB: zanim przeglądarka dostanie dokument

TTFB mierzy czas od rozpoczęcia nawigacji do otrzymania pierwszego bajtu odpowiedzi. Obejmuje więcej niż samą pracę serwera: mogą do niego dołożyć się przekierowania, DNS, zestawienie połączenia, TLS, odległość sieciowa, cache i generowanie HTML.

Wysoki TTFB może wynikać z:

• łańcucha przekierowań przed właściwym adresem,
• przeciążonego lub źle dobranego hostingu,
• wolnych zapytań do bazy danych,
• oczekiwania backendu na zewnętrzne API,
• braku cache albo częstych cache miss,
• zimnego startu procesu,
• zbyt dużej odległości od serwera źródłowego.

W panelu Network wybierz żądanie dokumentu i otwórz zakładkę Timing. Porównaj test po wyczyszczeniu cache z kolejnym wejściem. Jeżeli masz dostęp do backendu, nagłówek Server-Timing może rozdzielić czas bazy, renderowania i innych operacji. Oficjalny przewodnik Optimize Time to First Byte opisuje tę procedurę oraz ograniczenia laboratoryjnego pomiaru.

Naprawa zależy od przyczyny. Czasem pomoże cache odpowiedzi, czasem indeks bazy, usunięcie zewnętrznego wywołania z krytycznej ścieżki, a czasem zmiana infrastruktury. Migracja na stronę statyczną jest jedną z opcji, nie uniwersalną receptą.

LCP: kiedy pojawia się główna treść

LCP mierzy moment wyrenderowania największego widocznego obrazu, bloku tekstu lub klatki wideo w początkowym widoku. Sama waga pliku to tylko część wyniku.

web.dev rozkłada LCP na cztery obszary:

1. TTFB dokumentu,
2. opóźnienie wykrycia zasobu LCP,
3. czas pobierania zasobu,
4. opóźnienie renderowania elementu po pobraniu.

Najpierw znajdź element LCP w PageSpeed albo panelu Performance. Następnie sprawdź, czy przeglądarka widzi jego adres w początkowym HTML, jak szybko rozpoczyna pobieranie i co blokuje renderowanie.

Obrazy

• Użyj srcset i sizes, aby nie wysyłać telefonu pliku przeznaczonego na duży monitor.
• Dobierz WebP lub AVIF po porównaniu jakości i kompatybilności, zamiast zakładać stały procent oszczędności.
• Ustaw width i height albo aspect-ratio, by zarezerwować miejsce.
• Obrazy poniżej pierwszego widoku mogą używać loading="lazy".
• Prawdopodobnego obrazu LCP nie ładuj leniwie. Powinien być wykrywalny wcześnie, a w uzasadnionym przypadku dostać fetchpriority="high".

To ostatnie zalecenie wynika bezpośrednio z przewodnika Optimize Largest Contentful Paint. Nie ustawiaj wysokiego priorytetu wszystkim zdjęciom, bo przestaną się wzajemnie odróżniać.

Tekst i fonty

Jeżeli LCP jest nagłówkiem, jego renderowanie może czekać na font. Sprawdź liczbę krojów, odmian i zakresów znaków. WOFF2, subset, lokalne hostowanie oraz odpowiednie font-display mogą pomóc, ale każdą zmianę trzeba przetestować.

Preload ma sens tylko dla naprawdę krytycznego fontu użytego w początkowym widoku. Nadmiar preloadów konkuruje o pasmo z CSS i obrazem LCP. Dopasuj także font zapasowy, bo duża różnica metryk znaków może pogorszyć CLS po podmianie kroju.

INP: strona wygląda na gotową, ale nie reaguje

INP mierzy czas od interakcji użytkownika do kolejnego odmalowania. Obejmuje opóźnienie wejścia, wykonanie callbacków i prezentację następnej klatki. Pobranie JavaScriptu to dopiero początek: przeglądarka musi go sparsować, skompilować i wykonać.

Typowe źródła słabego INP:

• duży pakiet JavaScript uruchamiany na starcie,
• długie zadania na głównym wątku,
• ciężki handler kliknięcia lub wpisywania,
• renderowanie dużej liczby elementów po interakcji,
• synchroniczne odczyty i zapisy układu,
• widget czatu, mapa, test A/B lub skrypt reklamowy,
• praca wykonywana mimo że komponent nie jest widoczny.

Otwórz panel Performance, rozpocznij nagranie i wykonaj problematyczną czynność na realnym urządzeniu lub z odpowiednim ograniczeniem CPU. Znajdź długie zadanie otaczające interakcję, a następnie przejdź po wywołaniach do kosztownej funkcji.

Priorytety naprawy to zwykle: usunięcie niepotrzebnego kodu, podział pracy na mniejsze zadania, ograniczenie zakresu renderowania, ładowanie funkcji dopiero wtedy, gdy jest potrzebna, oraz przeniesienie ciężkich obliczeń poza główny wątek, jeśli architektura na to pozwala. Szczegóły opisuje Optimize Interaction to Next Paint.

CLS: dlaczego układ „skacze”

CLS rośnie, gdy widoczne elementy nieoczekiwanie zmieniają położenie. Najczęstsze przyczyny to:

• obrazy i filmy bez zarezerwowanego miejsca,
• iframe, reklama, mapa lub widget bez stałych wymiarów,
• baner cookies i komunikat wstrzyknięty nad istniejącą treść,
• późno dołączony pasek promocji,
• podmiana fontu o innych metrykach,
• animowanie właściwości wpływających na układ.

Panel Performance i dane field mogą pokazać źródła przesunięć. Laboratorium widzi tylko te, które wystąpiły podczas testu, więc problem po otwarciu menu lub po kilku sekundach może wymagać ręcznego odtworzenia.

Zarezerwuj miejsce przez wymiary obrazu lub aspect-ratio, używaj placeholderów dla embedów, a komunikaty dodawaj w sposób nieprzesuwający już widocznej treści. Dla animacji preferuj transform i opacity, jeśli odpowiadają zamierzonemu efektowi. Źródłowy przewodnik to Optimize Cumulative Layout Shift.

JavaScript, CSS i główny wątek

Nie każdy kilobajt kosztuje tyle samo. Duży obraz obciąża sieć, ale JavaScript obciąża również parsowanie, kompilację i wykonanie, szczególnie na słabszym telefonie.

JavaScript

• Sprawdź coverage i trace, zamiast usuwać plik tylko dlatego, że Lighthouse nazywa część kodu nieużywaną.
• Dziel kod według stron i funkcji.
• Ładuj czat, mapę lub galerię dopiero blisko użycia albo po działaniu użytkownika.
• Używaj defer dla skryptów zależnych od dokumentu i async tylko tam, gdzie kolejność nie ma znaczenia.
• Ogranicz polyfille oraz duplikaty bibliotek do wspieranych przeglądarek.

CSS

• Usuń reguły pozostawione przez nieużywane komponenty, ale przetestuj stany dynamiczne.
• Ogranicz CSS blokujący początkowe renderowanie.
• Nie wklejaj całego arkusza jako „critical CSS”. Krytyczna część powinna być mała i mierzona.
• Ładuj style komponentu tylko tam, gdzie są potrzebne, jeśli pozwala na to stack.

defer ani minifikacja nie naprawią skryptu, który wykonuje za dużo pracy. Z kolei usunięcie kilku kilobajtów CSS nie pomoże, jeżeli LCP czeka dwie sekundy na backend. Waterfall i profil procesora decydują o kolejności.

Zasoby zewnętrzne

Tag manager, analityka, mapa, wideo, font, czat, system opinii i baner zgód mogą pochodzić z innych domen. Każda nowa domena może wymagać DNS, połączenia i TLS, a kod dostawcy pozostaje poza pełną kontrolą strony.

Zrób listę zasobów według właściciela domeny i odpowiedz na trzy pytania:

1. Czy narzędzie ma mierzalną wartość?
2. Czy musi ładować się przed główną treścią?
3. Czy może zostać zastąpione lżejszym linkiem, miniaturą lub ładowaniem po kliknięciu?

async nie usuwa kosztu wykonania. preconnect może skrócić nawiązanie połączenia, ale stosowany do wielu domen sam zużywa zasoby. web.dev opisuje ryzyka i metody w artykule Load third-party JavaScript.

Cache, CDN i hosting

Te trzy warstwy rozwiązują różne problemy:

• cache przeglądarki pozwala ponownie wykorzystać zasób na urządzeniu użytkownika;
• cache serwera lub aplikacji ogranicza koszt ponownego generowania odpowiedzi;
• CDN może dostarczać kopię z serwera bliższego użytkownikowi i odciążyć origin;
• hosting zapewnia zasoby potrzebne do generowania treści, bazy i integracji.

Długie cache ma sens dla wersjonowanych plików statycznych. Odpowiedzi spersonalizowane nie powinny trafiać do publicznego cache. Po wdrożeniu CDN sprawdź nagłówki Cache-Control, wynik HIT/MISS, cache hit ratio i zachowanie po publikacji nowej wersji.

CDN nie naprawi ciężkiego JavaScriptu ani kosztownego renderowania w przeglądarce. Może też maskować wolny origin, jeśli testujesz tylko popularną, już zbuforowaną stronę. Dobry opis ograniczeń znajduje się w przewodniku Content delivery networks.

Hosting oceniaj w danych z różnych godzin i regionów, z rozróżnieniem cache hit oraz miss. Nie zakładaj, że każda strona współdzielona jest wolna ani że każda platforma edge będzie szybka dla konkretnej grupy użytkowników.

Procedura diagnostyczna krok po kroku

1. Wybierz reprezentatywne strony

Zbadaj stronę główną, główną usługę, artykuł, kontakt oraz stronę z nietypową funkcją. Wynik originu może ukrywać różnice między szablonami.

2. Zapisz dane field

Sprawdź PageSpeed Insights i raport Core Web Vitals w Search Console. Zanotuj, czy dane dotyczą URL-a czy originu, urządzenia mobilnego czy komputera i jakiego okresu.

3. Odtwórz problem w laboratorium

Wykonaj kilka testów w tej samej konfiguracji. Użyj Chrome DevTools Network i Performance. Testuj czyste wejście, ponowne wejście z cache oraz kluczowe interakcje.

4. Wskaż dowód

• TTFB: dokument, przekierowania, Timing i Server-Timing.
• LCP: konkretny element, jego URL, moment wykrycia, pobieranie i renderowanie.
• INP: konkretna interakcja i długie zadanie na głównym wątku.
• CLS: konkretny layout shift i element powodujący zmianę.

5. Napraw jeden największy problem

Nie instaluj jednocześnie wtyczki cache, CDN i nowego systemu obrazów. Trudno wtedy przypisać efekt lub regresję. Najpierw usuń największe potwierdzone opóźnienie.

6. Sprawdź skutki uboczne

Przetestuj formularze, logowanie, koszyk, zgody, analitykę, wersje językowe i cache po publikacji. Szybsza strona z niedziałającą konwersją nie jest poprawą.

7. Monitoruj dane rzeczywiste

Lighthouse może potwierdzić zmianę od razu, ale CrUX potrzebuje czasu i odpowiedniej liczby wizyt. Przy większym serwisie warto zbierać własne Real User Monitoring z rozbiciem na typ strony, urządzenie i kraj, bez przesyłania danych osobowych.

Jak ustalać priorytety napraw

Najpierw wybierz poprawkę o dużym wpływie i małym ryzyku:

1. usuń awarię, pętlę przekierowań lub zasób blokujący główną treść;
2. napraw element LCP ładowany leniwie albo wykrywany dopiero przez JavaScript;
3. ogranicz długie zadanie blokujące najważniejszą interakcję;
4. zarezerwuj miejsce dla obrazów, embedów i banerów;
5. usuń zbędne narzędzia zewnętrzne i kod nieużywany na danej stronie;
6. dopasuj obrazy, fonty, CSS i politykę cache;
7. dopiero potem rozważ zmianę hostingu, CDN, architektury lub platformy, jeśli pomiary wskazują tę warstwę.

Nie ma wiarygodnego progu typu „PageSpeed poniżej 50 oznacza migrację”. WordPress, strona statyczna i aplikacja JavaScript mogą być szybkie lub wolne zależnie od wdrożenia. Migracja strony ma sens, gdy obecna architektura utrudnia naprawy albo koszt utrzymania przewyższa odbudowę, nie tylko z powodu koloru wyniku Lighthouse.

Szybkość a pozycje w Google

Google potwierdza, że Core Web Vitals są używane przez systemy rankingowe. Jednocześnie oficjalna dokumentacja mówi wprost, że dobre wyniki nie gwarantują wysokiej pozycji, a perfekcyjny score nie powinien być celem samym w sobie. Trafność i jakość treści nadal mają podstawowe znaczenie. Źródłem jest dokument Understanding page experience.

Nie przedstawiaj współczynnika odrzuceń ani szybkiego powrotu do wyników jako prostego, potwierdzonego czynnika rankingowego. Mierz własne wyniki biznesowe: ukończenie formularza, telefon, rezerwację, zakup i błędy na kluczowej ścieżce.

Więcej o interpretacji wyniku znajdziesz we wpisach PageSpeed jako czynnik rankingowy oraz Core Web Vitals w 2026 roku.

Najczęstsze pytania

Jakie są aktualne progi Core Web Vitals?

Według web.dev wynik dobry to LCP do 2,5 s, INP do 200 ms i CLS do 0,1. Ocena danych rzeczywistych opiera się na 75. percentylu wizyt. Progi pomagają klasyfikować doświadczenie, ale nie są obietnicą pozycji w Google ani celem ważniejszym od potrzeb użytkownika.

Dlaczego PageSpeed pokazuje inne wyniki przy kolejnych testach?

Test laboratoryjny działa w kontrolowanych, lecz zmiennych warunkach serwera, sieci i urządzenia testowego. Dane terenowe pochodzą z rzeczywistych wizyt użytkowników i obejmują dłuższy okres. Pojedynczy test służy do diagnozy, a trend oraz dane field do oceny efektu.

Czy wysoki TTFB zawsze oznacza słaby hosting?

Nie. TTFB obejmuje między innymi przekierowania, połączenie, sieć, cache i czas generowania odpowiedzi. Przyczyną może być hosting, ale również wolna baza danych, zewnętrzne API, brak pamięci podręcznej, zimny start albo łańcuch przekierowań. Trzeba zbadać waterfall i pomiary serwera.

Czy format WebP automatycznie naprawi LCP?

Nie. Lżejszy plik może pomóc, ale LCP zależy też od TTFB, momentu wykrycia zasobu, priorytetu, CSS, fontu i renderowania. Obraz LCP nie powinien być leniwie ładowany. Najpierw trzeba zidentyfikować faktyczny element LCP i jego podmetryki.

Czy CDN zawsze przyspiesza stronę?

Nie zawsze. CDN pomaga, gdy skraca drogę do użytkownika i skutecznie serwuje zasoby z cache. Błędne nagłówki, niski współczynnik trafień, spersonalizowane odpowiedzi albo dodatkowe przekierowania mogą ograniczyć efekt. Po wdrożeniu trzeba zmierzyć cache hit ratio i wyniki terenowe.

Czy dobra szybkość poprawi pozycję strony w Google?

Core Web Vitals są używane przez systemy rankingowe Google, ale dobry wynik nie gwarantuje wysokiej pozycji. Trafność i jakość treści pozostają kluczowe. Optymalizację warto prowadzić przede wszystkim po to, aby użytkownik szybciej zobaczył treść, mógł sprawnie wejść w interakcję i nie klikał przesuniętych elementów.

Źródła i aktualność

Definicje, progi i zalecenia sprawdzono 16 lipca 2026 roku. Wykorzystano oficjalne materiały web.dev, Chrome for Developers i Google Search Central. Metryki, narzędzia oraz interfejsy raportów mogą się zmieniać, dlatego przy audycie należy ponownie sprawdzić bieżącą dokumentację.