Dlaczego warto badać szybkość ładowania strony?
Szybkość ładowania wpływa na wygodę użytkownika i na widoczność w Google, bo podstawowe wskaźniki internetowe (Core Web Vitals) należą do sygnałów jakości, które według dokumentacji Google "nasze najważniejsze systemy rankingowe starają się nagradzać". Do pomiaru Google udostępnia bezpłatne narzędzie PageSpeed Insights, które pokazuje kondycję techniczną strony i proponuje konkretne działania naprawcze.
Raport obejmuje osobno wersję mobilną i komputerową, a wyniki łączą dane od prawdziwych osób z testem w symulowanym środowisku. Z PageSpeed Insights korzystają programiści, właściciele firm, marketerzy i specjaliści od pozycjonowania stron, bo każdy z tych zawodów potrzebuje wglądu w wydajność.
Jak działa PageSpeed Insights?
Po wpisaniu adresu URL narzędzie analizuje stronę i przedstawia:
- ocenę w skali 0-100, w której 90 i więcej to wynik dobry, 50-89 wymaga poprawy, a poniżej 50 jest słaby,
- czas wczytywania głównych elementów i stabilność układu (LCP, INP, CLS),
- zalecenia optymalizacyjne w podziale na priorytety,
- dane z rzeczywistych wizyt z ostatnich 28 dni (jeśli są dostępne).
Test uruchamiasz cyklicznie, np. po aktualizacji strony, wdrożeniu nowego szablonu albo zmianach w nawigacji. PageSpeed Insights pokazuje dwa rodzaje danych: laboratoryjne z Lighthouse (symulacja w kontrolowanym środowisku, w kategoriach wydajność, dostępność, sprawdzone metody i SEO) oraz terenowe od użytkowników Chrome, zebrane w raporcie Chrome User Experience Report (CrUX). Dane z Chrome wymagają wystarczającej liczby wizyt, więc dla nowej albo mało odwiedzanej podstrony zostaje sam test Lighthouse.
Które metryki mierzy PageSpeed Insights?
PageSpeed Insights ocenia przede wszystkim 3 podstawowe wskaźniki internetowe, liczone na 75. percentylu wizyt, osobno dla telefonów i komputerów. Dokumentacja Google o Core Web Vitals opisuje je jako część jakości strony, którą nagradzają systemy rankingowe, a algorytm Google łączy ten sygnał z wieloma innymi.
LCP, czyli największe wyrenderowanie treści
LCP mierzy, jak szybko pojawia się największy element widoczny na ekranie, np. obraz główny, baner lub nagłówek sekcji startowej. Dobry wynik to do 2,5 s, przedział 2,5-4 s wymaga poprawy, a powyżej 4 s LCP uznaje się za słabe. Opóźnienie często wynika z nieoptymalizowanych obrazów, wolnego hostingu lub braku wczesnego pobierania krytycznych zasobów. Element, o który chodzi, pokazuje diagnostyka raportu PageSpeed, a priorytet ładowania nadajesz mu np. przez <link rel="preload"> dla czcionek czy obrazu głównego.
INP, czyli interakcja do kolejnego wyrenderowania (dawniej FID)
INP mierzy, jak szybko strona reaguje na kliknięcia, dotknięcia i naciśnięcia klawiszy w czasie całej wizyty, i zastąpił FID jako podstawowy wskaźnik, a obsługę FID web.dev zakończył 9 września 2024 r. Dobry wynik to do 200 ms, przedział 200-500 ms wymaga poprawy, powyżej 500 ms jest słaby. Wysokie wartości INP oznaczają, że główny wątek przeglądarki jest zajęty wykonywaniem kodu JavaScript, co często dotyczy stron z dużą liczbą zewnętrznych bibliotek, reklam lub tagów analitycznych. Rozwiązanie polega na rozłożeniu obciążenia w czasie (code splitting) lub odroczeniu mniej potrzebnych skryptów.
CLS, czyli skumulowane przesunięcie układu
CLS mierzy, czy elementy strony "skaczą" w czasie ładowania, np. gdy klikasz przycisk, a on przesuwa się w dół, bo doczytała się reklama lub obraz bez zdefiniowanych wymiarów. Za dobry uznaje się CLS do 0,1, a powyżej 0,25 za słaby. Web.dev jako przyczyny podaje m.in. "obrazy lub filmy o nieznanych wymiarach" oraz elementy dynamicznie dodawane przed istniejącą treścią, więc deklarujesz width i height dla grafik i nie wstrzykujesz komunikatów cookie ani banerów promocyjnych nad zawartością.
Jakie problemy najczęściej wskazuje PageSpeed Insights?
PageSpeed Insights najczęściej zgłasza 5 grup problemów, które obniżają ocenę i pogarszają odczucia odwiedzających:
- nieoptymalne obrazy: zbyt duże pliki, brak kompresji lub nowoczesnych formatów (WebP, AVIF),
- blokujący JavaScript: kod ładowany zbyt wcześnie lub bez potrzeby, który opóźnia renderowanie,
- brak cache przeglądarki: brak nagłówków HTTP, dzięki którym pliki zostają zapisane lokalnie,
- zbędne style i skrypty, np. z nieużywanych wtyczek, motywów lub zapomnianych integracji,
- brak lazy loading dla obrazów poniżej pierwszego ekranu i ramek iframe (np. filmów YouTube).
Nie każde zalecenie wdrażasz od razu: pierwszeństwo mają te, które poprawiają LCP, INP i CLS. Niektóre sugestie (np. "usuń nieużywany JavaScript") wymagają ingerencji w kod szablonu lub wyłączenia wtyczki, dlatego przed zmianą sprawdzasz, czy dany element jest faktycznie zbędny, czy tylko rzadko używany, np. na 1 podstronie z formularzem.
Jak poprawić wynik PageSpeed w praktyce?
Wynik PageSpeed poprawiasz krok po kroku, zaczynając od kopii zapasowej i dostępu do kodu lub panelu CMS. Testuj 1 zmianę na raz, aby zobaczyć jej wpływ na ocenę i stabilność działania.
Optymalizacja obrazów
Zastosuj:
- kompresję bez widocznej utraty jakości (np. TinyPNG, Squoosh, ImageOptim),
- format WebP lub AVIF zamiast JPEG/PNG,
- rozmiary dopasowane do układu strony: nie ładuj obrazu 3000×2000 px, jeśli wyświetla się on w kontenerze 600×400 px,
- atrybuty
widthiheightw tagu<img>, aby przeglądarka mogła zarezerwować miejsce przed załadowaniem.
Przy dużych galeriach zdjęć i sklepach internetowych opłaca się automatyczna konwersja i kompresja na serwerze lub przez CDN, który przetwarza obrazy w locie.
Wydzielenie i minimalizacja kodu
Usuń lub połącz zbędne pliki CSS i JS, ręcznie (edytując functions.php w WordPressie) albo wtyczką (np. Autoptimize, WP Rocket, Asset CleanUp). Zwróć uwagę na niewykorzystane reguły CSS: jeśli motyw ładuje style dla elementów, których nie używasz (np. wyłączonego slidera), możesz je wyciąć. Podobnie z JavaScript, bo wiele stron wczytuje jQuery i dodatkowe biblioteki globalnie, choć potrzebne są tylko na jednej podstronie.
Włączenie cache
Pamięć podręczna przechowuje kopie po stronie serwera (obiekty z bazy, gotowe pliki HTML) lub w przeglądarce (nagłówki Cache-Control, Expires), więc kolejne wizyty nie pobierają wszystkiego od nowa. W WordPressie wystarczy wtyczka WP Rocket lub W3 Total Cache, a dla stron statycznych odpowiednia konfiguracja nginx (moduł proxy_cache). Podstrony dynamiczne (np. koszyk, panel klienta) wykluczasz z tej pamięci, aby nie pokazywać nieaktualnych danych.
Lazy loading i preload
Obrazy i ramki poza pierwszym ekranem ładujesz dopiero wtedy, gdy użytkownik do nich przewija. Wystarczy atrybut loading="lazy" w tagu <img> albo skrypt (np. lazysizes.js). Web.dev zaleca jednak, by nie stosować leniwego ładowania do obrazów, które będą widoczne zaraz po wczytaniu strony. Dla zasobów krytycznych (np. logo w nagłówku, czcionka na pierwszym ekranie) zastosuj <link rel="preload">, aby przeglądarka pobrała je priorytetowo. Ogranicz go do kilku plików, bo nadmiar może spowolnić ładowanie zamiast je przyspieszyć.
Wybór lekkiego motywu i szybkiego hostingu
Bez lekkiego szablonu i szybkiego hostingu inne poprawki dają niewiele, bo nie uratują projektu z kilkunastoma sliderami, animacjami i dużą liczbą zapytań do bazy danych. Wybierz motyw zoptymalizowany pod wydajność (np. GeneratePress, Astra, Kadence) i serwer z obsługą HTTP/2, np. LiteSpeed, który sprawnie przesyła wiele małych plików. Rozważ też CDN (Content Delivery Network), który wysyła statyczne zasoby (obrazy, CSS, JS) z maszyn położonych bliżej użytkownika.
Jak kontrolować zmiany i testować efekty?
Po każdej aktualizacji uruchamiasz ponownie test PageSpeed i porównujesz go z dodatkowymi narzędziami:
- Google Search Console: raport Core Web Vitals grupuje adresy URL w 3 stanach, od "Dobrej jakości" przez "Wymagana poprawa" do najsłabszego, na podstawie danych z ostatnich 28 dni i pokazuje słabe podstrony w skali całej domeny,
- WebPageTest.org: szczegółowy zapis ładowania (tzw. waterfall), testy z różnych lokalizacji i urządzeń, wykrywanie blokujących zasobów i wąskich gardeł,
- Lighthouse (w Chrome DevTools): test lokalny bez danych historycznych, przydatny do weryfikacji zmian przed wdrożeniem na produkcję.
Dane terenowe w PageSpeed Insights i w Search Console obejmują 28 dni, więc efekt poprawki widać w nich w pełni dopiero po 28 dniach, a test laboratoryjny pokazuje różnicę od razu. Regularna kontrola i stopniowe wdrażanie poprawek dają lepszy wynik i szybsze ładowanie strony. Optymalizacja to proces ciągły: aktualizacje CMS, wtyczek i treści zmieniają wydajność, dlatego PageSpeed Insights sprawdzasz co najmniej raz na kwartał i po każdej większej modyfikacji. Szybkość jest też jednym z obszarów audytu SEO w Bizzit, który kosztuje 2 000 zł netto i kończy się raportem z listą poprawek i priorytetami.
