Core Web Vitals w e-commerce — dlaczego LCP poniżej 2,5s zwiększa sprzedaż

Strona ładująca się w 1 sekundę konwertuje 2,5× lepiej niż ta w 5 sekund (analiza Portent). Jeśli Twój sklep mierzy LCP w okolicach 4 sekund, nie tracisz kilku procent konwersji. Tracisz większość sprzedaży, którą mogłeś mieć z tego samego ruchu.

Core Web Vitals to nie jest „checklista dla deweloperów". To metryki, które Google oficjalnie używa jako czynnika rankingowego, a jednocześnie twarde predyktory tego, ile osób porzuci Twój sklep, zanim w ogóle zobaczy produkt. W tym artykule rozbieramy mechanizm: co dokładnie mierzą LCP, INP i CLS, dlaczego LCP poniżej 2,5 sekundy robi różnicę w kasie, co najczęściej psuje te wyniki w e-commerce i co realnie je naprawia.

Jeśli chcesz zrozumieć, jak CWV wpisują się w szerszy obraz SEO i sprzedaży, zajrzyj do artykułu o tym, jak SEO wpływa na sprzedaż w e-commerce. Jeśli architektura headless brzmi jeszcze abstrakcyjnie, zacznij od kompletnego przewodnika po headless. Tu skupiamy się konkretnie na wydajności jako bezpośrednim silniku konwersji.

Czym są Core Web Vitals

Google mierzy trzy rzeczy:

• LCP (Largest Contentful Paint). Czas, w którym użytkownik widzi największy widoczny element (zwykle zdjęcie produktu, hero baner, nagłówek kategorii). Próg „dobry": ≤ 2,5 sekundy. Powyżej 4 sekund Google klasyfikuje to jako „słaby".
• INP (Interaction to Next Paint). Responsywność strony na interakcję: kliknięcie, tapnięcie, wpisanie znaku. Zastąpił FID w marcu 2024. Próg „dobry": ≤ 200 ms.
• CLS (Cumulative Layout Shift). Stabilność wizualna. Ile razy elementy „skaczą" w trakcie ładowania (obraz wchodzi, baner doładowuje się, przycisk przesuwa). Próg „dobry": ≤ 0,1.

LCP jest powszechnie uznawany za najważniejszy z trzech, bo bezpośrednio odpowiada na pytanie: „Jak szybko użytkownik widzi to, po co przyszedł?". W e-commerce to zwykle zdjęcie produktu albo hero baner kategorii. Jeśli pojawia się po 4 sekundach, użytkownik już klika „wstecz".

Dlaczego LCP ≤ 2,5s realnie przekłada się na sprzedaż

Psychologia pierwszych sekund

Pierwsze sekundy po wejściu na stronę decydują, czy klient zostaje, czy odchodzi. To nie jest metafora. Gdy LCP mieści się w 2 sekundach, użytkownik odbiera sklep jako szybki, profesjonalny, godny zaufania. Gdy przekracza 4 sekundy, odbiera go jako zepsuty, niedopracowany, niewarty dalszego przeglądania. Decyzja o wyjściu zapada zanim w ogóle ocenisz produkt.

Strony z LCP powyżej 4 sekund mają o 32% wyższy bounce rate od tych ładujących się w 2 sekundy. Każda sekunda opóźnienia to mniej kliknięć w produkt, mniej dodań do koszyka, mniej finalizacji.

Łańcuch przyczynowo-skutkowy

Mechanizm jest liniowy: szybki LCP → mniej porzuceń → więcej użytkowników w lejku → więcej dodań do koszyka → więcej finalizacji → wyższa konwersja. Nie ma tu magii. Każdy etap lejka zaczyna się od tego, czy strona zdążyła się załadować, zanim użytkownik stracił cierpliwość.

Twarde dane i case studies

Statystyki, które warto mieć w głowie

• Strony ładujące się w ~1 sekundę osiągają do 2,5× wyższy współczynnik konwersji niż te w 5 sekund (Portent).
• Witryny z LCP poniżej 2 sekund mają o 15% wyższą konwersję niż te z LCP powyżej 4 sekund.
• Poprawa szybkości o zaledwie 0,1 sekundy na mobile może zwiększyć konwersję o 8–10% (Deloitte).
• Wzrost czasu ładowania z 1s do 3s zwiększa porzucenia o 32% (Google).
• Dobry wynik LCP koreluje ze wzrostem konwersji nawet o 61% (analiza danych terenowych).

