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:
- Usunięcie Slidera: Zastąpiliśmy slider statycznym układem CSS Grid.
- Priorytet Pobierania: Dodaliśmy
<img fetchpriority="high">do głównego obrazka hero. To mówi przeglądarce „Pobierz to PRZED logo i menu”. - 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.
- Czcionki: Tekst się pojawiał, potem ładowała się czcionka, przesuwając układ o 10 pikseli.
- Obrazy: Obrazy ładowane leniwie pojawiały się i spychały tekst w dół, ponieważ brakowało im atrybutów
widthiheight.
Naprawa:
- Preload Czcionek: Dodaliśmy
<link rel="preload">dla głównej czcionki i użyliśmyfont-display: optional. Jeśli czcionka nie załaduje się w 100ms, przeglądarka zostaje przy czcionce systemowej na zawsze (brak przeskoku). - 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:
- Prefetchuje HTML następnej strony.
- 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).
- Redis Object Cache: Zapytania do bazy danych dla „Menu” i „Opcji” są cache’owane w pamięci RAM.
- Edge Caching (Cloudflare Enterprise): HTML strony głównej jest serwowany z serwera w Warszawie, a nie ze ź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 pieniądze przez powolność? WPPoland optymalizuje pod zielone wyniki i zielone konta bankowe.
