Core Web Vitals PHP-webhelyekhez: LCP, INP és CLS javítása

A PHP-webhelyek Core Web Vitals nem csak a front-end témakörök. Egy lassú PHP-oldal egy másodpercet is eltölthet HTML-készítéssel, és ezt semmilyen képoptimalizálás nem állítja helyre. Ugyanakkor egy nagyon gyors szerver sem segít, ha egy 1,5 MB-os hero image blokkolja a legnagyobb festéket. Így közelítjük meg mindkét oldalt saját PHP-webhelyeinken (az integrono.com az nginx és Cloudflare mögött PHP-FPM futtat) és ügyfélprojekteken.

Mit mér Core Web Vitals

• LCP ( Largest Contentful Paint): amikor a legnagyobb látható elem (általában egy hőskép vagy egy címsor) kerül megjelenítésre. A jó 2,5 másodperc vagy kevesebb.
• INP ( Interaction to Next Paint): milyen gyorsan reagál az oldal vizuálisan kattintások, koppintások és billentyűlenyomások után, a teljes látogatás során. Jó, ha 200 ms vagy kevesebb.
• CLS ( Cumulative Layout Shift): mennyi tartalom ugrik be betöltés közben. A jó érték 0,1 vagy kevesebb.

A Google valódi Chrome-felhasználóktól származó helyszíni adatok alapján értékeli ki őket, a 75. percentilisben, külön mobil és asztali számítógép esetén. Ez azt jelenti, hogy egy lassú sablon vagy egy lassú ország tönkreteheti az egész csoportot. A laboratóriumi eszközök, mint például Lighthouse, a hibakeresésre szolgálnak, nem a végső pontszámra.

1. lépés Mérje meg a helyes utat

1. Nyissa meg a Core Web Vitals jelentést Google Search Console ban, és nézze meg, hogy mely URL-csoportok nem működnek, és melyik mutató alapján.
2. Ellenőrizze PageSpeed Insights egy URL-t minden egyes hibás csoportból. A felső "mezőadatok" blokk számít; az alábbi Lighthouse blokk egy laboratóriumi teszt, amely megmagyarázza, miért.
3. Használja a Chrome DevTools Performance paneljét a CPU 4-szeres lassításával és a „Lassú 4G” funkcióval a tipikus mobilélmény reprodukálásához.
4. A folyamatos megfigyeléshez gyűjtse össze a valós felhasználói adatokat a web-vitals JavaScript-könyvtárral, és küldje el az elemzési rendszernek.

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

2. lépés: Először javítsa ki a szerver válaszidejét ( TTFB).

LCP tartalmazza az első bájt érkezése előtti időt. Ha 800 ms-ig tart a HTML létrehozása, akkor már elköltötte a költségvetés egyharmadát. A PHP oldalakon a szokásos karok a következők:

• Engedélyezze OPcache, és ellenőrizze, hogy elég nagy-e az összes szkript tárolására. Enélkül a PHP minden kérésre újrafordítja a fájlokat.
• PHP-FPM hangolása. Túl kevés dolgozói sorkérelem, túl sok memóriakimerülés. Nézze meg a PHP-FPM állapotoldalát a "hallgatási sor" és a "max. gyermekek elérése" tekintetében.
• Gyorsítótárazza a teljes oldalakat a névtelen látogatók számára (nginx fastcgi_cache, egy Laravel válaszgyorsítótár vagy Cloudflare gyorsítótár szabályai), valamint gyorsítótárazza a töredékeket vagy lekérdezheti az eredményeket Redis segítségével.
• Lassú lekérdezések javítása. Kapcsolja be a lassú lekérdezési naplót, keressen N+1 mintát, és adjon hozzá indexeket. A 120 lekérdezést futtató oldal a PHP verziójától függetlenül lassú.
• Tartsa naprakészen a PHP-t. Az újabb PHP-verziók gyorsabbak és kevesebb memóriát használnak.

# 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

pm.max_children beállítása valós memóriából: ossza el a PHP-nek megadható memóriát egy munkafolyamat átlagos méretével (ellenőrizze ps-vel). validate_timestamps=0 esetén ne felejtse el újratölteni PHP-FPM minden telepítés után, különben a régi kód a memóriában marad.

Webszerver szinten engedélyezze a HTTP/2-t vagy a HTTP/3-at, Brotli vagy a gzip-et, valamint a statikus fájlok hosszú élettartamú gyorsítótárazási fejléceit:

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;

Használjon verziószámú fájlneveket vagy ?v= lekérdezést a fájl módosítási idejének alapján, hogy az „inmutable” soha ne szolgáljon ki elavult eszközöket.

3. lépés: Rögzítse az LCP elemet

Keresse meg az LCP elemet PageSpeed Insights vagy a DevTools Performance panelen. A legtöbb tartalmi oldalon ez egy hőskép. Majd:

