Core Web Vitals to trzy pomiary, które pokazują, jak strona zachowuje się u użytkownika. Nie chodzi tylko o to, czy strona jest szybka w testach. Chodzi o to, czy człowiek widzi treść szybko, czy może od razu kliknąć i czy nic nie przesuwa się pod palcem.
W WordPressie łatwo zgubić przyczynę problemu. Czasem winny jest serwer, bo długo czekasz na odpowiedź. Czasem strona dostaje odpowiedź szybko, ale potem ładuje zbyt dużo plików i przeglądarka nie daje rady. Bywa też tak, że jedna wtyczka potrafi zepsuć wyniki bardziej niż cała reszta razem.
Najprościej jest podzielić temat na dwie części. Pierwsza to to, co dzieje się zanim przeglądarka dostanie stronę do wczytania (tu ważny jest hosting). Druga to to, co dzieje się w przeglądarce po pobraniu strony (tu rządzi motyw, wtyczki i treści).
Co mierzą Core Web Vitals i gdzie je sprawdzić
Core Web Vitals to trzy metryki: LCP, INP i CLS. LCP mówi, kiedy użytkownik widzi główną treść na ekranie. INP mówi, czy strona szybko reaguje na kliknięcia. CLS mówi, czy układ nie przeskakuje w trakcie ładowania.
Wyniki możesz sprawdzić na dwa sposoby. Pierwszy to dane od prawdziwych użytkowników w Google Search Console. Drugi to testy narzędziowe, np. PageSpeed Insights. Oba są przydatne, ale pokazują trochę inne rzeczy. Search Console mówi, jak strona działa u ludzi. PageSpeed pomaga znaleźć, co dokładnie spowalnia stronę.
Zacznij od Google Search Console → Podstawowe wskaźniki internetowe. Zobaczysz tam grupy adresów, które mają problem. To ważne, bo inaczej poprawiasz stronę główną, a problem siedzi w produktach albo w kategoriach.
Potem weź 2–3 adresy do testu w PageSpeed Insights: stronę główną, typowy wpis i stronę z największą liczbą elementów (np. kategoria produktów). Dzięki temu szybciej zobaczysz powtarzalny wzór, a nie tylko przypadek.
Na końcu otwórz Chrome DevTools. W zakładce Network zobaczysz, na co przeglądarka czeka. W zakładce Performance zobaczysz, co obciąża stronę po pobraniu plików.
Jak szybko odróżnić problem hostingu od problemu motywu i wtyczek
Najważniejsze pytanie brzmi: czy przeglądarka długo czeka na odpowiedź serwera, czy dostaje odpowiedź szybko, ale potem długo ładuje i przetwarza stronę.
Sprawdź to w prosty sposób. Otwórz stronę w trybie incognito. Włącz DevTools → Network. Odśwież stronę i kliknij pierwszy wpis typu Document (to HTML). Zwróć uwagę na TTFB. To pokazuje, ile czasu minęło, zanim serwer zaczął odsyłać dane.
Jeśli TTFB jest duży, masz problem po stronie serwera albo cache. Wtedy poprawki w motywie mogą pomóc, ale często efekt będzie ograniczony, bo strona i tak startuje późno.
Jeśli TTFB jest mały, a mimo to wyniki są słabe, winne są zwykle zasoby strony: obrazki, style, skrypty, fonty. Wtedy zmiana hostingu rzadko robi dużą różnicę, bo przeglądarka nadal musi przerobić ciężki front.
Ten podział jest kluczowy. Bez niego łatwo stracić czas na zmiany, które nie trafiają w przyczynę.
LCP w WordPressie: co spowalnia główną treść i jak to naprawić
LCP dotyczy największego elementu widocznego na starcie. W WordPressie najczęściej jest to duże zdjęcie w nagłówku, zdjęcie produktu albo duży blok treści na górze strony.
Najpierw sprawdź, co jest elementem LCP. W PageSpeed Insights masz wskazany element. Jeśli to obraz, sprawa jest dość konkretna: obraz może być za ciężki albo pobierany za późno.
Najczęstszy błąd to zbyt duży plik graficzny. Zdjęcie ma kilka megabajtów, choć na ekranie zajmuje tylko część szerokości. Drugi błąd to ustawienie opóźnionego ładowania dla obrazów, które są na samej górze strony. Taki obraz powinien ładować się od razu, bo to on buduje LCP.
Jeśli elementem LCP jest tekst, często problemem są style i fonty. Motyw i wtyczki mogą ładować kilka plików CSS, a część z nich blokuje rysowanie strony. Wtedy serwer może być szybki, a użytkownik i tak długo nie widzi sensownego układu.
Gdy podejrzewasz, że problem jest po stronie serwera, popatrz na TTFB i stabilność. Warto też przeczytać artykuł PHP 8.x, OPcache i HTTP/3 – które technologie hostingu faktycznie przyspieszają WWW?.
INP: dlaczego kliknięcie reaguje wolno i jak znaleźć przyczynę
INP pokazuje, czy strona reaguje szybko po kliknięciu. Użytkownik naciska przycisk i chce zobaczyć efekt od razu. Jeśli strona ma opóźnienie, wygląda na zawieszoną.
W WordPressie są dwa typowe powody. Pierwszy to ciężkie skrypty w przeglądarce. Drugi to wolne zapytania do serwera po kliknięciu (np. dodanie do koszyka, filtr, wyszukiwarka).
Żeby to rozróżnić, otwórz DevTools → Network i kliknij coś, co działa wolno. Jeśli pojawiają się wolne żądania typu XHR/fetch, problem jest po stronie backendu. Jeśli nie ma wolnych żądań, a strona mimo to reaguje źle, najczęściej winny jest JavaScript.
W sklepach i stronach z dużą liczbą zapytań bardzo pomaga cache po stronie WordPressa i cache obiektowy. Jeśli masz dużo dynamicznych elementów, zajrzyj do wpisu Redis/Object Cache w WordPress. To temat, który często poprawia nie tylko szybkość, ale też stabilność w godzinach szczytu.
W przypadku skryptów reguła jest prosta: im mniej skryptów na każdej podstronie, tym lepiej. Wiele wtyczek dodaje swoje pliki wszędzie, nawet jeśli potrzebujesz ich tylko na jednej stronie.
CLS: skaczący układ i proste sposoby na poprawę
CLS rośnie, gdy elementy przesuwają się podczas ładowania. To najczęściej nie jest problem hostingu. To problem układu strony.
Najczęstszy powód to brak zarezerwowanego miejsca dla obrazów. Jeśli obraz nie ma wymiarów, przeglądarka nie wie, ile miejsca zostawić. Najpierw pokazuje treść, a potem po pobraniu obrazu przesuwa wszystko w dół. Drugi powód to osadzone elementy, np. wideo albo mapy. One też powinny mieć stały kontener o znanym rozmiarze. Inaczej układ skacze. Trzeci powód to fonty i elementy doklejane po chwili: baner zgody, pasek promocyjny, wysuwany nagłówek. Jeśli taki element wypycha treść, CLS rośnie.
W praktyce poprawki są proste: pilnuj wymiarów obrazów, stosuj kontenery o stałych proporcjach i unikaj wypychania treści przez elementy, które pojawiają się później.
Hosting a wyniki CWV: TTFB, stabilność i limity zasobów
Hosting wpływa na CWV głównie przez czas odpowiedzi serwera i przez to, czy serwer trzyma tempo przy większym ruchu. Jeśli TTFB jest wysoki, LCP zwykle też będzie słaby.
Dużo problemów bierze się z tego, że strona działa raz szybko, raz wolno. To często oznacza, że wchodzisz w limity zasobów albo serwer ma za mało zapasu na skoki ruchu. Wtedy wyniki w CWV pogarszają się falami.
Warto zrozumieć, jak czytać ograniczenia na hostingu, bo to pomaga odróżnić problem w kodzie od problemu w zasobach (zobacz artykuł limity hostingu). Jeśli zaczynasz dobijać CPU lub I/O, strona wolniej generuje HTML, a użytkownik dłużej czeka na start.
Druga sprawa to konfiguracja PHP i cache na serwerze. Dobrze ustawiony cache potrafi obniżyć TTFB nawet wtedy, gdy strona ma dużo wtyczek. Bez cache WordPress często wykonuje te same operacje w kółko.
Cache, Redis i CDN: kiedy pomagają, a kiedy robią bałagan
Cache strony jest najprostszą drogą do niższego TTFB. Dla treści publicznych działa świetnie, bo nie musisz generować strony od nowa przy każdym wejściu.
Jednocześnie cache bywa omijany. Wystarczy, że jakaś wtyczka ustawi ciasteczko dla wszystkich użytkowników i nagle większość wejść przestaje korzystać z cache. Dlatego po wdrożeniu zawsze testuj w incognito i sprawdzaj, czy drugie wejście jest wyraźnie szybsze.
Redis nie przechowuje gotowej strony. Pomaga WordPressowi i bazie danych działać szybciej przy powtarzalnych operacjach. Najbardziej czuć go w sklepach, filtrach i wyszukiwarkach. Jeśli masz taki typ strony, Redis/Object Cache w WordPress jest tematem, który warto mieć poukładany.
CDN pomaga w dostarczaniu obrazów, stylów i skryptów. Najczęściej daje efekt wtedy, gdy masz ciężkie obrazki albo użytkowników w różnych miejscach. Trzeba go jednak wdrożyć z głową, bo inaczej pojawiają się problemy z wersjami plików po aktualizacji. Jeśli chcesz zrozumieć, kiedy CDN ma sens, zobacz wpis o CDN w hostingu.
Kiedy zmieniać hosting, a kiedy wystarczy odchudzić stronę
Jeśli TTFB jest wysoki i to on dominuje w ładowaniu, zaczynasz od hostingu, cache i zasobów. Jeśli po poprawkach TTFB nadal jest wysoki, a przy ruchu sytuacja się pogarsza, zmiana hostingu lub planu ma sens.
Jeśli TTFB jest niski, a wyniki nadal są słabe, najczęściej problem leży w motywie, wtyczkach i zasobach strony. W takim przypadku migracja rzadko daje duży efekt, bo przeglądarka wciąż musi przerobić ciężkie pliki.
W praktyce najbezpieczniejsza kolejność to: najpierw poprawić obraz LCP i zmniejszyć liczbę skryptów, potem ustabilizować układ (CLS), a dopiero na końcu podejmować decyzje o hostingu. Gdy już porównujesz oferty, przydatny będzie Ranking hostingów, aby łatwiej zestawić opcje pod konkretny typ strony.
FAQ – Najczęściej zadawane pytania
Nie. PageSpeed pokazuje test i podpowiedzi, a raport w Search Console opiera się na danych od użytkowników. Test pomaga znaleźć przyczynę, raport pokazuje, czy poprawa działa u ludzi. Dlatego dobrze jest korzystać z obu.
Najczęściej czas odpowiedzi serwera (TTFB). Jeśli serwer długo oddaje HTML, LCP zwykle jest słaby. Hosting wpływa też na interakcje, jeśli po kliknięciu strona robi zapytania do serwera i czeka na odpowiedź.
Najprościej przez DevTools w Chrome. Wejdź w Network, odśwież stronę i kliknij HTML. Tam zobaczysz Waiting (TTFB). Dobrze testować w incognito, żeby nie mieszała pamięć przeglądarki.
Nie zawsze. Pomaga głównie przy zasobach statycznych (obrazy, CSS, JS). Jeśli główny problem to wysoki TTFB, CDN bez sensownego cache HTML niewiele zmieni. Ważna jest też poprawna konfiguracja cache.
To zwykle trwa dłużej niż testy narzędziowe, bo raport zbiera dane od użytkowników. Dlatego po wdrożeniu zmian kontroluj też wyniki w testach i w DevTools, a Search Console traktuj jako potwierdzenie po czasie.
30-letnia pasjonatka informatyki, która świat serwerów i hostingów zna od podszewki. Wierzy, że technologia powinna ułatwiać życie, a nie je komplikować. Żyje w ciągłym ruchu – jeśli akurat nie konfiguruje nowej usługi, prawdopodobnie pakuje plecak na kolejną wyprawę w nieznane.
Dodaj komentarz