Audyt wydajności e‑commerce – Core Web Vitals i szybkość sklepu
Sprawdzamy gdzie sklep traci czas: w przeglądarce, aplikacji, infrastrukturze lub integracjach. Łączymy pomiar kluczowych ścieżek z analizą zaplecza, aby odróżnić objaw od przyczyny i wskazać, co naprawić najpierw. Wynikiem jest raport z dowodami, priorytetami i warunkami ponownego pomiaru.
Zakres ścieżek, urządzeń i środowisk ustalamy przed rozpoczęciem prac, aby pomiar odpowiadał sytuacjom ważnym dla sprzedaży i pracy zespołu.
- Ścieżki zakupowe
- Core Web Vitals
- Backend i dane
- Infrastruktura i integracje
Wolne ładowanie jest objawem. Źródło może leżeć w kilku warstwach
Wynik PageSpeed Insights może potwierdzić, że użytkownik czeka zbyt długo. Sam nie wyjaśnia jeszcze, czy problem powoduje motyw, kod aplikacji, baza danych, serwer, tag marketingowy albo zewnętrzne API.
Sposób diagnozy powinien odpowiadać sytuacji, w której pojawia się problem. Inaczej analizuje się wolną kartę produktu na telefonie, inaczej checkout zwalniający podczas kampanii, a jeszcze inaczej panel administracyjny blokowany przez importy.
- 01
Karta produktu ładuje się długo na telefonie
- Możliwe obszary
- Obrazy, JavaScript, fonty, renderowanie, cache, czas odpowiedzi aplikacji.
- Konsekwencja
- Użytkownik czeka, zanim zobaczy ofertę i będzie mógł rozpocząć zakup.
- 02
Checkout zwalnia podczas większej kampanii
- Możliwe obszary
- Sesje, baza danych, płatności, zewnętrzne usługi, zasoby serwera, sposób skalowania.
- Konsekwencja
- Problem pojawia się dokładnie wtedy, gdy firma kieruje do sklepu najwięcej płatnego ruchu.
- 03
Importy i panel administracyjny blokują pracę zespołu
- Możliwe obszary
- Indeksowanie, zadania cykliczne, kolejki, zapytania do bazy, integracje z ERP lub PIM.
- Konsekwencja
- Aktualizacja oferty trwa dłużej, a operacje wykonywane w tle wpływają na część sprzedażową.
- 04
Sklep raz działa szybko, a raz wyraźnie zwalnia
- Możliwe obszary
- Cache, obciążenie, zewnętrzne API, zadania w tle, różnice między środowiskami.
- Konsekwencja
- Zespół nie potrafi odtworzyć problemu i wdraża poprawki bez wspólnego punktu odniesienia.
Ten sam objaw prowadzi więc do różnych badań. Jeżeli podejrzenie dotyczy raczej jakości kodu, architektury albo długu technologicznego niż samego czasu odpowiedzi, właściwszym zakresem jest audyt techniczny e‑commerce.
Core Web Vitals – LCP, INP i CLS
Core Web Vitals to trzy metryki, którymi Google opisuje jakość doświadczenia na stronie: jak szybko pojawia się główna treść, jak szybko interfejs odpowiada na działanie użytkownika i jak stabilny jest układ strony.
Definicje i progi pochodzą od Google (otwiera się w nowej karcie). Wynik „dobry” oznacza, że próg jest spełniony dla 75% wizyt — jedna szybka próba na komputerze nie zamyka tematu. FID nie jest już jedną z Core Web Vitals; jego miejsce zajęło INP.
LCP
Largest Contentful Paint
Szybkość załadowania głównej treści strony.
Dobry wynikdo 2,5 s
W sklepie tym elementem jest zwykle zdjęcie produktu, banner na stronie głównej albo pierwszy kafel na listingu. Opóźnienie bierze się z wagi i kolejności zasobów, a nie z liczby elementów na stronie.
INP
Interaction to Next Paint
Responsywność strony po interakcji użytkownika.
Dobry wynikdo 200 ms
Mierzy opóźnienie między kliknięciem a widoczną reakcją: rozwinięciem filtra, dodaniem do koszyka, wyborem wariantu. Najczęstszą przyczyną jest JavaScript wykonywany w tym samym momencie.
CLS
Cumulative Layout Shift
Stabilność wizualną strony.
Dobry wynikdo 0,1
Przeskoki układu podczas ładowania — doładowany banner, font bez zarezerwowanego miejsca, baner zgód — kończą się kliknięciem w niewłaściwy element, najczęściej w koszyku i checkoucie.
Metryki mierzymy osobno dla urządzeń mobilnych i komputerów, ponieważ te same zasoby zachowują się inaczej przy słabszym procesorze i wolniejszym połączeniu.
Co najczęściej spowalnia sklep internetowy?
Wydajność rzadko psuje jedna rzecz. Zwykle jest to kilka nakładających się kosztów, z których każdy osobno wydaje się nieduży, a razem przesuwają LCP i INP poza progi.
Najczęstsze źródła spowolnień
- Obrazy
- zdjęcia większe niż miejsce, w którym się wyświetlają, brak nowoczesnych formatów i brak leniwego ładowania poza pierwszym ekranem
- JavaScript
- kod wykonywany przed pierwszą interakcją, duże paczki bez podziału i biblioteki ładowane na każdym widoku
- CSS
- arkusze blokujące renderowanie, style nieużywane na danym widoku i brak wyodrębnionego stylu dla pierwszego ekranu
- Fonty
- kroje ładowane bez zapasowego wyświetlania, w kilku wariantach i z zewnętrznych domen
- Aplikacje i skrypty third-party
- menedżer tagów, czaty, testy A/B, mapy ciepła i piksele reklamowe — najczęściej największy pojedynczy koszt INP
- Renderowanie
- długie zadania w wątku głównym, wymuszone przeliczanie układu i praca wykonywana przed wyświetleniem treści
- Cache
- niska skuteczność cache, przedwczesne unieważnianie i widoki wyłączone z cache bez potrzeby
- Zapytania do API
- dane dociągane w trakcie ładowania widoku — stany magazynowe, ceny, rekomendacje — bez limitu czasu i bez zachowania awaryjnego
- Elementy dynamiczne
- karuzele, podpowiedzi wyszukiwania, filtry i konfiguratory przebudowujące widok po jego wyświetleniu
- Zasoby blokujące renderowanie
- skrypty i arkusze w nagłówku, które zatrzymują wyświetlenie treści do czasu ich pobrania
Gdzie kończy się ten audyt
Audyt wydajnościowy obejmuje wszystkie pięć warstw powyżej: krytyczne ścieżki, frontend, aplikację i backend, infrastrukturę i dane oraz integracje i zachowanie pod obciążeniem. Granicą nie jest warstwa, tylko pytanie: tutaj pytamy, co spowalnia sklep i co przyspieszy go najbardziej. Ocena jakości kodu, bezpieczeństwa, gotowości do aktualizacji i długu technologicznego — niezależnie od tego, czy wpływają na czas ładowania — należy do audytu technicznego e‑commerce.
Audyt łączy pomiar doświadczenia użytkownika z analizą zaplecza
Wydajność sklepu powstaje na styku kilku warstw. Poprawa jednej z nich nie musi przynieść zauważalnej zmiany, jeżeli główne opóźnienie znajduje się w innym miejscu.
Zakres jest ustalany przed rozpoczęciem audytu. Powinien obejmować ścieżki mające największe znaczenie dla sprzedaży i operacji, a nie przypadkowy zestaw adresów.
Krytyczne ścieżki i szablony
Sprawdzane mogą być między innymi strona główna, listing, karta produktu, wyszukiwarka, koszyk, checkout, konto klienta i wybrane procesy B2B. Zakres adresów oraz wariantów urządzeń ustala się przed pomiarem.
Sprawdzane elementy
- strona główna i wejścia z kampanii
- listing z filtrami i sortowaniem
- karta produktu i wybór wariantu
- wyszukiwarka i podpowiedzi
- koszyk oraz checkout z dostawą i płatnością
- konto klienta i wybrane procesy B2B
Frontend i przeglądarka
Analiza obejmuje sposób ładowania obrazów, fontów, CSS i JavaScriptu, renderowanie treści, skrypty zewnętrzne oraz metryki Core Web Vitals. Wyniki powinny wskazywać, które zasoby opóźniają wyświetlenie lub reakcję interfejsu.
Sprawdzane elementy
- kolejność i waga zasobów wpływających na pierwsze wyświetlenie
- obrazy: formaty, rozmiary, sposób ładowania
- fonty i blokowanie renderowania
- JavaScript wykonywany przed interakcją
- skrypty marketingowe i menedżer tagów
- Core Web Vitals na urządzeniach objętych zakresem
Aplikacja i backend
Sprawdzane są czasy odpowiedzi, działanie cache, sesje, koszt wybranych operacji, zapytania do bazy, indeksowanie, kolejki i zadania wykonywane w tle. Dokładny zakres zależy od technologii i dostępów.
Sprawdzane elementy
- czas odpowiedzi aplikacji na ścieżkach objętych zakresem
- trafienia i unieważnianie cache
- obsługa sesji i koszyka
- zapytania do bazy w najdroższych operacjach
- indeksowanie i przeliczanie danych katalogu
- kolejki oraz zadania cykliczne
Infrastruktura i dane
Analiza może obejmować wykorzystanie zasobów, konfigurację środowiska, bazę danych, warstwy cache, CDN, logi oraz dostępne dane z monitoringu. Zakres współpracy z administratorem hostingu i dostęp do narzędzi ustalamy przed rozpoczęciem prac.
Sprawdzane elementy
- wykorzystanie procesora, pamięci i dysku pod ruchem
- konfiguracja serwera aplikacyjnego i bazy danych
- warstwy cache oraz CDN
- logi i dostępne dane z monitoringu
- różnice między środowiskiem produkcyjnym a testowym
Integracje i obciążenie
Sprawdzany jest wpływ płatności, ERP, PIM, WMS, wyszukiwarki, narzędzi marketingowych i innych API na krytyczne procesy. Testy obciążeniowe wymagają ustalenia środowiska, scenariusza i bezpiecznych limitów przed uruchomieniem.
Sprawdzane elementy
- czasy odpowiedzi usług zewnętrznych w ścieżce zakupowej
- wpływ ERP, PIM i WMS na katalog oraz stany magazynowe
- zachowanie płatności i dostaw przy większym ruchu
- sposób obsługi błędów i przekroczeń czasu
- zakres testów obciążeniowych: do ustalenia w zakresie usługi
Sprawdzane mogą być między innymi strona główna, listing, karta produktu, wyszukiwarka, koszyk, checkout, konto klienta i wybrane procesy B2B. Zakres adresów oraz wariantów urządzeń ustala się przed pomiarem.
Sprawdzane elementy
- strona główna i wejścia z kampanii
- listing z filtrami i sortowaniem
- karta produktu i wybór wariantu
- wyszukiwarka i podpowiedzi
- koszyk oraz checkout z dostawą i płatnością
- konto klienta i wybrane procesy B2B
Analiza obejmuje sposób ładowania obrazów, fontów, CSS i JavaScriptu, renderowanie treści, skrypty zewnętrzne oraz metryki Core Web Vitals. Wyniki powinny wskazywać, które zasoby opóźniają wyświetlenie lub reakcję interfejsu.
Sprawdzane elementy
- kolejność i waga zasobów wpływających na pierwsze wyświetlenie
- obrazy: formaty, rozmiary, sposób ładowania
- fonty i blokowanie renderowania
- JavaScript wykonywany przed interakcją
- skrypty marketingowe i menedżer tagów
- Core Web Vitals na urządzeniach objętych zakresem
Sprawdzane są czasy odpowiedzi, działanie cache, sesje, koszt wybranych operacji, zapytania do bazy, indeksowanie, kolejki i zadania wykonywane w tle. Dokładny zakres zależy od technologii i dostępów.
Sprawdzane elementy
- czas odpowiedzi aplikacji na ścieżkach objętych zakresem
- trafienia i unieważnianie cache
- obsługa sesji i koszyka
- zapytania do bazy w najdroższych operacjach
- indeksowanie i przeliczanie danych katalogu
- kolejki oraz zadania cykliczne
Analiza może obejmować wykorzystanie zasobów, konfigurację środowiska, bazę danych, warstwy cache, CDN, logi oraz dostępne dane z monitoringu. Zakres współpracy z administratorem hostingu i dostęp do narzędzi ustalamy przed rozpoczęciem prac.
Sprawdzane elementy
- wykorzystanie procesora, pamięci i dysku pod ruchem
- konfiguracja serwera aplikacyjnego i bazy danych
- warstwy cache oraz CDN
- logi i dostępne dane z monitoringu
- różnice między środowiskiem produkcyjnym a testowym
Sprawdzany jest wpływ płatności, ERP, PIM, WMS, wyszukiwarki, narzędzi marketingowych i innych API na krytyczne procesy. Testy obciążeniowe wymagają ustalenia środowiska, scenariusza i bezpiecznych limitów przed uruchomieniem.
Sprawdzane elementy
- czasy odpowiedzi usług zewnętrznych w ścieżce zakupowej
- wpływ ERP, PIM i WMS na katalog oraz stany magazynowe
- zachowanie płatności i dostaw przy większym ruchu
- sposób obsługi błędów i przekroczeń czasu
- zakres testów obciążeniowych: do ustalenia w zakresie usługi
Jeżeli pomiar wskaże na zasoby serwera albo konfigurację środowiska, dalszym krokiem może być zmiana lub przegląd hostingu — dla Magento 2 opisujemy go na stronie Hosting Magento 2. Sam audyt pozostaje niezależny od tej decyzji: jego zadaniem jest wskazać, czy problem rzeczywiście leży w infrastrukturze.
PageSpeed Insights a dane realnych użytkowników – co analizujemy?
Ten sam adres zmierzony w innym momencie, na innym urządzeniu i przy innym stanie cache daje inny wynik. Dlatego warunki ustalamy przed pomiarem, a przy każdej istotnej obserwacji podajemy je razem z dowodem.
Przed pomiarem ustalamy krytyczne ścieżki, urządzenia, źródła ruchu, warunki sieciowe i momenty, w których sklep traci wydajność. Bez tego wyniki z różnych dni i narzędzi mogą prowadzić do sprzecznych wniosków, a zespół dostaje listę alertów zamiast diagnozy.
Ustalone warunki mają jeszcze jedno zastosowanie: pozwalają sprawdzić, czy wdrożona zmiana rzeczywiście pomogła. Ponowny pomiar bez tego samego scenariusza nie rozstrzyga niczego.
Rodzaje danych w audycie
- Dane laboratoryjne
- Pomiar w kontrolowanych warunkach, na zadanym urządzeniu i połączeniu. Dobrze wskazuje przyczynę, ale nie mówi, co widzą klienci.
- Dane realnych użytkowników (field data)
- Wyniki zebrane z rzeczywistych wizyt, na sprzęcie i łączach, których naprawdę używają klienci. To one rozstrzygają, czy problem jest realny.
- Core Web Vitals
- LCP, INP i CLS liczone z danych realnych użytkowników dla 75% wizyt. Wynik laboratoryjny może je przybliżyć, ale ich nie zastępuje.
- Wyniki mobile
- Osobny pomiar dla telefonów — słabszy procesor i wolniejsze łącze zmieniają wnioski, zwłaszcza dla INP.
- Wyniki desktop
- Osobny pomiar dla komputerów, istotny w B2B i wszędzie tam, gdzie zamówienia składa się z biura.
Wynik Lighthouse ani punktacja PageSpeed nie są ostateczną oceną wydajności sklepu. To narzędzia diagnostyczne: pokazują kierunek, w którym trzeba szukać, a rozstrzygają dane realnych użytkowników zebrane w ustalonych warunkach.
Warunki ustalane przed pomiarem
- Ścieżki i adresy
- Konkretne szablony i procesy, a nie przypadkowy zestaw adresów. Zakres wybieramy według znaczenia dla sprzedaży i pracy zespołu.
- Urządzenia i sieć
- Klasa urządzenia, przeglądarka i parametry połączenia. Wolna karta produktu na telefonie i ta sama karta na komputerze to dwa różne pomiary.
- Środowisko
- Produkcja, kopia produkcji albo środowisko testowe, wraz z informacją, czym różni się od produkcyjnego pod względem danych i zasobów.
- Moment i scenariusz
- Godzina, poziom ruchu, trwające kampanie, importy i zadania w tle. Część problemów pojawia się tylko w określonych warunkach.
- Stan cache i danych
- Czy pomiar dotyczy pierwszego wejścia, wejścia z rozgrzanym cache, czy sytuacji po jego unieważnieniu. Wielkość katalogu i liczba wariantów mają tu znaczenie.
Zakres powtórzeń, dobór danych terenowych i laboratoryjnych oraz sposób próbkowania dużego katalogu ustalamy razem z zakresem audytu. Zależą od technologii sklepu, dostępnych środowisk i dostępów.
Core Web Vitals, UX i SEO – dlaczego wydajność ma znaczenie?
Dobre Core Web Vitals wspierają jakość doświadczenia użytkownika i są jednym z elementów uwzględnianych przez systemy rankingowe Google. Nie są jednak samodzielnym czynnikiem gwarantującym wysokie pozycje w wynikach wyszukiwania.
Doświadczenie użytkownika
Wolna karta produktu i przeskakujący układ w koszyku kosztują najpierw uwagę, a potem zamówienie. To jedyny efekt wydajności, który firma kontroluje w całości.
Widoczność w wyszukiwarce
Core Web Vitals są jednym z sygnałów branych pod uwagę przez systemy rankingowe. Same nie przesuwają strony w wynikach — decyduje przede wszystkim treść i jej dopasowanie do zapytania.
Koszt kampanii i konwersja
Wolna strona docelowa marnuje ruch, za który firma zapłaciła. Poprawa wydajności zwykle widać najpierw w danych o porzuceniach, nie w pozycjach.
Nie obiecujemy, że poprawa punktacji PageSpeed automatycznie podniesie pozycje w Google — nie ma takiej zależności. Jeżeli celem jest widoczność, wydajność jest jednym z elementów pracy, a nie jej całością. Problemy, które wychodzą poza wydajność, opisuje audyt techniczny e‑commerce.
Najpierw ustalamy, co mierzyć i w jakich warunkach
Porównywalny pomiar wymaga wspólnego scenariusza. Zakres powinien uwzględniać technologię, urządzenia, krytyczne procesy, dostępne środowiska i momenty, w których pojawia się problem.
Etapy prowadzą od rozmowy o objawach do raportu, który da się przełożyć na backlog. Każdy z nich kończy się materiałem, do którego można wrócić przy późniejszej weryfikacji.
- 01
Kontekst i zakres
Zbieramy informacje o technologii, infrastrukturze, ruchu, kampaniach, integracjach i wcześniejszych próbach optymalizacji. Wspólnie wskazujemy procesy, których spowolnienie ma największy wpływ na sprzedaż lub pracę zespołu.
Rezultat etapuLista krytycznych ścieżek i procesów objętych pomiarem
- 02
Warunki bazowe
Ustalamy urządzenia, parametry sieci, środowisko, zestaw adresów oraz scenariusze użytkownika. Pozwala to porównywać wyniki uzyskane w różnych momentach.
Rezultat etapuScenariusz pomiaru: urządzenia, sieć, środowisko, adresy
- 03
Pomiar
Wykonujemy pomiary warstwy użytkownika oraz dostępnych elementów zaplecza. Zakres zależy od dostępów: część obserwacji da się zebrać z zewnątrz, część wymaga logów, monitoringu albo dostępu do środowiska.
Rezultat etapuWyniki warstwy użytkownika i dostępnych elementów zaplecza
- 04
Diagnoza
Wyniki porównujemy między warstwami. Sprawdzamy, czy problem można odtworzyć i czy obserwowane opóźnienie odpowiada wskazanej przyczynie, zamiast pojawiać się razem z nią przypadkiem.
Rezultat etapuPowiązanie obserwacji z warstwą, kodem, konfiguracją albo usługą
- 05
Raport i omówienie
Przekazujemy raport z obserwacjami, dowodami, priorytetami i sposobem weryfikacji, a następnie omawiamy wyniki z zespołem po stronie klienta.
Rezultat etapuRaport i backlog rekomendacji w ustalonej kolejności
Testy obciążeniowe, jeżeli wchodzą w zakres, uruchamiamy dopiero po ustaleniu środowiska, scenariusza i bezpiecznych limitów oraz po akceptacji osób odpowiedzialnych za platformę. Bez tych ustaleń pozostajemy przy pomiarach, które nie wpływają na dostępność sklepu.
Co otrzymasz po audycie wydajnościowym?
Każdy problem opisujemy tym samym łańcuchem, od metryki, na której go widać, do priorytetu. Dzięki temu raport da się przekazać wprost do backlogu, bez tłumaczenia wyniku z narzędzia na zadanie dla zespołu.
Rekomendacje dzielimy na dwie grupy, bo mają inny koszt wejścia: część można wdrożyć w ramach zwykłych prac utrzymaniowych, część wymaga zaplanowanego etapu developmentu.
| Pole | Treść |
|---|---|
| Problem | Zdjęcie główne na karcie produktu ładuje się w pełnym rozmiarze, bez formatu nowej generacji. |
| Metryka | LCP na urządzeniach mobilnych, powyżej progu 2,5 s. |
| Przyczyna | Brak wariantów rozmiarowych i konwersji formatu w szablonie karty produktu. |
| Rekomendacja | Warianty dopasowane do miejsca wyświetlania, format nowej generacji i priorytet ładowania dla pierwszego ekranu. |
| Wpływ | Skrócenie czasu do wyświetlenia głównej treści na widoku o największym udziale w ruchu. |
| Priorytet | Quick win — zmiana w szablonie, bez ingerencji w architekturę sklepu. |
Format pojedynczego problemu
Problem
Zdjęcie główne na karcie produktu ładuje się w pełnym rozmiarze, bez formatu nowej generacji.
Metryka
LCP na urządzeniach mobilnych, powyżej progu 2,5 s.
Przyczyna
Brak wariantów rozmiarowych i konwersji formatu w szablonie karty produktu.
Rekomendacja
Warianty dopasowane do miejsca wyświetlania, format nowej generacji i priorytet ładowania dla pierwszego ekranu.
Wpływ
Skrócenie czasu do wyświetlenia głównej treści na widoku o największym udziale w ruchu.
Priorytet
Quick win — zmiana w szablonie, bez ingerencji w architekturę sklepu.
Przykład formatu. Nie jest to wynik audytu konkretnego klienta.
Grupa 01
Quick wins
Zmiany o relatywnie małym nakładzie i szybkim efekcie. Zwykle mieszczą się w konfiguracji, szablonie albo sposobie ładowania zasobów.
- warianty i formaty obrazów oraz priorytet ładowania
- odłożenie skryptów niepotrzebnych przed interakcją
- porządek w menedżerze tagów i skryptach zewnętrznych
- zarezerwowanie miejsca dla elementów doładowywanych
- poprawki konfiguracji cache i nagłówków
Grupa 02
Zmiany wymagające developmentu
Zmiany wymagające większej ingerencji w frontend, architekturę albo sposób działania sklepu. Wchodzą do planu jako osobny etap, z własną estymacją.
- podział i przebudowa paczek JavaScriptu
- zmiana sposobu renderowania listingu albo filtrów
- przebudowa komponentów dynamicznych w koszyku i checkoucie
- zmiana strategii cache dla widoków personalizowanych
- wymiana albo ograniczenie zakresu skryptów third-party
Przy każdej rekomendacji podajemy warunki pomiaru, na których się opiera, i wskazujemy, co trzeba zmierzyć ponownie po wdrożeniu. Bez tego samego scenariusza ponowny pomiar nie rozstrzyga, czy zmiana pomogła.
FAQ – audyt wydajności e‑commerce i Core Web Vitals
Dokładne warunki zależą od technologii sklepu, dostępnych środowisk i źródła problemu. Te elementy ustalamy przed rozpoczęciem pomiarów.
Nie podajemy jednej ceny, ponieważ audyt jest wyceniany zakresem: liczbą ścieżek i szablonów objętych pomiarem, liczbą urządzeń i środowisk, dostępnością danych realnych użytkowników, obecnością testów obciążeniowych oraz tym, czy zakres obejmuje zaplecze sklepu. Kwotę i termin potwierdzamy po ustaleniu zakresu.
Czas zależy od liczby ścieżek i szablonów, liczby wariantów urządzeń, dostępności danych z monitoringu oraz tego, czy zakres obejmuje testy obciążeniowe. Pomiar wymaga też okna czasowego: część problemów pojawia się wyłącznie pod ruchem albo w trakcie zadań w tle. Termin zapisujemy w ofercie razem z zakresem.
To trzy metryki, którymi Google (otwiera się w nowej karcie) opisuje jakość doświadczenia na stronie: LCP (szybkość załadowania głównej treści), INP (responsywność po interakcji użytkownika) i CLS (stabilność wizualna układu). Liczone są z danych realnych użytkowników. FID nie jest już jedną z Core Web Vitals — jego miejsce zajęło INP.
LCP: do 2,5 s. INP: do 200 ms. CLS: do 0,1. Progi dotyczą 75% wizyt, osobno dla urządzeń mobilnych i komputerów, więc jeden szybki pomiar na komputerze nie oznacza, że metryka jest spełniona.
PageSpeed Insights to narzędzie, a Core Web Vitals to metryki. Narzędzie pokazuje dwie rzeczy naraz: wynik laboratoryjny z Lighthouse, uzyskany w kontrolowanych warunkach, oraz dane realnych użytkowników, jeżeli są dostępne dla danego adresu. Punktacja Lighthouse jest wskazówką diagnostyczną, nie ostateczną oceną wydajności sklepu — rozstrzygają dane realnych użytkowników.
Tak, i zwykle jest ona ważniejsza od wersji na komputer. Te same zasoby zachowują się inaczej przy słabszym procesorze i wolniejszym połączeniu, dlatego pomiary prowadzimy osobno dla urządzeń mobilnych i osobno dla komputerów. Klasę urządzeń i parametry sieci ustalamy przed pomiarem.
Tak. Zakres obejmuje reprezentatywne etapy procesu zakupowego: stronę główną, listing z filtrami, kartę produktu, koszyk oraz checkout z dostawą i płatnością. To w koszyku i checkoucie najczęściej widać koszt elementów dynamicznych i skryptów zewnętrznych, więc pominięcie ich zostawiłoby najdroższą część ścieżki bez pomiaru.
Audyt wydajnościowy koncentruje się na czasie odpowiedzi, ładowaniu stron, stabilności przy obciążeniu i wąskich gardłach między frontendem, aplikacją, bazą danych, infrastrukturą oraz usługami zewnętrznymi. Audyt techniczny e‑commerce ocenia szerzej kod, architekturę, bezpieczeństwo, dokumentację, dług technologiczny i możliwość dalszego rozwoju.
Tak, Core Web Vitals (otwiera się w nowej karcie) są jednym z obszarów pomiaru frontendu. Same wyniki Lighthouse lub PageSpeed Insights nie wystarczą jednak do ustalenia źródła problemu w całej platformie: pokazują skutek widoczny w przeglądarce, a nie warstwę, która go powoduje.
Można przeprowadzić część zewnętrzną, ale zakres diagnozy będzie ograniczony. Dostęp do kodu, logów, monitoringu lub środowiska pozwala sprawdzić, co dzieje się po stronie aplikacji i infrastruktury. Wymagane dostępy ustalamy przed rozpoczęciem prac i mówimy wprost, których wniosków nie da się bez nich postawić.
Testy obciążeniowe wymagają uzgodnienia środowiska, scenariusza i bezpiecznych limitów. Nie uruchamiamy ich bez wcześniejszej oceny ryzyka i akceptacji osób odpowiedzialnych za platformę. Czy takie testy wchodzą w standardowy zakres usługi, ustalamy przy zakresie audytu — zależy to od technologii i dostępnych środowisk.
Raport z obserwacjami, dowodami, możliwymi przyczynami, priorytetami i sposobem weryfikacji zmian, wraz z uporządkowanym backlogiem rekomendacji. Format raportu i backlogu oraz zakres spotkania omawiającego wyniki są do potwierdzenia w zakresie oferty.
Audyt może być podstawą osobnego zakresu wdrożeniowego. Prace wyceniamy po poznaniu zależności, ryzyk i kolejności rekomendacji. Audyt nie zobowiązuje klienta do zlecenia wdrożenia temu samemu wykonawcy — raport jest przygotowany tak, aby dało się go przekazać innemu zespołowi.
Nie ustawiamy sztywnego interwału, bo wydajność psuje się od zmian, nie od upływu czasu. Ponowny audyt ma sens przede wszystkim po dużym wdrożeniu, po redesignie, po zmianie frontendu, po dodaniu dużych integracji lub skryptów oraz wtedy, gdy dane Core Web Vitals wyraźnie się pogorszą. Między audytami wystarcza obserwacja danych realnych użytkowników.
Gdy źródło pilnej awarii jest znane, właściwsza może być bezpośrednia diagnostyka i naprawa albo stała opieka nad sklepem w modelu AURORA CARE. Jeżeli firma przygotowuje nowe wdrożenie lub wybór platformy, lepszym punktem wyjścia będzie analiza przedwdrożeniowa.
Omówmy, gdzie sklep zwalnia i jaki zakres pomiaru ma sens
Podaj technologię, adres sklepu i sytuacje, w których pojawia się problem. Na tej podstawie można ustalić, czy potrzebny jest pełny audyt, ograniczona diagnostyka czy inna analiza.
Nie musisz przygotowywać briefu technicznego. Wystarczy opis objawów i to, co już wiadomo — resztę pytań zadamy sami w pierwszej rozmowie.
Przygotuj, jeżeli masz
- przykładowe adresy lub procesy, które działają wolno
- informację, kiedy problem występuje
- technologię sklepu i hostingu
- dane o ostatnich zmianach w sklepie
- informacje o wcześniejszych próbach optymalizacji
- planowane kampanie lub okresy zwiększonego ruchu