Szybkość strony internetowej: które problemy naprawdę odczuwa klient, a które widać tylko w raporcie?

Właściciel strony otwiera raport PageSpeed Insights i widzi 62 punkty na urządzeniach mobilnych. Czy to znaczy, że klienci uciekają, zanim zobaczą ofertę? A jeśli wynik wynosi 95 punktów, czy strona na pewno działa szybko?

Na oba pytania odpowiedź brzmi: nie da się tego stwierdzić na podstawie samej liczby punktów. Raport może wskazać ważny problem, ale trzeba jeszcze sprawdzić, na której podstronie występuje, ilu osób dotyczy i czy przeszkadza im w wykonaniu konkretnego działania.

Dla klienta szybkość strony jest prosta w ocenie. Czy widzi treść, której szuka? Czy po kliknięciu przycisku coś się dzieje? Czy może bez pomyłek wybrać produkt i wysłać formularz? Warto zacząć od tych pytań, a dopiero potem szukać przyczyn w danych technicznych.

Co właściwie znaczy, że strona jest wolna?

Jedna strona może być „wolna” na kilka różnych sposobów. Długo czeka się na pojawienie głównej treści. Treść widać, ale menu reaguje z opóźnieniem. Albo wszystko ładuje się sprawnie, lecz zdjęcie nagle przesuwa przycisk, który użytkownik właśnie próbował nacisnąć.

To trzy inne doświadczenia. Właśnie dlatego Google opisuje jakość działania strony za pomocą trzech wskaźników Core Web Vitals:

• LCP dotyczy czasu wyświetlenia największego widocznego elementu treści, na przykład głównego zdjęcia lub dużego bloku tekstu. Dobry wynik to nie więcej niż 2,5 sekundy.
• INP opisuje, jak szybko strona wizualnie reaguje na interakcje użytkownika. Dobry wynik to nie więcej niż 200 milisekund.
• CLS mierzy nieoczekiwane przesunięcia układu. Dobry wynik to nie więcej niż 0,1.

Google ocenia te progi na podstawie 75. percentyla danych, osobno dla urządzeń mobilnych i komputerów. Oznacza to w uproszczeniu, że dobry wynik powinien dotyczyć większości wizyt, a nie tylko najszybszego otwarcia strony na komputerze właściciela. Aktualne definicje i progi są opisane w dokumentacji Web Vitals.

Czy klient zna skróty LCP, INP i CLS? Zwykle nie. Odczuwa jednak problemy, które te wskaźniki próbują uchwycić.

Problem pierwszy: główna treść pojawia się zbyt późno

Wyobraźmy sobie osobę, która klika reklamę konkretnego produktu. Strona się otwiera, ale przez kilka sekund widzi puste miejsce, fragment nagłówka lub animację. Nie wie jeszcze, czy trafiła tam, gdzie chciała.

Podobnie jest na stronie usługowej. Użytkownik szuka zakresu współpracy, a najważniejsza sekcja pojawia się późno, bo przeglądarka wczytuje duże zdjęcie, wideo albo zasoby potrzebne do wyświetlenia całego układu.

Co odczuwa klient? Niepewność i czekanie na informację, po którą przyszedł. Może zacząć przeglądać inną stronę, zanim zobaczy ofertę.

Co warto sprawdzić? Który element jest największą widoczną treścią, ile trwa odpowiedź serwera, czy obraz ma odpowiednio przygotowany rozmiar i czy jego wyświetlenia nie opóźniają inne zasoby. Samo „zmniejszenie zdjęć na całej stronie” może nie rozwiązać problemu, jeśli opóźnienie powstaje wcześniej.

Najpierw trzeba więc ustalić przyczynę konkretnego wolnego wyświetlenia. Dopiero potem decydować o zmianie obrazu, kodu lub sposobu ładowania.

Problem drugi: strona wygląda na gotową, ale nie reaguje

To szczególnie frustrująca sytuacja. Użytkownik widzi przycisk „Dodaj do koszyka”, naciska go i przez chwilę nic się nie dzieje. Próbuje ponownie. W efekcie zastanawia się, czy strona się zawiesiła, czy dodał produkt dwa razy.

