Blog · Performance · IdoSell

Core Web Vitals w IdoSell — jak poprawić wyniki

LCP, INP i CLS to trzy metryki, na które patrzy Google przy ocenie strony. W sklepie IdoSell część poprawek zrobisz w 10 minut przez panel, część wymaga ingerencji w szablon. Pokazujemy, co i jak — bez ogólników.

CZAS CZYTANIA: ~12 MIN

Google od 2021 roku traktuje Core Web Vitals jako jeden z czynników rankingowych. W praktyce wpływ na pozycje nie jest dramatyczny dla pojedynczego sklepu, ale w konkurencyjnych branżach (moda, elektronika, kosmetyki) różnica między "szybkim" a "wolnym" sklepem na tych samych frazach potrafi przesunąć ruch o kilkanaście procent. Drugi efekt jest jeszcze ważniejszy: powolny sklep konwertuje gorzej, niezależnie od SEO. Ten wpis pokazuje, co konkretnie da się poprawić w sklepie IdoSell, gdzie są ograniczenia platformy i jak realistycznie podejść do optymalizacji wydajności.

Czym są Core Web Vitals

Core Web Vitals to trzy metryki opisujące jak strona "czuje się" dla użytkownika. Google mierzy je w terenie (dane z prawdziwych przeglądarek użytkowników, agregowane w bazie CrUX) i porównuje z laboratorium (PageSpeed Insights, Lighthouse).

LCP — Largest Contentful Paint

Czas, w którym największy element widocznej części strony staje się widoczny. W sklepie internetowym to zwykle główne zdjęcie produktu, banner kategorii albo hero na stronie głównej. Progi Google:

Dobre: < 2,5 sekundy

Wymaga poprawy: 2,5 - 4,0 sekundy

Słabe: > 4,0 sekundy

INP — Interaction to Next Paint

Czas od kliknięcia/dotknięcia do widocznej reakcji strony. Zastąpił starszy FID w marcu 2024. Mierzy wszystkie interakcje na stronie i bierze najgorszą. W sklepach problem pojawia się najczęściej przy: kliknięciu w filtr produktów, dodaniu do koszyka, otwarciu mega-menu. Progi:

Dobre: < 200 ms

Wymaga poprawy: 200 - 500 ms

Słabe: > 500 ms

CLS — Cumulative Layout Shift

Suma "przesunięć" layoutu podczas ładowania strony. Klasyczny przykład: czytasz tekst, ładuje się banner i wszystko zjeżdża w dół. To nie tylko frustruje, ale prowadzi do pomyłkowych kliknięć (klikam "kup", ładuje się banner, klikam "usuń konto"). Progi:

Dobre: < 0,1

Wymaga poprawy: 0,1 - 0,25

Słabe: > 0,25

Strona dostaje status "Good" w Search Console tylko jeśli wszystkie trzy metryki są dobre. Jedna słaba metryka degraduje całość.

Gdzie i jak zmierzyć wynik

Zanim cokolwiek poprawisz, musisz wiedzieć, na czym stoisz. Cztery narzędzia, których używamy:

Google Search Console → Core Web Vitals

Najważniejsze źródło, bo pokazuje dane realnych użytkowników sklepu — w podziale na mobile i desktop, z listą konkretnych URL-i, które są problematyczne. Wymaga 28 dni od pierwszej wizyty użytkownika z aktywną telemetrią Chrome, więc nowy sklep tu nic nie pokaże od razu.

PageSpeed Insights (web.dev/measure)

Pokazuje dwie warstwy: dane z CrUX (jak Search Console — dane terenowe) i symulację laboratoryjną (Lighthouse). To drugie jest pomocne, ale ma swój haczyk: Lighthouse symuluje słabe łącze i procesor, więc laboratoryjne wyniki są ZAWSZE gorsze niż rzeczywiste. Nie martw się "75/100" w lab — patrz na CrUX.

Chrome DevTools → Performance + Lighthouse

Do diagnozy konkretnych problemów. DevTools pokazuje, co dokładnie blokuje renderowanie, które skrypty wykonują się długo, co powoduje layout shift. Dla deweloperów — niezbędne narzędzie. Dla operatora sklepu wystarczy Search Console.

