Jak przyspieszyć stronę do 90+ PageSpeed

Wynik 90+ w Google PageSpeed to nie szczęście, lecz efekt metodycznej pracy nad każdym elementem łańcucha dostarczania strony: od serwera i bazy, przez zasoby, po interakcje użytkownika. Poniżej znajdziesz konkretny, krok po kroku plan, który pozwoli zdiagnozować wąskie gardła, ustawić priorytety i wdrożyć działania przynoszące realny wzrost szybkości. Skupimy się na praktykach, które poprawiają odczuwalną wydajność oraz stabilność interfejsu na urządzeniach mobilnych i desktopie.

Ustalanie celu i pomiar stanu wyjściowego

Poznaj metryki i ich wpływ na ocenę

Zanim zaczniesz optymalizację, upewnij się, że rozumiesz, jak mierzony jest wynik. Narzędzie PageSpeed Insights opiera ocenę na danych terenowych i laboratoryjnych. Szczególną rolę odgrywają Core Web Vitals, czyli wskaźniki skupione na doświadczeniu użytkownika: LCP (czas wyrenderowania największego elementu), INP (czas reakcji interfejsu) oraz CLS (stabilność układu). Pracując nad nimi, najszybciej zbliżysz się do progu 90+.

Zdefiniuj budżet wydajności i progi

Ustal budżet dla kluczowych zasobów i opóźnień. Przykład: maks. 150 kB CSS po minifikacji, 150–250 kB JS dla widoku, LCP do 2,5 s, INP w 200 ms, CLS poniżej 0,1, a alternatywnie TTFB w przedziale 200–500 ms. Taki budżet stanie się mapą decyzji: jeśli nowa biblioteka przekracza limity, szukasz lżejszego zamiennika lub odkładasz jej ładowanie do momentu interakcji użytkownika.

Wykonaj audyt: laboratorium i teren

Połącz wyniki z PSI, Lighthouse i WebPageTest. Testuj tryb mobilny (throttling) oraz wolniejsze sieci. Zwróć uwagę na drzewo zależności skryptów, priorytety zasobów, kolejkę żądań i opóźnienia serwera. W Lighthouse przeanalizuj listę „opportunities” i sprawdź sekcję „Diagnostics”, a w WebPageTest – „Waterfall” oraz inicjatorów żądań, by namierzyć rzeczy blokujące renderowanie i niepotrzebny transfer.

Profiluj w przeglądarce

Otwórz DevTools: zakładki Performance, Network i Coverage. Performance pokaże długie taski, zamrożenia UI i czasy interakcji; Network ujawni ciężkie pliki i błędne cache; Coverage wskaże procent niewykorzystanego CSS/JS. Zanotuj, które pliki CSS blokują render, które skrypty uruchamiają się za wcześnie, oraz które moduły są ładowane na stronach, gdzie nie są potrzebne.

Ustal priorytety działań

W pierwszej kolejności popraw LCP i CLS: skup się na zasobach bohatera (hero image, nagłówek, fonty) oraz rezerwacji miejsca dla elementów. Następnie zoptymalizuj ścieżkę krytyczną (CSS/JS), a potem media i serwer. Dopiero na końcu zajmij się detalami – kolejność ma największy wpływ na płynność prac i wzrost punktów najszybszym kosztem.

Przyspieszenie krytycznej ścieżki renderowania

Wyodrębnij i zastosuj krytyczny CSS

Wyrenderuj wstępnie styl dla widoku „nad linią załamania” i wstrzyknij go w dokument jako krytyczny CSS. Resztę arkuszy ładuj asynchronicznie. Zadbaj, aby krytyczny fragment był mały i aktualizowany automatycznie (np. w pipeline CI). Duże frameworki CSS dziel na komponenty; odrzuć nieużywane klasy, wykorzystując narzędzia do „purge”. To natychmiast skraca czas do pierwszego pełnego malowania.

Defer i async dla skryptów

Skrypty niekrytyczne (analityka, widżety) ładuj z atrybutami opóźniającymi, a inicjalizacje uruchamiaj po zdarzeniach interakcji. Podziel pakiet na moduły i wczytuj je na żądanie (code splitting). Dla przeglądarek wspierających ES Modules wykorzystaj strategię module/nomodule. Unikaj długich zadań na głównym wątku – dziel je na mniejsze lub przenieś do Web Workerów.

Priorytety zasobów i wskazówki dla przeglądarki

Skorzystaj z hintów ładowania: preload dla kluczowego CSS i fontów, preconnect/dns-prefetch do zewnętrznych domen i fetchpriority=high dla głównego obrazu. Utrzymuj spójność priorytetów – nie preloaderuj wszystkiego. Pamiętaj, że nadmierny preload może zablokować ważniejsze żądania. Sprawdzaj w „Network” i „Initiator”, czy przeglądarka nadaje zasobom oczekiwane priorytety.

