Usługa · Analityka i marketing
Naprawiamy konkretne metryki Core Web Vitals – LCP, INP i CLS – tam, gdzie powstaje problem: w szablonie, skryptach i stylach. Cel to dobry wynik w danych od prawdziwych użytkowników.
Core Web Vitals to trzy metryki, którymi Google opisuje doświadczenie użytkownika na stronie. LCP mierzy, jak szybko pojawia się największy element widoczny na ekranie, INP – jak szybko strona reaguje na kliknięcia i dotknięcia, a CLS – czy układ nie przeskakuje w trakcie ładowania. Progi są publiczne: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, liczone dla 75. percentyla wizyt, osobno na telefonach i komputerach. Strona, która je spełnia, jest po prostu wygodniejsza w użyciu.
Ta usługa nie jest ogólnym przyspieszaniem strony. Serwerem, cache i kompresją obrazów zajmujemy się osobno, a tutaj pracujemy na konkretnych metrykach i ich przyczynach w kodzie: elemencie LCP ładowanym za późno, długich zadaniach JavaScript blokujących interakcje, banerach i fontach przesuwających treść. Zaczynamy od danych polowych z CrUX i Search Console, a nie od samego wyniku Lighthouse, bo to one pokazują, co naprawdę widzą Twoi użytkownicy.
W skrócie
Analizujemy dane CrUX i raport Core Web Vitals w Search Console, żeby ustalić, które grupy adresów i które urządzenia mają problem.
Wskazujemy element LCP, usuwamy opóźnienia w jego pobieraniu, ustawiamy mu wysoki priorytet i ograniczamy zasoby blokujące renderowanie.
Szukamy długich zadań w głównym wątku przeglądarki, dzielimy ciężkie skrypty, odraczamy kod zewnętrzny i odchudzamy obsługę zdarzeń.
Rezerwujemy miejsce na obrazy, osadzenia, reklamy i banery, a fonty ładujemy tak, by zamiana kroju pisma nie przesuwała tekstu.
Wdrażamy zbieranie metryk z przeglądarek odwiedzających, np. biblioteką web-vitals z wysyłką do GA4, by nie czekać tygodniami na CrUX.
Dokumentujemy zmiany i podpowiadamy, na co uważać przy dodawaniu wtyczek, skryptów marketingowych i nowych sekcji, by wynik nie spadł.
Wynik w PageSpeed Insights ma dwie części. Górna to dane polowe z raportu CrUX, czyli metryki zebrane od użytkowników Chrome z ostatnich 28 dni – to na ich podstawie ocenia się, czy strona spełnia progi. Dolna to test laboratoryjny Lighthouse, wykonany raz, na symulowanym urządzeniu i łączu. Lighthouse świetnie nadaje się do szukania przyczyn, ale standardowy test nie mierzy INP, bo nikt w nim nie klika – pokazuje za to Total Blocking Time jako przybliżenie. Zielony wynik w Lighthouse nie oznacza więc jeszcze zaliczonych Core Web Vitals.
Search Console grupuje adresy o podobnym szablonie i pokazuje, które grupy są dobre, wymagają poprawy albo są słabe. Gdy ruch na pojedynczych podstronach jest zbyt mały, CrUX podaje dane dla całej domeny albo nie podaje ich wcale. Wtedy zbieramy własne pomiary RUM, czyli z przeglądarek Twoich odwiedzających, i to na nich weryfikujemy efekt poprawek. Takie dane mają jeszcze jedną zaletę – pokazują, który element był LCP i która interakcja była wolna, czego CrUX nie podaje.
Każda metryka ma inne źródła problemów. Słabe LCP rzadko wynika z jednego dużego zdjęcia – częściej z tego, że przeglądarka dowiaduje się o nim za późno, bo obraz jest tłem w CSS, ładuje go skrypt slidera albo ma włączone leniwe ładowanie. INP psują zwykle skrypty zewnętrzne i rozbudowana obsługa kliknięć, a CLS – elementy wstrzykiwane nad treścią już po jej wyświetleniu. Poniżej sytuacje, które najczęściej spotykamy w szablonach WordPressa, Shopify czy PrestaShop.
Search Console grupuje adresy o podobnej budowie. Często to szablon kategorii czy wpisów odpowiada za zły wynik, a nie strona główna.
Obraz z pierwszego ekranu ładowany z opóźnieniem pogarsza LCP. Takie obrazy ładujemy z wysokim priorytetem, a leniwie tylko te niżej.
Elementy, które pojawiają się po załadowaniu i przesuwają treść, podnoszą CLS. Rezerwujemy dla nich miejsce w układzie.
Długie zadania JavaScriptu blokują reakcję strony i psują INP. Dzielimy je, opóźniamy lub usuwamy, jeśli nie są potrzebne.
Przyspieszanie strony to praca na infrastrukturze: hosting, wersja PHP, cache po stronie serwera, CDN, kompresja i formaty obrazów. To ważne, bo czas odpowiedzi serwera jest częścią LCP. Zdarza się jednak, że strona na szybkim serwerze nadal ma słabe INP albo skaczący układ, bo przyczyna leży w kodzie motywu, kolejności ładowania zasobów i skryptach dokładanych latami. Optymalizacja Core Web Vitals to praca programistyczna nad tymi trzema metrykami – zmiany w szablonach, stylach i JavaScripcie, testowane na kopii strony przed wdrożeniem.
Często obie usługi łączymy: najpierw porządkujemy serwer i cache, potem schodzimy do kodu. Jeśli jednak dane pokazują, że serwer odpowiada szybko, a problem dotyczy wyłącznie interakcji lub stabilności układu, zaczynamy od razu od kodu. Nie płacisz wtedy za zmiany infrastruktury, które niczego w metrykach nie poprawią. Z kolei przy wysokim czasie odpowiedzi serwera mówimy otwarcie, że same poprawki w kodzie nie wystarczą, by LCP zmieściło się w progu.
Raport w Search Console nie pokazuje każdej podstrony osobno. Grupuje adresy o podobnej budowie i przypisuje im wspólną ocenę na podstawie danych od użytkowników z ostatnich tygodni. Dlatego jeden wolny szablon potrafi pogorszyć ocenę setek adresów, a jedna poprawka w tym szablonie poprawia je wszystkie.
Zaczynamy od grup z największą liczbą adresów i najgorszymi wynikami, sprawdzamy przykładowe podstrony w narzędziach diagnostycznych i szukamy wspólnej przyczyny. Po wdrożeniu poprawek uruchamiamy w Search Console weryfikację, która śledzi, czy problem zniknął w kolejnych tygodniach.
Zanim zadzwonisz
Nie musisz mieć wszystkiego. Każdy z tych punktów skraca jednak drogę do dokładnej wyceny.
Dane z raportu Google pojawiają się z opóźnieniem i nie obejmują stron z małym ruchem. Dlatego proponujemy własny pomiar Core Web Vitals od odwiedzających, wysyłany do Google Analytics 4 lub innego narzędzia. Widać wtedy na bieżąco, które podstrony, urządzenia i przeglądarki mają problemy, i można szybciej sprawdzić efekt zmian.
Taki pomiar pozwala też wychwycić regresję: nowa wtyczka, widżet czy zmiana w szablonie, która pogarsza wyniki, jest widoczna w danych po kilku dniach, a nie dopiero po tygodniach w raporcie Search Console.
Zbieramy dane z CrUX, Search Console i własnych pomiarów, wskazujemy szablony stron i metryki, które nie spełniają progów Google.
W narzędziach deweloperskich Chrome nagrywamy ładowanie i interakcje, żeby znaleźć element LCP, długie zadania i źródła przesunięć.
Wprowadzamy zmiany w środowisku testowym, porównujemy pomiary przed i po, a następnie wdrażamy je na stronę produkcyjną.
Śledzimy pomiary RUM i CrUX przez kolejne tygodnie, a w Search Console uruchamiamy sprawdzenie poprawki dla grup adresów.
Dlaczego my
Masz jedną osobę kontaktową od wyceny, przez wdrożenie, po opiekę po starcie.
Struktura podstron, nagłówki, dane strukturalne i szybkość planujemy od pierwszego szkicu.
Domena, hosting, pliki i konta administratora są Twoje od pierwszego dnia.
Telefony, przeglądarki, formularze, szybkość i bezpieczeństwo sprawdzamy przed uruchomieniem.
Po starcie strony
Po wdrożeniu nie musisz szukać kolejnej agencji. W ramach opieki po starcie strony możemy poprowadzić pozycjonowanie i marketing – z tym samym opiekunem, który zna Twoją stronę od środka.
Pozycjonowanie
Gdy strona już działa, rozwijamy jej widoczność w Google i w odpowiedziach AI. Zaczynamy od audytu, a potem systematycznie pracujemy nad treściami, techniką, linkami i strukturą podstron.
Marketing
Kierujemy na gotową stronę osoby zainteresowane Twoją ofertą i budujemy rozpoznawalność marki. Mierzymy, co naprawdę przynosi zapytania i sprzedaż, i na tej podstawie rozwijamy działania.
FAQ
Nie ma tu Twojego pytania? Napisz na biuro@tworzeniestronwww.pl albo zadzwoń: 222 500 844.
Są jednym z sygnałów oceny doświadczenia na stronie, ale nie przeważają nad trafnością i jakością treści. Dobre wyniki nie wypchną słabej strony na szczyt, a złe przy mocnej treści rzadko ją pogrążą. Traktuj je przede wszystkim jako miarę wygody użytkowników, która przekłada się na rezygnacje i konwersje. Naszym zadaniem jest przygotować stronę tak, żeby szybkość nie była jej słabym punktem.
Lighthouse to pojedynczy test laboratoryjny na symulowanym urządzeniu, bez prawdziwych kliknięć, więc nie widzi INP i nie odtworzy słabszych telefonów Twoich klientów ani ich zasięgu. Search Console korzysta z danych CrUX zebranych od użytkowników przez 28 dni. Taka rozbieżność jest normalna – dlatego zaczynamy od danych polowych, a laboratorium służy nam do szukania przyczyn.
Własne pomiary RUM pokażą zmianę od razu po wdrożeniu. CrUX i raport w Search Console uśredniają dane z 28 dni, więc pełny obraz pojawia się stopniowo, w miarę jak starsze wizyty wypadają z okna pomiaru. Sprawdzenie poprawki w Search Console również trwa, bo Google musi zebrać nowe dane dla całej grupy adresów, zanim zmieni jej status.
Oznacza to, że CrUX nie ma wystarczającej liczby wizyt z Chrome, by udostępnić statystyki. Brakuje wtedy oceny polowej, ale użytkownicy nadal doświadczają tych samych problemów. Wdrażamy własny pomiar metryk z przeglądarek odwiedzających, wysyłany np. do GA4, i na nim opieramy zarówno diagnozę, jak i kontrolę efektów poprawek.
W większości przypadków tak. Priorytet ładowania obrazów, odroczenie skryptów, rezerwacja miejsca na elementy i optymalizacja fontów nie wymagają przebudowy. Gdy jednak kreator generuje bardzo rozbudowany DOM albo motyw ładuje dziesiątki niepotrzebnych zasobów na każdej podstronie, mówimy wprost, gdzie kończą się możliwości poprawek i kiedy przebudowa szablonu będzie rozsądniejsza.
Bezpłatna wycena
Opisz krótko swoją sytuację – przygotujemy bezpłatną wycenę z zakresem prac. Wolisz rozmowę? Zadzwoń.
Strony, sklepy i integracje, a po starcie strony także pozycjonowanie, kampanie, social media i PR – wycenimy każdą z tych usług.
Twoja wycenaco dostajesz w odpowiedzi Bezpłatnie