Podobny problem może dotyczyć otwierania menu na telefonie, rozwijania wariantów, wyboru terminu lub wpisywania danych do formularza.

Wskaźnik INP pomaga oceniać szybkość reakcji strony na interakcje. Nie wystarczy jednak zobaczyć słabego wyniku i uznać, że „cała strona jest wolna”. Trzeba znaleźć konkretne działanie, przy którym użytkownik czeka. Czasem przyczyną będzie rozbudowany skrypt, czasem sposób działania komponentu, a czasem wiele skryptów uruchamianych jednocześnie.

Warto przetestować ważne kroki na przeciętnym telefonie: otwarcie menu, zmianę wariantu, dodanie do koszyka i wysłanie formularza. To znacznie bliższe doświadczeniu klienta niż szybki test wykonany tylko na mocnym komputerze.

Problem trzeci: elementy uciekają spod palca

Czy zdarzyło Ci się kliknąć przycisk, a w ostatniej chwili trafić w coś innego, bo strona się przesunęła? Tak użytkownik odczuwa problem ze stabilnością układu.

Przyczyną może być na przykład obraz bez zarezerwowanego miejsca, pasek informacyjny dodany nad treścią lub element wczytywany dopiero po chwili. Na telefonie nawet niewielkie przesunięcie może utrudnić używanie formularza albo wybór opcji zakupu.

CLS pomaga zmierzyć nieoczekiwane przesunięcia, ale warto też po prostu obserwować stronę podczas ładowania. Czy przycisk kontaktu zmienia położenie? Czy lista produktów przeskakuje, gdy pojawiają się zdjęcia? Czy formularz przesuwa się po wyświetleniu komunikatu?

Tutaj poprawa wskaźnika ma bardzo czytelny cel: użytkownik powinien móc nacisnąć to, co zamierzał nacisnąć.

Skąd biorą się różnice między wynikami PageSpeed Insights?

PageSpeed Insights pokazuje dwa rodzaje danych, które łatwo ze sobą pomylić.

Dane od rzeczywistych użytkowników pochodzą z Chrome User Experience Report. Pokazują doświadczenia z poprzednich 28 dni, na różnych urządzeniach i przy różnych warunkach połączenia. Dla podstrony z małym ruchem może brakować wystarczającej liczby danych. Narzędzie może wtedy pokazać dane zbiorcze dla całej witryny albo nie wyświetlić ich wcale.

Dane laboratoryjne powstają podczas symulowanego testu konkretnego adresu. To z nich wynika punktowy wynik wydajności, na przykład 62 lub 95. Są przydatne do diagnozowania problemów i sprawdzania zmian, ale pojedynczy test nie opisuje wszystkich wizyt klientów.

Google wyjaśnia to rozróżnienie w dokumentacji PageSpeed Insights. Dlatego wynik może się zmienić między testami mimo braku zmian na stronie. Dlatego też dobry wynik laboratoryjny nie gwarantuje, że osoby korzystające ze strony na słabszych telefonach mają równie dobre doświadczenie.

Od czego zacząć czytanie raportu? Najpierw sprawdź, czy są dostępne dane od rzeczywistych użytkowników i czy odnoszą się do badanego adresu, czy do całej witryny. Potem użyj części laboratoryjnej, żeby szukać możliwych przyczyn problemu. Nie sprowadzaj obu części do jednej liczby.

Czy wynik 100/100 powinien być celem?

Nie zawsze. Jeśli poprawienie wyniku z 94 do 100 wymaga dużo pracy, a ważny formularz na telefonie nadal jest niewygodny, priorytet został źle ustawiony.

Podobnie niski wynik punktowy nie mówi jeszcze, że konkretna zmiana zwiększy sprzedaż. Może sygnalizować problem, który trzeba zbadać, ale jego wpływ zależy od tego, gdzie występuje i jak zachowują się użytkownicy.