Fonty bez migotania i opóźnień

Subsettuj fonty (tylko używane glify), ładuj formaty woff2, ustaw display: swap i rozważ wcześniejsze wczytanie metryki (font metrics). Preloaduj najważniejsze kroje i rozmiary, unikając nadmiaru wariantów. W razie potrzeby zastosuj font-face z unicode-range, aby dynamicznie dociągać rzadkie znaki. Zmniejszasz w ten sposób opóźnienia rysowania tekstu i ryzyko niestabilności układu.

Minimalny, stabilny DOM

Ogranicz liczbę elementów i zagnieżdżeń, aby skrócić pracę layoutu i malowania. Zapewnij atrybuty wymiarów obrazów i wideo, by zapobiec przesunięciom. Usuwaj niewidoczne elementy z pierwszego widoku, a dynamiczne komponenty renderuj leniwie. To wsparcie dla CLS oraz szybszego initial renderu, bez kosztownego reflow.

Media i zasoby statyczne

Obrazy: formaty, responsywność i lazy-loading

Konwertuj zdjęcia do WebP/AVIF, dobierając jakość do typu obrazu i rozdzielczości. Używaj atrybutów responsywnych i precyzyjnych rozmiarów, aby wysyłać tylko niezbędne piksele. Włącz leniwą dostawę (loading=lazy) dla wszystkich obrazów poza bohaterem ekranu, a dla obrazu LCP ustaw fetchpriority=high. Dodaj decoding=async, by nie blokować głównego wątku podczas dekodowania.

Wideo i osadzenia

Dla materiałów wideo stosuj preload=metadata oraz miniaturę poster, a same odtwarzacze ładuj dopiero przy przewinięciu do sekcji. Zastąp pełne iframy YouTube lekkimi placeholderami, które wczytują skrypt po kliknięciu. Ogranicz liczbę osadzonych widgetów i map – często wystarczy obraz zastępczy i przycisk „Pokaż mapę”, co znacząco zmniejsza ilość transferowanych skryptów.

Ikony, grafika wektorowa i sprity

Drobne ikony przenieś do SVG (inline dla kluczowych), większe zgrupuj w sprite. Optymalizuj SVG (usuwanie metadanych, skracanie ścieżek). To redukuje liczbę żądań i poprawia ostrość na ekranach o wysokiej gęstości pikseli. Gdy używasz fontów ikon, rozważ migrację na SVG, aby uniknąć opóźnień ładowania i problemów z dostępnością.

Kompresja i minifikacja

Włącz kompresję treści na serwerze, preferując Brotli dla tekstowych zasobów i Gzip jako fallback. Minifikuj HTML, CSS i JS, eliminując komentarze, białe znaki i zbędny kod. Dla plików z małą entropią (np. już skompresowane obrazy) wyłącz powtórną kompresję, aby nie marnować CPU. Regularnie weryfikuj poziomy kompresji w kontekście obciążenia serwera.

Strategie cache i dystrybucja

Ustal nagłówki Cache-Control dla statycznych zasobów (długie TTL + wersjonowanie w nazwach plików). Rozważ dystrybucję przez CDN, aby skrócić drogę pakietu do użytkownika i równoważyć obciążenie. Stosuj stale-while-revalidate do bezpiecznych odświeżeń w tle. Wersjonowanie plików pozwala serwować je z długą ważnością, bez ryzyka niezgodności po wdrożeniach.

Serwer, sieć i integracje zewnętrzne

Skróć TTFB i przyspiesz serwer

Wybierz nowoczesny stos: HTTP/2 lub HTTP/3, TLS 1.3, utrzymuj keep-alive i kompresuj nagłówki. Skrócenie TTFB osiągniesz dzięki cache’owi aplikacyjnemu, optymalizacji zapytań do bazy (indeksy, ograniczanie JOIN), pre-renderingowi popularnych podstron oraz warstwie edge, która odpowiada z najbliższego regionu. Mierz Server-Timing, by śledzić miejsca opóźnień.

CMS i baza danych

W systemach CMS porządkuj wtyczki i motywy: zostaw tylko potrzebne, aktualne i lekkie. Włącz cache obiektowy (np. Redis), aktywuj opcache dla PHP i unikaj generowania HTML przy każdym żądaniu. Zidentyfikuj najwolniejsze zapytania, dodaj indeksy i pamiętaj o limitach oraz paginacji. Łącz assety generowane dynamicznie w stabilne, wersjonowane pakiety.

Edge, CDN i przetwarzanie przy brzegu

Wdrażaj reguły na brzegu: kompresja, przepisywanie nagłówków, transformacje obrazów, geolokalizacja i autoglify. Dzięki temu odciążasz aplikację i skracasz czas transportu. CDN może serwować multimedia w odpowiednim formacie i rozmiarze per urządzenie, co eliminuje konieczność utrzymywania wielu wariantów po stronie serwera głównego.

