Jak osiągnąć Lighthouse 99/100 na WordPress

Wynik Lighthouse 99/100 na WordPress jest realny dla biznesowej strony z analityką, fontami i obsługą formularzy. Pełna setka wymaga kompromisów, których większość klientów Hanse Studio nie zaakceptuje: zero third-party, zero web fontów, zero pixela reklamowego. W tym instrukcja wdrożeniowau pokazujemy dokładną listę kroków, którą stosujemy u nas w studio i u kilku innych klientów utrzymujących wynik 99/100 mobile od miesięcy.

Założenia: WordPress 6.4+, Astra Pro jako theme parent, własny motyw potomny, LiteSpeed Cache 7.8+ i Cloudflare jako CDN. Cały zestaw technologii utrzymujemy zgodnie z naszą filozofią no page builders, opisaną w kontekście usług. Dla klientów którzy mają już Elementor lub Divi, równoległym tematem jest migracja z Elementor na Gutenberg, ponieważ bloatowane buildery rzadko pozwalają zejść poniżej 85/100.

Jak osiągnąć Lighthouse 99/100 na WordPress: pełen instrukcja wdrożeniowa

Lighthouse 99/100 to wynik mierzony w trybie mobile, na slow 4G, z włączonym CPU throttling. Każdy punkt poniżej 99 oznacza realny problem, który Google widzi również jako sygnał rankingowy. Nasze podejście idzie od fundamentów (theme, hosting) przez assety (CSS, JS, obrazy) po caching i monitoring po wdrożeniu. Każdy krok ma mierzalny efekt i mierzalny koszt.

Dlaczego 99/100 zamiast 100/100

Pełna setka wymaga rezygnacji z trzech rzeczy, które dla biznesu są nienegocjowalne. Pierwsza to zewnętrzne skrypty analityki: GA4, Meta Pixel, Hotjar. Każdy z nich kosztuje 1 do 3 punktów w Best Practices i Performance, ale bez nich nie wiadomo, co robią użytkownicy. Druga to fonty webowe: nawet self-hosted Manrope czy Fraunces zwiększają Time to First Byte i Largest Contentful Paint o kilkadziesiąt milisekund. Trzecia to widgety third-party: chat, mapa Google, embed YouTube. Każdy z nich jest osobnym domain lookup i osobnym JS bundle.

Nasz benchmark wewnętrzny utrzymuje 99/100 z GA4, Polylangiem 5 języków, dwoma webfontami (Manrope, Fraunces) i Brevo SMTP do formularzy. To realna konfiguracja produkcyjna. 100/100 dla porównania osiągamy tylko na statycznych one-pagerach bez analityki, czyli mniej niż 5 procent naszego portfolio.

Praktyczna reguła: 99/100 to maksimum w warunkach biznesowych, 100/100 to projekt portfolio bez instrumentacji. Klientom z Niemiec, Austrii i Szwajcarii market i decyzją 3000-15000 EUR rocznie polecamy cel 99/100 z pełnym trackingiem, bo bez danych nie da się optymalizować konwersji.

Theme i motyw potomny: fundament wyniku

Wybór theme decyduje o 30 do 50 punktach Lighthouse, zanim dotkniemy jakiegokolwiek pluginu. Astra Pro ma footprint 5 KB CSS po minifikacji, GeneratePress podobnie, Kadence około 8 KB. Dla porównania Divi ładuje 80 KB CSS i 60 KB JS w bazowym konfiguracji, Avada 120 KB CSS, Elementor sam plugin to dodatkowe 200 KB plus 50 KB dla każdego widgetu Pro. Mnożąc to przez średni layout strony, łatwo dochodzi się do 400-500 KB nadmiarowych assetów.

Decyzja w Hanse Studio: Astra Pro plus własny motyw potomny dla każdego klienta. Motyw potomny zawiera tylko to, czego Astra nie ma natywnie: własny bloki Gutenberg, brand colors w theme.json, ewentualne wzorce sekcji jako block patterns. Cały własny kod CSS ma maksimum 15 KB po minifikacji, JavaScript pisany w vanilla (zero jQuery) i ładowany z opóźnieniem.

• Astra Pro 5 KB base CSS, 0 KB base JS (ładowane warunkowo)
• Motyw potomny: własny CSS max 15 KB minified, własny JS max 8 KB minified
• theme.json dla design tokens (paleta kolorów, skala spacing, typografia)
• Block patterns zamiast Elementor templates
• Critical CSS inline w head dla above-the-fold (typowo 4-8 KB)

Inline critical CSS generujemy w build step, zapisujemy do pliku w motyw potomny i wstrzykujemy w sekcji head. Pozostałe arkusze ładujemy z opóźnieniem, używając standardowych technik defer CSS. Ten wzorzec daje 200-300 ms oszczędności w LCP na typowym urządzeniu mobilnym.

