Core Web Vitals för PHP-webbplatser: hur man fixar LCP, INP och CLS

Core Web Vitals för PHP-webbplatser är inte enbart ett front-end-ämne. En långsam PHP-sida kan spendera en sekund på att bara producera HTML, och ingen mängd bildoptimering återställer det. Samtidigt hjälper inte en väldigt snabb server om en hjältebild på 1,5 MB blockerar den största färgen. Här är hur vi närmar oss båda sidor på våra egna PHP-sajter (integrono.com kör PHP-FPM bakom nginx och Cloudflare) och på klientprojekt.

Vad Core Web Vitals mäter

• LCP ( Largest Contentful Paint): när det största synliga elementet (vanligtvis en hjältebild eller ett rubrikblock) renderas. Bra är 2,5 sekunder eller mindre.
• INP ( Interaction to Next Paint): hur snabbt sidan reagerar visuellt efter klick, tryck och knapptryckningar, under hela besöket. Bra är 200 ms eller mindre.
• CLS ( Cumulative Layout Shift): hur mycket innehåll som hoppar runt när du laddar. Bra är 0,1 eller mindre.

Google utvärderar dem på fältdata från riktiga Chrome-användare, vid 75:e percentilen, separat för mobil och dator. Det betyder att en långsam mall eller ett långsamt land kan svika hela gruppen. Labverktyg som Lighthouse är till för felsökning, inte för slutresultatet.

Steg 1. Mät på rätt sätt

1. Öppna rapporten Core Web Vitals i Google Search Console för att se vilka URL-grupper som misslyckas och på vilket mått.
2. Kontrollera PageSpeed Insights för en URL från varje misslyckad grupp. Det översta "fältdata"-blocket är det som räknas; Lighthouse nedan är ett labbtest som förklarar varför.
3. Använd prestandapanelen i Chrome DevTools med CPU 4x nedgång och "Långsam 4G" för att återskapa en typisk mobilupplevelse.
4. För fortlöpande övervakning, samla in riktiga användares data med web-vitals JavaScript-biblioteket och skicka det till din analys.

<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>

Steg 2. Fixa serverns svarstid ( TTFB) först

LCP inkluderar tiden innan den första byten anländer. Om din HTML tar 800 ms att generera har du redan spenderat en tredjedel av budgeten. På PHP-webbplatser är de vanliga spakarna:

• Aktivera OPcache och se till att den är tillräckligt stor för att rymma alla skript. Utan det kompilerar PHP om filer på varje begäran.
• Ställ in PHP-FPM. För få arbetsköförfrågningar, för många avgasminnen. Titta på PHP-FPM-statussidan för "lyssningskö" och "max antal barn nått".
• Cachelagra helsidor för anonyma besökare (nginx fastcgi_cache, en Laravel svarscache eller Cloudflare cacheregler) och cachefragment eller frågeresultat med Redis.
• Åtgärda långsamma frågor. Slå på den långsamma frågeloggen, leta efter N+1-mönster och lägg till index. En sida som kör 120 frågor är långsam oavsett PHP-version.
• Håll PHP aktuell. Nyare PHP-versioner är snabbare och använder mindre minne.

# 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

Ställ in pm.max_children från verkligt minne: dela minnet du kan ge PHP med medelstorleken på en arbetsprocess (kolla med ps). Med validate_timestamps=0 kom ihåg att ladda om PHP-FPM efter varje distribution, annars stannar gammal kod i minnet.

Aktivera HTTP/2 eller HTTP/3, Brotli eller gzip på webbservernivå och långlivade cachehuvuden för statiska filer:

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;

Använd versionerade filnamn eller en ?v=-fråga baserad på filens modifieringstid så att "oföränderlig" aldrig tjänar inaktuella tillgångar.

Steg 3. Fixa LCP elementet

Hitta LCP elementet i PageSpeed Insights eller panelen DevTools Performance. På de flesta innehållssidor är det en hjältebild. Sedan:

