Krótko: najpierw zmierz szybkość poprawnie — na mobile i na danych realnych użytkowników, a nie na jednym wyniku narzędzia. Potem naprawiaj według siły wpływu: obrazy, zbędne skrypty i wtyczki, odpowiedź serwera, brak cache. Większość problemów rozwiązuje kilka dni pracy. Ale jeśli strona jest złożona na kreatorze wizualnym z dwudziestoma wtyczkami, optymalizacja uderzy w sufit architektury i taniej wyjdzie przebudować niż w nieskończoność przyspieszać.
Wolną stronę widać nie po liczbach, tylko po zachowaniu: ludzie wychodzą, nie doczekawszy pierwszego ekranu. Właściciel widzi tymczasem co innego — wynik w PageSpeed, który chciałby doprowadzić do zielonego.
To zły cel. Wynik narzędzia i realna szybkość u Waszych odwiedzających to dwie różne rzeczy, a zacząć trzeba od ustalenia, co konkretnie jest wolne i dla kogo.
Jak poprawnie zmierzyć szybkość ładowania strony
Oddzielcie dane laboratoryjne od terenowych. PageSpeed Insights pokazuje dwie rzeczy: wynik testowego przebiegu na umownym urządzeniu oraz dane realnych użytkowników, jeśli jest ich dość. Pierwsze przydaje się do diagnozy, drugie jest jedynym, co liczy się w praktyce. Wynik bywa żółty, a realni odwiedzający widzą stronę szybko — i odwrotnie.
Zajrzyjcie do raportu w Search Console. Sekcja podstawowych wskaźników internetowych pokazuje, które grupy adresów są wolne dla prawdziwych ludzi. To punkt odniesienia, a nie ocena z narzędzia.
Mierzcie wersję mobilną. Większość ruchu jest mobilna, a problemy ujawniają się właśnie tam: słabszy procesor, gorsze łącze.
Nie wyciągajcie wniosków z jednego pomiaru. Wyniki się wahają; liczy się powtarzalność, a nie pojedyncza liczba.
Sprawdzajcie nie tylko stronę główną. Główna zwykle jest dopieszczona, a ruch idzie na podstrony usług i artykuły. Sprawdźcie te dwadzieścia podstron, które przynoszą odwiedzających i zapytania — optymalizowanie dwustu nieistotnych nie ma sensu.
Dlaczego strona ładuje się wolno: przyczyny według siły wpływu
Ciężkie obrazy. Najczęstsza i najtańsza w naprawie przyczyna. Zdjęcia wgrane prosto z aparatu ważą megabajty, a wyświetlają się w bloku szerokim na kilkaset pikseli. Leczy się kompresją, nowoczesnymi formatami i rozmiarami pod urządzenie.
Nadmiar wtyczek i skryptów. Każda wtyczka dokłada własne style i kod, często na wszystkich podstronach, także tych, gdzie jej funkcja nie jest używana. Dwadzieścia wtyczek to dwadzieścia zestawów plików przy każdym wczytaniu.
Wolna odpowiedź serwera. Jeśli serwer długo myśli, cała reszta przesuwa się w czasie. Przyczyny to słaby hosting, przeciążona baza, brak cache.
Brak cache. Bez niego strona składa się od nowa przy każdym wejściu. Włączenie cache to jedna z niewielu zmian o niemal natychmiastowym efekcie.
Blokujące style i skrypty. Przeglądarka nie pokaże treści, dopóki nie pobierze tego, co stoi w kolejce przed nią.
Czcionki. Kilka krojów pobieranych z obcej domeny opóźnia pojawienie się tekstu.
Skrypty zewnętrzne. Czaty, analityka, piksele systemów reklamowych, widżety opinii. Każdy wygląda niewinnie, razem dają wyraźny ciężar — a ich szybkości nie kontrolujecie.
Brak wymiarów obrazów i bloków. Nie wpływa wprost na szybkość, ale powoduje przeskakiwanie układu podczas wczytywania, co drażni bardziej niż samo czekanie.
Tabela: co spowalnia stronę i kto to naprawia
- Pierwszy ekran pojawia się długo — Ciężki obraz w nagłówku, wolny serwer — Często własnymi siłami
- Strona „myśli" przed rozpoczęciem ładowania — Odpowiedź serwera, brak cache — Hosting albo programista
- Wszystko widać, ale nie reaguje na kliknięcia — Ciężki JavaScript, nadmiar wtyczek — Programista
- Układ przeskakuje przy wczytywaniu — Brak wymiarów obrazów i bloków — Programista
- Na mobile wielokrotnie wolniej — Nieoptymalne obrazy, ciężkie skrypty — Mieszanie
- Optymalizacja nie daje efektu — Sufit architektury — Przebudowa
Co da się poprawić samodzielnie w jeden wieczór
Skompresować obrazy. Wgrać ponownie w rozsądnym rozmiarze i nowoczesnym formacie. To najczęstsza przyczyna i najszybsza wygrana.
Usunąć nieużywane wtyczki. Nie dezaktywować, tylko usunąć: połowa zwykle została zainstalowana „na próbę" i zapomniana.
Włączyć cache, jeśli go nie ma.
Usunąć zbędne skrypty zewnętrzne. Czat, z którego nikt nie korzysta, liczniki z trzech systemów analitycznych, widżety pozostałe po dawnej kampanii.
Sprawdzić hosting. Jeśli strona stoi na najtańszym pakiecie, przeprowadzka na sensowny bywa skuteczniejsza niż tygodnie optymalizacji.
Tych kroków wystarczy, żeby ocenić skalę problemu. Jeśli po nich szybkość nadal jest niska, dalej potrzebny jest programista.
Co wymaga programisty
Praca z czcionkami i kolejnością ładowania stylów, odroczenie drugorzędnych skryptów, krytyczny CSS, optymalizacja zapytań do bazy, usunięcie przeskoków układu, dostarczanie obrazów dopasowanych do urządzenia. Wszystko to daje wyraźny efekt, ale wymaga wiedzy, czego można dotknąć, a co się zepsuje.
Osobne ostrzeżenie: wtyczki „przyspieszające jednym kliknięciem" czasem pomagają, a czasem psują układ i funkcje. Sprawdza się je na kopii strony, nie na żywej.
Kiedy optymalizacja nie pomaga i potrzebna jest przebudowa
Jest moment, w którym dalsza optymalizacja zamienia się w walkę z architekturą.
Objawy: skompresowaliście obrazy, włączyliście cache, usunęliście połowę wtyczek, a wyniki prawie się nie zmieniły. Albo zmieniły się i wróciły po aktualizacji motywu. Albo każda poprawa psuje coś innego.
Przyczyna zwykle leży w sposobie złożenia strony. Kreator wizualny ładuje kod na wszystkie okazje, także funkcje, których na podstronie nie ma. Motyw kupiony jako uniwersalny ciągnie za sobą możliwości, których nie potrzebujecie. Optymalizować to można w nieskończoność, a sufit i tak zostanie.
Przykład z praktyki. Strona warszawskiego warsztatu renowacji felg działała na przestarzałej platformie i była wolna. Zbudowałem ją od nowa na autorskim motywie WordPress — bez kreatora i ciężkich wtyczek, żeby ładowało się wyłącznie to, co potrzebne. Mobilny wynik wydajności wzrósł z około 50 do 92. To nie efekt optymalizacji, tylko innego sposobu złożenia: ta sama treść, inna architektura.
Wniosek praktyczny: jeśli optymalizacja nie daje efektu dwa-trzy podejścia z rzędu, taniej policzyć koszt przebudowy niż ciągnąć dalej.
Czy szybkość strony wpływa na pozycje i zapytania
Uczciwie: szybkość jest czynnikiem rankingowym, ale nie głównym. Wolna strona z mocną treścią wyprzedzi szybką i pustą. Jeśli Wasze podstrony stoją na pięćdziesiątej pozycji, rzecz nie w szybkości.
Za to na zachowanie ludzi szybkość wpływa wprost, zwłaszcza na mobile. Odwiedzający, który nie doczekał pierwszego ekranu, nie zobaczy ani oferty, ani cen, ani przycisku. W tym sensie szybkość dotyczy nie SEO, tylko tego, czy ludzie w ogóle docierają do treści.
Właściwa kolejność jest więc taka: jeśli pozycji nie ma — najpierw widoczność. Jeśli ruch jest, a zapytań nie ma — szybkość trafia na krótką listę podejrzanych obok oferty i wygody kontaktu.
Jak pracuję z szybkością stron
Łączę tworzenie stron z SEO, więc patrzę na szybkość nie jak na wynik w narzędziu, tylko jak na element łańcucha od wyświetlenia w wyszukiwarce do zapytania.
Audyt techniczny — od 1000 zł. Co konkretnie spowalnia, w jakiej kolejności naprawiać, co da się zrobić własnymi siłami, a co opiera się o architekturę.
Przebudowa strony — od 4500 zł, jeśli z audytu wynika, że optymalizowanie istniejącej konstrukcji kosztuje więcej niż złożenie jej od nowa.
Czasem wynikiem audytu jest lista trzech rzeczy do zrobienia w jeden wieczór, i wtedy tak mówię: bywa, że przebudowa nie jest potrzebna.
Od czego zacząć, gdy strona ładuje się wolno
Sprowadzając do jednej zasady: najpierw zmierz na realnych użytkownikach, potem naprawiaj według siły wpływu i nie goń za wynikiem.
Krok praktyczny na dziś: otwórzcie raport podstawowych wskaźników internetowych w Search Console i zobaczcie, które grupy podstron są oznaczone jako problematyczne. Potem sprawdźcie te podstrony w PageSpeed na mobile. Te dwa kroki wystarczą, żeby wiedzieć, czy mowa o wieczorze pracy, czy o przebudowie.
Jeśli chcecie rozstrzygnąć to szybciej — napiszcie do mnie, sprawdzę, co konkretnie spowalnia Waszą stronę.
