Core Web Vitals dla witryn PHP: jak naprawić LCP, INP i CLS

Core Web Vitals dla witryn PHP nie są tematem wyłącznie front-endowym. Wolna strona PHP może spędzić sekundę na tworzeniu kodu HTML i żadna optymalizacja obrazu tego nie przywróci. Jednocześnie bardzo szybki serwer nie pomoże, jeśli obraz bohatera o wielkości 1,5 MB blokuje największą farbę. Oto jak podchodzimy do obu stron w naszych własnych witrynach PHP (integrono.com obsługuje PHP-FPM za nginx i Cloudflare) oraz w projektach klientów.

Co mierzą Core Web Vitals

• LCP ( Largest Contentful Paint): gdy renderowany jest największy widoczny element (zwykle obraz bohatera lub blok nagłówka). Dobry to 2,5 sekundy lub mniej.
• INP ( Interaction to Next Paint): jak szybko strona reaguje wizualnie na kliknięcia, dotknięcia i naciśnięcia klawiszy podczas całej wizyty. Dobry to 200 ms lub mniej.
• CLS ( Cumulative Layout Shift): ilość treści przeskakujących podczas ładowania. Dobra wynosi 0,1 lub mniej.

Google ocenia je na podstawie danych terenowych od rzeczywistych użytkowników Chrome, na 75. percentylu, oddzielnie dla urządzeń mobilnych i komputerów stacjonarnych. Oznacza to, że jeden powolny szablon lub jeden powolny kraj może zawieść całą grupę. Narzędzia laboratoryjne, takie jak Lighthouse służą do debugowania, a nie do uzyskania końcowego wyniku.

Krok 1. Zmierz we właściwy sposób

1. Otwórz raport Core Web Vitals w Google Search Console, aby zobaczyć, które grupy adresów URL zawiodły i według jakich wskaźników.
2. Sprawdź w PageSpeed Insights jeden adres URL z każdej grupy, w której wystąpił błąd. Liczy się górny blok „danych pola”; poniższy blok Lighthouse to test laboratoryjny wyjaśniający dlaczego.
3. Użyj panelu Wydajność w Chrome DevTools z 4-krotnym spowolnieniem procesora i „Slow 4G”, aby odtworzyć typowe wrażenia mobilne.
4. Aby na bieżąco monitorować, zbierz dane rzeczywistych użytkowników za pomocą biblioteki JavaScript web-vitals i wyślij je do swoich analiz.

<script type="module">
  import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
  const send = (m) => navigator.sendBeacon('/vitals', JSON.stringify({
    name: m.name, value: m.value, id: m.id, url: location.pathname
  }));
  onLCP(send); onINP(send); onCLS(send);
</script>

Krok 2. Najpierw napraw czas odpowiedzi serwera ( TTFB).

LCP uwzględnia czas przed przybyciem pierwszego bajtu. Jeśli wygenerowanie kodu HTML zajmuje 800 ms, oznacza to, że wydałeś już jedną trzecią budżetu. W witrynach PHP typowymi dźwigniami są:

• Włącz OPcache i upewnij się, że jest wystarczająco duży, aby pomieścić wszystkie skrypty. Bez tego PHP rekompiluje pliki na każde żądanie.
• Dostrój PHP-FPM. Zbyt mało żądań pracowników w kolejce, zbyt dużo pamięci. Obejrzyj stronę stanu PHP-FPM pod kątem „kolejki nasłuchiwania” i „osiągnięto maksymalną liczbę dzieci”.
• Buforuj całe strony dla anonimowych gości (nginx fastcgi_cache, pamięć podręczna odpowiedzi Laravel lub reguły pamięci podręcznej Cloudflare) i buforuj fragmenty lub wyniki zapytań za pomocą Redis.
• Napraw powolne zapytania. Włącz dziennik wolnych zapytań, poszukaj wzorców N+1 i dodaj indeksy. Strona, która uruchamia 120 zapytań, działa wolno niezależnie od wersji PHP.
• Zachowaj aktualność PHP. Nowsze wersje PHP są szybsze i zużywają mniej pamięci.

# php.ini (production)
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0   ; reload php-fpm on each deploy

# php-fpm pool
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

Ustaw pm.max_children z pamięci rzeczywistej: podziel pamięć, którą możesz dać PHP, przez średni rozmiar procesu roboczego (sprawdź za pomocą ps). Z validate_timestamps=0 pamiętaj o ponownym załadowaniu PHP-FPM po każdym wdrożeniu, w przeciwnym razie stary kod pozostanie w pamięci.

Na poziomie serwera WWW włącz HTTP/2 lub HTTP/3, Brotli lub gzip oraz nagłówki buforowania o długim czasie życia dla plików statycznych:

