Pierwszy raz, kiedy klient WooCommerce hostowany na cyber_Folks otworzył PageSpeed Insights i zobaczył LCP 4,0 s przy 200 KB hero w PNG, diagnoza zajęła trzydzieści sekund, a poprawka jedno popołudnie. Konwersja hero do AVIF (cyber_Folks już od kilku lat ma obsługę AVIF na LiteSpeed) plus fetchpriority="high" zbiły stronę do 1,4 s LCP. Po stronie CSS było trudniej: 800 KB arkusza z motywu page-buildera blokowało renderowanie na komórce, dopiero ekstrakcja critical CSS z 12 KB inline w head zbiła FCP poniżej sekundy. Te dwa wzorce powtarzają się prawie w każdym audycie polskiej strony WordPress.
Ten poradnik prowadzi przez pipeline, który realnie rusza Core Web Vitals na polskiej instalacji WordPress: wybór formatu między AVIF, WebP i JPEG XL przy obecnej rzeczywistości przeglądarek (Safari 16+ obsługuje AVIF, Chrome dekoduje JPEG XL tylko za flagą, Firefox zatrzymał JPEG XL w 2024); wybór wtyczki między ShortPixel (firma polska, MartinKrcho i zespół z Krakowa), Imagify, Smush i EWWW z limitami API i kwestiami DPA każdej z nich; reguła 14 KB above-the-fold wynikająca z TCP slow start, a nie z marketingowego slajdu; oraz ustawienia LiteSpeed Cache produkujące mierzalną zmianę LCP zamiast placebo.
Skąd realnie biorą się straty LCP i FCP
Otwórz panel Network na typowej polskiej stronie WordPress hostowanej w nazwa.pl, home.pl albo cyber_Folks i zobaczysz dwa winowajców budżetu LCP: hero o rozmiarze 1-2 MB w JPEG lub PNG oraz arkusz główny od 300 do 800 KB oznaczony jako blokujący renderowanie. Trzeci sprawca, fonty webowe ładowane bez font-display: swap, jest mniejszy bajtowo, ale blokuje paint do momentu pobrania.
Hero jest oczywistym celem, bo LCP z definicji to największy widoczny element nad linią zgięcia, a na większości polskich homepage’ów tym elementem jest JPEG. WebP tnie ten plik o około 25-35% przy równoważnej jakości, a AVIF tnie go ponownie, lądując zwykle 40-55% mniej niż oryginalny JPEG zależnie od treści. Wsparcie AVIF jest obecnie szerokie: Chrome od 85, Firefox od 93, Safari od 16. JPEG XL to głośny nieobecny: Chromium wycofał flagę dekodera, Firefox odłożył go bezterminowo, tylko Safari natywnie go obsługuje, więc dla polskiego ruchu (Chrome dominuje w Pagespeed Insights data referencyjnym dla rynku PL) nie jest to format produkcyjny w 2026.
Po stronie CSS liczy się reguła 14 KB. TCP slow start otwiera połączenie z około dziesięcioma pakietami, około 14 KB po nagłówkach, przed pierwszym ACK round-trip. Wkleić więcej niż tyle inline w <head> znaczy wydłużyć pierwszy paint o pełen RTT. To jest cały powód, dla którego ekstraktory critical CSS celują w pułap 14 KB, a nie w okrągłą liczbę z checklisty.
Wybór wtyczki do optymalizacji obrazów
Cztery wtyczki wykonują większość pracy w optymalizacji obrazów WordPress w 2026, a wybór między nimi rzadko sprowadza się tylko do jakości kompresji. Limity API, miejsce gdzie konwersja się odbywa i co opuszcza Twój serwer, mają taką samą wagę jak finalny rozmiar pliku.
ShortPixel Image Optimizer
ShortPixel jest wtyczką polską, rozwijaną w Krakowie, kompresuje przez API w chmurze i dostarcza WebP plus AVIF jako standard. Trzy tryby: lossy, glossy, lossless. Na stronach foto-heavy preset glossy zwykle ląduje w granicach kilku procent jakości lossless przy połowie bajtów. Pułapka na masowych przetwarzaniach to limit API: przepchnięcie 10 000+ obrazów w jeden dzień na małym planie wywołuje throttling, a bulk processor wycofuje się zamiast jawnie zawodzić, co sprawia, że zatrzymany bulk wygląda jak zepsuty bulk.
Kluczowe mocne strony:
- Generowanie AVIF w produkcji od 2023
- Masowe przetwarzanie z kolejką w tle
- Glossy preset jako praktyczny domyślny dla redakcyjnych i sklepów
- Cennik oparty na limicie, indywidualny
Imagify
Stworzona przez zespół odpowiedziąlny za WP Rocket, Imagify bezproblemowo integruje się z tą wtyczką cache. Oferuje trzy tryby kompresji (normalny, agresywny, ultra) i automatycznie generuje pliki WebP.
Kluczowe mocne strony:
- Głęboka integracja z WP Rocket dla połączonej optymalizacji
- Narzędzie porównania wizualnego do podglądu wyników kompresji
- Automatyczne zmniejszanie zbyt dużych przesyłanych plików
- Generowanie WebP jednym kliknięciem
- Cennik oparty na limicie (indywidualny, zależy od użycia)
Smush
Smush od WPMU DEV to najbardziej przyjazna dla początkujących opcja. Wersja darmowa obsługuje podstawową kompresję i lazy loading. Wersja Pro dodaje konwersję WebP, dostarczanie CDN i bardziej agresywną optymalizację.
Kluczowe mocne strony:
- Darmowy poziom z nieograniczoną liczbą obrazów (do 5 MB każdy)
- Wbudowany lazy loading
- CDN w zestawie z Pro
- Smush na poziomie katalogów dla obrazów spoza biblioteki mediów
- Cennik Pro zależy od planu
EWWW Image Optimizer
EWWW jest jedyną wtyczką z tej listy, która potrafi działać całkowicie na serwerze bez zewnętrznego API. Ma to znaczenie, jeśli umowa powierzenia przetwarzania danych zabrania wysyłania wgranych zdjęć poza UE, albo jeśli siedzisz za zaporą, która nie wypuszcza połączeń HTTPS do SaaS. Tryb lokalny używa jpegoptim, optipng, pngquant i cwebp wywoływanych z PHP, więc binarki muszą być na dysku; na hostingach współdzielonych w PL (zenbox, MyDevil, dhosting) to zwykle krótka rozmowa z supportem.
Kluczowe mocne strony:
- Tryb kompresji lokalnej bez round-tripa do chmury
- Konwersja WebP i AVIF
- Opcja CDN ExactDN do dostawy z negocjacją formatu
- Komendy WP-CLI dla bulków uruchamianych z crona
- Cennik zależy od trybu, lokalny darmowy, plany API indywidualne
Porównanie wtyczek w skrócie
| Funkcja | ShortPixel | Imagify | Smush | EWWW |
|---|---|---|---|---|
| Obsługa WebP | Tak | Tak | Tylko Pro | Tak |
| Obsługa AVIF | Tak | Nie | Nie | Tak |
| Kompresja lokalna | Nie | Nie | Nie | Tak |
| Przetwarzanie masowe | Tak | Tak | Tak | Tak |
| Integracja z WP Rocket | Podstawowa | Natywna | Nie | Podstawowa |
| Darmowy poziom | 100 obrazów/mies. | 20 MB/mies. | Bez limitu (ograniczone) | Tryb lokalny |
Dla większości profesjonalnych stron WordPress ShortPixel lub EWWW oferują najlepszą kombinację obsługi formatów, jakości kompresji i elastyczności.
Konfiguracja dostarczania WebP i AVIF
Instalacja wtyczki optymalizacyjnej to dopiero połowa pracy. Musisz również upewnić się, że przeglądarki faktycznie otrzymują nowoczesny format zamiast oryginalnego JPEG lub PNG.
Metoda 1: Przepisywanie elementu picture
Najbardziej niezawodne podejście wykorzystuje element HTML <picture> do oferowania wielu formatów z automatycznym przełączaniem:
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="Opis" width="800" height="600" loading="lazy">
</picture>Większość wtyczek optymalizacyjnych obsługuje to przepisywanie automatycznie. ShortPixel i EWWW wstawiają tagi <picture> po odpowiedniej konfiguracji.
Metoda 2: Negocjacja treści przez .htaccess
Jeśli Twój serwer działa na Apache lub LiteSpeed, możesz serwować pliki WebP transparentnie za pomocą negocjacji treści. Przeglądarka wysyła nagłówek Accept z listą obsługiwanych formatów, a serwer odpowiada najlepszym dostępnym plikiem:
<IfModule mod_rewrite.c>
RewriteEngine On
# Serwuj AVIF jeśli dostępny i obsługiwany
RewriteCond %{HTTP_ACCEPT} image/avif
RewriteCond %{REQUEST_FILENAME} (.+)\.(jpe?g|png|gif)$
RewriteCond %{REQUEST_FILENAME}.avif -f
RewriteRule (.+)\.(jpe?g|png|gif)$ $1.$2.avif [T=image/avif,E=REQUEST_image,L]
# Serwuj WebP jeśli dostępny i obsługiwany
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME} (.+)\.(jpe?g|png|gif)$
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule (.+)\.(jpe?g|png|gif)$ $1.$2.webp [T=image/webp,E=REQUEST_image,L]
</IfModule>
<IfModule mod_headers.c>
Header append Vary Accept env=REQUEST_image
</IfModule>To podejście jest niewidoczne dla Twojego HTML i działa z każdym motywem lub page builderem.
Metoda 3: Filtr WordPress dla programistycznej kontroli
Dla deweloperów, którzy chcą precyzyjnej kontroli, możesz filtrować wyjście obrazów na poziomie PHP:
<?php
declare(strict_types=1);
add_filter('wp_get_attachment_image_attributes', function (array $attr, WP_Post $attachment): array {
$webp_url = preg_replace('/\.(jpe?g|png)$/i', '.webp', $attr['src']);
$upload_dir = wp_get_upload_dir();
$webp_path = str_replace($upload_dir['baseurl'], $upload_dir['basedir'], $webp_url);
if (file_exists($webp_path)) {
$attr['src'] = $webp_url;
if (isset($attr['srcset'])) {
$attr['srcset'] = preg_replace('/\.(jpe?g|png)/i', '.webp', $attr['srcset']);
}
}
return $attr;
}, 10, 2);Porządkowanie rozmiarów obrazów WordPress
WordPress i WooCommerce rejestrują domyślnie wiele rozmiarów obrazów. Każdy przesłany obraz generuje kopię w każdym zarejestrowanym rozmiarze, zużywając przestrzeń dyskową i spowalniając masową optymalizację. Usunięcie rozmiarów, których nie używasz, to szybka wygrana.
Usuwanie nieużywanych domyślnych rozmiarów
<?php
declare(strict_types=1);
add_action('after_setup_theme', function (): void {
// Usuń rozmiary, których nie używasz
remove_image_size('1536x1536');
remove_image_size('2048x2048');
});
add_filter('intermediate_image_sizes_advanced', function (array $sizes): array {
// Zachowaj tylko rozmiary, których Twój motyw faktycznie używa
$remove = ['medium_large'];
foreach ($remove as $size) {
unset($sizes[$size]);
}
return $sizes;
});Rejestrowanie tylko tego, czego potrzebujesz
<?php
declare(strict_types=1);
add_action('after_setup_theme', function (): void {
add_image_size('hero-banner', 1200, 630, true);
add_image_size('card-thumb', 400, 300, true);
add_image_size('logo-small', 200, 0, false);
});Ustawianie maksymalnych wymiarów przesyłania
Zapobiegaj przesyłaniu przez użytkowników oryginałów o szerokości 6000 px, które marnują przestrzeń dyskową i czas przetwarzania:
<?php
declare(strict_types=1);
add_filter('wp_handle_upload', function (array $upload): array {
$max_width = 2400;
$max_height = 2400;
if (!str_starts_with($upload['type'], 'image/')) {
return $upload;
}
$image = wp_get_image_editor($upload['file']);
if (is_wp_error($image)) {
return $upload;
}
$size = $image->get_size();
if ($size['width'] > $max_width || $size['height'] > $max_height) {
$image->resize($max_width, $max_height, false);
$image->save($upload['file']);
}
return $upload;
});Zrozumienie critical CSS i zasobów blokujących renderowanie
Gdy przeglądarka ładuje stronę WordPress, musi pobrać i przeanalizować pełny arkusz stylów CSS przed wyrenderowaniem czegokolwiek na ekranie. Na typowej stronie WordPress z motywem page buildera ten arkusz stylów może mieć 300-500 KB CSS, z czego większość dotyczy elementów poniżej linii zagięcia lub na zupełnie innych stronach.
Critical CSS rozwiązuje ten problem poprzez ekstrakcję tylko stylów wymaganych dla treści widocznej powyżej linii zagięcia i wstawianie ich bezpośrednio inline w nagłówku HTML <head>. Pełny arkusz stylów jest następnie ładowany asynchronicznie, usuwając go że ścieżki krytycznego renderowania.
Jak działa ekstrakcja critical CSS
- Narzędzie renderuje stronę w bezgłowej przeglądarce w standardówym rozmiarze okna (zazwyczaj 1300x900 dla desktopa, 375x812 dla urządzeń mobilnych).
- Identyfikuje, które reguły CSS dotyczą elementów widocznych w tym oknie.
- Te reguły są ekstrahowane i minifikowane.
- Wyekstrahowany CSS jest wstawiany inline w tagach
<style>w nagłówku dokumentu. - Oryginalny arkusz stylów jest ładowany z
media="print"i zamieniany namedia="all"po załadowaniu.
Ręczny wzorzec wczytywania critical CSS
Jeśli nie używasz wtyczki, która obsługuje to automatycznie, możesz zaimplementować ten wzorzec za pomocą filtra WordPress:
<?php
declare(strict_types=1);
add_action('wp_head', function (): void {
$critical_css_file = get_template_directory() . '/critical.css';
if (!file_exists($critical_css_file)) {
return;
}
$critical_css = file_get_contents($critical_css_file);
if ($critical_css === false) {
return;
}
echo '<style id="critical-css">' . $critical_css . '</style>' . "\n";
}, 1);
add_filter('style_loader_tag', function (string $html, string $handle): string {
// Odrocz niekrytyczne arkusze stylów
$defer_handles = ['theme-style', 'woocommerce-layout', 'woocommerce-general'];
if (in_array($handle, $defer_handles, true)) {
$html = str_replace(
"media='all'",
"media='print' onload=\"this.media='all'\"",
$html
);
}
return $html;
}, 10, 2);Wczytywanie krytycznych zasobów za pomocą tagów link
Dla zasobów, których przeglądarka potrzebuje natychmiast, podpowiedzi preload informują ją, aby rozpoczęła pobieranie, zanim naturalnie odkryje zasób w HTML:
<!-- Wczytaj wstępnie obraz hero -->
<link rel="preload" as="image" href="/wp-content/uploads/hero.webp" type="image/webp">
<!-- Wczytaj wstępnie krytyczną czcionkę -->
<link rel="preload" as="font" href="/wp-content/themes/theme/fonts/main.woff2"
type="font/woff2" crossorigin>W WordPress dodaj je programistycznie:
<?php
declare(strict_types=1);
add_action('wp_head', function (): void {
if (!is_front_page()) {
return;
}
$hero_image = get_template_directory_uri() . '/images/hero.webp';
echo '<link rel="preload" as="image" href="' . esc_url($hero_image) . '" type="image/webp">' . "\n";
}, 1);Konfiguracja LiteSpeed Cache dla WordPress
LiteSpeed Cache to najszybsza dostępna wtyczka cache dla WordPress, ponieważ działa na poziomie serwera webowego, a nie przez PHP. Jeśli Twój hosting działa na OpenLiteSpeed lub LiteSpeed Enterprise, ta wtyczka komunikuje się bezpośrednio z wbudowanym silnikiem cache serwera, omijając PHP całkowicie dla żądań z cache.
Podstawowe ustawienia LiteSpeed Cache
Cache strony (zakładka Cache):
- Włącz cache: Wł.
- Cache zalogowanych użytkowników: Wył. (chyba że masz treści członkowskie)
- Cache mobilny: Wł. (z osobnym cache dla urządzeń mobilnych, jeśli motyw serwuje inny markup)
- TTL: 604800 (7 dni dla stron że statyczną treścią), 86400 (1 dzień dla często aktualizowanych stron)
Cache przeglądarki (zakładka Cache):
- Cache przeglądarki: Wł.
- TTL cache przeglądarki: 31557600 (1 rok, polegaj na wersjonowanych nazwach plików do odświeżania cache)
Cache obiektów (zakładka Cache):
- Cache obiektów: Wł. (wymaga Redis lub Memcached na serwerze)
- TTL cache obiektów: 3600
Ustawienia optymalizacji CSS/JS
Przejdź do LiteSpeed Cache, następnie Optymalizacja:
- Minifikacja CSS: Wł.
- Łączenie CSS: Wł. (testuj ostrożnie, może zepsuć niektóre motywy)
- Generowanie critical CSS: Wł.
- Asynchroniczne ładowanie CSS: Wł.
- Minifikacja JS: Wł.
- Łączenie JS: Wył. (często powoduje problemy, testuj przed włączeniem)
- Odraczanie JS: Wł.
- Inline JS po gotowości DOM: Wł.
Optymalizacja obrazów w LiteSpeed Cache
LiteSpeed Cache zawiera własną usługę optymalizacji obrazów przez QUIC.cloud:
- Zamiana obrazów na WebP: Wł.
- Lazy load obrazów: Wł.
- Responsywny placeholder: Wł.
- Obrazy w viewport (pierwsze N obrazów wyłączonych z lazy load): 2-3
Reguły .htaccess LiteSpeed dla cache przeglądarki
Dodaj te reguły do .htaccess dla nagłówków cache na poziomie serwera:
# LiteSpeed Cache przeglądarki i kompresja
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/avif "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE font/woff
</IfModule>
# Nagłówki bezpieczeństwa poprawiające również wydajność
<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "interest-cohort=()"
</IfModule>Konfiguracja crawlera LiteSpeed
Crawler utrzymuje cache ciepły, odwiedzając strony zanim zrobią to prawdziwi użytkownicy:
- Crawler: Wł.
- Czas trwania: 200 (sekundy)
- Przerwa między uruchomieniami: 600 (sekundy)
- Opóźnienie crawlowania: 500 (milisekundy)
- Limit obciążenia serwera: 1
Ustaw te wartości zachowawczo na hostingu współdzielonym. Na serwerze dedykowanym lub VPS możesz zwiększyć czas trwania i zmniejszyć przerwę.
Pomiar wyników za pomocą PageSpeed Insights
Optymalizacja bez pomiaru to zgadywanie. Google PageSpeed Insights dostarcza zarówno dane laboratoryjne (symulowane testy), jak i dane terenowe (rzeczywiste metryki użytkowników z Chrome User Experience Report).
Co sprawdzić po optymalizacji
Uruchom PageSpeed Insights na kluczowych stronach i zweryfikuj te elementy:
Zaliczone audyty (zielone):
- “Serwuj obrazy w formatach nowej generacji” powinno przejść, jeśli WebP/AVIF jest skonfigurowany
- “Efektywnie koduj obrazy” powinno przejść po kompresji
- “Prawidłowo dobieraj rozmiary obrazów” powinno przejść, jeśli usunąłeś nieużywane rozmiary
- “Eliminuj zasoby blokujące renderowanie” powinno przejść z critical CSS
Core Web Vitals:
- Cel LCP: poniżej 2,5 sekundy
- Cel CLS: poniżej 0,1
- Cel INP: poniżej 200 milisekund
Weryfikacja dostarczania formatów w Chrome DevTools
Otwórz DevTools (F12), przejdź do zakładki Network i filtruj po “Img”. Sprawdź kolumnę “Type”: powinieneś widzieć webp lub avif zamiast jpeg lub png. Jeśli nadal widzisz oryginalne formaty, Twoje reguły przepisywania lub konfiguracja wtyczki wymaga korekty.
Budżet wydajności Lighthouse
Ustaw budżet wydajności, aby wychwycić regresje:
[
{
"resourceSizes": [
{ "resourceType": "image", "budget": 300 },
{ "resourceType": "stylesheet", "budget": 50 },
{ "resourceType": "script", "budget": 200 },
{ "resourceType": "total", "budget": 800 }
]
}
]Wartości podane są w kilobajtach. Ten budżet zapewnia, że całkowita waga strony pozostaje poniżej 800 KB, z obrazami ograniczonymi do 300 KB.
Zaawansowane techniki na 2026
Fetchpriority dla obrazów hero
Atrybut fetchpriority informuje przeglądarkę, które obrazy mają priorytet podczas ładowania. Zastosuj go do obrazu LCP:
<img src="hero.webp" alt="Baner hero" width="1200" height="630"
fetchpriority="high" decoding="async">W WordPress możesz dodać ten atrybut za pomocą filtra:
<?php
declare(strict_types=1);
add_filter('wp_get_attachment_image_attributes', function (array $attr, WP_Post $attachment, string $size): array {
if ($size === 'hero-banner' && is_front_page()) {
$attr['fetchpriority'] = 'high';
$attr['decoding'] = 'async';
unset($attr['loading']); // Usuń lazy loading z hero
}
return $attr;
}, 10, 3);Content-visibility dla sekcji poniżej linii zagięcia
Właściwość CSS content-visibility pozwala przeglądarce pominąć renderowanie sekcji poza ekranem, dopóki nie będą potrzebne:
.below-fold-section {
content-visibility: auto;
contain-intrinsic-size: auto 500px;
}To znacząco redukuje początkową pracę renderowania na długich stronach z wieloma obrazami.
Responsywne obrazy z art direction
Dla obrazów wymagających różnych kadrów przy różnych breakpointach, użyj elementu <picture> z media queries:
<picture>
<source media="(max-width: 640px)" srcset="hero-mobile.avif" type="image/avif">
<source media="(max-width: 640px)" srcset="hero-mobile.webp" type="image/webp">
<source srcset="hero-desktop.avif" type="image/avif">
<source srcset="hero-desktop.webp" type="image/webp">
<img src="hero-desktop.jpg" alt="Obraz hero" width="1200" height="630">
</picture>Lista kontrolna wydajności
Użyj tej listy kontrolnej, aby zweryfikować kompletność implementacji:
- Wtyczka do optymalizacji obrazów zainstalowana i skonfigurowana
- Generowanie WebP włączone dla wszystkich nowych przesyłanych plików
- Generowanie AVIF włączone (jeśli wtyczka to obsługuje)
- Masowa optymalizacja przeprowadzona na istniejącej bibliotece mediów
- Nieużywane rozmiary obrazów usunięte
- Maksymalne wymiary przesyłania ustawione
- Reguły przepisywania WebP/AVIF w .htaccess na miejscu
- Ekstrakcja critical CSS włączona
- Niekrytyczne arkusze stylów odroczone
- Obraz hero wczytany wstępnie za pomocą
<link rel="preload"> - Obraz hero oznaczony
fetchpriority="high" - Cache strony LiteSpeed Cache włączony
- Cache przeglądarki LiteSpeed Cache włączony
- Optymalizacja CSS/JS LiteSpeed Cache skonfigurowana
- Crawler skonfigurowany i uruchomiony
- Wynik PageSpeed Insights zweryfikowany na 90+
- Dostarczanie WebP/AVIF potwierdzone w DevTools
Dwa przypadki, które mapują pipeline na liczby
Pierwszy przypadek to sklep WooCommerce na hostingu współdzielonym w cyber_Folks serwujący 200 KB hero w PNG, karuzelę 1,2 MB nieoptymalizowanych JPEG-ów i arkusz page-buildera około 600 KB na każdej stronie. Dane polowe pokazywały LCP mobilne 4,0 s, FCP 2,8 s. Skonwertowaliśmy hero do AVIF (28 KB po kompresji glossy w ShortPixel), dodaliśmy fetchpriority="high" i <link rel="preload">, wyregenerowaliśmy miniatury dla rzeczywistych rozmiarów używanych przez motyw, uruchomiliśmy bulk ShortPixel dla zaległego katalogu. LCP spadło do 1,4 s bez ruszania CSS.
Drugi przypadek był odwrotny: obrazy już były AVIF, ale FCP odmawiał spadku poniżej 2,4 s na komórce. Jedynym blokującym renderowanie sprawcą był main.css o wadze 800 KB zawierający każdy moduł page-buildera, którego strona nigdy nie używała. Wyciągnęliśmy critical CSS dla strony głównej i trzech szablonów landing przez Penthouse, wkleiliśmy 12 KB inline w head, odroczyliśmy resztę wzorcem media="print" z onload swap, dodaliśmy font-display: swap do deklaracji WOFF2. FCP spadło o około 600 ms na zdławionym profilu Android mid-tier, a panel WP Rocket przestał flagować “wyeliminuj zasoby blokujące renderowanie”.
Wzorzec wart nazwania jawnie: kiedy zawodzi LCP, naprawa jest prawie zawsze po stronie obrazów; kiedy zawodzi FCP a LCP jest akceptowalny, naprawa jest po stronie CSS. Narzędzia, które łączą te dwa, produkują ulepszenia mgliste; traktowanie ich jako oddzielne wąskie gardła produkuje ulepszenia mierzalne.
Co WP Rocket, FlyingPress i Perfmatters faktycznie robią
Te trzy wtyczki nie są wymienne, a strony marketingowe to zaciemniają. WP Rocket pakuje cache strony, konkatenację i defer CSS/JS, lazy loading oraz hak integracyjny dla Imagify; ekstrakcja critical CSS (RUCSS) działa po stronie serwera w SaaS i fail-safe gracefully. FlyingPress skupia się na lokalnym serwowaniu fontów, inline’owaniu critical CSS per szablon i usuwaniu nieużywanego CSS na poziomie URL a nie strony, co jest lepszym modelem dla witryn z różnymi layoutami. Perfmatters nie cache’uje: wyłącza funkcje WordPressa, których strona nie potrzebuje (heartbeat, emoji, embed.js, REST endpoints) i dodaje preconnect, prefetch oraz dns-prefetch. Trzy stackują się czysto: Perfmatters obcina, FlyingPress lub WP Rocket obsługuje CSS i cache, wtyczka obrazów obsługuje AVIF.
Jeśli host to OpenLiteSpeed lub LiteSpeed Enterprise (cyber_Folks, dhosting na planach LiteSpeed, MyDevil), kalkulacja się zmienia. LiteSpeed Cache komunikuje się z modułem cache zbudowanym w serwerze i pomija PHP całkowicie na cache hit, co jest szybsze niż jakakolwiek wtyczka działająca w PHP może być. Kompromis: QUIC.cloud obsługuje critical CSS i konwersję obrazów off-site, co ma własne implikacje DPA pod RODO.
Wyniki pipeline wydajności
W ostatnich pracach klienckich wzorzec ląduje w tym przedziale. Traktuj liczby jako orientacyjną kopertę a nie gwarancję, bo stan wyjściowy ma większe znaczenie niż interwencja.
| Metryka | Przed | Po |
|---|---|---|
| Wynik PageSpeed mobilny | 35-55 | 90-98 |
| LCP | 4,5-8 s | 1,2-2,0 s |
| Całkowita waga strony | 3-6 MB | 400-800 KB |
| Liczba żądań | 80-120 | 25-40 |
| TTFB | 800 ms+ | 150-300 ms |
Kombinacja nowoczesnych formatów obrazów, critical CSS i poprawnej konfiguracji cache adresuje trzy niezależne wąskie gardła: rozmiar pliku, blokowanie renderowania i czas odpowiedzi serwera. Żadne nie zastępuje pozostałych.
Gdzie wpisuje się wppoland.com
Prowadzimy ten pipeline na produkcyjnych instalacjach WordPress i WooCommerce: konfiguracja LiteSpeed na poziomie serwera (najczęściej cyber_Folks i dhosting w PL), ekstrakcja critical CSS z ręcznym czyszczeniem przez zakładkę Coverage tam gdzie Penthouse pomija selektor, dostawa AVIF z negocjacją treści oraz audyt w danych polowych PageSpeed Insights, żeby zmiany trzymały się pod realnym ruchem CrUX. Cennik jest indywidualny i zależy od rozmiaru biblioteki mediów, śladu page-buildera i tego ile pracy to migracja a ile optymalizacja w miejscu. Jeśli wyniki PageSpeed blokują pozycje stron, skontaktuj się w sprawie audytu wydajności.
