Google Search Console wysłał alarm

Klient – agencja rekrutacyjna z Warszawy – nie rozumiał, dlaczego traci pozycje, choć regularnie publikował nowy content. Raport Core Web Vitals w GSC: 87% URL w kategorii „Słabe”. Wynik Mobile PageSpeed: 12/100. LCP na stronie głównej: 9,2 sekundy.

Motyw: Divi z 14 aktywnymi wtyczkami – Slider Revolution, WPBakery, kilka formularzy, 3 niezależne galerie. Historia znajoma.

Diagnoza: cztery źródła czerwonych wskaźników

1. Render-blocking JavaScript – 4,2s blokady

Chrome DevTools Coverage wykazał: 73% JavaScriptu ładowanego na stronie głównej jest nieużywane. Slider Revolution ładował swój pełny bundle (480 KB) nawet na stronach bez slidera. WPBakery dokładał kolejne 320 KB nieużywanego JS.

2. Brak WebP – obrazy 8× za ciężkie

Strona główna ładowała 11 obrazów JPEG, łącznie 9,4 MB. Największy: banner 1920×1080 px, 3,1 MB. Serwer nie obsługiwał nagłówka Accept: image/webp.

3. Google Fonts ładowane synchronicznie

Divi ładował 4 warianty czcionki Roboto z zewnętrznego serwera. Każde żądanie DNS + TCP handshake dodawało 180–220ms. Na wolniejszych łączach mobilnych: 600ms.

4. Brak lazy loading i złe priorytety obrazów

Wszystkie 11 obrazów ładowało się z tym samym priorytetem. Obraz LCP nie miał fetchpriority="high", 8 obrazów poniżej fold nie miało loading="lazy".

Akcja HelpGuru – 48 godzin pracy

Dzień 1: JavaScript i CSS (0–16h)

• WPBakery i Slider Revolution zastąpione natywnymi blokami Gutenberga i Swiper.js (28 KB vs 800 KB)
• Divi: włączony tryb Performance Mode + statyczne arkusze CSS
• Wszystkie skrypty zewnętrzne: defer lub async
• Krytyczny CSS inline w <head> – eliminacja blokującego renderowanie żądania

Dzień 1: Google Fonts lokalnie (16–20h)

Pobraliśmy warianty Roboto i wgraliśmy na serwer. Wyrejestrowano ładowanie Google Fonts, zastąpiono lokalną wersją z font-display: swap. Oszczędność: eliminacja 2 zewnętrznych żądań DNS na każdym wejściu.

Dzień 2: Obrazy i WebP (20–36h)

• Włączona obsługa WebP w Nginx przez nagłówek Vary: Accept
• Imagify: masowa konwersja 847 zdjęć do WebP (średnia kompresja: 72%)
• Banner LCP: JPEG 3,1 MB → WebP 210 KB + fetchpriority="high"
• Obrazy poniżej fold: loading="lazy" + decoding="async"
• Tag <picture> z WebP jako źródłem głównym, JPEG jako fallback

Dzień 2: WP Rocket (36–48h)

Konfiguracja WP Rocket: minifikacja HTML/CSS/JS, cache pre-loading co 12h, CDN dla zasobów statycznych, GZIP/Brotli compression.

Wyniki po 48 godzinach

• ✅ Mobile PageSpeed: 12 → 92/100
• ✅ LCP: 9,2s → 1,4s
• ✅ FCP: 4,1s → 0,9s
• ✅ CLS: 0,38 → 0,02
• ✅ INP: 580ms → 95ms

Po 14 dniach: +3 pozycje na kluczową frazę, ruch organiczny wzrósł o 28%. GSC przestał wysyłać alerty o złych CWV.

Lekcja: motyw to nie wszystko

Divi i Elementor mają cenę w postaci ciężkiego kodu. Problemy zaczynają się, gdy do ciężkiego motywu dodajesz ciężkie wtyczki i nikt nie pilnuje wynikowego kodu. Dobra zasada: PageSpeed poniżej 50 – sprawdź wtyczki. Poniżej 30 – zadzwoń do nas.