Core Web Vitals Nuxt oldalakhoz és webshopokhoz: LCP, INP és CLS javítása

Egy Nuxt oldal elérhet 100 pontot a Lighthouse-ban, és mégis lassúnak érződhet azoknak, akik az üzletedet fizetik. Az ok egyszerű: a Core Web Vitals terepi metrika. Azt írja le, mit tapasztaltak valódi felhasználók valódi eszközökön, a 75. percentilisnél, és ide tartozik a vonaton használt közepes Android telefon is, nem csak a fejlesztői laptopod.

Ez a cikk az a checklist, amit Nuxt oldalakhoz és webshopokhoz használok (Nuxt 4, jelenleg a 4.5-ös ágban). Metrikák szerint épül fel: honnan jön az LCP, az INP és a CLS egy szerveroldalon renderelt Vue-appban, mely Nuxt funkciók kezelik az egyes okokat, és hol nem segít a platform. A végén egy javítás-metrikánként táblázat és egy rövid bevezetési checklist áll. Háttérként: egy TYPO3 B2B webshopot refaktoráltam, és 65%-kal gyorsabb oldalbetöltést értem el (4,6 s-ról 1,6 s-ra), lásd a referenciákat. Az alábbi alapelvek attól függetlenül érvényesek, milyen stack áll az oldal mögött.

Előbb mérj: a terepi adat erősebb a laboradatnál

A három Core Web Vitals és céljaik rögzítettek: LCP (betöltés) 2,5 másodpercen belül, INP (reagálóképesség) legfeljebb 200 milliszekundum, CLS (vizuális stabilitás) legfeljebb 0,1. Egy oldal akkor felel meg, ha mindhármat eléri a 75. percentilisnél, eszköztípusonként. A Google kifejezetten hangsúlyozza, hogy a labormérés nem helyettesíti a terepi mérést, és az olyan eszközök, mint a Lighthouse, amelyek felhasználó nélkül töltenek be egy oldalt, az INP-t egyáltalán nem tudják mérni. A Total Blocking Time csak közelítés.

Ezért nem fogadok el olyan teljesítményjegyet, amely így szól: „a Lighthouse szerint 98”. Két terepi forrást és egy labor-eszközt kérek, mindegyiket arra használva, amiben jó:

A web-vitals könyvtár onLCP, onINP és onCLS függvényeket ad; az attribution build, kb. 1,5 KB-tal nagyobb, diagnosztikai adatot ad hozzá, például hogy melyik elem volt az LCP-jelölt. Küldd az értékeket navigator.sendBeaconnel egy általad kontrollált végpontra, címkézd őket az útvonalsablonnal (termékoldal, kategória, checkout), és végre megválaszolhatod, hogy „melyik oldaltípus bukik”, ahelyett hogy átlagokon vitatkoznál. Ha az is érdekel, hogyan látják ezeket az oldalakat az ügynökök és a crawlerek, a GEO-audit ugyanezen oldalak másik oldalát tárgyalja.

Honnan jön az egyes metrika egy Nuxt oldalbetöltésben

A Nuxt alapértelmezetten univerzálisan renderel: a szerver teljes HTML-t küld, majd a böngésző letölti a JavaScriptet, és hidratálja az oldalt, hogy interaktív legyen. Ez a kétfázisú modell magyarázza a számok nagy részét. Az LCP az első felében dől el (szerverválasz, a legnagyobb elem felfedezése és betöltése), az INP a másodikban (a JavaScript-futtatás és a hydration versenyez a felhasználó első érintéseivel), a CLS pedig az oldal teljes életén végigfut.

A web.dev az LCP-t négy részre bontja: time to first byte, resource load delay, resource load duration és element render delay. Egy jól optimalizált oldalon az irányadó arány nagyjából 40% TTFB, 10% alatti load delay, 40% load duration és 10% alatti render delay. A két késleltetésnek nullához kell közelítenie; az auditjaimban itt bújnak meg a könnyű nyereségek, mert senki sem érzi magáénak.