Optymalizacja obrazów: lista kontrolna

Obrazy to zwykle 60 do 80 procent wagi strony i bezpośrednio wpływają na LCP, czyli najtrudniejszy do utrzymania Core Web Vital. Reguła brzegowa: każdy obraz na stronie powinien być w formacie WebP lub AVIF, mieć ustawione atrybuty width i height, mieć adekwatny srcset i być załadowany lazy, chyba że jest above-the-fold.

• Format: WebP jako domyślny standard, AVIF dla high-traffic strona (Cloudflare Polish lub LSCache image WebP robi to automatycznie)
• Responsive: srcset z 3-4 wariantami szerokości (400w, 800w, 1280w, 1920w), atrybut sizes precyzyjny
• Width i height: zawsze obecne, eliminuje Cumulative Layout Shift
• Loading: loading="lazy" below-fold, loading="eager" plus fetchpriority="high" dla hero LCP image
• Waga: po kompresji każdy obraz pod 200 KB, hero pod 150 KB
• Obrazy dekoracyjne: jako CSS background lub SVG inline (omijają HTML parser priority queue)

Konkretny przykład z naszego studia: hero image strony głównej to render zapisany jako WebP 1920×1080, waga 145 KB, srcset z trzema wariantami. LSCache 7.8 automatycznie generuje WebP dla wszystkich uploadowanych PNG/JPG, plus Cloudflare Polish jako drugi layer optymalizacji. Czas LCP na mobile (slow 4G): 1.8 sekundy, dobrze poniżej progu 2.5 sekundy.

Najczęstszy błąd: klient wgrywa PNG 8 MB jako hero, plugin auto-resize ratuje sytuację, ale po przejściu przez WP scaling pipeline obraz nadal waży 2 MB i blokuje LCP. Procedura: ZAWSZE kompresuj source plik (Squoosh.app, ImageOptim) przed wgraniem do WP, nawet jeśli LSCache i tak konwertuje. Source plik trafia do backupów, oszczędność disk space liczy się długoterminowo (nasza praktyka: 155 KB WebP zamiast 12 MB PNG dla hero featured images).

JavaScript: minimalizuj, opóźniaj, dziel

JavaScript to drugi co do wagi resource po obrazach i kosztuje punkty w Performance, TBT (Total Blocking Time) i INP (Interaction to Next Paint). Każdy KB JS to potencjalnie kilka milisekund parse time na słabszych telefonach. Cel: pod 50 KB minified JS bez third-party, pod 150 KB total łącznie z GA4 i ewentualnym chat widgetem.

• Opóźniaj wszystkie non-critical skrypty atrybutem defer, nie async (async może zmienić kolejność)
• Ładuj on-demand widgety tylko po interakcji (np. mapa Google ładowana po kliknięciu, nie podczas wczytywania strony)
• Audytuj jQuery: jeśli theme nie używa, wyrejestruj go w functions.php motyw potomny
• Audytuj third-party: każdy plugin który ładuje swój JS na każdej stronie to red flag (Contact Form 7 ładuje swój JS globalnie, FluentForm tylko gdy formularz na stronie)
• Self-host fontów: subset latin + latin-ext oddzielnie (pojedynczy plik .woff2 z Google Fonts jest zawsze latin-only, polskie diakrytyki padają na fallback)
• Font-display swap dla wszystkich własny fontów, eliminuje FOIT (Flash of Invisible Text)

Pułapka self-hosted fontów: pliki .woff2 pobrane bezpośrednio z fontsource v5 lub Google Fonts są subsetowane do latin only. Polskie ł, ż, ć i czeskie ě, ř spadną na fallback systemowy (Cambria, Consolas), powodując widoczny mismatch za glyph. Rozwiązanie: serwuj dwa pliki za font (NAME-latin.woff2 i NAME-latin-ext.woff2) z poprawnym unicode-range w arkuszu CSS. Spotkaliśmy ten błąd 2 razy w maju 2026 na własnym strona.

Pluginy do audytu w pierwszej kolejności: Asset CleanUp Pro pozwala selektywnie wyłączyć pluginowe CSS/JS na stronach, gdzie nie są potrzebne. Realny przykład: Contact Form 7 ładujący się na 100 stronach gdy formularz jest tylko na 2 to typowy zysk 30 KB JS plus 40 KB CSS na 98 stronach.

CSS: critical inline plus opóźniona reszta

CSS musi być zminifikowany, połączony i podzielony na critical (above-the-fold inline w head) plus resztę (ładowaną z opóźnieniem). Cel: pod 14 KB inline critical (mieści się w pierwszym TCP packet), reszta ładowana z opóźnieniem z fallbackiem dla użytkowników z JS off.

