Szybkość sklepu internetowego: plan naprawy

Szybkość sklepu internetowego sprawdzisz bezpłatnie w PageSpeed Insights, ale sam kolor wyniku nie wystarczy do podjęcia decyzji. Najpierw zobacz, jak strona działa u prawdziwych klientów, potem ustal, czy problemem jest ładowanie treści, reakcja na kliknięcie czy przesuwający się układ. Dopiero wtedy poprawiaj obrazy, skrypty albo szablon. Poniżej znajdziesz progi Core Web Vitals, sposób czytania raportu i plan prac, który możesz przekazać wykonawcy sklepu.

Szybkość sklepu internetowego w trzech liczbach

Google opisuje jako Core Web Vitals trzy metryki doświadczenia użytkownika. LCP, czyli Largest Contentful Paint, mierzy czas wyświetlenia największego widocznego obrazu lub bloku tekstu. Dobry wynik wynosi maksymalnie 2,5 sekundy. INP, czyli Interaction to Next Paint, pokazuje, jak szybko strona wizualnie odpowiada na kliknięcia, dotknięcia i użycie klawiatury. Tutaj granicą dobrego wyniku jest 200 milisekund. CLS, czyli Cumulative Layout Shift, mierzy niespodziewane przesunięcia układu, a dobry wynik nie przekracza 0,1.

Liczy się 75. percentyl wizyt. W praktyce co najmniej 75 procent odsłon powinno mieścić się w dobrym progu każdej metryki. Oficjalna tabela i metodologia są dostępne w dokumentacji Core Web Vitals. Taki sposób oceny uwzględnia klientów ze słabszym telefonem lub łączem, których łatwo pominąć podczas testu na szybkim laptopie.

Te liczby opisują różne awarie. Wysokie LCP może wskazywać ciężkie zdjęcie główne albo wolną odpowiedź serwera. Wysokie INP często wiąże się z nadmiarem JavaScriptu, rozbudowaną wyszukiwarką lub skryptami zewnętrznymi. Wysokie CLS pojawia się, gdy baner, zdjęcie lub komunikat ładuje się bez zarezerwowanego miejsca i przesuwa przycisk pod palcem klienta.

Jak wykonać test i nie pomylić dwóch rodzajów danych

Otwórz PageSpeed Insights, wklej adres i sprawdź osobno wersję mobilną. Raport może pokazać dwie warstwy danych. Pierwsza pochodzi z Chrome UX Report, w skrócie CrUX, i opisuje doświadczenia prawdziwych użytkowników Chrome z ostatnich 28 dni. Druga pochodzi z jednorazowego testu Lighthouse przeprowadzonego w kontrolowanych warunkach.

Dane terenowe są właściwym miejscem do oceny rezultatu biznesowego. Test laboratoryjny służy do diagnozy: wskazuje duże obrazy, niewykorzystany kod, zasoby blokujące renderowanie i długie zadania procesora. Wyniki mogą się różnić, ponieważ prawdziwi klienci mają inne urządzenia, połączenia i zachowania. CrUX zasila zarówno PageSpeed Insights, jak i raport Core Web Vitals w Search Console, co potwierdza oficjalny przewodnik Chrome.

Nie testuj wyłącznie strony głównej. Wybierz po jednym adresie z najważniejszych szablonów: stronę kategorii, popularną kartę produktu i koszyk. Jeżeli chcesz dobrze wybrać próbkę, zacznij od podstron z największym ruchem i przychodem opisanych w poradniku o analityce sklepu internetowego. Zapisz datę, wartości LCP, INP i CLS oraz adres. Po wdrożeniu zmiany powtórz test laboratoryjny, a na dane terenowe poczekaj, ponieważ obejmują ruch z przesuwającego się okna 28 dni.

Co poprawić najpierw: LCP, INP czy CLS

Pracuj od metryki, która w danych terenowych ma status „słaba”. W jej obrębie zacznij od szablonu generującego najwięcej sprzedaży. Dzięki temu poprawa karty produktu lub koszyka może objąć tysiące adresów, podczas gdy ręczna korekta pojedynczej strony da niewielki zasięg.

