Strona wolno się ładuje

„Strona działa wolno” to opis odczucia, nie usterki. Zanim cokolwiek zmienisz, trzeba wiedzieć, która część ładowania zabiera czas — inaczej łatwo zoptymalizować to, co i tak było szybkie, i nie ruszyć prawdziwego hamulca.

Zacznij od pomiaru, nie od wtyczek

Otwórz PageSpeed Insights i wpisz adres strony. Dostaniesz dwa zestawy danych i warto je rozróżniać:

• Dane z pola — rzeczywiste pomiary od użytkowników Chrome'a. To one trafiają do oceny strony.
• Dane laboratoryjne — jednorazowy test Lighthouse na symulowanym łączu. Przydatne do diagnozy, ale potrafią się rozjechać z tym, co widzą ludzie.

Google ocenia trzy wskaźniki, mierzone na 75. percentylu wejść — czyli próg musi spełnić trzy czwarte odwiedzin, osobno na telefonach i na komputerach:

• LCP (największy element treści) — 2,5 sekundy lub mniej.
• INP (reakcja na interakcję) — 200 milisekund lub mniej. Zastąpił wcześniejszy wskaźnik FID.
• CLS (przeskoki układu) — 0,1 lub mniej.

Oddziel wolny serwer od ciężkiej strony

To najważniejszy podział w całej diagnozie. Spójrz na czas odpowiedzi serwera, czyli moment, w którym przeglądarka dostaje pierwszy bajt dokumentu. Lighthouse uznaje ten test za niezaliczony powyżej 600 milisekund; w rekomendacjach Core Web Vitals granica jest ustawiona na 800 milisekund.

Jeśli serwer odpowiada wolno, żadna kompresja obrazków tego nie naprawi — pracujesz po złej stronie. Typowe przyczyny:

1. Brak cache'owania odpowiedzi. Strona generuje się od zera przy każdym wejściu, choć dla większości podstron wynik jest identyczny.
2. Zapytania do bazy. Jedno widoczne opóźnienie to często kilkaset zapytań na stronę — klasyczny problem N+1, gdy w pętli dociągane są dane powiązane.
3. Brak cache'u obiektowego. Redis albo Memcached zdejmują z bazy powtarzalne odczyty.
4. Przeciążony lub współdzielony serwer. Czas odpowiedzi skacze zależnie od obciążenia sąsiadów, nie od Twojego kodu.

Jak to szybko rozstrzygnąć? Sprawdź czas odpowiedzi kilka razy, w różnych godzinach, dla tej samej podstrony. Stabilnie wysoki wynik wskazuje na kod albo bazę. Wynik, który skacze od 200 ms do 2 sekund, wskazuje na serwer.

Po stronie przeglądarki

Gdy serwer odpowiada szybko, a strona nadal się wlecze, czas zajmuje to, co przeglądarka musi pobrać i wykonać:

• Obrazy. Najczęstsza pojedyncza przyczyna. Zdjęcie 4000 px wyświetlane w kontenerze 800 px marnuje transfer. Skaluj do rzeczywistych rozmiarów, podawaj width i height, używaj formatów WebP lub AVIF i loading="lazy" poza pierwszym ekranem.
• Blokujące skrypty i arkusze. Wszystko w <head> bez defer albo async wstrzymuje wyświetlenie treści.
• Skrypty zewnętrzne. Czaty, mapy, piksele reklamowe i testy A/B. Każdy to osobne połączenie i kod, nad którym nie masz kontroli.
• Fonty. Bez font-display: swap tekst czeka na pobranie kroju.

Przeskoki układu

CLS to inny rodzaj problemu — strona może być szybka i nadal irytująca, jeśli treść ucieka spod palca. Winowajcy są powtarzalni: obrazy i ramki bez zadeklarowanych wymiarów, banery zgody na cookies wstawiane nad treścią oraz fonty zmieniające wysokość wiersza po podmianie. Rezerwuj miejsce na elementy, które dogrywają się później.

Kolejność, która się opłaca

Najpierw zmierz i zapisz wynik. Potem napraw czas odpowiedzi serwera, bo on dotyczy każdej podstrony naraz. Następnie weź obrazy z pierwszego ekranu, dalej skrypty zewnętrzne, na końcu detale. Po każdej zmianie zmierz ponownie — bez tego nie wiesz, co pomogło, a dane z pola aktualizują się z opóźnieniem, więc efektu nie zobaczysz od razu.