100/100 Core Web Vitals, case study

Wszyscy mówią, że optymalizują pod kątem szybkości. Niewielu potrafi to udowodnić. W tym tygodniu zakończyliśmy przebudowę wydajnościową dla klienta w konkurencyjnej branży e-commerce „Wyposażenie Domu”.

Punkt Startowy:

• Wynik Mobilny: 42/100
• LCP: 4.8s
• INP: 450ms (Słabo)
• CLS: 0.25 (Przesunięcia układu wszędzie)

Wynik (Po 4 Tygodniach):

• Wynik Mobilny: 100/100
• LCP: 1.2s
• INP: 48ms
• CLS: 0.00

To nie była magia. To była inżynieria. Oto dokładnie, jak to zrobiliśmy.

#1. Naprawa LCP (największe wyrenderowanie treści)

Złoczyńca: Slider Hero. Klient używał ciężkiego Revolution Slider. Ładował 4MB JavaScriptu zanim pokazał pierwszy obrazek.

Naprawa:

1. Usunięcie Slidera: Zastąpiliśmy slider statycznym układem CSS Grid.
2. Priorytet Pobierania: Dodaliśmy <img fetchpriority="high"> do głównego obrazka hero. To mówi przeglądarce „Pobierz to PRZED logo i menu”.
3. Format AVIF: Przekonwertowaliśmy wszystkie PNG do AVIF. Obrazek nagłówka 800KB stał się 45KB.

Rezultat: LCP spadło z 4.8s do 1.9s natychmiast.

#2. Rozwiązanie CLS (zbiorcze przesunięcie UKładu)

Złoczyńca: Niestandardowe Czcionki i Lazy Loading.

1. Czcionki: Tekst się pojawiał, potem ładowała się czcionka, przesuwając układ o 10 pikseli.
2. Obrazy: Obrazy ładowane leniwie pojawiały się i spychały tekst w dół, ponieważ brakowało im atrybutów width i height.

Naprawa:

1. Preload Czcionek: Dodaliśmy <link rel="preload"> dla głównej czcionki i użyliśmy font-display: optional. Jeśli czcionka nie załaduje się w 100ms, przeglądarka zostaje przy czcionce systemówej na zawsze (brak przeskoku).
2. Aspect Ratio: Wymusiliśmy aspect-ratio: 16/9; na wszystkich kontenerach obrazów w CSS. Przeglądarka rezerwuje białą przestrzeń zanim obraz się pobierze.

Rezultat: CLS spadło do 0.00.

#3. Miażdżenie INP (interakcja do następnego wyrenderowania)

Złoczyńca: Skrypty Zewnętrzne. Widgety czatu, Pixel Facebooka, Google Tag Manager, Hotjar. Wszystkie walczyły o główny wątek. Gdy użytkownik klikał „Menu”, przeglądarka była zbyt zajęta śledzeniem użytkownika, by otworzyć menu.

Naprawa: Partytown. Przenieśliśmy wszystkie oddzielne skrypty zewnętrzne do Web Workera używając Partytown. To uruchamia ciężki kod śledzący w wątku tła. Główny wątek (UI) pozostaje idealnie płynny.

Rezultat: INP spadło z 450ms do 48ms.

#4. Tajna broń 2026: Speculation rules API

Nie chcieliśmy tylko, żeby było szybko. Chcieliśmy, żeby czuło się, że jest natychmiastowe. Zaimplementowaliśmy Speculation Rules API.

Gdy użytkownik najeżdża kursorem na kartę produktu, przeglądarka:

1. Prefetchuje HTML następnej strony.
2. Prerenderuje go w ukrytej karcie w tle.

Gdy klikają, ładowanie strony wynosi dosłownie 0ms. Ona już tam jest.

#5. Optymalizacja po stronie serwera (infrastruktura)

Nie osiągniesz wyniku 100 na serwerze za 20 zł. Zmigrowaliśmy klienta na architekturę klasy WordPress VIP (lub spójny high-end).

1. Redis Object Cache: Zapytania do bazy danych dla „Menu” i „Opcji” są cache’owane w pamięci RAM.
2. Edge Caching (Cloudflare Enterprise): HTML strony głównej jest serwowany z serwera w Warszawie, a nie że źródła w Nowym Jorku. TTFB spadło z 600ms do 40ms.

#6. Wpływ biznesowy

Dlaczego zrobiliśmy to wszystko? Nie dla poudawanych metryk.

• Współczynnik Odrzuceń: Spadł o 18%.
• Wydatki na Reklamy: CPC spadło o 12% (Wynik Jakości Google Ads poprawił się dzięki szybkości).
• Przychód: Ruch organiczny wzrósł o 40% w 2 miesiące, ponieważ Google nagrodziło sygnały „Page Experience”.

Wniosek: Szybkość to nie dług techniczny. To dźwignia przychodów.

Czy Twój sklep WooCommerce traci pieńiądze przez powolność? WPPoland optymalizuje pod zielone wyniki i zielone konta bankowe.

Explore os nossos otimização de velocidade WordPress para levar o seu projeto mais longe.