CrUX Report (publicznie dostępny)

Możesz sprawdzić dowolną domenę, nawet konkurenta, na treo.sh/sitespeed albo BigQuery z CrUX. Daje obraz, czy Twój sklep wypada lepiej czy gorzej od konkurencji na tych samych frazach.

Jak poprawić LCP w sklepie IdoSell

LCP w sklepie e-commerce to zwykle główne zdjęcie produktu na karcie albo banner hero na stronie głównej. Pięć rzeczy, które realnie pomagają:

Format zdjęć — WebP, nie JPG

IdoSell potrafi serwować zdjęcia w formacie WebP zamiast JPG/PNG — to ustawienie panelu. WebP ma zwykle 25-35% mniejszy rozmiar przy tej samej jakości wizualnej. Sama zmiana formatu potrafi obniżyć LCP o 0,5-1,5 sekundy w mobile. Sprawdź w panelu IdoSell w ustawieniach grafik, czy konwersja do WebP jest włączona.

Wymiary zdjęć dopasowane do realnego użycia

Klasyczny problem: zdjęcie produktowe ma 3000x3000 px (z aparatu), a wyświetlane jest jako 500x500. Przeglądarka pobiera 1,5 MB i renderuje thumbnail. W IdoSell konfigurujesz wymiary miniatur i wariantów zdjęć — warto przejrzeć ustawienia i upewnić się, że zdjęcia listingu są generowane w sensownych rozmiarach, nie 1:1 z oryginałów.

Lazy-loading dla zdjęć poza viewportem

Zdjęcia, które nie są widoczne na pierwszym ekranie (poniżej fold), powinny ładować się dopiero, gdy użytkownik do nich doscrolluje. To natywna funkcja przeglądarki (loading="lazy"). Ważne: nie ładuj lazy najważniejszego zdjęcia (hero, główne zdjęcie produktu) — to zaszkodzi LCP, bo Google chce zobaczyć ten element jak najszybciej. Lazy dotyczy tylko obrazków poniżej fold.

Preload głównego zdjęcia karty produktu

Na karcie produktu warto zasygnalizować przeglądarce: "to zdjęcie będzie potrzebne od razu, ładuj priorytetowo". Robi się to przez <link rel="preload" as="image"> w head. To zaawansowana optymalizacja wymagająca modyfikacji szablonu, ale potrafi obniżyć LCP o 0,3-0,8 sekundy.

CDN i kompresja po stronie serwera

IdoSell ma własną infrastrukturę CDN dla zdjęć. To załatwia większość problemów z dostarczaniem grafik. Co możesz dorzucić: Cloudflare przed sklepem dla cache'owania HTML i kompresji Brotli. To pomoże nie tylko LCP, ale całemu czasowi ładowania.

Jak poprawić INP w sklepie IdoSell

INP mierzy responsywność — jak szybko strona reaguje na interakcję. W sklepach problem pojawia się niemal zawsze w JavaScript. Co konkretnie się dzieje i co z tym zrobić:

Skrypty trzecich (Analytics, Pixel, chat, recenzje)

Każdy zewnętrzny skrypt (Google Analytics, Meta Pixel, Hotjar, chatbot, system opinii) dodaje obciążenie przy każdej interakcji użytkownika. Audyt: otwórz DevTools → Network → Filter "JS" i policz, ile skryptów ładuje się na stronie produktu. Sklepy z 15-25 zewnętrznymi skryptami to standard, i to jest największy zabójca INP.

Co można zrobić:

Usuń to, czego realnie nie używasz — chatboty, które nikt nie kliknął od pół roku, integracje z platformami, które już nie sprzedają

Konsoliduj przez Google Tag Manager — jeden skrypt na stronie, a w GTM zarządzasz wszystkim. Łatwiej kontrolować, co kiedy się ładuje

Defer i async dla skryptów nie-krytycznych — w szablonie IdoSell większość zewnętrznych skryptów można wczytywać asynchronicznie, żeby nie blokowały głównego wątku

Filtry produktowe