• Ne lusta – töltse be. loading="lazy" az LCP képen késlelteti. Használja helyette fetchpriority="high".
• Megfelelő méretű tálaljuk. Egy 2400 képpontos kép egy 900 képpontos helyhez bájtokat pazarol. Használja srcset és sizes.
• Használjon WebP vagy AVIF. A tipikus megtakarítás 30-60 százalék a JPEG-hez hasonló minőség mellett.
• Kerülje a láncokat. A CSS-háttérrel beállított vagy JavaScript által beinjektált képet későn fedeznek fel. Helyezze be a HTML-be <img>-ként.
• Harmadik féltől származó források előcsatlakoztatása vagy saját üzemeltetése, amelyektől az LCP függ (betűtípusok, kép-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">

A cikkben ezt a mintát használja a blogon: két WebP méret, explicit méretek és magas lekérési prioritás a hős számára.

4. lépés: Távolítsa el az elrendezéseltolásokat ( CLS)

• Mindig állítsa be width és height (vagy a CSS-ben aspect-ratio) a képeken, videókon és iframe-eken, hogy a böngésző lefoglalja a helyet.
• Foglaljon helyet bannereknek, sütikkel kapcsolatos értesítéseknek és hirdetéseknek. Helyezze be őket egy rögzített minimális magasságú tartályba, ahelyett, hogy betöltés után lenyomná a tartalmat.
• Betűtípusok: használd font-display: swap vagy optional, töltse be előre a fő betűtípusfájlt, és állítsa be azt. Válasszon egy tartalék betűtípust hasonló mutatókkal.
• Ne szúrjon be tartalmat a meglévő tartalom fölé, hacsak nem a felhasználó váltotta ki.
• Animáljon transform és opacity, nem pedig olyan tulajdonságokkal, amelyek megváltoztatják az elrendezést (top, height).

5. lépés: INP javítása: kevesebb JavaScript a főszálon

INP a legújabb mérőszám, amelyet a PHP fejlesztők figyelmen kívül hagynak, mivel a szerver nem befolyásolja közvetlenül. Az okok a böngészőben keresendők: hosszú feladatok nagy csomagokból, nehéz harmadik féltől származó szkriptek (analitika, csevegési widgetek, címkekezelők) és kezelők, amelyek túl sok munkát végeznek szinkronban.

• Harmadik féltől származó szkriptek ellenőrzése. Távolítsa el, amit senki sem használ, a többit defer vagy az első interakció után töltse be.
• Ossza meg a hosszú feladatokat. A munkát requestIdleCallback, setTimeout vagy a Scheduler API segítségével darabokra bonthatja ; nehéz számítások áthelyezése egy Web Worker.
• A DOM legyen kicsi. A csomópontok ezrei lassítanak minden frissítést.
• Kerülje a kényszerített szinkron elrendezéseket ciklusokban (az elrendezés tulajdonságainak felváltva olvasása és írása).
• Mutasson azonnali visszajelzést (lenyomott állapot vagy fonó) a lassú munka megkezdése előtt.

6. lépés: Őrizze meg a telepítési folyamat során

A teljesítmény csendesen visszafejlődik: új címke, súlyosabb hős, extra lekérdezés a kezdőlapon. Adja hozzá Lighthouse CI-t vagy egy ütemezett PageSpeed API-t, ellenőrizze az öt legfontosabb sablont, állítsa be a költségkereteket ( LCP, teljes JS-méret, képsúly), és értesítsen, ha túllépik azokat. Hasonlítsa össze TTFB minden kiadás előtt és után; ha ugrik, az ok szinte mindig egy lekérdezés vagy egy gyorsítótár, amely már nem találja.

Reális munkarend

1. Mérje meg a mezőadatokat, és azonosítsa a hibás URL-csoportokat.
2. Engedélyezze OPcache, tekintse át PHP-FPM beállításait, adjon hozzá teljes oldalas gyorsítótárat az anonim forgalomhoz.
3. Hősképek javítása: formátum, méret, prioritás, méretek.
4. Foglaljon helyet mindennek, ami későn tölt be.
5. A JavaScript csökkentése és elhalasztása; távolítsa el a fel nem használt harmadik feleket.
6. Mérje meg újra 28 nap elteltével, mert a terepi adatok gördülő ablakok.

Várható, hogy a fejlesztések fokozatosan jelenjenek meg Search Console-ban: a jelentés nagyjából az elmúlt 28 nap adatait használja fel, így a ma kiküldött javítás csak körülbelül egy hónap múlva válik láthatóvá.

Hogyan segíthetünk

PHP és Laravel projekteken végzünk teljesítménymunkát technikai SEO megbízás részeként és egyszeri tuningként: gyorsítótárazás, lekérdezések, képek és előtér-javítások kódban. Ha szeretné tudni, hogy a fenti változtatások közül melyik lenne kifizetődő az Ön webhelyén, foglaljon konzultációt vagy szerverelemzést. A feltérképezéssel és indexeléssel kapcsolatos szélesebb ellenőrzőlistához olvassa el technikai SEO audit ellenőrzőlistánkat.