Core Web Vitals pentru site-urile PHP: cum să remediați LCP, INP și CLS

Core Web Vitals pentru site-urile PHP nu sunt un subiect doar pentru front-end. O pagină PHP lentă poate petrece o secundă doar producând HTML și nicio cantitate de optimizare a imaginii nu recuperează asta. În același timp, un server foarte rapid nu ajută dacă o imagine erou de 1,5 MB blochează cea mai mare vopsea. Iată cum abordăm ambele părți pe propriile noastre site-uri PHP (integrono.com rulează PHP-FPM în spatele nginx și Cloudflare) și pe proiectele clienților.

Ce măsoară Core Web Vitals

• LCP ( Largest Contentful Paint): atunci când este redat cel mai mare element vizibil (de obicei o imagine erou sau un bloc de titlu). Bun este de 2,5 secunde sau mai puțin.
• INP ( Interaction to Next Paint): cât de repede răspunde vizual pagina după clicuri, atingeri și apăsări de taste, pe parcursul întregii vizite. Bun este 200 ms sau mai puțin.
• CLS ( Cumulative Layout Shift): cât de mult conținut sare în timpul încărcării. Bun este 0,1 sau mai puțin.

Google le evaluează pe datele de teren de la utilizatorii Chrome reali, la a 75-a percentila, separat pentru mobil și desktop. Asta înseamnă că un șablon lent sau o țară lentă poate eșua întregul grup. Instrumentele de laborator, cum ar fi Lighthouse, sunt pentru depanare, nu pentru scorul final.

Pasul 1. Măsurați modul corect

1. Deschideți raportul Core Web Vitals în Google Search Console pentru a vedea ce grupuri de adrese URL eșuează și pentru ce valoare.
2. Verificați PageSpeed Insights pentru o adresă URL din fiecare grup nereușit. Blocul de sus „date de câmp” este ceea ce contează; blocul Far de Lighthouse jos este un test de laborator care explică de ce.
3. Utilizați panoul de performanță din Chrome DevTools cu încetinirea procesului de 4x și „4G lentă” pentru a reproduce o experiență mobilă tipică.
4. Pentru monitorizarea continuă, colectați date despre utilizatori reali cu biblioteca JavaScript web-vitals și trimiteți-le la datele dvs. de 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>

Pasul 2. Remediați mai întâi timpul de răspuns al serverului ( TTFB).

LCP include timpul înainte de sosirea primului octet. Dacă HTML-ul dvs. durează 800 ms pentru a se genera, ați cheltuit deja o treime din buget. Pe site-urile PHP, pârghiile obișnuite sunt:

• Activați OPcache și asigurați-vă că este suficient de mare pentru a stoca toate scripturile. Fără el, PHP recompilează fișierele la fiecare cerere.
• Ajustați PHP-FPM. Prea puțini lucrători stau la coadă solicitări, prea multă memorie epuizată. Urmăriți pagina de stare PHP-FPM pentru „listen queue” și „maximum copii atinși”.
• Memorați în cache pagini întregi pentru vizitatorii anonimi (nginx fastcgi_cache, un cache de răspuns Laravel sau reguli de cache Cloudflare) și stocați în cache fragmentele sau rezultatele interogării cu Redis.
• Remediați interogările lente. Porniți jurnalul de interogări lente, căutați modele N+1 și adăugați indecși. O pagină care rulează 120 de interogări este lentă, indiferent de versiunea PHP.
• Păstrați PHP actualizat. Versiunile mai noi PHP sunt mai rapide și folosesc mai puțină memorie.

# 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

Setați pm.max_children din memoria reală: împărțiți memoria pe care o puteți oferi PHP la dimensiunea medie a unui proces de lucru (verificați cu ps). Cu validate_timestamps=0 nu uitați să reîncărcați PHP-FPM după fiecare implementare, altfel vechiul cod rămâne în memorie.

La nivel de server web, activați HTTP/2 sau HTTP/3, Brotli sau gzip și anteturile de stocare în cache de lungă durată pentru fișierele statice:

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;

Folosiți nume de fișiere versionate sau o interogare ?v= bazată pe timpul de modificare a fișierului, astfel încât „imuabil” să nu servească niciodată materialele învechite.

Pasul 3. Fixați elementul LCP

Găsiți elementul LCP în PageSpeed Insights sau în panoul DevTools Performance. Pe majoritatea paginilor de conținut este o imagine de erou. Apoi:

