Core Web Vitals 100/100: jak budujemy strony, które ładują się w sekundę

Trzy metryki, które naprawdę liczą się dla Google

Core Web Vitals sprowadzają wydajność do trzech mierzalnych rzeczy. Warto je znać, bo każda opisuje inny moment z perspektywy użytkownika.

• LCP (Largest Contentful Paint): jak szybko pojawia się największy element widoczny na ekranie, zwykle nagłówek lub główne zdjęcie. Cel: poniżej 2,5 sekundy.
• INP (Interaction to Next Paint): jak szybko strona reaguje na kliknięcie czy dotyk. Cel: poniżej 200 milisekund.
• CLS (Cumulative Layout Shift): czy treść nie „przeskakuje" podczas ładowania. Cel: poniżej 0,1.

Te trzy liczby mierzy między innymi PageSpeed Insights i raport w Google Search Console. Wynik 100 nie bierze się z jednego triku. Bierze się stąd, że żaden etap ładowania nie marnuje czasu użytkownika.

Renderowanie po stronie serwera i statyczne strony

Najczęstsza przyczyna wolnego LCP to strona, która najpierw ładuje pustą skorupę, potem pobiera JavaScript, a dopiero on dorysowuje treść. Użytkownik patrzy w tym czasie na biały ekran. Rozwiązanie to renderowanie treści zawczasu, czy to statycznie przy budowaniu strony, czy po stronie serwera, tak by przeglądarka dostała gotowy HTML i pokazała go od razu.

W praktyce strona firmowa czy landing page powinny serwować gotową treść, a interaktywność doładowywać dopiero tam, gdzie naprawdę jest potrzebna. Mniej JavaScriptu na starcie to szybszy pierwszy obraz i lepszy INP.

Obrazy: największy i najłatwiejszy do naprawienia problem

Zdjęcia odpowiadają za większość wagi przeciętnej strony, a przy tym najłatwiej je okiełznać. Kilka decyzji potrafi ściąć rozmiar o 80% bez widocznej straty jakości.

• Format WebP lub AVIF zamiast JPG i PNG, często kilkukrotnie mniejszy plik przy tej samej jakości.
• Rozmiar dopasowany do realnego miejsca w layoucie, a nie wgrany prosto z aparatu.
• Atrybuty width i height na każdym obrazie, żeby przeglądarka rezerwowała miejsce i nie było przeskoków (CLS).
• Lazy loading dla zdjęć poniżej pierwszego ekranu, żeby nie blokowały startu.

Czcionki, które nie blokują renderowania

Niestandardowe czcionki potrafią opóźnić pokazanie tekstu albo wywołać przeskok, gdy font wreszcie się załaduje. Pomaga ładowanie tylko potrzebnych grubości i znaków, ustawienie zamiany fontu tak, by tekst był widoczny od razu, i wczesne nawiązanie połączenia z serwerem czcionek. Użytkownik czyta treść natychmiast, a font dociąga się w tle, bez szarpnięcia układu.

Mniej kodu znaczy szybszy klik

INP psuje się wtedy, gdy w momencie kliknięcia przeglądarka jest zajęta wykonywaniem JavaScriptu. Dlatego ograniczamy ciężkie biblioteki, dzielimy kod tak, żeby ładował się tylko ten potrzebny na danej stronie, i pilnujemy, żeby animacje korzystały z właściwości obsługiwanych sprzętowo. Najmocniej czuć to na tańszych telefonach, na których siedzi duża część ruchu.

Dlaczego to się opłaca biznesowo

Szybkość nie jest celem samym w sobie. Strona, która pokazuje ofertę w sekundę, zatrzymuje więcej osób, lepiej się pozycjonuje i taniej konwertuje ruch z reklam, bo Google nagradza dobre strony niższym kosztem kliknięcia. To jeden z nielicznych obszarów, w którym ta sama praca poprawia naraz SEO, doświadczenie użytkownika i wynik płatnych kampanii.

Podsumowanie

Wynik 100/100 to suma drobnych, konsekwentnych decyzji: gotowy HTML zamiast pustej skorupy, lekkie obrazy we właściwym formacie, czcionki, które nie blokują tekstu, i minimum JavaScriptu na starcie. Z osobna żadna z tych rzeczy nie jest spektakularna. Razem dają stronę, która ładuje się w sekundę i realnie sprzedaje.