Poprawa Core Web Vitals: kolejność, która naprawdę pomaga

Włączenie wtyczki do cache to pierwszy krok i często jedyny, jaki się wykonuje. Potem wynik stoi na „wymaga poprawy” i tam pozostaje. Powód: trzy wskaźniki mierzą trzy różne rzeczy, a cache naprawdę pomaga tylko przy jednym z nich.

Trzy wartości, każda w jednym zdaniu

Stąd wynika kolejność: najpierw obrazy, potem skrypty, potem układ. Cache działa przede wszystkim na czas odpowiedzi serwera — czyli na część LCP, a na INP prawie wcale.

Krok 1: największy obraz

Na większości stron kandydatem LCP jest obraz hero. Od razu pomagają trzy rzeczy, w tej kolejności:

1. Zmniejsz obraz do faktycznie potrzebnego rozmiaru — zdjęcie o szerokości 4000 pikseli w obszarze szerokim na 1200 pikseli to najczęstsza pojedyncza przyczyna.
2. Przekonwertuj go do nowoczesnego formatu (WebP lub AVIF), z wersją zapasową dla starych przeglądarek.
3. NIE ładuj go leniwie. Obraz na samej górze ma się ładować od razu — Lazy-Load pogarsza tu wynik, zamiast go poprawiać.

Sprawdź, gdzie odbywa się konwersja. Niektóre wtyczki wysyłają w tym celu twoje obrazy do usługi producenta. Kto tego nie chce, potrzebuje narzędzia, które konwertuje lokalnie — wtedy pierwszy przebieg trwa dłużej, ale nic nie wychodzi na zewnątrz.

Krok 2: JavaScript

INP to wartość, przy której cache nie pomaga. Mierzy, ile czasu przeglądarka potrzebuje, by zareagować na kliknięcie — a blokują ją skrypty, które pracują dokładnie w tym momencie.

Najskuteczniejszą dźwignią jest rezygnacja: slider, którego nikt nie obsługuje; okno czatu na każdej stronie; trzy rodziny czcionek, z których dwie nie rzucają się w oczy. Dopiero potem opłacają się defer, łączenie plików i opóźnianie do pierwszej interakcji.

Krok 3: koniec z przeskakiwaniem

• Każdy obraz potrzebuje width i height w kodzie — wtedy przeglądarka rezerwuje dla niego miejsce
• Osadzone treści umieszczaj w ramce o stałej wysokości
• Serwuj czcionki lokalnie i steruj nimi przez font-display, zamiast doładowywać je z zewnątrz
• Banery cookie i paski z komunikatami wbudowuj tak, by nakładały się na treść, zamiast ją przesuwać

Dopiero potem: cache, Minify, Preload

Cache stron oszczędza generowanie strony — to dużo, gdy serwer jest wolny, i mało, gdy jest szybki. Minify oszczędza bajty i jest najczęstszą przyczyną zepsutych stron po optymalizacji. Preload to polecenie, nie prośba: zbyt wiele takich poleceń wypiera właśnie to, co jest potrzebne najpierw.

Włączaj Minify pojedynczo i za każdym razem sprawdzaj stronę z formularzem, koszyk i stronę z filmem. Kto włącza wszystko naraz, w razie błędu szuka wśród dziesięciu przełączników.

Poprawny pomiar

Trzeba rozróżniać dwa rodzaje pomiarów. Test laboratoryjny mierzy w stałych warunkach i dobrze nadaje się do porównania stanu przed i po. Dane terenowe pochodzą od prawdziwych odwiedzających z prawdziwymi urządzeniami i połączeniami — to one decydują, jak Google ocenia stronę.

Dlatego: zawsze mierz w tych samych warunkach, trzy razy zamiast raz, a w danych terenowych zmiana pojawia się dopiero po tygodniach. Kto sprawdza po godzinie i nic nie zauważa, nie zoptymalizował za mało, tylko spojrzał za wcześnie.

Kiedy wtyczka już nie pomaga

Istnieje granica, za którą żadna wtyczka do cache już nic nie wskóra: przeładowany kreator stron z trzydziestoma skryptami, hosting z wysokim obciążeniem bazowym, motyw, który na każdej stronie ładuje wszystko. Jeśli odpowiedź serwera jest wolna już bez treści, to nie wina wtyczki.

Najczęściej zadawane pytania