W sklepach z dużą liczbą filtrów (rozmiar, kolor, cena, marka, materiał...) kliknięcie filtra często potrafi zająć 500-1000 ms — bo JavaScript musi przebudować całą listę produktów. Jeśli to Twój problem, dwie ścieżki:

Filtry server-side — kliknięcie filtra to przekierowanie z nowym parametrem URL, sklep renderuje listę po stronie serwera. Wolniejsze wizualnie, ale ma zerowy INP. Dobre dla SEO (każdy filtr ma swój URL).

Filtry AJAX z optymalizacją — JavaScript, ale z debouncingiem, cache'owaniem wyników i renderowaniem przez Virtual DOM zamiast pełnego rebuildu

Animacje koszyka i menu

Mega-menu, które animuje się przy hover, animowane przejście dodania do koszyka, slidery banerów na stronie głównej — wszystko to potrafi blokować INP. Praktyczne podejście: jeśli animacja trwa dłużej niż 200 ms i nie ma kluczowej funkcji, wytnij ją. Mniej znaczy szybciej.

Jak poprawić CLS w sklepie IdoSell

CLS to przesunięcia layoutu podczas ładowania strony. Pięć typowych winowajców i ich naprawienie:

Zdjęcia bez deklarowanych wymiarów

Klasyk: zdjęcie produktu w HTML <img src="..."> bez atrybutów width i height. Dopóki obrazek się nie pobierze, przeglądarka nie wie, ile miejsca zarezerwować — więc treść pod nim "skacze" w momencie załadowania. Każdy <img> musi mieć zadeklarowane wymiary. To do sprawdzenia w szablonie IdoSell.

Reklamy i banery ładowane asynchronicznie

Banner reklamowy, który ładuje się po stronie skryptu reklamowego, wstawia się w środek treści i pcha wszystko w dół. Rozwiązanie: zarezerwuj miejsce na banner ze stałą wysokością (placeholder div ze sztywno ustawioną wysokością odpowiadającą bannerowi). Wtedy ładujący się banner wpadnie w przygotowane miejsce i nic się nie przesuwa.

Web fonts

Strona wczytuje się systemowym fontem, po chwili dochodzi własny font (np. Inter) — i tekst zmienia rozmiar/odstępy. To "flash of unstyled text" plus przesunięcie layoutu. Trzy techniki:

font-display: optional w CSS — jeśli font nie dojedzie szybko, pomijamy go zupełnie. Brak przesunięć, ale ryzyko że user zobaczy systemowy font

Preload kluczowego fontu — <link rel="preload" as="font"> w head. Font ładuje się równolegle z resztą strony

Dopasowanie metryki fontu fallback — przez size-adjust i podobne. Zaawansowane, ale działa

Pop-upy zgody na cookies (RODO)

Cookie banner, który ładuje się po sekundzie i zajmuje pół ekranu, to katastrofa dla CLS. Banner powinien być częścią pierwszego renderu strony, nie ładować się przez skrypt po 800 ms. W IdoSell jeśli używasz wbudowanego mechanizmu zgód, to jest OK. Jeśli wgrałeś zewnętrzny (Iubenda, Cookiebot, CookieYes), sprawdź, czy nie psuje layoutu.

Powiadomienia "Ktoś właśnie kupił..."

Toast w lewym dolnym rogu, który pojawia się po sekundzie i przesuwa layout — popularny zabieg w sklepach. Sprawdź, czy ma position: fixed. Jeśli ma, nie powinien wpływać na CLS. Jeśli jest pozycjonowany inline, wstaw go do position: fixed albo wytnij.

Czego nie zmienisz w IdoSell

IdoSell jako platforma SaaS ma ograniczenia, których nie obejdziesz bez modyfikacji rdzenia (a tego nie robimy). Kilka rzeczy, których nie da się "naprawić" w klasycznym sensie:

Globalne skrypty platformy — IdoSell ładuje własne skrypty obsługujące panel klienta, koszyk, formularze. Nie usuniesz ich, są częścią platformy. Można je tylko optymalizować w czasie, jak robi to sam dostawca

Server response time (TTFB) — czas odpowiedzi serwera zależy od infrastruktury IdoSell. Możesz wpiąć Cloudflare przed sklep, ale część komunikacji (koszyk, checkout, panel klienta) i tak pójdzie do origin

