100/100 w Lighthouse to wynik laboratoryjny. Core Web Vitals, których Google używa w rankingu, to p75 w Chrome UX Report z 28 dni. Zmieszaj te dwa, a gonisz screenshot, podczas gdy pole jest czerwone.
WordPress 7.1 na PHP 8.4 może oddać zielone vitals. Nie robi tego sam. Motyw z Elementorem, banner consentu, który spycha hero, oraz widget kasowy, który hydratuje 200 KB na kliknięcie, tracą INP, zanim LCP w ogóle się skończy. Ten przewodnik ma dwie warstwy: pole (CrUX), które musi siedzieć w zielonych pasmach Google, oraz lab (Lighthouse mobile), gdzie wewnętrznie gonimy 100/100, bo to wymusza dyscyplinę w obrazach, CSS i stronach trzecich.
Opublikowane „good” Google dla LCP to 2,5 sekundy na p75 w polu. W tym tekście tego nie zmieniamy i nie udajemy, że jakiś dokument z 2026 obniżył oficjalną listę. Gdy mówimy, że hero powinien malować się bliżej jednej sekundy, to jest nasz wewnętrzny budżet labowy, nie próg Google. INP „good” to 200 ms. CLS „good” to 0,1. Lab 100/100 chce ciaśniejszych liczb, bo Lighthouse karze TTFB, nieużywany CSS i pracę głównego wątku w symulowanym przebiegu.
Reszta tekstu dotyczy polskiego hostingu współdzielonego, belki consentu pod UODO i widgetów Przelewy24 / PayU. Bez tego przewodnik CWV jest przetłumaczony, nie użyty.
Pole kontra lab: CrUX to nie Lighthouse
CrUX to dane polowe od użytkowników Chrome, którzy zgodzili się na telemetrię. Okno to 28 dni. Liczy się 75. percentyl dla URL albo originu. Lighthouse to lab: jedno urządzenie, jeden profil sieci, jedno ładowanie, często bez logowania, bez widgetu płatności, bez bannera consentu, który pokazuje się tylko w EOG.
Konsekwencje:
- Strona może mieć LCP 1,1 s w labie i 2,8 s w polu, bo część trafień wchodzi na 4G na skraju pokrycia, albo bo origin jest bity bez cache HTML.
- Strona może mieć 100 w labie i czerwone INP w polu, bo widget PayU albo Przelewy24 wstrzykuje się tylko dla odwiedzających sklep.
- PageSpeed Insights pokazuje oba. Najpierw czytaj zakładkę pola. Lab to diagnoza, nie wyrok.
Własny RUM z web-vitals (onLCP, onINP, onCLS) wysyłany przez sendBeacon daje p75, zanim CrUX przewinie 28 dni. To sterowanie wewnętrzne. Nie zastępuje CrUX w Search Console. Nigdy nie raportuj liczby z Lighthouse tak, jakby to było CrUX.
| Miara | Źródło | Czym jest | Czym nie jest |
|---|---|---|---|
| LCP p75 pole | CrUX | Sygnał rankingowy Google | Przebieg Lighthouse |
| INP p75 pole | CrUX | Wszystkie interakcje, 200 ms zielone | Pierwszy klik (to było FID) |
| CLS p75 pole | CrUX | Nieoczekiwany skok layoutu, 0,1 zielone | „Na Macu wyglądało stabilnie” |
| 100/100 mobile | Lighthouse | Lab pod stałym profilem | Pole, i nie próg Google |
LCP: 2,5 s Google i nasz budżet 1,2 s w labie
Largest Contentful Paint to czas do namalowania największego elementu treści w viewportcie. Na WordPressie prawie zawsze jest to obraz hero, czasem H1 nad tłem, które nigdy nie staje się LCP, bo wygrywa tekst.
Google, pole, p75: 2,5 s lub lepiej to zieleń. Między 2,5 a 4,0 s to „needs improvement”. Powyżej 4,0 s to czerwień. To jest lista. Wewnętrznie, w Lighthouse mobile, często gonimy LCP poniżej 1,2 s, bo 100/100 tego wymaga i bo zostawia margines, gdy pole jest twardsze niż lab. To nasz cel. To nie nowy próg Google.
Czas LCP to TTFB plus opóźnienie startu pobierania plus pobranie plus opóźnienie renderu. Typowe wpadki WordPressa:
-
Hero z
loading="lazy". Core i wiele motywów lazy-loaduje wszystko. Lazy na obrazie LCP opóźnia start pobierania do momentu po layoutcie. Zdejmij lazy z pierwszego obrazu. Ustawfetchpriority="high". Preload w<head>zimagesrcsetiimagesizeszgodnymi z tym, co faktycznie widać. -
WebP tam, gdzie AVIF jest tańszy w bajtach. AVIF to format, do którego kodujemy w 2026. WebP to fallback. JPEG to oryginał w bibliotece mediów, nie dostawa. Hero na 1800 px nie potrzebuje 3 MB PNG z ostatniego eksportu kampanii.
-
Font, który blokuje paint. Jeśli LCP to tekst, webfont leży na ścieżce krytycznej. Subset do skryptów, których naprawdę używasz (latin + latin-ext dla polskich znaków),
font-display: optionalalbo metric-adjusted fallback. -
Origin bez cache. Preload nie pomoże, jeśli HTML przychodzi po 700 ms.
Dwa przypadki, które mierzyliśmy:
- Katalog WooCommerce z 30-plus wtyczkami i TTFB około 1,8 s na szablonach kategorii. Related products, recenzje, schema i mega-menu składane w PHP przy każdym żądaniu. Cache HTML dla anonimowych URL kategorii, hero w AVIF, bez lazy na pierwszym obrazie. LCP w polu ruszyło. Checkout został bez cache.
- Landing Elementora, który padał pod ruchem z kampanii. Builder malował każdy wariant w PHP. Nie było historii cache-tagów, tylko „purge all”. Nie odłączaliśmy tej strony. Obcięliśmy builder, zostawiliśmy sprzężony motyw, Redis i page cache. Odłączanie stosu page-buildera to przepisanie redakcyjne, nie zmiana hostingu.
<?php
declare(strict_types=1);
add_action('wp_head', static function (): void {
if (!is_front_page() && !is_singular()) {
return;
}
$url = get_the_post_thumbnail_url(null, 'full');
if (!$url) {
return;
}
printf(
'<link rel="preload" as="image" href="%s" fetchpriority="high" />' . "\n",
esc_url($url)
);
}, 1);Na Astro 7 i Next.js 16 preload żyje w szablonie, nie w wp_head. Origin oddaje URL i wymiary przez GraphQL. Frontend pisze <link rel="preload"> i <img> z width, height oraz srcset AVIF. Nie pozwól WordPressowi i frameworkowi zgadywać jednocześnie.
Na polskim hostingu współdzielonym (home.pl, nazwa.pl, podobne panele) TTFB bez cache HTML często siedzi w 400-800 ms, gdy wp-cron i workery PHP zbiegają się z ruchem z Ads. LCP w polu dziedziczy ten TTFB. Żadna pipeline AVIF w motywie tego nie uratuje. Cloudflare (lub równoważna krawędź) z cache HTML dla anonimowych GET, bypassem /wp-admin, /wp-login.php, preview=true, koszyka i wordpress_logged_in to najtańszy sposób, by pierwsze bajty spadły poniżej 200 ms dla anonimów.
HTMLRewriter na krawędzi kontra wtyczka inlinująca CSS
Krytyczny CSS i wskazówki preload należą do granicy HTML, nie do kolejnej mu-plugin, która odpala się przy każdym trafieniu PHP.
Wtyczka, która „inline’uje krytyczny CSS”, nadal potrzebuje startu PHP, zapytania o post i wypisania bloku <style>. To pomaga opóźnieniu renderu po TTFB. Nic nie robi dla TTFB. Jeśli origin ma 600 ms, budżet LCP jest już zjedzony, zanim inliner w ogóle ruszy.
Cloudflare HTMLRewriter (albo równoważna transformacja HTML na krawędzi) przepisuje dokument z cache: wstrzykuje preload obrazu LCP, zdejmuje tracker, który marketing dorzucił w wp_footer, dokłada fetchpriority, jeśli szablon o tym zapomniał. Origin PHP nie jest na tej ścieżce. Anonimowy GET zostaje trafieniem cache.
Zasady, których używamy:
- Anonimowy HTML jest cache’owany z tagami (
post-id,template-home,lang-pl). Publikacja czyści tagi, nie całą strefę. - HTMLRewriter mutuje tylko bezpieczne, idempotentne wskazówki. Nie personalizuje. Spersonalizowany HTML z definicji jest missem.
- Wtyczka inlinująca CSS jest dozwolona na sprzężonym motywie w trakcie migracji, potem wychodzi. Dwa inlinery (wtyczka plus krawędź) dublują bajty i walczą o to, który
<style>wygrywa.
LiteSpeed Cache plus Cloudflare „cache everything” plus inliner to trzy cache’e bez wspólnej invalidacji. Redaktor zapisuje, origin się aktualizuje, krawędź serwuje wczorajszą stronę główną przez dwie godziny. To nie strategia Core Web Vitals. To kolejka supportu.
INP: 200 ms i widget kasowy
Interaction to Next Paint zastąpiło FID w 2024. FID mierzyło pierwszy klik. INP mierzy klik, tap i klawisz przez całą sesję. Zielone INP w polu to 200 ms lub lepiej na p75. Między 200 a 500 ms to „needs improvement”. Powyżej 500 ms to czerwień. Lab 100/100 często chce wyraźnie poniżej 200 ms, bo Lighthouse twardo karze długie zadania.
INP to opóźnienie wejścia plus przetwarzanie plus prezentacja. Na sklepach WordPress przetwarzanie prawie zawsze jest stroną trzecią, nie Twoim toggleMenu().
Widgety płatności i komunikatów (Przelewy24, PayU, Blik, Apple Pay, przyciski w hero albo w koszyku) ładują zewnętrzny skrypt, otwierają modal i rejestrują handlery na przyciskach. Jeśli skrypt wchodzi synchronicznie w <head>, zajmuje główny wątek przed pierwszym kliknięciem w menu. Ładuj widget, gdy checkout jest w viewportcie (client:visible w Astro 7, dynamic import w Next.js 16), albo na idle. Przycisk może być HTML z href do cienkiej trasy kasowej. Hydratuj widget tam, nie na stronie głównej.
Pozostałe:
- Google Tag Manager, Meta Pixel, Hotjar, chat: Partytown albo ładuj po
requestIdleCallback. Nigdy na ścieżce krytycznej. Partytown nie jest darmowe. Przenosi pracę do workera. Nie robi z kontenera tagów 400 KB małego kontenera. - Długie listy (filtry sklepu, mega-menu):
scheduler.yield()między kawałkami, albo wirtualizacja.querySelectorAllpo 2000 węzłach w handlerze kliknięcia to naruszenie INP. - Menu mobilne: pierwszy tap w hamburger często jest tym INP, które łapie CrUX. Jeśli klik czeka na hydratację całego drzewa nawigacji, 200 ms znika. Menu serwerowe na
<details>albo wyspa, która posiada tylko menu, wystarczy. Nie hydratuj całego headera jako jednej wyspy React.
async function yieldToMain() {
if ('scheduler' in window && 'yield' in window.scheduler) {
return window.scheduler.yield();
}
return new Promise((resolve) => setTimeout(resolve, 0));
}Mierz INP w polu per szablon, nie jako średnią originu. Blog może być zielony, podczas gdy kasa jest czerwona. CrUX na poziomie originu to ukrywa. Search Console na poziomie URL i własny RUM per page_type to pokazują.
Pole w Polsce to nie symulowany profil kabla z Lighthouse. CrUX na .pl zawiera Orange, Play, Plus i T-Mobile na 4G, często z throttlingiem CPU na starszym Androidzie. Przebieg labu z Maca przeciwko localhost ze 100/100 nic nie mówi o p75 w Białymstoku. Dlatego: cache HTML blisko użytkownika, małe wyspy JS i żaden synchroniczny PayU na stronie głównej.
CLS: banery consentu i późny paint motywu
Cumulative Layout Shift sumuje nieoczekiwane skoki. Zielone CLS w polu to 0,1 lub lepiej. Lab 100/100 chce blisko 0,00. Dwa źródła, które biją brakujące width i height na obrazach, to consent i motyw.
Banner consentu (ePrivacy + RODO). Cookiebot, Didomi, Usercentrics i własne belki często wstrzykują się po hydratacji. Banner bierze 80 do 120 px u góry albo u dołu. Hero, które już jest LCP, zostaje spychane. To CLS, i trafia prawie każdą pierwszą wizytę w EOG. CrUX p75 to zapisuje. Lighthouse bez bannera nie.
Naprawa: zarezerwuj miejsce w CSS, zanim skrypt ruszy. Stały min-height na wrapperze, który zawsze jest w szablonie. Nie animuj wysokości od 0 do 96 px. Jeśli banner jest overlayem, nie rezerwuj nic w flow, ale zablokuj scroll bez zmiany padding-top na <body> po pomiarze. Ładuj skrypt consentu tak, by nie wygrał z LCP, ale zostaw wrapper w pierwszym HTML.
Późny dark mode. Jeśli klasa motywu (dark na <html> albo <body>) jest ustawiana w skrypcie klienta po pierwszym paintcie, skaczą tło, tekst i cienie. To CLS i często flash. Naprawa: mały synchroniczny <script> w <head> przed CSS, odczyt localStorage i matchMedia, oraz zmienne kolorów tak, by zamiana nie zmieniała geometrii. Zmieniaj kolor, nie font-size i line-height. filter: invert na body to problem CLS i kontrastu, nie motyw.
Pozostałe CLS:
- Obrazy i iframe:
width,heightalboaspect-ratio. Embed YouTube w pudełku 16/9. - Fonty:
size-adjust,ascent-overridena fallbacku, żeby Arial i Geist zajmowały tę samą linię. - Reklamy i bloki related: min-height, nie „nie wiemy, dopóki API nie odpowie”.
.consent-slot {
min-height: 96px;
}
.hero-media {
width: 100%;
aspect-ratio: 16 / 9;
object-fit: cover;
}
@font-face {
font-family: Geist-Fallback;
src: local("Arial");
size-adjust: 106%;
ascent-override: 90%;
descent-override: 22%;
line-gap-override: 0%;
}Cookiebot, IAB TCF i CLS na polskim consencie
Na polskich sklepach i serwisach contentowych belka consentu to nie dekoracja. To pierwszy element UI, który większość nowych sesji z EOG zobaczy przed wszystkim innym, a jednocześnie najczęstszy sprawca CLS, którego lab nie widzi. Cookiebot, Didomi, Consent Manager i własne paski „pod UODO” mają ten sam wzorzec awarii: skrypt CMP ładuje się po hydratacji, wstawia belkę albo modal, hero (LCP) spada o wysokość bannera, a klik w „Akceptuję” konkuruje o główny wątek z Tag Managerem.
IAB TCF 2.x dokłada drugą warstwę. Gdy CMP ładuje string TC, listy vendorów i ewentualnie iframe’y transparentności, główny wątek dostaje pracę, której Lighthouse bez EEA nie odtwarza. INP na pierwszym tapie w hamburger albo w przycisku „Kup” bywa czerwone, mimo zielonego labu na Macu w USA. To nie opinia prawna o tym, czy TCF wystarczy pod UODO. To pomiar: consent, który wstrzykuje się po paintcie, psuje CLS i kradnie INP.
Wzorce, które widzimy na .pl:
- Cookiebot Auto Blocking ładuje się z
asyncwwp_footer, a belka pojawia się dopiero po odpowiedzi API. Wrapper w DOM nie istnieje w pierwszym HTML. Hero maluje się na pełnej wysokości, potem belka wchodzi u góry i spycha layout. CrUX zapisuje skok. Lab bez cookies EEA tego nie widzi. - Didomi / własne belki mierzą wysokość treści po renderze i ustawiają
padding-topnabody. Każda zmiana paddingu po pierwszym paintcie to CLS. Stały slot w szablonie zmin-height(np. 96 px albo wysokość belki w mobile) usuwa skok, nawet jeśli treść CMP przyjdzie później. - GTM „Consent Mode” dorzuca dodatkowe tagi w momencie akceptacji. Jeśli kontener jest już na ścieżce krytycznej, akceptacja staje się long taskiem. Consent Mode ma iść po idle albo z Partytownem; belka ma być w HTML od pierwszej odpowiedzi.
Co robić technicznie (zostając przy vitals):
- Slot consentu w pierwszym HTML: pusty albo z placeholderem, zawsze z zarezerwowaną wysokością. Nie
height: autoanimowane od zera. - Skrypt CMP po LCP:
defer/ idle /client:idlew Astro 7. Belka wizualna nie czeka na skrypt, jeśli slot już zajmuje miejsce. - Overlay zamiast belki w flow: wtedy nie rezerwujesz wysokości, ale nie wolno po pomiarze dokładać paddingu do
bodyani przesuwać hero. Scroll-lock bez zmiany geometrii. - Nie ładuj pełnej listy vendorów TCF na stronie artykułu, jeśli checkout i tagi i tak są za consentem. Im mniej JS w pierwszej interakcji, tym bliżej 200 ms INP.
- Mierz CLS i INP na sesjach z PL / EEA osobno. Origin-level CrUX miesza boty labu i realnych odwiedzających; RUM z flagą
consent_shown=1pokazuje, czy belka jest sprawcą.
Przykład slotu, który nie czeka na Cookiebot:
<div id="consent-slot" class="consent-slot" aria-live="polite"></div>.consent-slot {
min-height: 96px;
/* belka fixed/sticky: slot zostaje, layout nie skacze */
}Jeśli CMP wstawia belkę jako position: fixed, slot nadal warto mieć na czas, gdy ktoś przełączy CMP na tryb „push content”. Stała rezerwacja jest tańsza niż gaszenie pożaru CLS po kampanii Black Friday, gdy p75 w Search Console spada przez dwa tygodnie.
Nie mieszaj tu porad prawnych. UODO, ePrivacy i treść klauzul to osobna ścieżka. Ścieżka vitals jest prosta: belka w pierwszym HTML albo overlay bez mutacji geometrii, skrypt CMP poza ścieżką LCP, akceptacja bez long taska na Tag Managerze.
Obrazy i fonty bez kradzieży LCP
Biblioteka mediów trzyma oryginały. Dostawa to AVIF w szerokościach 400, 768, 1200 i 1920, z sizes dopasowanym do layoutu, nie 100vw na artykule w kolumnie 680 px. loading="lazy" na wszystkim poniżej foldu. decoding="async". Żadnego karuzela w hero, które ładuje pięć kandydatów LCP.
Fonty: dwie wagi, nie pięć. Subset (latin + latin-ext). WOFF2. Self-host, nie CSS Google Fonts, który dokłada dwie dodatkowe rundy przed @font-face. Na Astro 7 i Next.js 16 to siedzi w pipeline builda. Na monolicie: wtyczka albo build, który pisze pliki subset, nie „Elementor Custom Fonts” z TTF.
Krytyczny CSS należy do pierwszego pakietu. Header, typografia i pudełko hero dostają styl w HTML, poniżej około 14 KB skompresowanych, żeby pierwszy paint nie czekał na style.css. Reszta arkusza ładuje się asynchronicznie. Buildy Elementora i Divi, które wysyłają 400 KB CSS na każdy URL, tracą LCP, zanim obraz zostanie wspomniany. W headless Astro i Next emitują tylko klasy użyte na stronie. Na monolicie: wyciągnij above-the-fold per szablon albo zmień motyw.
content-visibility: auto na komentarzach, siatce related i stopce tnie pracę stylu i layoutu podczas pierwszego paintu. Ustaw contain-intrinsic-size, żeby scrollbar nie skakał (to CLS).
Wyspy Astro 7 i Next.js 16 pod vitals
Dwa fronty, to samo wymaganie: pierwszy paint bez zbędnego JavaScriptu.
Astro 7 jest domyślne dla contentu. HTML i CSS na zewnątrz. Wyspy tam, gdzie jest klik. client:idle dla wyszukiwarki. client:visible dla widgetu koszyka. Artykuł bez wysp wysyła 0 KB JS i wygrywa lab. Dlatego 100/100 jest osiągalne na magazynie bez oszukiwania designu.
Next.js 16 ma sens, gdy strona jest aplikacją. PPR: statyczny shell, dynamiczne dziury. React Server Components dla listy, komponent klienta dla filtra. Cały App Router jako "use client" na layoutcie to oddanie INP. Partial Prerendering pomaga LCP. Nie pomaga, jeśli useEffect w root layoutcie ładuje Tag Manager i widget płatności naraz.
Monolit na PHP 8.4 z ciasnym motywem, Redisem i Cloudflare też może być zielony w polu. Przegrywa, gdy redaktor instaluje „jedną małą” wtyczkę popup. Headless przegrywa, gdy wyspa importuje cały pakiet ikon. Architekturę wybierasz w przewodniku architektury headless. Vitals są skutkiem tej architektury plus stron trzecich.
Speculation Rules (<script type="speculationrules"> z konserwatywnym prerenderem na linkach wewnętrznych) ścinają następną nawigację w kierunku zera w wspieranych klientach Chrome. To poprawia odczuwaną szybkość. Nie zmienia LCP na landingu z Google, a to URL, o który CrUX dba.
PHP 8.4, Redis i TTFB za Cloudflare
HTML bez cache na hostingu współdzielonym to sufit LCP. Redis object cache tnie SQL dla zalogowanych i dla missów cache. Opcache na 8.4 tnie start PHP. Page cache z przodu (Cloudflare, albo Nginx fastcgi_cache, jeśli masz własny VPS) tnie PHP całkowicie dla anonimów.
Priorytet:
- Cache HTML dla anonimów, z purge przy publikacji.
- Redis dla
WP_Queryi transientów. - Mniej wtyczek na froncie. Każde
wp_enqueue_scriptto INP. - Indeksy bazy i sprzątanie autoload. Autoload 2 MB w
wp_optionsto TTFB, zanim motyw w ogóle wystartuje.
WordPress 7.1 tego nie zmienia. Core nie jest problemem LCP. Kolejka skryptów i odległość do originu są.
Pułapki, które wracają na polskich instalacjach:
- Cache wtyczkowy (LiteSpeed Cache, WP Super Cache) i cache HTML Cloudflare bez wspólnej invalidacji.
- „Cache everything” na WooCommerce: cena i koszyk przeciekają między sesjami, albo kasa staje się loterią cache. HTML sklepu jest prywatny. Listy produktów mogą mieć cache z tagiem.
- Origin zostawiony na PHP 8.1, podczas gdy WordPress 7.1 oczekuje nowocześniejszego runtime. To kosztuje TTFB i bezpieczeństwo naraz.
RUM, budżety i regresja
Lab w CI: budżety Lighthouse na PR dla szablonów, które mają znaczenie (home, artykuł, produkt, kasa). Fail buildu, jeśli JS na szablonie artykułu przekracza kilkadziesiąt kilobajtów, albo jeśli element LCP nie ma wymiarów. To łapie regresję z nowej wtyczki albo nowej wyspy.
Pole: web-vitals na Wasz endpoint, agregowane p75 per szablon per tydzień. Alarm, gdy INP przekracza 200 ms w polu, nie gdy ktoś odpalił Lighthouse na światłowodzie. CrUX API co tydzień jako źródło prawdy względem Search Console.
Budżety, które przeżywają tydzień kampanii:
- Wrapper consentu ma wysokość w CSS.
- Skrypt motywu w
<head>ma poniżej 1 KB i nie rusza layoutu. - Widgety płatności nie siedzą na stronie głównej.
- Hero jest AVIF, preload, nie lazy.
Bez budżetu 100/100 to screenshot z tygodnia premiery.
Multisite nie zmienia progów. Zmienia obciążenie originu. Jedna instancja Redis na sieć, cache HTML per blog ID i żaden wspólny all.min.js, który ładuje skrypty WooCommerce na magazynie. Z tym Multisite może siedzieć tak samo zielono w CrUX jak pojedyncza instalacja. Bez tego każda witryna dziedziczy enqueue wolnego sąsiada.
Audyt i dalsza lektura
Audyt Core Web Vitals to pole plus lab plus lista stron trzecich, które muszą zejść z głównego wątku. Najpierw otwieramy CrUX i Search Console, Lighthouse potem, a checkout mierzymy jako osobny szablon.
Praca nad szybkością istniejącego monolitu jest w przyspiesz swoją stronę WordPress. Odłączanie jako topologia, nie jako zaklęcie wydajności, jest w architekturze headless.
Podsumowanie
Google nie obniżyło listy LCP do 1,2 s. Zielone LCP w polu to 2,5 s. Zielone INP to 200 ms. Zielone CLS to 0,1. 100/100 to dyscyplina labu. Na WordPressie oznacza to cache HTML przed originem, miejsce na belkę consentu (Cookiebot, Didomi, własne paski), motyw bez FOUC, widgety kasowe poza pierwszą interakcją oraz rewrite na krawędzi zamiast kolejnego inlinera PHP. To oddziela zielone pole od ładnego screenshotu Lighthouse.
Napisz z URL i dostępem do Search Console, jeśli pole jest czerwone, a lab kłamie. Usługa przyspieszania WordPressa to powierzchnia komercyjna.
