Prędkość strony i SEO: Core Web Vitals, LCP, INP, CLS w 2026 roku

Dlaczego prędkość strony jest krytyczna dla SEO

Od 2021 roku Google oficjalnie uwzględnia Core Web Vitals w rankingach — są to metryki prędkości i użyteczności mierzone w rzeczywistych warunkach na rzeczywistych urządzeniach użytkowników. Strony, które przechodzą próg Core Web Vitals, otrzymują niewielką przewagę w rankingach.

Jednak bardziej istotny jest wpływ pośredni: wolna strona → wyższy wskaźnik odrzuceń → mniej czasu na stronie → gorsze sygnały behawioralne → niższe pozycje. Dodatkowo Google przydziela mniejszy budżet na indeksowanie wolnym stronom.

Core Web Vitals: trzy kluczowe metryki

LCP — Largest Contentful Paint

Czas do pojawienia się największego widocznego elementu (zwykle główne zdjęcie lub nagłówek). Pokazuje, kiedy użytkownik widzi główną treść.

• Dobrze: do 2.5 sekundy
• Wymaga poprawy: 2.5–4 s
• Źle: ponad 4 sekundy

Główne przyczyny słabego LCP: duże niekompresowane obrazy, wolny serwer, zasoby blokujące renderowanie (JS, CSS), brak CDN.

INP — Interaction to Next Paint

Czas reakcji na interakcję użytkownika (kliknięcie, dotyk, wpisanie). Zastąpił FID w marcu 2024 roku.

• Dobrze: do 200 ms
• Wymaga poprawy: 200–500 ms
• Źle: ponad 500 ms

CLS — Cumulative Layout Shift

Całkowite przesunięcie elementów podczas ładowania. Treść "skacze", gdy ładowane są obrazy lub reklamy.

• Dobrze: do 0.1
• Wymaga poprawy: 0.1–0.25
• Źle: ponad 0.25

Optymalizacja obrazów — najszybszy zysk

Obrazy są główną przyczyną wolnego LCP. Kilka zasad:

• Format WebP — o 25–35% mniejszy niż JPEG przy tej samej jakości
• Lazy loading — loading="lazy" dla obrazów poniżej pierwszego ekranu
• Wymiary w HTML — zawsze podawaj width i height, aby uniknąć CLS
• Preload LCP obraz — dodaj <link rel="preload" as="image"> dla głównego obrazu
• CDN dla obrazów — Cloudflare Images lub odpowiednik dla globalnej dostawy

Prędkość serwera i TTFB

TTFB (Time to First Byte) — czas do pierwszego bajtu odpowiedzi serwera. Google uważa TTFB do 800 ms za dobry.

• Cache — strony powinny być zwracane z cache, a nie generowane za każdym razem
• Hosting — VPS lub hosting w chmurze jest znacznie szybszy niż shared
• CDN — Cloudflare bezpłatnie zmniejsza TTFB dla odwiedzających z różnych krajów
• Bazy danych — wolne zapytania SQL są najczęstszą przyczyną złego TTFB

Optymalizacja JavaScript i CSS

Przeglądarka nie może renderować strony, gdy pobierane i wykonywane są zasoby blokujące renderowanie:

• Przenieś JS na koniec body lub dodaj defer / async
• Wydziel krytyczny CSS (above-the-fold) i wbuduj go w head
• Minifikuj i kompresuj pliki JS i CSS
• Usuń nieużywany CSS (zakładka Coverage w DevTools)
• Podziel duży JS na kawałki i ładuj je leniwie

Czcionki i prędkość

• Używaj font-display: swap — tekst jest widoczny od razu, czcionka ładowana w tle
• Preconnect do fonts.googleapis.com i fonts.gstatic.com
• Ogranicz warianty czcionek — tylko te wagi, które są rzeczywiście używane
• Rozważ czcionki systemowe dla krytycznego tekstu (zerowy czas ładowania)

Optymalizacja mobilna

Google używa indeksowania Mobile-First — indeksuje mobilną wersję strony jako główną. Dlatego prędkość mobilna jest ważniejsza niż desktopowa.

• Sprawdź mobilny PageSpeed oddzielnie od desktopowego
• Testuj na rzeczywistych urządzeniach, a nie tylko w DevTools
• Przyciski minimum 48x48px dla łatwego dotyku
• Unikaj poziomego przewijania
• Popupy nie powinny zasłaniać głównej treści (kara za intruzywne interstitials)

Lista kontrolna prędkości strony

• LCP poniżej 2.5 sekundy na urządzeniach mobilnych
• INP poniżej 200 ms
• CLS poniżej 0.1
• Wszystkie obrazy w formacie WebP
• lazy loading dla obrazów poniżej pierwszego ekranu
• Podłączone CDN (Cloudflare lub odpowiednik)
• JS przeniesione na koniec lub dodane defer
• Cache serwera skonfigurowane
• TTFB poniżej 800 ms
• font-display: swap dla niestandardowych czcionek
• Audyt skryptów zewnętrznych zakończony