Jak poprawić Core Web Vitals? Sprawdź zaawansowane techniki

Largest Contentful Paint mierzy czas renderowania największego widocznego elementu, najczęściej obrazu hero lub nagłówka. Zacznij od serwera: zredukuj TTFB poniżej 200 ms wybierając hosting z serwerami blisko użytkowników i włączając cache na poziomie serwera (Redis, Varnish). Następnie dodaj preload do najważniejszego obrazu w sekcji head dokumentu HTML. Wstaw krytyczny CSS (above-the-fold) inline w tagu style, a resztę arkuszy stylów załaduj asynchronicznie. Zamień duże obrazy na format WebP lub AVIF z atrybutem fetchpriority=high dla obrazu hero. Jeśli LCP to tekst, zoptymalizuj ładowanie fontów za pomocą font-display: swap i preload plików WOFF2.

Od marca 2024 roku Google zastąpiło FID nowym wskaźnikiem INP (Interaction to Next Paint), który mierzy responsywność na wszystkie interakcje użytkownika, nie tylko pierwszą. Wartość progowa to 200 ms. Główna przyczyna wysokiego INP to blokujący JavaScript. Użyj Chrome DevTools (zakładka Performance) do identyfikacji długich zadań (Long Tasks). Podziel ciężkie operacje na mniejsze fragmenty za pomocą funkcji scheduler.yield() lub requestIdleCallback. Odrocz ładowanie skryptów analitycznych i marketingowych za pomocą atrybutów defer lub async. Zewnętrzne widgety (czat, pop-upy, embedy social media) ładuj dopiero po interakcji użytkownika, np. po pierwszym kliknięciu.

Cumulative Layout Shift mierzy, jak bardzo elementy strony przeskakują podczas ładowania. Próg to 0,1. Najczęstsze przyczyny wysokiego CLS to obrazy bez zadeklarowanych wymiarów, dynamicznie wstrzykiwane reklamy i banery cookie, fonty zastępowane po załadowaniu (FOUT) oraz lazy-loaded elementy zmieniające wysokość strony. Rozwiązania: zawsze deklaruj width i height obrazów w HTML, rezerwuj przestrzeń dla reklam za pomocą min-height w CSS, stosuj font-display: optional dla fontów dekoracyjnych i używaj content-visibility: auto z contain-intrinsic-size dla elementów poniżej widoku. Przetestuj CLS na mobile osobno, bo tam wartości bywają znacznie wyższe.

Google Search Console pokazuje zagregowane dane polowe (od realnych użytkowników), ale do głębokiej diagnostyki potrzebujesz dodatkowych narzędzi. Chrome DevTools z zakładką Performance nagrywają sesję i pokazują waterfall z dokładnością do milisekund. WebPageTest pozwala przetestować stronę z różnych lokalizacji i urządzeń, generując filmstrip ładowania klatka po klatce. CrUX Dashboard w Google Data Studio prezentuje dane historyczne Core Web Vitals, byś widział trendy zmian. Na poziomie kodu biblioteka web-vitals od Google (npm) pozwala wysyłać dane CWV do własnego systemu analitycznego, by monitorować je w czasie rzeczywistym.

Skrypty reklamowe (Google Ads, Facebook Pixel), chatboty, narzędzia heatmap (Hotjar) i tagi Google Tag Manager mogą dodać 500 ms do czasu ładowania i znacząco pogorszyć INP. Zamiast usuwać je całkowicie, zastosuj strategię opóźnionego ładowania. Skrypt GTM załaduj z atrybutem defer i uruchom tagi z niskim priorytetem po zdarzeniu load. Pixel Facebooka możesz inicjalizować po 3 sekundach od załadowania strony za pomocą setTimeout. Chatboty uruchamiaj dopiero po kliknięciu ikony czatu. Partytown to biblioteka, która przenosi skrypty zewnętrzne do Web Workera, uwalniając główny wątek od ich obciążenia.