Firmy, które to zmierzyły

• Vodafone. Poprawa LCP o 31% → wzrost sprzedaży o 8%.
• Renault. Przyspieszenie LCP o 1 sekundę → spadek bounce rate o 14%, wzrost konwersji o 13%.
• The Economic Times. Poprawa LCP o 80% i CLS o 250% → redukcja bounce rate o 43%.
• Walmart. Każda 1s poprawy szybkości → wzrost konwersji o 2% na sekundę.
• Mozilla. Przyspieszenie strony o 2,2 sekundy → 60 milionów więcej pobrań rocznie.

Symulacja na polskich realiach

Sklep ze średnią wartością koszyka 200 PLN, 25 000 wizyt miesięcznie, budżet reklamowy 50 000 PLN:

• Przed optymalizacją LCP. Bounce rate 60%, konwersja 5% z pozostałych → 500 zamówień, przychód 100 000 PLN, CPA 100 PLN.
• Po optymalizacji LCP (2s → 1,2s). Bounce rate 30%, konwersja 5% z pozostałych → 875 zamówień, przychód 175 000 PLN, CPA 57 PLN.

Ten sam budżet, ta sama kampania, ten sam produkt. 75% więcej przychodu z tego samego ruchu, wyłącznie dzięki szybszej stronie. To nie jest „drobne usprawnienie". To jest zmiana w rentowności całego biznesu.

LCP jako czynnik rankingowy Google

CWV to nie tylko konwersja, to także pozycja w wyszukiwarce, która napędza cały lejek. Google oficjalnie uwzględnia Core Web Vitals jako czynnik rankingowy. Strony z optymalnym LCP są lepiej oceniane przez algorytmy, co przekłada się na wyższe pozycje w SERP. Wyższe pozycje to więcej ruchu organicznego, a ruch organiczny nie kosztuje Cię nic za kliknięcie.

Mechanizm jest prosty: słaby LCP zabija konwersję u tych, którzy już wchodzą, i ogranicza liczbę tych, którzy w ogóle wchodzą. Pełny obraz, jak SEO techniczne przekłada się na przychód, rozbieramy w artykule o wpływie SEO na sprzedaż w e-commerce.

Co najczęściej psuje LCP w sklepie

Najczęstsi winowajcy

• Duże, nieskompresowane obrazy. Hero bannery i zdjęcia produktów w pełnej rozdzielczości to numer jeden.
• Wolny czas odpowiedzi serwera (TTFB). Tani shared hosting, brak cachingu, zatłoczona baza danych.
• Blokujący CSS i JavaScript. Render-blocking resources, które muszą się załadować, zanim strona w ogóle zacznie się malować.
• Brak lazy loadingu dla obrazów poza viewportem. Uwaga: nie stosuj lazy loadingu na elemencie LCP, to go pogorszy.
• Zbyt dużo third-party scripts. Tracking, chat widgety, piksele reklamowe, wszystkie ciągną zasoby równolegle z Twoją treścią.
• Ciężkie motywy i page buildery. Elementor, Divi, WPBakery dokładają setki kilobajtów nieużywanego CSS/JS.

Ranking problemów po platformach

• WooCommerce. PHP renderuje całą stronę przy każdym żądaniu, TTFB zależy od jakości hostingu i liczby wtyczek. Typowy sklep ma 20–40 pluginów, z których każdy dokłada zapytania do bazy i ładuje własny CSS/JS. Elementor albo Divi dokładają do tego warstwę page buildera.
• Shoper, IdoSell. Brak realnej kontroli nad priorytetami zasobów, critical CSS, preloadem. Platforma robi, co uważa, Ty się dopasowujesz.
• PrestaShop. Ekosystem modułów o bardzo nierównej jakości, często ciężkich i słabo utrzymywanych.
• Headless na Next.js. SSG/ISR dla stron produktów, CDN, next/image z WebP i responsive sizes, Server Components redukujące bundle JS, pełna kontrola nad <head>. Zero bloatu wtyczkowego z definicji.