LCP: a legnagyobb elemet tedd felfedezhetővé és könnyűvé

Az LCP elem általában egy kép (img, videó poster vagy CSS háttérkép) vagy egy nagy szövegblokk. Először derítsd ki, melyik az sablononként, a DevTools-szal vagy az attribution builddel; webshop kategóriaoldalakon gyakran egy banner, termékoldalakon a fő termékfotó. Ezután dolgozd végig a részeket.

Felfedezés. Az LCP erőforrásnak a HTML forrásból felfedezhetőnek kell lennie. A kliensoldali JavaScript által beszúrt hero, a CSS háttérkép vagy a csak hydration után renderelő karusszel a kérést a JavaScript-bundle mögé tolja. A Nuxt Image-dzsel a NuxtImg komponensnek van preload propja, amely link taget tesz a headbe, és elfogad high fetchPriority értéket. Soha ne tegyél loading="lazy"-t az LCP képre: a web.dev ezt nevezi meg a resource load delay közvetlen okaként.

• Megfelelő formátum és méret. A NuxtImg támogatja a format, quality és sizes propokat, így egy forrásfájlból reszponzív, modern változatok (webp vagy avif) lesznek. Minden hero és termékképhez explicit sizes értéket adok; a 2000 pixeles kép egy 400 pixeles helyen a leggyakoribb egyedi pazarlás, amit látok.
• Explicit méretek. Adj meg width és height értéket (vagy képarányt), hogy a böngésző helyet foglaljon. Ez segít az LCP felfedezésében, és ahogy alább látod, ez az első CLS-javítás is.
• Szerver válaszideje. A TTFB az LCP-költségvetés legnagyobb része. Prerendereld vagy cache-eld, amit lehet (lásd a renderelés szakaszt), és a lassú adatlekéréseket tartsd ki a kritikus útvonalból a lazy opcióval vagy a useLazyFetch-csel a nem kritikus adatokhoz.
• Fontok. Ha az LCP elem szöveg, egy későn érkező webfont késlelteti. Előtöltsd a kritikus fontot, és használj illeszkedő metrikájú fallbacket (a CLS-ről szóló következő szakasz).
• Nincs renderelést blokkoló meglepetés. Egy cookie-banner, egy az oldalt elrejtő A/B-teszt snippet vagy egy szinkron külső szkript a headben akkor is késleltetheti a renderelést, ha minden más tökéletes.

A Nuxt 4.5 kísérleti SSR streaminget is hozott, amely azonnal elküldi a HTML-vázat ahelyett, hogy az egész oldalt pufferelné, és közvetlenül a TTFB-t célozza. Kísérleti, botoknál ki van kapcsolva, és minden, ami a renderelés megkezdése után módosítja a választ (fejlécek, átirányítások), nem jut el a klienshez; ezért egyetlen útvonalon próbálnám ki RUM-mal, mielőtt bevezetném. Ugyanezt a streaming-szemléletet AI funkciókra a LLM-funkciók Nuxtban az AI SDK-val cikk mutatja.

INP: hydration, hosszú taskok és amit szállítasz

Az INP a látogatás során minden kattintás, érintés és billentyűleütés késleltetését figyeli, a bemeneti késleltetéstől az eseménykezelőkön át a következő kirajzolt képkockáig. A jó érték legfeljebb 200 ms; 500 ms felett rossz. A First Input Delay-t váltotta, mert az FID csak az első interakciót nézte. A görgetés és a hover nem számít.

Egy szerveroldalon renderelt Vue-appban a minta mindig ugyanaz: az oldal késznek tűnik, a felhasználó koppint, a main thread pedig még hidratál vagy egy külső taget futtat. Ez a hosszú taskok okozta bemeneti késleltetés (minden 50 ms feletti blokkolja a main threadet). Ha ehhez jönnek a lassú eseménykezelők (feldolgozási idő) és a drága újrarenderelések vagy layout-munka (megjelenítési késleltetés), megvan a három hely, ahol az INP elvész.

