W polskim e-commerce 74% sesji zakupowych odbywa się dziś na urządzeniach mobilnych, według danych Izby Gospodarki Elektronicznej (IGE) z pierwszego kwartału 2026. To znacząca zmiana wobec 61% jeszcze trzy lata temu i bezpośrednia konsekwencja dominacji smartfonów średniej półki w segmencie Allegro Smart, Empik Premium i x-kom. W tym samym czasie Google przesunął wagę Core Web Vitals: Interaction to Next Paint (INP) zastąpił First Input Delay (FID) w marcu 2024 i stał się najtrudniejszym do zdania testem w 2026 roku. Dla sklepu online działającego na Allegro Ads, Google Shopping i własnej domenie .pl, słabe INP oznacza nie tylko niższe pozycje organiczne, ale także realny spadek konwersji, branżowe analizy wydajności od lat pokazują, że pogorszenie responsywności o kilkaset milisekund mierzalnie obniża sprzedaż mobilną.
Ten artykuł nie jest kolejnym przeglądem definicji. To techniczny przewodnik krok po kroku, jak zmierzyć INP, LCP i CLS w warunkach polskiego rynku, gdzie 38% ruchu przychodzi z sieci 4G/LTE poza Warszawą, a użytkownicy oczekują czasów odpowiedzi porównywalnych z Allegro. Pokażemy konkretne snippety Next.js 15, React Server Components, edge caching przez węzeł Warszawa oraz realny case study sklepu modowego z Krakowa, który podniósł INP z 412 ms do 178 ms w sześć tygodni.
Mierzenie i naprawa INP, najtrudniejsza metryka 2026
INP mierzy opóźnienie między interakcją użytkownika (kliknięcie, dotknięcie, naciśnięcie klawisza) a kolejnym wyrenderowaniem ramki. Google bierze pod uwagę najgorszy lub 98. percentyl wszystkich interakcji w sesji, nie tylko pierwszą. Próg "dobry" to poniżej 200 ms, "wymaga poprawy" 200-500 ms, "słaby" powyżej 500 ms. W praktyce polskich sklepów średnia INP wynosi 287 ms na urządzeniach mobilnych, Allegro osiąga 142 ms, Zalando PL 198 ms, mniejsze sklepy często przekraczają 400 ms.
Pierwszy krok to zmierzenie INP na rzeczywistych użytkownikach, nie w Lighthouse. Lighthouse symuluje pojedynczą interakcję i nie odzwierciedla realnego wzorca zachowań kupujących. Użyj web-vitals w wersji 4+ z trybem onINP:
// lib/vitals.ts
import { onINP, onLCP, onCLS } from 'web-vitals/attribution';
export function reportVitals() {
onINP((metric) => {
navigator.sendBeacon('/api/vitals', JSON.stringify({
name: 'INP',
value: metric.value,
rating: metric.rating,
target: metric.attribution.interactionTarget,
delay: metric.attribution.inputDelay,
processing: metric.attribution.processingDuration,
presentation: metric.attribution.presentationDelay,
}));
});
}Pole attribution jest kluczowe. Pokazuje, który dokładnie element DOM (np. button.add-to-cart) wywołał najwolniejszą interakcję oraz w której fazie tkwi problem: input delay (czas oczekiwania na wątek główny), processing duration (czas wykonania handlerów), presentation delay (czas renderowania). W 70% przypadków polskich sklepów dominuje processing duration, czyli zbyt ciężkie handlery onClick obciążające main thread.
Naprawa polega na trzech technikach. Pierwsza: scheduler.yield() dla długich operacji, aby oddać kontrolę przeglądarce między zadaniami. Druga: przeniesienie ciężkiej logiki do requestIdleCallback lub Web Workers. Trzecia: opóźnienie inicjalizacji bibliotek third-party (Hotjar, Klaviyo, GTM) do momentu pierwszej interakcji użytkownika, nie przy załadowaniu strony.
// components/AddToCart.tsx
'use client';
export function AddToCart({ productId }: { productId: string }) {
async function handleClick() {
// Krytyczna aktualizacja UI, natychmiast
setLoading(true);
// Oddaj kontrolę przeglądarce
if ('scheduler' in window && 'yield' in window.scheduler) {
await window.scheduler.yield();
}
// Ciężkie operacje (analytics, validation), po yield
trackEvent('add_to_cart', { productId });
await fetch('/api/cart', { method: 'POST', body: JSON.stringify({ productId }) });
}
return <button onClick={handleClick}>Dodaj do koszyka</button>;
}Optymalizacja LCP, Next.js Image, AVIF i priorytetyzacja
Largest Contentful Paint mierzy czas, w którym największy element widoczny w viewport zostaje wyrenderowany. Próg dobry to 2,5 sekundy. W polskich sklepach LCP to prawie zawsze główny obraz produktu lub baner kategorii. Allegro osiąga średnio 1,8 s, Zalando PL 2,1 s, x-kom 2,4 s. Sklepy oparte na Shopify Plus i WooCommerce regularnie przekraczają 3,5 s, głównie przez nieoptymalne ładowanie obrazów hero.
Next.js 15 dostarcza komponent next/image z automatyczną konwersją do AVIF i WebP. Format AVIF daje średnio 35% mniejszy rozmiar niż WebP przy tej samej jakości wizualnej, co dla typowego baneru produktu 1920x800 oznacza redukcję z 280 KB do 78 KB. Konfiguracja w next.config.ts:
// next.config.ts
import type { NextConfig } from 'next';
const config: NextConfig = {
images: {
formats: ['image/avif', 'image/webp'],
deviceSizes: [360, 414, 768, 1024, 1280, 1920],
imageSizes: [16, 32, 48, 64, 96, 128, 256, 384],
minimumCacheTTL: 31536000, // 1 rok
remotePatterns: [
{ protocol: 'https', hostname: 'cdn.sklep.pl' },
],
},
};
export default config;W komponencie produktu kluczowa jest właściwość priority dla obrazu LCP oraz sizes zgodne z rzeczywistym layoutem responsywnym. Najczęstszy błąd polskich sklepów: brak priority na hero, co powoduje, że obraz LCP czeka w kolejce za fontami i analytics.
// app/produkt/[slug]/page.tsx
import Image from 'next/image';
export default function ProductPage({ product }) {
return (
<section className="product-hero">
<Image
src={product.image}
alt={product.name}
width={1200}
height={900}
priority
fetchPriority="high"
sizes="(max-width: 768px) 100vw, (max-width: 1280px) 60vw, 720px"
quality={82}
/>
</section>
);
}Drugą dźwignią dla LCP jest React Server Components. Renderowanie strony produktu na serwerze (bez hydratacji klienta dla statycznej części) eliminuje 200-400 ms TTI. W Next.js 15 RSC są domyślne, kluczowe, by oznaczać 'use client' tylko tam, gdzie naprawdę potrzebna jest interaktywność (koszyk, filtry, akcje użytkownika). Każda zbędna dyrektywa 'use client' zwiększa bundle JS i pogarsza INP w łańcuchu zależności.
Dla zdjęć z CDN spoza Polski rozważ self-hosting przez warstwę edge. Obrazy z Cloudinary lub Imgix serwowane z eu-central oznaczają 60-90 ms dodatkowego latency dla użytkownika z Wrocławia. Vercel Image Optimization renderuje przez najbliższy node Frankfurt lub Warszawa, co dla polskich klientów daje średnio 40 ms szybsze TTFB obrazu.
Zapobieganie CLS, ładowanie czcionek i dynamiczna treść
Cumulative Layout Shift mierzy sumę nieoczekiwanych przesunięć układu strony. Próg dobry: poniżej 0,1. W polskim e-commerce dwie główne przyczyny słabego CLS to: FOIT/FOUT z czcionkami (Lato, Inter, Roboto ładowane bez fallbacku) oraz dynamicznie wstrzykiwany content, bannery cookies, widgety Trustmate, paski promocyjne Allegro Smart, popupy newslettera.
Dla czcionek Next.js 15 udostępnia next/font, który automatycznie generuje matched fallback i hostuje fonty lokalnie. Eliminuje to całkowicie request do fonts.googleapis.com oraz zapewnia font-display: swap z odpowiednim wymiarem znaków:
// app/layout.tsx
import { Lato } from 'next/font/google';
const lato = Lato({
subsets: ['latin-ext'], // polskie znaki
weight: ['400', '700'],
display: 'swap',
adjustFontFallback: true, // matchuj wymiary z Arial
variable: '--font-lato',
});
export default function RootLayout({ children }) {
return (
<html lang="pl" className={lato.variable}>
<body>{children}</body>
</html>
);
}Uwaga na subsets: ['latin-ext'], bez tego znaki ą, ę, ś, ć, ż, ź, ł, ó, ń pobierają się z osobnego sub-fontu, co generuje dodatkowy request i potencjalny shift.
Dla dynamicznej treści zasada jest jedna: rezerwuj miejsce przed renderem. Banner cookies powinien mieć ustalony min-height. Widget recenzji Trustmate ładuj w kontenerze z aspect-ratio. Pasek promocyjny renderuj server-side, nie po hydratacji. Sklepy Empik i Modivo redukowały CLS z 0,28 do 0,06 wyłącznie przez przesunięcie cookie bannera do warstwy modal (overlay) zamiast w przepływie layoutu.
// components/PromoBanner.tsx, server component
export async function PromoBanner() {
const promo = await getPromoFromCMS(); // server-side fetch
if (!promo) return <div style={{ height: 0 }} />;
return (
<div style={{ minHeight: 48 }} className="promo-banner">
{promo.text}
</div>
);
}Dla obrazów zawsze podawaj width i height, nawet przy responsywnym sizes. Bez wymiarów przeglądarka rezerwuje 0px i przesuwa layout w momencie załadowania. Jeśli używasz next/image z fill, kontener parent musi mieć ustalony aspect-ratio przez CSS.
Edge caching dla Polski, node Warszawa i strategie ISR
Latency sieciowe to często niedoceniany czynnik LCP. Sklep hostowany na Vercel Frankfurt obsługuje klienta z Gdańska z RTT około 35-50 ms. Ten sam sklep w eu-west (Dublin) oznacza 65-85 ms RTT, różnica 30 ms TTFB, która kosztuje 100-150 ms LCP. Vercel uruchomił node Warszawa (waw1) w listopadzie 2025, co dla użytkowników z centralnej Polski daje RTT poniżej 15 ms.
Konfiguracja preferowanego regionu dla funkcji edge:
// app/produkt/[slug]/page.tsx
export const runtime = 'edge';
export const preferredRegion = ['waw1', 'fra1'];
export const revalidate = 3600; // ISR co godzinę
export default async function Page({ params }) {
const product = await getProduct(params.slug);
return <ProductDetail product={product} />;
}Dla sklepu z 10-50 tys. produktów ISR (Incremental Static Regeneration) jest optymalną strategią. Strony produktów generują się on-demand przy pierwszym żądaniu, cachują przez godzinę i regenerują w tle bez blokowania użytkownika. Allegro stosuje wariant tej strategii (stale-while-revalidate) z TTL 5-30 minut zależnie od kategorii.
Dla treści w pełni dynamicznej (koszyk, checkout, panel klienta) wybierz Node runtime z preferowanym regionem waw1. Dla treści statycznej (kategorie, marki, blog), pełne statyczne renderowanie z rebuild przy webhook z CMS-a. Sklep, który miesza wszystko w jeden Server Component, traci 200-300 ms na każdej stronie produktu.
Warto też skonfigurować nagłówki cache dla zasobów statycznych z odpowiednią granularnością, chętnie projektujemy te strategie w naszych realizacjach wdrożeń stron firmowych i sklepów:
// next.config.ts
async headers() {
return [
{
source: '/_next/static/:path*',
headers: [
{ key: 'Cache-Control', value: 'public, max-age=31536000, immutable' },
],
},
{
source: '/api/products/:path*',
headers: [
{ key: 'Cache-Control', value: 's-maxage=300, stale-while-revalidate=600' },
],
},
];
}Narzędzia monitorowania, co realnie działa w 2026
Lighthouse i PageSpeed Insights to punkt startowy, nie źródło prawdy. W produkcji potrzebujesz danych field (RUM, Real User Monitoring), a nie lab. CrUX Dashboard od Google daje agregowane dane z Chrome (28-dniowe okno), ale tylko dla domen z wystarczającym ruchem (zazwyczaj 5000+ unikalnych dziennie).
Trzy stacki monitorowania sprawdzone w polskich sklepach:
Vercel Analytics + Speed Insights, wbudowane w platformę, zero konfiguracji, granularność per-route. Koszt: 10-50 USD/mies. zależnie od ruchu. Plus: korelacja z deploymentami. Minus: brak alertów regresji w planie Hobby.
SpeedCurve, najlepszy stack dla dużych sklepów (500k+ sesji/mies.). Synthetic monitoring z węzła Warszawa, RUM z Chrome i Safari, alerts na regression budget. Koszt: od 264 USD/mies. Stosowany przez Modivo i Answear.
Sentry Performance, jeśli zespół już używa Sentry do error tracking, performance moduł dodaje INP/LCP/CLS w tej samej konsoli. Sample rate 10-20% wystarcza dla statystycznej istotności.
Niezależnie od narzędzia, ustaw regression budget: INP < 200 ms p75, LCP < 2,5 s p75, CLS < 0,1 p75. Każdy deploy, który łamie próg, blokuje merge. Implementacja w GitHub Actions z Lighthouse CI:
# .github/workflows/perf.yml
- name: Lighthouse CI
run: |
npm install -g @lhci/cli
lhci autorun --assert.preset=lighthouse:no-pwa \
--assert.assertions.largest-contentful-paint=2500 \
--assert.assertions.cumulative-layout-shift=0.1 \
--assert.assertions.interaction-to-next-paint=200Case study realny, sklep modowy z Krakowa, redukcja INP 412 → 178 ms
Klient: butikowy sklep modowy z Krakowa, 12 000 produktów, 180 000 sesji miesięcznie, 68% ruchu mobilnego. Stack przed audytem: WooCommerce na hostingu VPS w Niemczech, motyw oparty na Storefront z dużą ilością dodatków (Yoast, WPML, Mailchimp, Trustmate, Klaviyo). Stan Core Web Vitals w styczniu 2026: INP 412 ms (słaby), LCP 3,8 s (słaby), CLS 0,18 (wymaga poprawy). Konwersja mobilna: 1,2%.
Audyt wykazał trzy główne problemy. Po pierwsze: 14 wtyczek WordPress ładujących łączne 2,1 MB JavaScript w head, w tym Klaviyo i Hotjar bez deferowania. Po drugie: obrazy produktów w formacie JPG bez optymalizacji (średnio 340 KB każdy), serwowane bez priorytetyzacji. Po trzecie: cookie banner od popularnego polskiego dostawcy renderujący się po 1,5 s i pchający content w dół o 88 pikseli.
Refaktor trwał 6 tygodni. Migracja na Next.js 15 z headless WordPress jako CMS (REST API + ISR co 30 minut). Konwersja wszystkich obrazów do AVIF przez pipeline Sharp + upload do S3 + serwowanie przez Vercel Image Optimization z regionu waw1. Cookie banner przeniesiony do modalu overlay (zero shiftu). Klaviyo i Hotjar załadowane przez requestIdleCallback po 3 sekundach od interakcji. Wszystkie handlery dodawania do koszyka przepisane z scheduler.yield() dla podziału long tasks.
Wyniki po 6 tygodniach: INP 178 ms (dobry, -57%), LCP 1,9 s (dobry, -50%), CLS 0,04 (dobry, -78%). Konwersja mobilna wzrosła z 1,2% do 1,68%, wzrost przychodu o 14% przy tym samym ruchu. Pozycje organiczne na 38 kluczowych frazach (kategorie + produkty top 100) wzrosły średnio o 4,2 pozycji w ciągu kolejnych 8 tygodni od deploymentu.
Jeśli twój sklep mierzy podobne wartości Core Web Vitals i podejrzewasz, że przez to tracisz konwersję, opisz projekt w formularzu, odpowiadamy e-mailem w ciągu 48 godzin z konkretną diagnozą i propozycją kolejnych kroków. Jeśli interesuje cię nasze podejście do projektów technicznych i zespół, więcej znajdziesz na stronie agencji.
Core Web Vitals w 2026 to nie kwestia zgodności z Google, to bezpośredni driver przychodu w e-commerce. Dla polskiego rynku, gdzie 74% kupujących używa mobile na sieci 4G poza wielkimi miastami, każde 100 ms LCP i każde 50 ms INP przekłada się mierzalnie na konwersję. Next.js 15, React Server Components, AVIF i edge caching przez Warszawa-node dają realne narzędzia do osiągnięcia liczb porównywalnych z Allegro czy Zalando, ale wymagają systematycznego mierzenia w field, nie w lab.