Różnica nie jest ilościowa, tylko architektoniczna. Tradycyjne platformy mają strukturalny problem z LCP, headless eliminuje go na poziomie fundamentu. Pełne porównanie platform po wydajności, kosztach i elastyczności znajdziesz w osobnym artykule o headless vs tradycyjnym e-commerce.

Jak poprawić LCP — konkretne techniki z mierzalnym wpływem

Optymalizacja obrazów (największy zysk)

Obrazy zwykle stanowią 50–70% wagi strony w e-commerce. Tu leży największa rezerwa:

• Format WebP (30–50% mniejszy niż JPEG/PNG przy tej samej jakości).
• Kompresja przez TinyPNG, ShortPixel albo odpowiednik natywny.
• Responsive images z srcset. Smartphone dostaje 400px, desktop 1920px.
• Preload hero image: <link rel="preload"> dla głównego obrazu.
• Na elemencie LCP ustaw fetchpriority="high". Nie stosuj loading="lazy" na LCP, to go zepsuje.

Szacowana poprawa: około 0,5 sekundy na LCP przy dobrze zrobionej optymalizacji obrazów.

Przyspieszenie serwera

• Włącz cache (Redis, Varnish) dla PHP. Na headless tego problemu nie masz, bo SSG serwuje statyczny HTML.
• Użyj CDN (Cloudflare, Bunny CDN). Typowa poprawa LCP: ~0,6 sekundy.
• Zoptymalizuj zapytania do bazy, szczególnie w koszyku i na stronach kategorii.

Szacowana poprawa: 0,8 sekundy z samej redukcji TTFB przy dobrej konfiguracji.

Optymalizacja CSS i JavaScript

• Inline critical CSS w <head>. Tylko najważniejsze style potrzebne do first paint.
• Resztę CSS ładuj asynchronicznie.
• Usuń nieużywany CSS i JS (tree shaking).
• Dziel długie zadania JS na mniejsze (yield to main thread).

Dlaczego architektura decyduje o Twoim suficie CWV

Optymalizacja ma sufit. Na WooCommerce z Elementorem możesz wycisnąć LCP do 3 sekund po tygodniach pracy, ale do 1,5 sekundy już się nie zejdziesz, bo problem jest strukturalny. Next.js z SSG startuje od zera w okolicach 1–1,5 sekundy out of the box.

To nie jest kwestia „lepszych deweloperów". To kwestia tego, że jedna architektura renderuje stronę przy każdym żądaniu na serwerze z bazą i wtyczkami, a druga serwuje gotowy HTML z CDN-u, który dotarł do użytkownika zanim serwer źródłowy w ogóle o tym usłyszał.

Z wdrożeń w stylu headless: po migracji z tradycyjnej platformy LCP skraca się typowo do 1,8–2,2 sekundy na mobile, bounce rate spada o 30–40%, konwersja rośnie o 12–18%, CPA spada o około 25%. To nie są liczby z reklamy, to typowe efekty wynikające wprost z mechaniki: szybciej pokazana treść to więcej osób, które zostają, a więcej osób, które zostają, to więcej zamówień.

Nie każdy sklep musi iść w headless. Jeśli masz małego sklepa z 20 produktami i 300 wizytami miesięcznie, siłowe przejście na headless dla CWV się nie zwróci. Jeśli masz rosnący sklep z ruchem w pięciocyfrowych i budżetem reklamowym w pięciocyfrowych, każda sekunda LCP to miesięcznie kilka tysięcy PLN nie-przychodu. Tu rachunek staje się prosty.

Narzędzia do pomiaru CWV

• Google PageSpeed Insights. Dane laboratoryjne (Lighthouse) plus terenowe (CrUX, realni użytkownicy Chrome). Najlepszy punkt startowy.
• Lighthouse. Audyt w Chrome DevTools. Szczegółowe rekomendacje, ale tylko dane laboratoryjne.
• Google Search Console → Core Web Vitals. Raport na poziomie całej domeny, klasyfikuje strony jako Dobre / Wymagające poprawy / Słabe. To tym Google faktycznie Cię rankuje.
• WebPageTest. Waterfall charts na poziomie każdego zasobu, identyfikacja wąskich gardeł.
• Chrome DevTools → Performance. Analiza renderowania klatka po klatce, przy debugowaniu konkretnych problemów.