Amit tennék, a haszon sorrendjében:

• Szállíts kevesebb JavaScriptet. Mielőtt kódhoz nyúlsz, nézd meg a bundle-t egy visualizerrel. Minden nehéz könyvtárat indokolni kell egy oldalon; egy dátumkönyvtárnak vagy rich-text szerkesztőnek egy katalógusoldalon ritkán van indoka.
• Hidratálj késleltetve. A Nuxt támogatja a késleltetett hydrationt Lazy komponenseken: hydrate-on-visible, hydrate-on-idle, hydrate-on-interaction, hydrate-on-media-query, hydrate-after, hydrate-when és hydrate-never. Az értékelések, ajánló karusszelek, láblécek és chat widgetek nem kell, hogy interaktívak legyenek az első megjelenéskor. A megszorítás: egy késleltetve hidratált komponens bármely prop-változása azonnal kiváltja a hydrationt, és csak single-file komponensekkel és template propokkal működik, v-bind spreaddel nem.
• Egyszer renderelj, kevesebb state-et szállíts. A Nuxt a lekért adatokat a payloadba szerializálja. Használd a pick vagy transform opciót a useFetch és useAsyncData hívásokon, hogy csak a template által használt mezők menjenek át; a dokumentáció szerint ezek nem akadályozzák meg az adatok lekérését, de kint tartják őket a payloadból. A payload extraction alapból be van kapcsolva, a stripNeverHydratedData kísérlet pedig a hydrate-never komponensek adatait is kint tartja.
• A statikus maradjon statikus. Azok a komponensek, amelyek a renderelés után sosem változnak (marketingblokkok, láblécek), hydrate-never vagy csak szerveres megoldás jelöltjei, hogy a Vue ne hozzon létre hozzájuk reaktív state-et.
• Bontsd szét a hosszú taskokat. Ahol nehéz munkát kell végezned (nagy terméklista szűrése, parsing), add vissza a main threadet. A web.dev scheduler.yield()-et javasol setTimeout fallbackkel, és hogy nagyjából 50 ms munkánként yieldelj, ne minden elem után.
• Fékezd az eseménykezelőket. Debounce-old a drága bemeneti kezelőket, kerüld a szinkron layout-olvasást ciklusokban, és adj azonnali visszajelzést (lenyomott állapot, spinner), mielőtt a lassú munka elindul, mert az INP a következő kirajzolt képkockánál ér véget.

CLS: foglalj helyet mindennek, ami később érkezik

Az elmozdulás a legmechanikusabb metrika: valami megjelent vagy méretet váltott, és eltolta a már látható tartalmat. Nuxt webshopokban újra és újra ugyanazokat a tetteseket találom:

• Méret nélküli képek és médiák. Mindig add meg a width és height értéket; a böngészők ebből számolják a képarányt. Reszponzív képeknél a CSS aspect-ratio tulajdonság ugyanezt a célt szolgálja.
• Webfontok. Mind a flash of unstyled text, mind a flash of invisible text elmozdíthatja a layoutot. A Nuxt Fonts modul automatikus font-metrika optimalizálást végez (a fontaine és a capsize révén), így a fallback font ugyanannyi helyet foglal, mint a webfont, támogatja az olyan szolgáltatók, mint a Google, helyi letöltését, és a font okozta elmozdulások egész osztályát szinte ingyen megszünteti. A kritikus fontok előtöltése és a font-display: optional a web.dev további javaslatai.
• Késői bannerek. A hydration után beszúrt cookie- és hozzájárulás-sávok, akciócsíkok és „ingyenes szállítás ettől” sávok az egész oldalt lenyomják. Rendereld őket szerveroldalon foglalt helyen, vagy fix pozícióval fedd át az oldalt, ahelyett hogy a folyamba szúrnád.
• Beágyazások és hirdetések. Foglalj dobozt min-height vagy aspect-ratio értékkel, mielőtt egy iframe, térkép vagy videó betöltene. Ugyanez igaz a késleltetve hidratált komponensekre, amelyek interaktívvá válva magasságot váltanak.
• Csak kliensoldali tartalom. Egy .client.vue komponens vagy ClientOnly blokk csak a mount után renderel; megfelelő méretű helyőrző nélkül elmozdítja az oldalt. A fallback slotban renderelj végleges méretű skeletont.
• Animációk. transform-mal animálj top, left vagy height helyett; a kompozitált animációk nem járulnak hozzá a CLS-hez.