Gdy problemem jest LCP

Sprawdź w Lighthouse, który element został uznany za LCP. Jeśli jest nim zdjęcie produktu lub baner, przygotuj odpowiednie rozmiary dla telefonu i komputera, skompresuj plik oraz użyj nowoczesnego formatu obsługiwanego przez platformę. Głównego obrazu widocznego od razu po wejściu nie oznaczaj jako loading="lazy", bo przeglądarka zacznie pobierać go później. Dla ważnego obrazu wykonawca może rozważyć fetchpriority="high", lecz po zmianie powinien ponownie zmierzyć stronę.

Jeżeli winny jest czas serwera, sprawdź hosting, pamięć podręczną, liczbę przekierowań oraz ciężkie zapytania do bazy. Przy wyborze nowego silnika uwzględnij też odpowiedzialność za hosting i aktualizacje, opisaną w porównaniu platform e-commerce.

Gdy problemem jest INP lub CLS

Przy wysokim INP wyłącz na kopii testowej dodatki, które uruchamiają dużo kodu: czaty, mapy ciepła, widżety opinii i kolejne systemy reklamowe. Usuń integracje bez mierzalnego zastosowania, a pozostałe ładuj możliwie późno. Sprawdź szczególnie wyszukiwanie, zmianę wariantu produktu, dodanie do koszyka i przejście do płatności.

Przy wysokim CLS ustaw wymiary zdjęć i zarezerwuj miejsce na banery, komunikaty o dostawie oraz widżety. Pasek promocji dołożony po załadowaniu strony nie powinien spychać całej treści. Na ścieżce zakupowej takie przesunięcie dokłada tarcie do problemów opisanych szerzej w analizie niskiej konwersji w sklepie.

Plan poprawy na jeden tydzień

Pierwszego dnia zbierz dane dla trzech szablonów i zapisz punkt startowy. Drugiego dnia wybierz jedną metrykę oraz jedną hipotezę, na przykład: „obraz produktu opóźnia LCP”. W kolejnych dwóch dniach wprowadź zmianę na środowisku testowym, sprawdź stronę na telefonie i wykonaj test Lighthouse przed oraz po wdrożeniu.

Piątego dnia opublikuj poprawkę i obserwuj błędy, konwersję oraz rozpoczęte płatności. Przy większej zmianie porównuj podobne okresy i nie wdrażaj jednocześnie nowego cennika, szablonu i kampanii. Poradnik o zakupach przez AI przypomina również o jakości danych produktowych, więc po technicznej zmianie upewnij się, że warianty, cena i dostępność nadal wyświetlają się prawidłowo.

Przy odbiorze prac poproś wykonawcę o krótką tabelę: adres, metryka przed zmianą, metryka po zmianie i opis wdrożenia. Zrzut zielonego wyniku bez adresu oraz ustawień testu ma małą wartość, bo kolejny pomiar może odbyć się w innych warunkach. Zachowaj raport, wersję kodu i datę publikacji. W razie pogorszenia łatwiej ustalisz wtedy, która integracja albo aktualizacja szablonu wprowadziła problem.

Ustal także budżet wydajnościowy dla nowych dodatków. Każdy widżet powinien mieć właściciela, cel biznesowy i datę ponownej oceny. Jeśli dodatek nie wspiera sprzedaży, obsługi klienta lub obowiązku prawnego, wyłączenie go na próbę jest rozsądnym testem. W sklepie stale przybywają piksele, czaty i moduły promocyjne, dlatego jednorazowa optymalizacja bez kontroli kolejnych zmian szybko traci efekt.

Google potwierdza, że jego systemy rankingowe używają Core Web Vitals, ale dobry raport nie gwarantuje wysokiej pozycji. Szybkość działa razem z trafną treścią, bezpiecznym połączeniem, wygodą na urządzeniach mobilnych i czytelnym procesem zakupu. Dlatego traktuj wynik jako wskaźnik doświadczenia klienta. Po każdej serii zmian wracaj do CrUX i wyników sprzedaży, a kolejny problem wybieraj na podstawie danych.