• Nu-l încărca leneș. loading="lazy" pe imaginea LCP îl întârzie. Folosiți în schimb fetchpriority="high".
• Serviți mărimea potrivită. O imagine de 2400 px pentru un slot de 900 px irosește octeți. Utilizați srcset și sizes.
• Utilizați WebP sau AVIF. Economiile tipice sunt de 30 până la 60 la sută față de JPEG la calitate similară.
• Evitați lanțurile. O imagine setată prin fundal CSS sau injectată de JavaScript este descoperită târziu. Puneți-l în HTML ca <img>.
• Preconectează sau auto-găzduiește origini terță parte de care depinde LCP (fonturi, imagine 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">

Acesta este modelul pe care îl acoperă articolul pe acest blog: două dimensiuni WebP, dimensiuni explicite și prioritate ridicată de preluare pentru erou.

Pasul 4. Eliminați schimbările de aspect ( CLS)

• Setați întotdeauna width și height (sau aspect-ratio în CSS) pe imagini, videoclipuri și cadre iframe, astfel încât browserul să rezerve spațiul.
• Rezervați spațiu pentru bannere, notificări privind cookie-urile și reclame. Introduceți-le într-un recipient cu o înălțime minimă fixă în loc să împingeți conținutul în jos după încărcare.
• Fonturi: utilizați font-display: swap sau optional, preîncărcați fișierul font principal și subsetați-l. Alegeți un font alternativ cu valori similare.
• Nu injectați conținut peste conținutul existent decât dacă utilizatorul l-a declanșat.
• Animați cu transform și opacity, nu cu proprietăți care schimbă aspectul (top, height).

Pasul 5. Îmbunătățiți INP: mai puțin JavaScript în firul principal

INP este cea mai nouă metrică și pe care dezvoltatorii PHP o neglijează, deoarece serverul nu o influențează direct. Cauzele sunt în browser: sarcini lungi de la pachete mari, scripturi grele de la terți (analitice, widget-uri de chat, manageri de etichete) și handlere care lucrează prea mult sincron.

• Auditează scripturile de la terți. Eliminați ceea ce nimeni nu folosește, încărcați restul cu defer sau după prima interacțiune.
• Împărțiți sarcini lungi. Împărțiți munca în bucăți cu requestIdleCallback, setTimeout sau Scheduler API; mutați calculele grele la un Web Worker.
• Păstrați DOM-ul mic. Mii de noduri fac fiecare actualizare încetinită.
• Evitați machetele sincrone forțate în bucle (citirea și scrierea proprietăților aspectului alternativ).
• Afișați feedback imediat (o stare apăsată sau un rotitor) înainte de a începe lucrul lent.

Pasul 6. Protejează-l în procesul de implementare

Performanța regresează liniștit: o nouă etichetă, un erou mai greu, o interogare suplimentară pe pagina de pornire. Adăugați Lighthouse CI sau o verificare API PageSpeed programată pentru cele mai importante cinci șabloane ale dvs., setați bugete ( LCP, dimensiunea totală JS, greutatea imaginii) și alertați când acestea sunt depășite. Comparați TTFB înainte și după fiecare lansare; dacă sare, cauza este aproape întotdeauna o interogare sau un cache care nu mai lovește.

O ordine de lucru realistă

1. Măsurați datele din câmp și identificați grupurile de adrese URL nereușite.
2. Activați OPcache, revizuiți setările PHP-FPM, adăugați cache pe toată pagina pentru trafic anonim.
3. Remediați imaginile eroului: format, dimensiune, prioritate, dimensiuni.
4. Rezervă spațiu pentru tot ce se încarcă târziu.
5. Reduceți și amânați JavaScript; eliminarea terților neutilizați.
6. Măsurați din nou după 28 de zile, deoarece datele câmpului sunt o fereastră rulantă.

Așteptați-vă să apară treptat îmbunătățiri în Search Console: raportul utilizează aproximativ ultimele 28 de zile de date, așa că o remediere livrată astăzi este complet vizibilă numai după aproximativ o lună.

Cum putem ajuta

Lucrăm de performanță pe proiecte PHP și Laravel ca parte a unui angajament tehnic SEO și ca reglare unică: cache, interogări, imagini și remedieri front-end livrate în cod. Dacă doriți să știți care dintre modificările de mai sus ar da roade pe site-ul dvs., rezervați o consultație sau o analiză de server. Pentru o listă de verificare mai largă despre accesarea cu crawlere și indexare, citiți lista noastră de verificare tehnică pentru auditul SEO.