Skrypty zewnętrzne pod kontrolą

Audytuj integracje: analityka, chat, mapy, testy A/B, piksele. Ładuj je leniwie, po interakcji lub zgodzie użytkownika, stosuj preconnect do ich domen i ograniczaj liczbę tagów w managerze. Korzystaj z opcji zredukowanych bibliotek (lite), sandboxuj iframy oraz ustaw ograniczenia uprawnień. Każdy zewnętrzny skrypt to potencjalny „zabójca” wyniku 90+.

Bezpieczeństwo i stabilność połączeń

Certyfikaty TLS aktualizuj automatycznie, wymuś HSTS i zadbaj o OCSP stapling. Włącz HTTP/3 tam, gdzie to możliwe, by skorzystać z lepszej odporności na utratę pakietów. Pamiętaj, że stabilne, szybkie połączenie redukuje nie tylko czasy pobierania, ale również minimalizuje błędy przy ładowaniu zasobów kluczowych dla renderowania.

Stabilność interfejsu i jakość interakcji

Zapobieganie przesunięciom układu

Atrybuty width/height i rezerwacja miejsca dla dynamicznych modułów to pierwszy krok do niskiego CLS. Unikaj wstrzykiwania banerów lub reklam nad treścią; jeśli musisz, zabezpiecz im stałą ramkę. Wstrzymaj animacje layoutu w pierwszych sekundach ładowania i preferuj transformacje GPU (translate/scale) zamiast zmian wymiarów czy top/left.

Reakcja interfejsu bez lagów

Monitoruj INP w narzędziach RUM (Real User Monitoring). Dzielenie długich zadań, stosowanie requestIdleCallback dla niekrytycznych prac, debouncing/throttling eventów oraz przeniesienie kosztownej logiki do Workerów wyraźnie poprawiają płynność. Optymalizuj render list (np. wirtualizacja), ogranicz liczbę listenerów i dbaj o czystość cyklu życia komponentów.

Hydratacja w częściach i ostrożny CSR

Jeśli używasz frameworków SPA/SSR, rozważ wyspy interaktywności (islands), częściową hydratację i ładowanie logiki komponentów dopiero, gdy wejdą w viewport. Unikaj globalnej, jednorazowej hydratacji całej strony, jeśli użytkownik zobaczy tylko fragment. Ten wzorzec skraca czas blokady głównego wątku i zmniejsza rozmiar początkowego pakietu JS.

Utrzymywanie spójności zasobów

Wersjonuj pliki, unikaj „hotfixów” poza pipeline i trzymaj kontrolę nad kolejnością ładowania stylów oraz skryptów. Wymuś jednolite reguły dla animacji, typografii i siatki, by uniknąć konfliktów CSS. Im bardziej przewidywalny zestaw zasobów, tym łatwiej utrzymać dobrą metrykę LCP oraz stabilne pierwsze wrażenie.

Monitoring, automatyzacja i praca ciągła

Wprowadź budżet wydajności do CI/CD

Ustal limity rozmiarów, ilości żądań i regresji metryk. Każde wdrożenie niech uruchamia testy Lighthouse i porównanie z poprzednim wynikiem. Jeśli budżet jest przekroczony, pipeline powinien wymagać akceptacji lub automatycznie odrzucać build. Taka dyscyplina powstrzymuje stopniowe „puchnięcie” frontu i chroni wynik 90+ przed erozją.

RUM i obserwacja w terenie

Zbieraj dane z realnych przeglądarek: wartości LCP, INP, CLS, a także błędy i czasy w poszczególnych regionach. Korzystaj z CrUX i własnych skryptów pomiarowych. Porównuj cohorty (np. sieć 3G vs 4G, urządzenia low-end vs high-end), aby priorytetyzować poprawki tam, gdzie przyniosą największy skok jakości.

Checklisty i przeglądy regresji

Buduj listy kontrolne dla grafików, redaktorów i developerów: limity rozdzielczości obrazów, zasady osadzania wideo, wybór komponentów, polityka skryptów zewnętrznych. Raz w tygodniu wykonuj szybki przegląd: waga bundla, liczba requestów, coverage CSS/JS, sygnały stabilności i error rate. Małe, regularne korekty są tańsze niż wielkie refaktoryzacje.

Świadome interpretowanie wyniku

Wynik 90+ na mobile jest trudniejszy niż na desktop – priorytetyzuj optymalizacje dla urządzeń o niskiej mocy i słabszych sieci. Nie „poluj” na każdy punkt, jeśli koszt przewyższa korzyści biznesowe. Celem jest spójnie szybkie doświadczenie: przewidywalny render, płynne przewijanie, szybkie interakcje i rozsądny transfer. Taka strategia utrzymuje wynik, zamiast jednorazowo go „wywindować”.