• Inline critical CSS w sekcji head, maksimum 14 KB (limit single TCP packet z TLS overhead)
• Reszta CSS jako external file z techniką opóźnionego ładowania (preload jako style, podmiana na stylesheet po onload)
• Fallback noscript dla użytkowników bez JS (rzadkość, ale dobra praktyka a11y)
• PurgeCSS lub Asset CleanUp dla usuwania nieużywanych selektorów (typowo 60-70% CSS pluginu jest nieużywane)
• Brak @import w CSS, blokuje render
• Font-display swap w każdej deklaracji @font-face

LiteSpeed Cache 7.8 ma wbudowaną opcję Generate Critical CSS która działa za page type. Włącz dla home, single post, single page, archive, produkt (jeśli WooCommerce). Wygeneruje critical CSS dla każdego typu osobno, zapisze do uploads/litespeed/ccss/ i będzie serwował automatycznie. Czas generowania: 30-60 sekund za page type, raz po wdrożeniu.

Caching: LiteSpeed plus Cloudflare combo

Caching to pojedynczy największy lewar dla Lighthouse wynik po wyeliminowaniu bloatu w theme i pluginach. LiteSpeed Cache 7.8 zapewnia page pamięć podręczna na poziomie webserwera (bez wykonania PHP), object pamięć podręczna via Redis (DB queries skip), CSS/JS minify plus combine, image WebP auto-convert. Cloudflare dodaje edge pamięć podręczna HTML, static asset pamięć podręczna, Cache Reserve dla mitygacji cold start. Razem dają 100 ms TTFB i 0.5-0.8 sekundy LCP dla cache’owany requests.

• LSCache page pamięć podręczna: włączony dla anonymous users, bypass dla logged-in i wp-admin
• LSCache object pamięć podręczna: Redis backend, expire 60 minut dla post objects, 5 minut dla menu queries
• LSCache CSS minify plus combine plus inline critical: włączone
• LSCache image WebP auto-convert: włączone, jakość 80
• Cloudflare CDN: domena proxowana (pomarańczowa chmurka), SSL Full Strict z Origin Cert
• Cloudflare Cache Rules: pamięć podręczna HTML edge 5 min dla anonymous, bypass dla wp-admin i wp-login
• Cloudflare Cache Reserve: włączony (mitygacja dla cold edge pamięć podręczna po purge)

Kolejność purge ma znaczenie. Po edycji posta w WP: LSCache purge (post_id specific), potem Cloudflare purge (URL specific). Plugin LiteSpeed ma Cloudflare integration tab gdzie wklejasz API token i Zone ID, purge robi się automatycznie. Bez tego edge pamięć podręczna Cloudflare pokazuje stary content jeszcze przez 5-60 minut po publikacji. Więcej technicznych detali w naszym osobnym tekście o konfiguracja Cloudflare plus WordPress.

Hosting i baseline serwera

Bez przyzwoitego hostingu wszystkie powyższe optymalizacje są bez sensu. Cel TTFB pod 200 ms, response time API pod 100 ms dla cache’owany requests. Wymagania techniczne: PHP 8.2 lub wyższy z OPpamięć podręczna włączonym, MySQL 8 lub MariaDB 10.6 plus z query pamięć podręczna tuned, Redis server dla object pamięć podręczna, LiteSpeed Web Server lub OpenLiteSpeed (Apache plus nginx też OK, ale LSCache plugin wymaga LSWS dla page pamięć podręczna na poziomie servera).

• VPS: Hetzner CPX32 (4 vCPU, 8 GB RAM, 80 GB NVMe SSD) za 14 EUR/mc: nasz domyślny standard dla wszystkich własnych projektów
• Managed: SiteGround GoGeek (€20/mc) lub Kinsta Starter (€35/mc) dla klientów którzy nie chcą zarządzać serwerem
• PHP 8.2 plus z OPpamięć podręczna 128 MB minimum
• MySQL/MariaDB z innodb_buffer_pool_size 2 GB plus dla średniej wielkości strona
• Redis server lokalnie (nie shared, każdy WP instance własny redis_db_id)
• HTTP/2 lub HTTP/3 obowiązkowo (multiplexing connections)

Shared hosting (OVH ekonomiczny, home.pl base) nie pozwala uniknąć 300-500 ms TTFB i tracimy 5-10 punktów Performance vs VPS. Dla każdego klienta z budżetem powyżej 800 PLN/miesiąc stała opieka rekomendujemy migrację z shared na CPX32 plus self-managed lub SiteGround. Zysk Lighthouse: typowo 5-12 punktów Performance i zauważalna poprawa LCP (1.5 sek na shared → 0.8 sek na VPS).

Audit po wdrożeniu: Lighthouse plus WebPageTest