Google potwierdza, że Core Web Vitals są wykorzystywane przez systemy rankingowe, ale dobry wynik nie gwarantuje wysokiej pozycji w wyszukiwarce. Zwraca też uwagę, że dążenie do idealnej oceny wyłącznie ze względu na SEO może być złym wykorzystaniem czasu. Zobacz wskazówki Google dotyczące jakości strony.

Lepsze pytanie brzmi: jaki problem użytkownika rozwiążemy dzięki tej poprawce?

Które podstrony sprawdzać najpierw?

Testowanie wyłącznie strony głównej to częsty błąd. Klienci trafiają przecież także bezpośrednio na karty produktów, strony usług, artykuły i strony docelowe kampanii.

Kolejność analizy warto ustalić na podstawie roli podstron:

• Karty produktów i kategorii mają znaczenie, gdy sklep pozyskuje na nie ruch z reklam lub wyszukiwarki.
• Strony usług powinny szybko pokazywać zakres oferty i umożliwiać kontakt.
• Strony docelowe kampanii trzeba oceniać szczególnie na urządzeniach, z których faktycznie przychodzi ruch.
• Koszyk i formularze warto sprawdzić pod kątem reakcji na kliknięcia oraz stabilności układu.
• Strona główna pozostaje ważna, ale nie reprezentuje działania wszystkich pozostałych adresów.

Jeśli wiele podstron korzysta z tego samego szablonu, sprawdź przykładowe adresy z każdej grupy. Jedna ciężka sekcja powielona na setkach kart produktów może mieć większe znaczenie niż pojedynczy problem na rzadko odwiedzanej podstronie.

Jak zdecydować, co naprawić w pierwszej kolejności?

Najprostsza zasada: połącz skalę problemu z wagą działania, które utrudnia.

Jeżeli przycisk „Dodaj do koszyka” na telefonie reaguje z opóźnieniem na najpopularniejszych kartach produktów, problem powinien trafić wysoko na listę. Jeśli dekoracyjna animacja na podstronie odwiedzanej kilka razy w miesiącu minimalnie pogarsza wynik laboratoryjny, jej poprawa może poczekać.

W praktyce warto przejść przez cztery kroki:

1. Wskaż objaw. Co dokładnie odczuwa użytkownik: czekanie na treść, opóźnioną reakcję czy przesuwający się układ?
2. Sprawdź zasięg. Których adresów, urządzeń i grup użytkowników to dotyczy?
3. Znajdź przyczynę. Użyj danych od rzeczywistych użytkowników, testów laboratoryjnych i sprawdzenia działania strony.
4. Zweryfikuj zmianę. Po wdrożeniu sprawdź, czy zniknął problem użytkownika, a nie tylko czy wzrosła punktacja w jednym teście.

Pamiętaj, że dane od rzeczywistych użytkowników w PageSpeed Insights obejmują poprzednie 28 dni. Poprawka wdrożona dzisiaj nie musi od razu zmienić tej części raportu.

Czy szybka strona będzie automatycznie lepiej sprzedawać?

Nie. Strona może otwierać się błyskawicznie, ale nadal nie wyjaśniać oferty, ukrywać kosztów albo prowadzić do trudnego formularza. Może też mieć dobre wyniki Core Web Vitals i źle działać w konkretnym kroku procesu zakupowego, którego te wskaźniki w pełni nie opisują.

Szybkość jest częścią doświadczenia użytkownika. Warto oceniać ją razem z treścią, układem strony i drogą do kontaktu lub zakupu. Podczas projektowania stron internetowych te elementy powinny tworzyć jeden proces, bo klient nie dzieli swojej wizyty na „wydajność”, „UX” i „treści”. Po prostu próbuje załatwić swoją sprawę.

Raport pokazuje, gdzie szukać. Klient pokazuje, dlaczego warto to poprawić. Jeśli zaczniemy od problemów, które przerywają jego drogę do zakupu lub kontaktu, praca nad szybkością strony będzie miała jasny cel, niezależnie od tego, ile punktów pokaże następny test.

‍