• Ladda den inte på latsidan. loading="lazy" på LCP bilden fördröjer det. Använd fetchpriority="high" istället.
• Servera i rätt storlek. En 2400 px bild för en 900 px slot slösar byte. Använd srcset och sizes.
• Använd WebP eller AVIF. Typiska besparingar är 30 till 60 procent mot JPEG vid liknande kvalitet.
• Undvik kedjor. En bild som är inställd via CSS-bakgrund eller injicerad av JavaScript upptäcks sent. Lägg det i HTML-koden som en <img>.
• Föranslut eller värd för tredje parts ursprung som LCP är beroende av (teckensnitt, bild-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">

Det här är mönstret som artikeln täcker på den här bloggen använder: två WebP storlekar, explicita mått och hög prioritet för att hämta hjälten.

Steg 4. Ta bort layoutförskjutningar ( CLS)

• Ställ alltid in width och height (eller aspect-ratio i CSS) på bilder, videor och iframes så att webbläsaren reserverar utrymmet.
• Reservera plats för banners, cookienotiser och annonser. Sätt in dem i en behållare med en fast minimihöjd istället för att trycka ner innehållet efter lastning.
• Teckensnitt: använd font-display: swap eller optional, förladda huvudteckensnittsfilen och underställ den. Välj ett reservteckensnitt med liknande mätvärden.
• Injicera inte innehåll ovanför befintligt innehåll om inte användaren har utlöst det.
• Animera med transform och opacity, inte med egenskaper som ändrar layout (top, height).

Steg 5. Förbättra INP: mindre JavaScript på huvudtråden

INP är det nyaste måttet och det som PHP-utvecklare försummar, eftersom servern inte påverkar det direkt. Orsakerna finns i webbläsaren: långa uppgifter från stora paket, tunga tredjepartsskript (analyser, chattwidgets, tagghanterare) och hanterare som gör för mycket arbete synkront.

• Granska skript från tredje part. Ta bort det som ingen använder, ladda resten med defer eller efter första interaktionen.
• Dela upp långa uppgifter. Dela upp arbetet i bitar med requestIdleCallback, setTimeout eller Scheduler API; flytta tung beräkning till en Web Worker.
• Håll DOM litet. Tusentals noder gör varje uppdatering långsam.
• Undvik påtvingade synkrona layouter i loopar (läs- och skrivlayoutegenskaper omväxlande).
• Visa omedelbar feedback (ett tryckt läge eller spinner) innan du börjar långsamt arbete.

Steg 6. Bevaka den i din distributionsprocess

Prestanda går tyst tillbaka: en ny tagg, en tyngre hjälte, en extra fråga på startsidan. Lägg till Lighthouse CI eller en schemalagd PageSpeed API-kontroll för dina fem viktigaste mallar, ställ in budgetar ( LCP, total JS-storlek, bildvikt) och varna när de överskrids. Jämför TTFB före och efter varje release; om den hoppar är orsaken nästan alltid en fråga eller en cache som inte längre träffar.

En realistisk arbetsordning

1. Mät fältdata och identifiera felaktiga URL-grupper.
2. Aktivera OPcache, granska PHP-FPM-inställningar, lägg till helsidescache för anonym trafik.
3. Fixa hjältebilder: format, storlek, prioritet, dimensioner.
4. Reservera plats för allt som laddas sent.
5. Minska och skjuta upp JavaScript; ta bort oanvända tredje parter.
6. Mät om efter 28 dagar, eftersom fältdata är ett rullande fönster.

Räkna med att förbättringar kommer att visas i Search Console gradvis: rapporten använder ungefär de senaste 28 dagarnas data, så en korrigering som skickas idag är helt synlig först efter ungefär en månad.

Hur vi kan hjälpa till

Vi utför prestandaarbete på PHP- och Laravel-projekt som en del av ett tekniskt SEO-engagemang och som engångsinställning: cachelagring, frågor, bilder och front-end-fixar skickas i kod. Om du vill veta vilka av ändringarna ovan som skulle löna sig på din sida, boka en konsultation eller en serveranalys. För den bredare checklistan kring genomsökning och indexering, läs vår checklista för teknisk SEO-revision.