Még egy olcsó nyereség: tedd az oldalakat alkalmassá a back/forward cache-re. A visszaállított oldalak azonnal megjelennek, és nem okoznak új layout-elmozdulást, ami olyan webshopokban számít, ahol a felhasználók a listázó és a részletező oldal között ugrálnak.

Külső szkriptek: az adó, amit nem te kontrollálsz

Az analitika, tag managerek, chat widgetek, értékelési badge-ek és A/B-teszt eszközök ugyanazon a main threaden futnak, mint a Vue-appod. Ezek a szokásos okai annak, hogy egy karcsú Nuxt bundle is rossz INP-t ad, és hogy az LCP romlik, miután a marketing „csak még egy taget” ad hozzá. Kezelj minden szkriptet költségvetéses függőségként, gazdával.

A Nuxt Scripts a hivatalos módja ennek a kezelésére. A useScript composable külső szkripteket tölt be SSR-támogatással, késleltetett betöltéssel és típusos API-kkal. Az alapértelmezett onNuxtReady trigger megvárja a hydrationt, majd üresjárati időszakra ütemezi a betöltést. További opciók: kézi betöltés, useScriptTriggerIdleTimeout, useScriptTriggerInteraction (első görgetés, kattintás vagy billentyű), useScriptTriggerElement (amikor egy elem láthatóvá válik) és hozzájáruláson alapuló triggerek. Vannak registry integrációk gyakori szolgáltatásokhoz, például Google Analytics, Google Maps, YouTube és Stripe, valamint facade komponensek, amelyek könnyű helyőrzőt mutatnak, amíg nincs szükség az igazi beágyazásra.

Az én szabályaim: semmi külső a kritikus renderelési útvonalon; chat és videó interakciós vagy láthatósági trigger mögött; analitika hydration és hozzájárulás után; minden szkriptet a kiadás előtt és után az INP-költsége szerint ellenőrizni RUM-ban. Foglalj layout-helyet mindennek, ami vizuális (lásd CLS). Bejelentkezett vásárlókkal működő B2B webshopnál azt is megkérdőjelezném, hogy egy heatmap eszköznek egyáltalán futnia kell-e a checkoutban.

Prerender, SSR vagy ISR: útvonalanként dönts

A renderelési mód szabja meg a TTFB alsó határát, így az LCP felső határát. A Nuxt hibrid renderelése lehetővé teszi, hogy útvonalanként, route rules-szal dönts egyetlen globális beállítás helyett:

B2B webshopnál a felosztás általában egyértelmű: a marketing-, tartalom- és kategóriaoldalak prerenderelve vagy cache-elve vannak, a termékoldalak swr-t vagy isr-t használnak, az ár és a készlet a hydration után kliensoldalon (vagy ügyfelenként az edge-en) töltődik be, a kosár, a checkout és a fiók pedig SSR marad. A csapda a személyre szabás: egyetlen ügyfélspecifikus ár a szerveren renderelt HTML-ben minden cache-elt oldalt kérésenkénti oldallá tesz. Tartsd cache-elhetőnek a vázat, és a személyes részt külön töltsd be, foglalt dobozzal, hogy ne okozzon layout-elmozdulást. Ugyanezeket a webshop-oldalakat kérik le az agentic commerce protokollok és az ügynökök is, így egy gyors, cache-elhető váz kétszeresen térül meg.

