Optymalizacja szybkości strony: praktyczna kolejność pracy
Praca nad szybkością ma bardzo nierówny rozkład: garść interwencji odpowiada za większość poprawy na większości stron, i są to niemal zawsze obrazy, odpowiedź serwera i zewnętrzne skrypty.
Ten przewodnik omawia kolejność pracy, sposób pomiaru, czy zmiana pomogła, i optymalizacje, które zwykle nie są warte wysiłku.
Zmierz przed zmianą#
Optymalizowanie bez pomiaru to naprawianie tego, co najłatwiejsze, zamiast tego, co wolne. Dwa pomiary, potem praca.
- Pobierz dane terenowe od realnych odwiedzających — raport Core Web Vitals albo własny monitoring.
- Uruchom test laboratoryjny na trzech głównych szablonach, ograniczony do średniego telefonu w 4G.
- Zapisz liczby przed startem. Bez punktu odniesienia nie ocenisz, czy coś pomogło.
- Ustal dla każdego szablonu największy pojedynczy plik i największe żądanie blokujące.
- Zanotuj osobno Time to First Byte: powyżej 800 ms żadna praca front-endowa cię nie uratuje.
Kolejność, która się opłaca#
Mniej więcej według poprawy na godzinę wysiłku, dla typowej strony firmowej lub treściowej.
| Praca | Typowy zysk | Wysiłek |
|---|---|---|
| Optymalizacja i skalowanie obrazów | Duży | Niski |
| Usunięcie nieużywanych zewnętrznych skryptów | Duży | Niski — głównie polityczny |
| Włączenie cache'u i CDN | Duży | Niski |
| Naprawa blokującego CSS i JS | Średni do dużego | Średni |
| Zmniejszenie paczki JavaScriptu | Średni do dużego | Średni do wysokiego |
| Naprawa wolnych zapytań do bazy | Duży tam, gdzie dotyczy | Średni |
| Optymalizacja ładowania krojów | Średni | Niski |
| Minifikacja i kompresja tekstu | Mały | Niski — zwykle już włączone |
| Mikrooptymalizacja selektorów CSS | Znikomy | Nie warto |
Obrazy: zwykle największy zysk#
Na większości stron obrazy stanowią większość wagi, a większość jest serwowana wielokrotnie większa, niż jest wyświetlana. To najtańsza duża poprawa, jaka istnieje.
- Serwuj WebP albo AVIF; oba mają szerokie wsparcie i są zwykle o 25 do 50 % mniejsze niż JPEG przy tej samej jakości.
- Generuj kilka rozmiarów i używaj srcset z sizes, żeby telefony pobierały pliki telefonowe.
- Nigdy nie serwuj obrazu 2000 px w ramce 400 px — ten pojedynczy błąd jest nadzwyczaj częsty.
- Ładuj z opóźnieniem wszystko poniżej linii zgięcia i nic powyżej.
- Zautomatyzuj w buildzie albo w CMS. Ręcznie zoptymalizowane obrazy przestają być zoptymalizowane, gdy ktoś inny wgra własny.
- Usuwaj metadane; EXIF z aparatu potrafi ważyć dziesiątki kilobajtów na plik.
Automatyzacja jest sednem. Jednorazowa runda optymalizacji traci ważność w miesiącach wraz z napływem treści, i nikt tego nie zauważa, aż waga się podwoi.
Zewnętrzne skrypty i serwer#
Dwa obszary, w których problem jest zwykle organizacyjny, a nie techniczny: nikt nie jest właścicielem menedżera tagów i nikt nie jest właścicielem wyboru hostingu.
| Problem | Co zrobić |
|---|---|
| Menedżer tagów z nieznanymi tagami | Zaudytować każdy; usunąć to, czego nikt nie uzasadni |
| Widżet czatu na każdej podstronie | Ładować po interakcji albo tylko tam, gdzie potrzebne wsparcie |
| Kilka narzędzi analitycznych | Zostawić jedno; każde to skrypt i połączenie |
| Skrypt testów A/B blokujący renderowanie | Przenieść na serwer albo zaakceptować mignięcie i ładować async |
| Wolny TTFB na hostingu współdzielonym | Cache pełnych stron; wyższy plan, jeśli utrzymuje się |
| Zapytania bez cache'u | Cache'ować drogie; indeksy dla częstych |
| Brak CDN | Dodać — najtańsza globalna poprawa opóźnień |
Zewnętrzne skrypty to najpewniejsze źródło niewyjaśnionej powolności, bo zmieniają się bez uprzedzenia i są poza twoim procesem wdrożeń.
Najczęstsze pytania
Jaki czas ładowania jest dobry?
Użyteczne cele to progi Core Web Vitals, a nie jedna liczba: LCP poniżej 2,5 sekundy i Time to First Byte poniżej 800 ms. Całkowity czas ładowania jest złą miarą, bo strona bywa użyteczna dużo wcześniej niż zakończy się pobieranie wszystkich plików — a na wolnym urządzeniu bezużyteczna dużo wcześniej.
Czy szybsza strona podnosi konwersję?
Zwykle tak, a efekt jest największy tam, gdzie strony są wolne, a odwiedzający korzystają z sieci komórkowych. Zysk z trzech sekund do dwóch jest znacznie większy niż z półtorej do jednej. Jeśli strona jest już szybka, wydaj wysiłek na treść i jasność — zwrot będzie lepszy.
Czy wtyczki cache rozwiązują wszystko?
Rozwiązują dobrze jedną realną rzecz — powtarzalną pracę serwera dla tej samej strony — i potrafią stworzyć nowe problemy, zwłaszcza przy zalogowanych użytkownikach, koszykach i formularzach. Nie robią też nic ze zbyt dużymi obrazami ani zewnętrznymi skryptami, które są zwykle większym problemem. Przydatne, niewystarczające.
Czy renderowanie na serwerze opłaca się dla szybkości?
Jeśli twoje podstrony renderują się dziś wyłącznie w przeglądarce — tak: renderowanie na serwerze albo generowanie statyczne usuwa całą podróż tam i z powrotem przed pojawieniem się treści, a przy okazji pomaga indeksacji. Jeśli podstrony to już HTML z serwera, pytanie nie występuje — masz tę przewagę.
optymalizacja szybkości stronyszybkość ładowaniawydajność stronyoptymalizacja obrazówcachecdn