Crawler optymalizacja — nie masz dostępu do .htaccess, więc nie ustawisz własnych nagłówków cache, kompresji itp. To po stronie IdoSell

Dobra wiadomość: te elementy zwykle są już dobrze skonfigurowane po stronie platformy. Realny budżet optymalizacji w sklepie IdoSell leży głównie w szablonie, zdjęciach i skryptach zewnętrznych — i tam można uzyskać dramatyczną poprawę.

Lista kontrolna — od czego zacząć

Praktyczna sekwencja działań przy audycie CWV sklepu IdoSell. Kolejność od "darmowe i szybkie" do "wymaga większej pracy":

Quick wins (1-2 dni pracy)

Sprawdź w panelu IdoSell: czy włączona konwersja zdjęć do WebP

Sprawdź wymiary miniatur produktów — czy nie są niepotrzebnie duże

Audyt skryptów trzecich na stronie produktu (DevTools → Network → JS)

Wyłącz analytics/pixel/chatboty, których nie używasz aktywnie

Sprawdź cookie banner — czy nie wpływa na CLS

Średnie (3-7 dni pracy)

Audyt szablonu — czy <img> mają zadeklarowane wymiary

Konsolidacja skryptów przez Google Tag Manager

Lazy-loading dla zdjęć poza fold (jeśli nie jest natywne w szablonie)

Preload głównego zdjęcia karty produktu i kluczowego fontu

Defer dla nie-krytycznych skryptów

Większe (1-3 tygodnie pracy)

Customowy szablon zoptymalizowany pod CWV — od zera albo gruntowna przeróbka

Przejście z filtrów AJAX na server-side z URL-ami pod SEO

Wpięcie Cloudflare przed sklep z konfiguracją cache i Brotli

Optymalizacja krytycznej ścieżki CSS (critical CSS inline w head)

Co dalej — pomiar i monitoring

Po wdrożeniu poprawek nie patrzy się od razu na Search Console. Cykl wygląda tak:

Dzień 0: wdrażasz zmianę, robisz pomiar w PageSpeed Insights — widzisz różnicę w lab (Lighthouse) od razu

Tydzień 1-2: dane z CrUX (terenowe) zaczynają się aktualizować, ale są mieszane — średnia z ostatnich 28 dni zawiera jeszcze dane sprzed zmiany

Tydzień 4: pełne dane terenowe pokazują rzeczywisty wpływ zmiany

Tydzień 4-8: Search Console → Core Web Vitals stabilizuje status strony (Good / Needs Improvement / Poor)

Po 2-3 miesiącach: jeśli wszystko OK, pozycje w SERP-ach mogą wzrosnąć na konkurencyjnych frazach. Wpływ jest niewielki, ale mierzalny

Najczęstsza pułapka: wdrażasz zmianę, sprawdzasz Search Console po tygodniu, nic się nie zmieniło, frustrujesz się. To normalne — dane terenowe potrzebują czasu. Patrz na PageSpeed Insights → lab data zaraz po wdrożeniu, na CrUX po 4 tygodniach.

Podsumowanie

Core Web Vitals to nie magia. To pomiar trzech bardzo konkretnych rzeczy: jak szybko ładuje się największy element, jak szybko strona reaguje na klik, ile się "trzęsie" podczas ładowania. W sklepie IdoSell większość problemów wynika z:

Za dużych zdjęć produktów (LCP)

Zbyt wielu skryptów zewnętrznych (INP)

Brakujących wymiarów obrazków w szablonie (CLS)

Niezoptymalizowanego cookie bannera (CLS)

Większość quick wins jest do zrobienia w 1-2 dni. Większy projekt optymalizacji szablonu i filtrów zajmie 2-3 tygodnie, ale daje wymierne efekty: lepszą konwersję, niższy bounce rate, lepsze pozycje w Google na konkurencyjnych frazach. Jeśli chcesz dowiedzieć się więcej o tym, jak błędy SEO w sklepach IdoSell wpływają na pozycje, albo jak prowadzimy stałą pracę SEO dla naszych klientów — sprawdź powiązane wpisy i usługi.