Core Web Vitals w praktyce: jak naprawić 5 problemów, które spowalniają większość stron małych firm
Większość stron małych firm nie przechodzi oceny Core Web Vitals z tych samych pięciu powodów: zbyt dużych obrazów, niezoptymalizowanego elementu hero, ciężkich skryptów firm trzecich, przesunięć układu spowodowanych późno ładowaną treścią oraz rozbudowanych motywów i wtyczek. Naprawianie ich w kolejności zmierzonego wpływu, zaczynając od metryki, która zawodzi w danych od prawdziwych użytkowników, zwykle ma większe znaczenie niż jakiekolwiek narzędzie, wynik czy zmiana platformy.
Dlaczego wynik PageSpeed i rzeczywiste Core Web Vitals się nie zgadzają
Zielony wynik Lighthouse nie oznacza, że strona przechodzi ocenę. Lighthouse to dane laboratoryjne: jedno symulowane załadowanie strony przy ograniczonej prędkości połączenia. Ocena Core Web Vitals opiera się na danych terenowych, czyli pomiarach od prawdziwych użytkowników zbieranych przez Chrome UX Report i oceniany w ruchomym oknie 28 dni, jak opisuje dokumentacja Google web.dev.
Ta różnica wyjaśnia częstą skargę: strona dostaje 95 punktów w PageSpeed Insights, a mimo to nie przechodzi oceny w Search Console. Prawdziwi odwiedzający używają starszych telefonów, wolniejszych sieci i otwierają strony w sposób, którego test laboratoryjny nie odwzorowuje. Zanim zaufasz głównemu wynikowi, spójrz na sekcję danych terenowych na górze PageSpeed Insights oraz na raport Core Web Vitals w Search Console.
Trzy obecne metryki to LCP, INP i CLS. INP zastąpił FID (First Input Delay) jako Core Web Vital w marcu 2024 roku, według web.dev. Starsze poradniki, które wciąż wspominają o FID, są nieaktualne.
Co mierzą te trzy metryki, prostym językiem
Largest Contentful Paint (LCP) to czas, po którym pojawia się największy widoczny element, zwykle zdjęcie hero lub nagłówek. To czas oczekiwania. Udokumentowany przez Google próg „dobrego" wyniku to 2,5 sekundy lub mniej.
Interaction to Next Paint (INP) mierzy, jak szybko strona reaguje wizualnie po dotknięciu lub kliknięciu. To uczucie, gdy stukasz w menu i nic się nie dzieje. „Dobry" wynik to 200 milisekund lub mniej.
Cumulative Layout Shift (CLS) ocenia, jak bardzo treść przeskakuje podczas ładowania. To przycisk, który przesuwa się dokładnie w chwili, gdy ląduje na nim Twój kciuk. „Dobry" wynik to 0,1 lub mniej. Wszystkie trzy progi pochodzą z dokumentacji Web Vitals Google.
Co do pozycji w wynikach: Google opisało doświadczenie użytkownika na stronie jako umiarkowany sygnał, który nie przesłania trafności, zgodnie ze wskazówkami Search Central dotyczącymi page experience. Nie obiecujemy zysków w rankingu. Mocniejszy argument jest praktyczny: wolne, skaczące strony tracą odwiedzających, zanim ci cokolwiek przeczytają.
Problemy 1 i 2: zbyt duże obrazy i wolny element hero (LCP)
Na stronach małych firm elementem LCP jest niemal zawsze zdjęcie hero lub slider, a często jest to kilkumegabajtowy plik wgrany prosto z aparatu lub banku zdjęć. Zacznij tutaj, bo zwykle to największa pojedyncza poprawa.
- Zmień rozmiar obrazów do wymiarów, w jakich faktycznie są wyświetlane, a następnie serwuj WebP lub AVIF zamiast JPEG czy PNG.
- Używaj obrazów responsywnych (
srcset), żeby telefony nie pobierały plików w rozmiarze na komputery. - Nigdy nie stosuj leniwego ładowania (lazy loading) dla obrazu widocznego bez przewijania. Lazy loading opóźnia dokładnie ten element, który mierzy LCP.
- Dodaj
fetchpriority="high"do obrazu hero, żeby przeglądarka pobrała go wcześnie. - Zastąp slidery pojedynczym statycznym obrazem hero. Slidery dokładają JavaScript i zwykle opóźniają pierwszy obraz.
Co obserwujemy na stronach, które prowadzimy: obraz hero jest elementem LCP na większości podstron, a kompresja i usunięcie z niego lazy loadingu dają najbardziej widoczną zmianę. Nie sprawdziliśmy różnic między AVIF a WebP na wystarczającej liczbie stron, by twierdzić, że któryś konsekwentnie wygrywa; oba biją niezoptymalizowany JPEG.
Problem 3: skrypty firm trzecich blokujące interakcję (INP)
Widgety czatu, narzędzia do rezerwacji, menedżery tagów, piksele śledzące i osadzone opinie uruchamiają JavaScript w głównym wątku przeglądarki. Gdy ten wątek jest zajęty, dotknięcie czeka w kolejce, a INP rośnie.
Oceń każdy skrypt, porównując koszt z wartością biznesową. Otwórz Chrome DevTools, nagraj ślad w zakładce Performance podczas klikania po stronie i sprawdź, które skrypty zajmują wątek najdłużej. Potem zdecyduj: usunąć go, załadować dopiero po pierwszej interakcji albo hostować samodzielnie, jeśli pozwala na to licencja.
Kompromis jest realny. Widget rezerwacji, który przynosi wizyty, jest wart więcej niż kilka milisekund. Trzeci piksel śledzący, którego nikt nie czyta, nie jest. Podejmij tę decyzję jako właściciel firmy, a nie wyłącznie jako programista.
Problem 4: przesunięcia układu przez fonty, osadzenia i reklamy (CLS)
Przesunięcia powstają, gdy coś ładuje się późno i spycha treść w dół: obrazy bez atrybutów width i height, fonty webowe, które podmieniają się po wyrenderowaniu tekstu, banery cookies oraz osadzenia, takie jak mapy czy filmy.
Rozwiązaniem jest zarezerwowanie miejsca. Ustaw jawne wymiary obrazów i osadzeń (lub użyj CSS aspect-ratio) oraz zastosuj font-display: swap z podobnym rozmiarowo fontem zastępczym. Aby znaleźć winowajcę, otwórz DevTools, włącz opcję Layout Shift Regions w ustawieniach renderowania i przeładuj stronę; przesuwające się elementy migną na niebiesko.
Typowy przypadek: baner cookies wstrzykiwany na górze spycha całą stronę w dół. Naprawa polegająca na nałożeniu banera na dole albo wcześniejszym zarezerwowaniu jego wysokości często usuwa przesunięcie. Potem przetestuj ponownie na urządzeniu mobilnym, ponieważ to tam pojawia się większość problemów w danych terenowych.
Problem 5: ciężkie motywy, wtyczki i ograniczenia hostingu
Strona na WordPressie z wielofunkcyjnym motywem i tuzinem nałożonych na siebie wtyczek zwykle dostarcza znacznie więcej CSS i JavaScriptu, niż potrzebuje jakakolwiek podstrona. Lekkie motywy i wiele hostowanych kreatorów stron startuje z mniejszego bagażu, choć kreatory ograniczają to, co można zmienić pod maską.
Cache i CDN pomagają w dostarczaniu treści, ale nie naprawią przeładowanej strony ani wolnego serwera. Jeśli czas do pierwszego bajtu (TTFB) jest słaby, wszystko inne ma ograniczony sufit. Sprawdź go, zanim zaczniesz przepisywać szablony.
Zmiana platformy jest uzasadniona tylko wtedy, gdy sama platforma jest barierą: poprawiłeś obrazy, skrypty i przesunięcia, a TTFB lub waga motywu nadal zawodzą. Migracja kosztuje realne pieniądze i grozi utratą adresów URL, treści i pozycji, więc najpierw wypróbuj tańsze rozwiązania.
Realistyczna kolejność napraw i jak sprawdzić, czy zadziałały
Zacznij od metryki, która zawodzi w danych terenowych. Najpierw napraw szablony stron o największym ruchu (strona główna, usługa, wpis na blogu), zmieniaj jedną rzecz naraz i mierz ponownie. Dane terenowe się opóźniają z powodu 28-dniowego okna, więc spodziewaj się tygodni, zanim Search Console odzwierciedli poprawę. W międzyczasie używaj testów laboratoryjnych jako wskazówki kierunkowej.
Cichym problemem są regresje. Każdy proces publikowania treści, także zautomatyzowany, jak Post Pilot, może wprowadzić zbyt duże obrazy lub ciężkie osadzenia, jeśli nikt nie ustawi zabezpieczeń. Ogranicz wymiary wgrywanych plików, kompresuj przy wgrywaniu i wymagaj podania rozmiarów obrazów przed publikacją.
Co zrobić w tym tygodniu
- Otwórz raport Core Web Vitals w Search Console i zanotuj, która metryka zawodzi, najpierw na urządzeniach mobilnych.
- Skompresuj i zmniejsz obraz hero, usuń z niego lazy loading i zastąp wszelkie slidery.
- Wypisz wszystkie skrypty firm trzecich i usuń lub opóźnij te, których nie możesz powiązać z pozyskiwaniem zapytań.
- Dodaj width i height do obrazów i osadzeń, a następnie sprawdź Layout Shift Regions w DevTools.
- Ustaw zabezpieczenie przy wgrywaniu plików, żeby nowe wpisy nie wprowadzały z powrotem ciężkich obrazów.
Najczęściej zadawane pytania
Czy Core Web Vitals naprawdę wpływają na moje pozycje w Google?
Nieznacznie. Google opisuje je jako część szerszego sygnału doświadczenia użytkownika na stronie, a nie dominujący czynnik. Traktuj je jako sposób na zatrzymanie odwiedzających, a nie dźwignię rankingową.
Jaki wynik LCP, INP i CLS jest dobry?
LCP do 2,5 sekundy, INP do 200 milisekund i CLS do 0,1, mierzone na 75. percentylu rzeczywistych wizyt, zgodnie z dokumentacją Google.
Dlaczego moja strona przechodzi w PageSpeed Insights, ale nie przechodzi w Search Console?
Wynik laboratoryjny to jeden symulowany test. Search Console odzwierciedla prawdziwych użytkowników z okresu 28 dni, w tym wolniejsze urządzenia i sieci.
Po jakim czasie widać poprawę?
Zazwyczaj po kilku tygodniach, ponieważ okno danych terenowych jest ruchome. Testy laboratoryjne pokazują zmiany od razu.
Czy zmiana kreatora stron lub platformy CMS naprawi moje Core Web Vitals?
Rzadko samo w sobie. Większość problemów wynika z obrazów, skryptów i układu strony, które przechodzą na nową platformę razem z Tobą. Zmieniaj platformę tylko wtedy, gdy to sama platforma, na przykład czas odpowiedzi serwera lub waga motywu, jest udowodnionym ograniczeniem.
Źródła
Zdjęcie: Christina Morillo / Pexels