Javítás-metrikánként táblázat

A sűrített változat, amit a RUM dashboard mellé érdemes kitűzni:

A webshopok mások: mit ellenőrzök B2B áruházaknál

Egy TYPO3 B2B webshop refaktorálásánál 65%-kal csökkentettem az oldalbetöltési időt, 4,6 s-ról 1,6 s-ra (részletek a referenciákban). A cikk alapelveit ott is ugyanígy alkalmazom: előbb mérek, rövidre fogom a kritikus útvonalat, és minden további kérést és szkriptet olyasminek tekintek, aminek ki kell érdemelnie a helyét.

A webshopok három saját csapdát hoznak. A terméklisták több száz képet és szűrőt renderelnek, ezért az első sor kivételével mindent tölts lazy, és az INP-t a szűrő-interakcióknál mérd, ne csak betöltéskor. Az árak, a készlet és az ügyfélspecifikus katalógusok arra csábítanak, hogy az egész oldalról kikapcsold a cache-t. A shop tag-stackje (analitika, remarketing, értékelések, live chat) pedig negyedévről negyedévre nő. Ha Nuxt storefrontot építesz vagy migrálsz, a Vue és Nuxt szakértelem oldalam megmutatja, mit vállalok.

Bevezetési checklist

1. Állíts be RUM-ot a web-vitals attribution builddel, útvonalsablonnal címkézve, és tartsd mellette az origin CrUX-számait.
2. Válaszd ki forgalom és bukó metrika szerint a három legrosszabb sablont; a többit hagyd, amíg ezek nem felelnek meg.
3. Azonosítsd az LCP elemet minden sablonon, és tedd felfedezhetővé a HTML-ben, előtöltve, megfelelő méretben és soha nem lazy módon.
4. Rendelj renderelési módot minden útvonalhoz route rules-szal; a személyre szabott adatot tartsd ki a cache-elt HTML-ből.
5. Add hozzá a Nuxt Fonts modult, és ellenőrizd a fallback metrikákat; adj width, height vagy aspect-ratio értéket minden képhez és beágyazáshoz.
6. Ellenőrizd a bundle-t és a payloadot; alkalmazz pick vagy transform opciót; a nehéz komponenseket oszd szét a Lazy előtaggal.
7. Adj hydration stratégiát a nem látható és nem interaktív komponensekhez; teszteld újra az első érintéseket CPU-fojtás alatt.
8. Vigyél minden külső szkriptet a Nuxt Scriptsre triggerrel, gazdával és mért INP-költséggel.
9. Tegyél teljesítménykeretet a CI-ba (bundle-méret, Lighthouse az LCP-hez és CLS-hez), és figyeld a RUM-ot néhány hétnyi valódi forgalmon, mielőtt győzelmet hirdetsz.

Források

1. web.dev: Web Vitals
2. web.dev: Largest Contentful Paint (LCP)
3. web.dev: Optimize Largest Contentful Paint
4. web.dev: Interaction to Next Paint (INP)
5. web.dev: Optimize Cumulative Layout Shift
6. web.dev: Optimize long tasks
7. Chrome for Developers: Chrome UX Report (CrUX)
8. Chrome for Developers: CrUX methodology
9. GitHub: GoogleChrome/web-vitals
10. Nuxt docs: Rendering modes
11. Nuxt docs: Components (Lazy prefix, delayed hydration, client components)
12. Nuxt docs: Experimental features (lazyHydration, payloadExtraction)
13. Nuxt docs: Data fetching (pick, transform, lazy)
14. Nuxt blog: Nuxt 4.5
15. GitHub: Nuxt releases
16. Nuxt Image: NuxtImg
17. Nuxt Fonts module
18. Nuxt Scripts: Getting started
19. Nuxt Scripts: Script triggers