D-142P1 · krytyczne
PageSpeed mobile i desktop
Raportujemy wynik PageSpeed i Lighthouse w skali do 100 punktów, osobno dla wersji mobilnej i desktopowej. Mierzymy każdy typ szablonu: stronę główną, kategorię, produkt, artykuł, ofertę i checkout, bo średnia dla całej domeny ukrywa problemy.
Jak to robimy
- Wybieramy reprezentatywne adresy dla każdego szablonu i zapisujemy je jako stały zestaw testowy.
- Powtarzamy pomiary kilka razy i bierzemy wynik środkowy, bo pojedynczy test bywa niestabilny.
- Zapisujemy wynik mobilny i desktopowy w raporcie razem z najważniejszymi rekomendacjami narzędzia.
- Porównujemy wyniki z poprzednim pomiarem i oznaczamy szablony, które się pogorszyły.
Co otrzymujesz
Dostajesz tabelę wyników mobile i desktop dla każdego szablonu z trendem w czasie. Widzisz, które typy stron wymagają pracy w pierwszej kolejności.
Kiedy i w jakiej formie: Miesięcznie
D-143P1 · krytyczne
Core Web Vitals
Mierzymy pełny zestaw wskaźników wydajności: LCP, INP, CLS, FCP, TTFB, TBT, Speed Index i TTI. LCP rozbijamy według typu elementu, czyli obrazu, fontu, obrazu tła lub bloku tekstu, bo każdy wymaga innej poprawki.
Jak to robimy
- Zbieramy wskaźniki z danych polowych oraz z testów laboratoryjnych dla wybranych szablonów.
- Ustalamy dla każdego szablonu, jaki element jest mierzony jako LCP i z czego składa się jego czas.
- Łączymy TBT i TTI z analizą skryptów, żeby znaleźć kod blokujący główny wątek przeglądarki.
- Zestawiamy FCP i TTFB, żeby oddzielić problemy serwera od problemów z renderowaniem.
Co otrzymujesz
Otrzymujesz raport wskaźników z podziałem na szablony i przyczyny opóźnień. Poprawki możemy kierować w konkretne miejsca: serwer, obrazy, fonty albo skrypty.
Kiedy i w jakiej formie: Miesięcznie
D-144P1 · krytyczne
RUM: realne dane
Zbieramy dane Real User Monitoring, czyli pomiary szybkości z przeglądarek Twoich prawdziwych użytkowników. Porównujemy wyniki mobilne z desktopowymi, opóźnienia w poszczególnych regionach oraz rozbieżności między testami laboratoryjnymi a danymi polowymi.
Jak to robimy
- Wdrażamy zbieranie wskaźników Core Web Vitals z przeglądarek użytkowników i przesyłamy je do analityki.
- Dzielimy wyniki według urządzenia, typu strony i lokalizacji, zwłaszcza na rynkach ważnych dla sprzedaży.
- Porównujemy dane RUM z testami laboratoryjnymi i wyjaśniamy, skąd biorą się różnice.
- Budujemy raport, który pokazuje zmiany wskaźników po każdym wdrożeniu.
Co otrzymujesz
Dostajesz raport opisujący, jak szybko strona działa u realnych klientów na ich urządzeniach. Decyzje o poprawkach opieramy na doświadczeniu użytkowników z konkretnych regionów.
Kiedy i w jakiej formie: Miesięcznie
D-145P1 · krytyczne
Obrazy
Wdrażamy nowoczesną obsługę obrazów: WebP lub AVIF, lazy loading, poprawne wymiary, kompresję i obrazy responsywne. Przy dużej liczbie grafik proponujemy Image CDN, czyli usługę, która sama dopasowuje rozmiar i format pliku do urządzenia.
Jak to robimy
- Mierzymy odsetek obrazów w formatach WebP lub AVIF i zapisujemy go w raporcie.
- Sprawdzamy, czy lazy loading działa, i zapisujemy wynik jako TAK lub NIE dla każdego szablonu.
- Porównujemy wymiary plików z miejscem wyświetlania i wskazujemy grafiki do przeskalowania.
- Oceniamy, czy przy dużej bibliotece zdjęć opłaca się dynamiczne skalowanie obrazów w Image CDN.
Co otrzymujesz
Otrzymujesz raport z udziałem nowoczesnych formatów, statusem lazy loadingu i listą poprawek. Po wdrożeniu obrazy ważą mniej i pasują rozmiarem do ekranu użytkownika.
Kiedy i w jakiej formie: Kwartalnie
D-146P1 · krytyczne
CSS/JS
Porządkujemy kod CSS i JavaScript, który przeglądarka musi pobrać i wykonać przed pokazaniem strony. Stosujemy minifikację, usuwamy nieużywany kod, wydzielamy krytyczny CSS, ustawiamy async lub defer i pilnujemy budżetu skryptów zewnętrznych.
Jak to robimy
- Mierzymy rozmiar paczek JS i CSS oraz liczbę żądań wysyłanych przez stronę.
- Wskazujemy w raporcie pokrycia kodu fragmenty, które się ładują, ale nie są używane.
- Wydzielamy style pierwszego ekranu do krytycznego CSS, a resztę ładujemy bez blokowania renderowania.
- Ustalamy budżet na skrypty firm zewnętrznych i sprawdzamy go przy każdej nowej integracji.
Co otrzymujesz
Dostajesz odchudzony kod z mniejszą liczbą żądań oraz zapisany budżet skryptów. Strona szybciej się renderuje, a nowe tagi nie zwiększają jej wagi bez kontroli.
Kiedy i w jakiej formie: Miesięcznie/kwartalnie
D-147P2 · ważne
Cache, CDN i edge
Analizujemy konfigurację cache na każdym poziomie: w przeglądarce, w CDN i na serwerach brzegowych, czyli edge. Sprawdzamy nagłówki cache-control, czas życia TTL, odsetek trafień, ETag, Last-Modified, stale-while-revalidate oraz kompresję Brotli lub Gzip.
Jak to robimy
- Odczytujemy nagłówki odpowiedzi dla stron, obrazów, stylów i skryptów na wybranych adresach.
- Sprawdzamy w panelu CDN odsetek trafień w cache i wskazujemy zasoby pobierane za każdym razem z serwera.
- Ustawiamy stale-while-revalidate tam, gdzie serwer może odświeżać zasób w tle bez szkody dla użytkownika.
- Weryfikujemy, czy pliki tekstowe są kompresowane algorytmem Brotli lub Gzip.
Co otrzymujesz
Otrzymujesz raport konfiguracji cache z rekomendowanymi nagłówkami dla każdego typu zasobu. Po wdrożeniu większa część ruchu jest obsługiwana z cache, co odciąża serwer i skraca ładowanie.
Kiedy i w jakiej formie: Miesięcznie
D-148P2 · ważne
HTTP/2/3 i Early Hints
Weryfikujemy, czy serwer obsługuje HTTP/2 lub HTTP/3, które pozwalają przesyłać wiele plików jednym połączeniem. Ustawiamy też wskazówki dla przeglądarki: preconnect, DNS prefetch, preload, fetchpriority dla elementu LCP i Early Hints, czyli odpowiedź 103.
Jak to robimy
- Sprawdzamy wersję protokołu dla domeny głównej, CDN i najważniejszych domen zewnętrznych.
- Dodajemy preconnect i DNS prefetch dla domen, z których strona pobiera fonty lub skrypty.
- Ustawiamy fetchpriority z wartością high dla obrazu LCP oraz preload dla zasobów krytycznych.
- Oceniamy, czy serwer lub CDN obsługuje Early Hints, i włączamy je dla ważnych szablonów.
Co otrzymujesz
Dostajesz raport obsługi protokołów i wdrożone wskazówki ładowania zasobów. Przeglądarka wcześniej zaczyna pobierać to, co potrzebne do pokazania pierwszego ekranu.
Kiedy i w jakiej formie: Kwartalnie
D-149P2 · ważne
Font loading
Konfigurujemy ładowanie fontów tak, aby tekst był widoczny od razu i nie przesuwał układu. Wdrażamy font-display: swap, preload najważniejszych plików, ograniczamy liczbę wariantów i dobieramy krój zastępczy o podobnych proporcjach.
Jak to robimy
- Sprawdzamy, które pliki fontów blokują wyświetlenie tekstu i ile ważą.
- Ustawiamy font-display: swap, żeby tekst pojawiał się od razu w kroju zastępczym.
- Dobieramy krój zastępczy i jego parametry tak, aby podmiana nie zmieniała długości wierszy.
- Mierzymy CLS wywołany przez fonty przed zmianami i po nich na ważnych szablonach.
Co otrzymujesz
Otrzymujesz nową konfigurację fontów z mniejszą liczbą plików i dobranym krojem zastępczym. Tekst pojawia się szybciej, a podmiana kroju przestaje przesuwać treść.
Kiedy i w jakiej formie: Kwartalnie
D-150P2 · ważne
Service Worker i PWA
Jeżeli ma to sens dla Twojego serwisu, wdrażamy Service Worker, czyli skrypt działający w tle przeglądarki. Obsługuje on tryb offline, manifest aplikacji PWA i kontrolę cache. Pilnujemy przy tym, żeby nie utrudniał indeksacji.
Jak to robimy
- Oceniamy, czy powracający użytkownicy lub słaby zasięg mobilny uzasadniają wdrożenie Service Workera.
- Przygotowujemy stronę zapasową offline oraz manifest z nazwą, ikonami i kolorami aplikacji.
- Ustalamy strategię cache dla zasobów, żeby użytkownik nie oglądał nieaktualnych cen ani treści.
- Testujemy renderowanie stron przez Googlebota, żeby pełna treść nie zależała od Service Workera.
Co otrzymujesz
Dostajesz rekomendację, czy PWA ma sens, a po decyzji na tak działający Service Worker z manifestem. Serwis szybciej otwiera się przy kolejnych wizytach i działa przy słabym połączeniu.
Kiedy i w jakiej formie: Opcjonalnie
D-151P1 · krytyczne
Mobile-friendly i parzystość
Sprawdzamy, czy strona spełnia podstawowe wymagania mobilne: poprawny viewport, odpowiednio duże elementy dotykowe i czytelne fonty. Wyszukujemy przestarzałe elementy, takie jak Flash i nieobsługiwane ramki iframe. Porównujemy też treść obu wersji, bo Google indeksuje serwis głównie na podstawie wersji mobilnej.
Jak to robimy
- Sprawdzamy meta tag viewport i zachowanie układu na typowych szerokościach ekranów.
- Mierzymy rozmiar i odstępy elementów dotykowych, czyli przycisków, linków i pól formularzy.
- Crawlujemy serwis agentem mobilnym i porównujemy treść, linki oraz dane strukturalne z wersją desktopową.
- Wskazujemy osadzone elementy, które nie działają na telefonach, i proponujemy zamienniki.
Co otrzymujesz
Otrzymujesz raport zgodności mobilnej z listą różnic między wersjami i elementów do wymiany. Strona jest przygotowana na ocenę w indeksowaniu mobile-first.
Kiedy i w jakiej formie: Kwartalnie
D-152P2 · ważne
Zaangażowanie mobile vs desktop
Porównujemy zachowanie użytkowników na telefonach i komputerach: współczynnik odrzuceń, CTR, konwersje, przewijanie i kliknięcia CTA. Duże różnice między urządzeniami zwykle wskazują na problem z wersją mobilną, który trzeba naprawić przed kolejnymi kampaniami.
Jak to robimy
- Konfigurujemy zdarzenia w analityce, jeśli brakuje pomiaru przewijania, kliknięć CTA lub formularzy.
- Zestawiamy wskaźniki zaangażowania i konwersji osobno dla urządzeń mobilnych i desktopowych.
- Porównujemy CTR z wyszukiwarki dla obu typów urządzeń na tych samych frazach.
- Wskazujemy strony z największą różnicą i sprawdzamy w nagraniach sesji, co ją powoduje.
Co otrzymujesz
Dostajesz raport różnic w zaangażowaniu między urządzeniami z listą stron do poprawy. Wiesz, gdzie użytkownik mobilny rezygnuje częściej niż desktopowy i z jakiego powodu.
Kiedy i w jakiej formie: Miesięcznie
D-153P2 · ważne
Zrównoważony web
Monitorujemy wagę stron i ilość przesyłanych danych, bo lżejsza strona szybciej się ładuje i zużywa mniej energii. Oznaczamy strony cięższe niż 3 MB, liczymy transfer na użytkownika i szacujemy emisję CO2 na odsłonę lub na 1000 odsłon.
Jak to robimy
- Mierzymy wagę każdego typu strony i wskazujemy adresy przekraczające 3 MB.
- Sprawdzamy odsetek obrazów w nowoczesnych formatach oraz udział skryptów zewnętrznych w transferze.
- Szacujemy emisję CO2 na podstawie transferu danych, korzystając z publicznych modeli obliczeniowych.
- Weryfikujemy, czy hosting i CDN korzystają z energii odnawialnej, i opisujemy dostępne opcje.
Co otrzymujesz
Otrzymujesz raport wagi stron i szacowanej emisji z listą najcięższych adresów do odchudzenia. Te same poprawki skracają czas ładowania i zmniejszają koszty transferu.
Kiedy i w jakiej formie: Kwartalnie