Uwaga: dane laboratoryjne (Lighthouse w DevTools) nie zawsze pokrywają się z terenowymi (CrUX). Google rankuje po terenowych, więc na nich musisz się skupić, nawet jeśli Lighthouse pokazuje 95/100.

Najczęściej zadawane pytania

Jakie są realne koszty optymalizacji CWV na istniejącym sklepie?

Zależy od punktu startu. Na Shoperze z domyślnym szablonem, bez wtyczek, LCP zwykle mieści się w 3–4 sekundy. Na WooCommerce z Elementorem i dwudziestoma pluginami potrafi przekraczać 6 sekund. Porządna optymalizacja w granicach platformy to zwykle 5–15 tys. PLN jednorazowo plus ciągłe utrzymanie. Problem w tym, że sufit optymalizacji na ciężkich platformach jest niski, więc często inwestujesz kilkanaście tysięcy, a i tak nie zejdziesz poniżej 3 sekund.

Czy headless to jedyny sposób na zielone CWV?

Nie, ale najpewniejszy. Na Shoperze z minimalistycznym szablonem da się zejść poniżej 2,5 sekundy. Na WooCommerce z lekkim motywem, bez page buildera, z WP Rocket i CDN-em też. Problem w tym, że takie konfiguracje są rzadkie, bo kolidują z tym, jak właściciele sklepów faktycznie używają tych platform (page buildery, dziesiątki wtyczek, markety szablonów). Headless daje zielone CWV jako domyślne zachowanie, nie jako efekt walki z systemem.

Czy CWV dotyczą też mobile, czy głównie desktop?

Google mierzy i rankuje oba, ale mobile jest ważniejsze. Od 2019 roku obowiązuje mobile-first indexing, wersja mobilna jest bazą do oceny rankingu. W e-commerce ponad połowa zakupów odbywa się na telefonach, a to właśnie na mobile różnica w LCP między dobrą a słabą architekturą jest największa (wolniejsze procesory, słabsze połączenia).

Jak długo trzeba czekać na poprawę rankingu po optymalizacji CWV?

Google odświeża dane CrUX w 28-dniowych oknach, więc zanim zobaczysz pełny efekt w Search Console, minie miesiąc od pełnego wdrożenia. Realny wpływ na pozycje widać zwykle w 6–12 tygodni. Efekt na konwersję jest natychmiastowy, od pierwszego dnia szybszej wersji.

Co zrobić najpierw: LCP, INP czy CLS?

Zacznij od LCP. To metryka z najwyższym wpływem na konwersję i najczęściej to ona jest problemem w e-commerce. CLS naprawia się szybko (ustalone rozmiary obrazów, rezerwacja miejsca na baner) i warto to zrobić przy okazji. INP to już finezja i zwykle nie jest głównym bottleneckiem, chyba że masz ciężki checkout z wieloma interakcjami.

Na koniec

Core Web Vitals to nie jest abstrakcyjna metryka z dashboardu Google Search Console. To liczba, która bezpośrednio mapuje się na procent ludzi, którzy zobaczą Twój produkt, zanim klikną „wstecz". Przy LCP 2 sekund zostaje ich większość. Przy 5 sekundach większość odchodzi, zanim strona się załaduje.

Dobra wiadomość: to jest naprawialne. Zła wiadomość: na tradycyjnych platformach sufit naprawialności jest niski, a każde większe przejście powyżej niego wymaga architektonicznej zmiany, nie kolejnej wtyczki optymalizacyjnej.

Jeśli mierzysz swój LCP powyżej 3 sekund i czujesz, że kolejny plugin nic już nie zmieni, zacznijmy od konkretnej diagnozy. Pokażemy, gdzie dokładnie siedzi problem i czy to kwestia optymalizacji w ramach obecnej platformy, czy sufit, który można przebić tylko zmianą architektury. Bez marketingu, z liczbami z Twojego sklepu.