location ~* \.(?:css|js|webp|avif|jpg|png|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;

Użyj wersjonowanych nazw plików lub zapytania ?v= w oparciu o czas modyfikacji pliku, aby „niezmienny” nigdy nie udostępniał nieaktualnych zasobów.

Krok 3. Napraw element LCP

Znajdź element LCP w PageSpeed Insights lub panelu DevTools Performance. Na większości stron z treścią jest to obraz bohatera. Następnie:

• Nie ładuj go leniwie. loading="lazy" na obrazie LCP opóźnia to. Zamiast tego użyj fetchpriority="high".
• Podawaj w odpowiednim rozmiarze. Obraz o rozdzielczości 2400 pikseli dla szczeliny o wielkości 900 pikseli marnuje bajty. Użyj srcset i sizes.
• Użyj WebP lub AVIF. Typowe oszczędności wynoszą od 30 do 60 procent w porównaniu z plikami JPEG o podobnej jakości.
• Unikaj łańcuchów. Obraz ustawiony w tle CSS lub wstrzyknięty przez JavaScript jest wykrywany późno. Umieść go w kodzie HTML jako <img>.
• Wstępnie połącz źródła zewnętrzne lub hostuj je samodzielnie, od których zależy LCP (czcionki, obraz CDN).

<img src="/images/hero-1200.webp"
     srcset="/images/hero-640.webp 640w, /images/hero-1200.webp 1200w"
     sizes="(max-width: 1040px) 92vw, 960px"
     width="1200" height="630"
     alt="Descriptive alt text"
     decoding="async" fetchpriority="high">

To jest wzorzec, który wykorzystuje artykuł na tym blogu: dwa rozmiary WebP, wyraźne wymiary i wysoki priorytet pobierania dla bohatera.

Krok 4. Usuń przesunięcia układu ( CLS)

• Zawsze ustawiaj width i height (lub aspect-ratio w CSS) obrazów, filmów i elementów iframe, aby przeglądarka rezerwowała miejsce.
• Zarezerwuj miejsce na banery, powiadomienia o plikach cookie i reklamy. Zamiast spychać zawartość po załadowaniu, włóż je do pojemnika o ustalonej minimalnej wysokości.
• Czcionki: użyj font-display: swap lub optional, załaduj wstępnie główny plik czcionek i podziel go. Wybierz czcionkę zastępczą o podobnych parametrach.
• Nie wstawiaj treści powyżej istniejącej treści, chyba że użytkownik ją uruchomił.
• Animuj za pomocą transform i opacity, a nie właściwości zmieniających układ (top, height).

Krok 5. Ulepsz INP: mniej JavaScript w głównym wątku

INP jest najnowszym miernikiem, o którym programiści PHP zapominają, ponieważ serwer nie ma na niego bezpośredniego wpływu. Przyczyny leżą w przeglądarce: długie zadania z dużych pakietów, obciążające skrypty innych firm (analizy, widżety czatu, menedżery tagów) i programy obsługi, które wykonują zbyt dużo pracy synchronicznej.

• Audytuj skrypty stron trzecich. Usuń to, czego nikt nie używa, resztę załaduj z defer lub po pierwszej interakcji.
• Podziel długie zadania. Podziel pracę na fragmenty za pomocą requestIdleCallback, setTimeout lub Scheduler API; przenieś ciężkie obliczenia do Web Worker.
• Trzymaj DOM mały. Tysiące węzłów spowalnia każdą aktualizację.
• Unikaj wymuszonych układów synchronicznych w pętlach (na przemian odczytywanie i zapisywanie właściwości układu).
• Pokaż natychmiastową informację zwrotną (stan wciśnięcia lub pokrętła) przed rozpoczęciem powolnej pracy.

Krok 6. Strzeż tego w procesie wdrażania

Wydajność cicho spada: nowy tag, cięższy bohater, dodatkowe zapytanie na stronie głównej. Dodaj Lighthouse CI lub zaplanowaną kontrolę PageSpeed API dla swoich pięciu najważniejszych szablonów, ustaw budżety ( LCP, całkowity rozmiar JS, wagę obrazu) i ostrzegaj, gdy zostaną przekroczone. Porównaj TTFB przed i po każdym wydaniu; jeśli przeskoczy, przyczyną prawie zawsze jest zapytanie lub pamięć podręczna, która już nie trafia.

Realistyczny porządek pracy

1. Zmierz dane w polach i zidentyfikuj wadliwe grupy adresów URL.
2. Włącz OPcache, przejrzyj ustawienia PHP-FPM, dodaj buforowanie całej strony dla anonimowego ruchu.
3. Napraw obrazy bohaterów: format, rozmiar, priorytet, wymiary.
4. Zarezerwuj miejsce na wszystko, co ładuje się z opóźnieniem.
5. Zredukuj i odrocz JavaScript; usuń nieużywane strony trzecie.
6. Dokonaj ponownego pomiaru po 28 dniach, ponieważ dane terenowe to okno kroczące.

Spodziewaj się, że ulepszenia będą pojawiać się w Search Console stopniowo: raport uwzględnia dane z mniej więcej ostatnich 28 dni, więc przesłana dziś poprawka będzie w pełni widoczna dopiero po około miesiącu.

Jak możemy pomóc

Wykonujemy prace wydajnościowe nad projektami PHP i Laravel w ramach technicznego zaangażowania SEO oraz jako jednorazowe dostrajanie: buforowanie, zapytania, obrazy i poprawki front-endu dostarczane w kodzie. Jeśli chcesz wiedzieć, które z powyższych zmian przydadzą się na Twojej stronie, umów się na konsultację lub analizę serwera. Aby zapoznać się z szerszą listą kontrolną dotyczącą przeszukiwania i indeksowania, przeczytaj naszą listę kontrolną technicznego audytu SEO.