Wolna strona kosztuje klientów — o szybkości ładowania po ludzku

Co się dzieje w pierwszych sekundach

Człowiek, który klika w wynik wyszukiwania, ma bardzo małą cierpliwość — mierzoną w sekundach, nie minutach. Jeśli w tym czasie nie zobaczy nic sensownego, wraca do wyników i klika następną pozycję. Z perspektywy Google taki powrót jest sygnałem, że strona nie odpowiedziała na potrzebę użytkownika.

Co gorsza, ten efekt kumuluje się właśnie tam, gdzie boli najbardziej: na telefonie, przy słabym zasięgu, czyli w sytuacji, w której klient szuka usługi „na już”.

Core Web Vitals bez żargonu

Google sprowadza doświadczenie ładowania do trzech mierzalnych rzeczy:

• LCP — po jakim czasie pojawia się największy, główny element strony (zwykle zdjęcie w nagłówku albo tytuł). Odpowiada na pytanie: „czy coś już widzę?”.
• INP — jak szybko strona reaguje, gdy w coś klikniesz. Odpowiada na pytanie: „czy to w ogóle działa?”. Ten wskaźnik zastąpił wcześniejszy FID.
• CLS — czy elementy skaczą podczas ładowania. Każdy zna sytuację, w której chce się kliknąć przycisk, a w ostatniej chwili doładowuje się baner i klika się w reklamę.

Nie trzeba tego umieć liczyć. Wystarczy wiedzieć, że wszystkie trzy dotyczą tego samego: czy strona zachowuje się przewidywalnie i szybko.

Co najczęściej spowalnia strony

• Zdjęcia wrzucone prosto z aparatu — pojedynczy plik potrafi ważyć kilka megabajtów, a wyświetla się w oknie o szerokości kilkuset pikseli.
• Nadmiar wtyczek — każda dokłada własne skrypty i style, ładowane na każdej podstronie, nawet jeśli są używane tylko w jednym miejscu.
• Uniwersalne motywy graficzne — zbudowane tak, żeby obsłużyć każdy możliwy układ, więc wczytujące kod do funkcji, których nigdy nie użyjesz.
• Skrypty zewnętrzne — czaty, piksele reklamowe, mapy, widżety opinii. Każdy z osobna wygląda niewinnie, razem potrafią podwoić czas ładowania.
• Kilka rodzin fontów naraz — każda waga i odmiana to osobny plik do pobrania.
• Slidery i animowane tła — kosztują dużo, a badania użyteczności od lat pokazują, że prawie nikt nie ogląda drugiego slajdu.

Zdjęcia — największy pojedynczy problem

W większości wolnych stron, które oglądam, ponad połowa wagi to zdjęcia. To zarazem najłatwiejsza rzecz do naprawienia.

Trzy rzeczy załatwiają zdecydowaną większość problemu: przeskalowanie zdjęcia do rozmiaru, w jakim faktycznie się wyświetla, zapisanie go w nowoczesnym formacie (WebP zamiast JPG), oraz leniwe ładowanie, dzięki któremu zdjęcia spoza pierwszego ekranu pobierają się dopiero wtedy, gdy użytkownik do nich doscrolluje.

Do tego dochodzi drobiazg, o którym często się zapomina: podanie wymiarów obrazu w kodzie. Dzięki temu przeglądarka rezerwuje miejsce jeszcze przed pobraniem pliku i układ strony nie przeskakuje — czyli poprawia się wskaźnik CLS.

Jak sprawdzić własną stronę

Najprościej wpisać adres strony w narzędzie PageSpeed Insights od Google. Dostaniesz wynik osobno dla telefonu i komputera oraz listę konkretnych rzeczy do poprawienia, posortowaną według tego, ile czasu każda z nich kosztuje.

Dwie uwagi. Po pierwsze: liczy się wynik na telefonie, bo stamtąd przychodzi większość ruchu. Po drugie: nie ma sensu gonić za wynikiem 100 na 100. Zielony wynik i strona, która realnie otwiera się szybko, wystarczą — ostatnie punkty zwykle kosztują nieproporcjonalnie dużo pracy przy zerowym zysku dla klienta.

Czego nie da się naprawić bez przebudowy

Jeśli strona jest zbudowana na ciężkim, uniwersalnym motywie z kilkunastoma wtyczkami, optymalizacja przypomina odchudzanie samochodu przez wyjmowanie foteli. Da się poprawić wynik o kilka punktów, ale fundament pozostaje ten sam.

Dlatego strony, które robię, powstają od zera — bez gotowych motywów i bez wtyczek dokładanych „na wszelki wypadek”. Strona ładuje dokładnie ten kod, którego potrzebuje, i nic ponadto. To nie jest szczególne osiągnięcie, tylko konsekwencja pisania kodu ręcznie. Więcej o technicznej stronie pracy piszę przy okazji pozycjonowania.