Lighthouse w devtools to pierwszy gate, ale daje wynik na konkretnej maszynie deweloperskiej. Realny benchmark to PageSpeed Insights z laboratoryjnym Lighthouse plus Chrome UX Report (CrUX) z 28-dniowymi danymi z rzeczywistych użytkowników. CrUX pokazuje LCP, INP i CLS które realnie odczuwają użytkownicy, nie tylko symulację.

• Lighthouse mobile slow 4G plus desktop: cel 99/100 dla obu
• PageSpeed Insights field data (CrUX): LCP pod 2.5 s, INP pod 200 ms, CLS pod 0.1 (75 percentyl)
• WebPageTest 4G plus cable: TTFB pod 200 ms, Speed Index pod 3 s
• Monitor INP i CLS w real user data via Sentry Performance lub Vercel Analytics
• Regression test po każdym update: dedicated CI step lub manualny check po major plugin update

Dla klientów w stała opiekaze 800 PLN/miesiąc robimy weekly auto-check Lighthouse via WP-CLI plus uptimerobot, alert na Telegram jeśli wynik spadnie poniżej 95. Dla klientów premium robimy też manual review co miesiąc plus rotacyjnie sprawdzamy 5 najczęściej odwiedzanych URL-i. Pełen zakres naszego stała opieka pokazuje co dokładnie monitorujemy.

Bezpieczeństwo nie może czekać po wynik

Performance i security to dwie strony tej samej infrastruktury. Site z 99/100 Lighthouse ale dziurawym pluginem to liability, nie asset. Po stabilizacji wyniku Lighthouse, kolejny krok to WordPress security utwardzanie zabezpieczeń: 10 obowiązkowych kroków, gdzie pokazujemy minimum bezpieczeństwa dla każdego klienta B2B. Bez tego rebuild za 12000 PLN może paść w 6 miesięcy po wdrożeniu przez plugin CVE.

Dla pełnego obrazu architektury polecamy też dokumentację techniczną: web.dev Learn Performance jako podstawa Core Web Vitals i LiteSpeed Cache documentation dla pluginowych konfiguracji.

FAQ

Czy 99/100 utrzyma się po każdym update WordPress lub pluginu?

Tak, pod warunkiem że plugin/theme zestaw technologii jest stabilny i robimy regression test po major update. Astra Pro, LiteSpeed Cache, Polylang utrzymują wynik release-over-release. Ryzyko pojawia się przy major plugin updates (np. WooCommerce 8.x → 9.x), wtedy warto sprawdzić Lighthouse w staging przed pushem na prod.

Czy sklep WooCommerce z dużym katalogiem może osiągnąć 99/100?

Tak, ale wymaga osobnej pracy nad WooCommerce specific blockerami. Dla jednego klienta sklepie internetowym Niemiec, Austrii i Szwajcarii utrzymujemy 92/100 z 30k SKU, optymalizacja query pamięć podręczna na archive pages plus własnyowy lazy load dla produkt gallery. Single karcie produktu osiąga 96/100, archive 92/100. Dla typowego B2B sklepu poniżej 5k SKU 99/100 jest realne.

GTmetrix vs Lighthouse: który jest ważniejszy?

Lighthouse, ponieważ jego dane są używane przez Google jako ranking factor (Core Web Vitals z CrUX data). GTmetrix daje przydatny secondary view (waterfall, server response details), ale dla decyzji SEO liczy się Lighthouse plus PageSpeed Insights field data. GTmetrix free plan testuje z Vancouver, co zniekształca wyniki dla polskiego ruchu.

Co z TTFB powyżej 200 ms: jak optymalizować?

TTFB powyżej 200 ms zwykle wskazuje na shared hosting, brak OPpamięć podręczna, brak object pamięć podręczna (Redis), lub wolne pluginy admin-side blokujące request. Procedura: sprawdź New Relic lub Query Monitor który plugin blokuje, włącz OPpamięć podręczna plus Redis, rozważ migrację na VPS. Cloudflare Cache Reserve pomaga maskować wolne origin, ale to plaster a nie fix.

Kolejne kroki dla twojego strona

Jeśli twój strona WordPress ma obecnie wynik poniżej 90 i chcesz wiedzieć dokładnie co blokuje 99/100, Hanse Studio robi techniczny audyt Lighthouse plus performance roadmap w cenie od 1500 PLN. Audyt obejmuje analizę theme i pluginów, identyfikację top 5 wąskich gardeł, priorytyzowaną listę 10-15 quick winów (typowo zwracają 10-25 punktów Lighthouse) oraz zakres dla większego rebuildu jeśli quick winy nie wystarczą. Skontaktuj się w sprawie wyceny, odpowiadamy w 24 godziny w dni robocze.