Naprawianie stron ze słabym wynikiem w testach
Kolejność napraw według stosunku zysku do kosztu. Tekst z 2019 roku, napisany od nowa w 2026 — bo przyczyny wolnych stron przez siedem lat prawie się nie zmieniły.
Zaczynasz od najtańszej rzeczy, nie od najciekawszej
Naprawianie strony ma tę własność, że pierwsze dwadzieścia procent pracy daje osiemdziesiąt procent zysku, a ostatnie dwadzieścia potrafi kosztować więcej niż całe wcześniejsze. Dlatego kolejność ma znaczenie większe niż wybór narzędzi.
Poniżej jest ta kolejność. Sprawdza się na tyle powtarzalnie, że kiedy klient przychodzi z „stroną, która ledwo dycha”, zaczynamy zawsze tak samo — i zwykle po dwóch pierwszych punktach dalszej pracy już nie potrzeba.
Kolejność
-
1
Obrazy
Najczęstsza przyczyna i najtańsza naprawa. Właściwy format (WebP albo AVIF zamiast JPEG z aparatu), rozmiar odpowiadający miejscu wyświetlania, wymiary podane w kodzie, leniwe ładowanie poniżej pierwszego ekranu. Samo to daje często połowę zysku i zajmuje kilka godzin.
-
2
Skrypty firm trzecich
Policz je. Czat, dwa narzędzia analityczne, piksel reklamowy, mapa, widżet opinii, baner zgody. Każdy to osobne połączenie i kod do wykonania. Usuń te, których nikt nie używa — zwykle jest to połowa. Zwykle nikt nie wie, kto je dodał.
-
3
Kroje pisma
Serwuj z własnego serwera, nie z cudzego. Wczytuj wcześnie. Ogranicz do znaków, których naprawdę używasz — polski alfabet plus interpunkcja to ułamek pełnego kroju. Ustal sensowne zachowanie na czas ładowania, żeby tekst nie znikał i nie przeskakiwał.
-
4
Cache
Nagłówki po stronie serwera, żeby wracający odwiedzający nie pobierał tego samego drugi raz. Pół dnia pracy, efekt na każdej kolejnej odsłonie. Uwaga: bez nazw plików zawierających skrót zawartości nie ustawiaj długich okresów, bo zostawisz ludzi ze starą wersją.
-
5
Baza i zapytania
Ostatnia, bo najdroższa. Ma sens, gdy sam serwer odpowiada dłużej niż pół sekundy. Zwykle chodzi o brakujące indeksy albo o zapytanie w pętli — czyli o jedną poprawkę, nie o przepisanie systemu.
Trzy typowe przypadki i co je naprawiło
-
Sklep, karta produktu 6 sekund
Zdjęcia wgrywane prosto z aparatu, po 3–5 MB każde, wyświetlane w kontenerze 400 pikseli. Przetworzenie i podanie właściwych rozmiarów: 6 s → 1,8 s. Jeden dzień pracy.
-
Strona firmowa, wynik 34
Cztery skrypty analityczne z trzech różnych wdrożeń przez lata, karuzela z pięcioma zdjęciami na starcie i osiem krojów pisma. Usunięcie zbędnych: wynik 34 → 91. Pół dnia.
-
Portal, serwer odpowiada 2,4 s
Zapytanie o pola niestandardowe bez indeksu, wykonywane raz na każdy z 40 wpisów na liście. Jeden indeks i jedno zapytanie zbiorcze: 2,4 s → 180 ms.
Czego nie robić
- Nie kupuj mocniejszego hostingu jako pierwszego kroku. Jeśli strona ładuje 6 MB obrazów, serwer nie ma z tym nic wspólnego.
- Nie instaluj wtyczki „optymalizującej” na wierzchu problemu. Zwykle dokłada własny kod do i tak przeciążonej strony.
- Nie minifikuj i nie łącz plików, zanim nie usuniesz tych, których nie potrzebujesz. To optymalizowanie balastu.
- Nie goń wyniku 100. Ostatnie punkty kosztują wielokrotnie więcej niż pierwsze i nie odczuje ich żaden użytkownik.
- Nie wyłączaj rzeczy, które są potrzebne — czatu, z którego korzysta obsługa, albo analityki, na której opierasz decyzje. Przenieś je, opóźnij, ale nie usuwaj po cichu.
Pytania
- Ile to zwykle trwa?
- Przy typowej zaniedbanej stronie zejście z 5–6 sekund do poniżej 2 to dwa–trzy dni pracy. Pierwszy dzień daje zwykle większość zysku.
- Czy trzeba przebudować stronę?
- Prawie nigdy. Optymalizacja to praca na tym, co jest. Przebudowa ma sens dopiero, gdy strona składa się z kilkudziesięciu wtyczek, których nie da się rozplątać bez ryzyka.
- Czy poprawa szybkości podniesie pozycje w Google?
- Może pomóc, bo Core Web Vitals są jednym z czynników. Ale większy i pewniejszy zysk jest gdzie indziej: w liczbie osób, które doczekały do załadowania strony.
Podaj adres — powiemy, co daje najwięcej.
Pomiar i lista priorytetów są bezpłatne. Naprawy wyceniamy po nich.
Napisz do nas