Ugrás a fő tartalomra
Vissza a blogra
TeljesítményOptimalizációSEO

Gyorsabb weboldal: 5 javítás mérhető teljesítményhez

K
Kraftio
·2025. január 8.·Frissítve: 2026. augusztus 11.·4 perc olvasás

A „gyors weboldal” nem egyetlen pontszámot jelent. Más hiba lassítja az első nagy tartalmi elem megjelenését, más akadályozza a kattintásra adott választ, és megint más mozdítja el váratlanul az oldalt. Ezért a javítást mérésből érdemes indítani, nem egy általános optimalizáló bővítményből.

A web.dev Core Web Vitals útmutatója három felhasználói mutatót emel ki: az LCP a betöltést, az INP az interakciók válaszkészségét, a CLS pedig a vizuális stabilitást méri. A jó célérték az oldalletöltések 75. percentilisénél LCP esetén legfeljebb 2,5 másodperc, INP-nél legfeljebb 200 ezredmásodperc, CLS-nél pedig legfeljebb 0,1.

1. Előbb találd meg, mi lassú

Kezdd a PageSpeed Insights valós felhasználói adataival, ha már van elegendő forgalom. A Lighthouse laboradata ezután segít reprodukálni a hibát. A két nézet nem felcserélhető: a labor egy ellenőrzött futás, a terepadat valódi eszközök és hálózatok összesítése.

Ellenőrzéskor jegyezd fel:

  • melyik elem az LCP, például hero kép vagy főcím;
  • melyik interakciónál romlik az INP;
  • mi mozdul el betöltés közben;
  • mobilon vagy asztali gépen jelentkezik-e a gond;
  • egyetlen URL-ről vagy az egész webhelyről van-e szó.

Ebből lesz javítási sorrend. A látványos, de nem kritikus tétel várhat, ha a hero kép közben több megabájtot tölt le.

2. A képet a megjelenési helyéhez igazítsd

Ne csak formátumot válts: a böngészőnek akkora képet adj, amekkorát ténylegesen megjelenít. Használj több méretet srcset és sizes segítségével, rögzíts szélességet és magasságot, és tömöríts a kép tartalmához illően.

<img
  src="hero-1200.avif"
  srcset="hero-640.avif 640w, hero-1200.avif 1200w"
  sizes="(max-width: 768px) 100vw, 60vw"
  width="1200"
  height="800"
  alt="A szolgáltatás működés közben"
/>

A hajtás alatti képeknél hasznos a késleltetett betöltés. A legfontosabb, képernyő tetején lévő kép viszont ne legyen indokolatlanul lazy loadolva, mert ezzel éppen az LCP-t késleltetheted. Az AVIF vagy WebP gyakran hatékony, de a tényleges eredményt a saját képeiden mérd.

3. Csökkentsd a böngészőre háruló JavaScriptet

A nagy kliensoldali csomag nemcsak letöltés: a böngészőnek fel is kell dolgoznia. Ez gyengébb telefonon ronthatja leginkább az INP-t.

Gyakorlati lépések:

  • a csak kattintás után szükséges komponenst dinamikusan töltsd be;
  • a tartalmi részeket ne tedd kliensoldalivá pusztán egy animáció miatt;
  • töröld a nem használt könyvtárat és harmadik fél scriptet;
  • egy teljes animációs csomag helyett mérlegelj CSS-megoldást;
  • elemző és chat scripteket csak valódi üzleti indokkal tarts meg.

Next.js-ben a szerverkomponens jó alap, de nem automatikus garancia. Egy túl magasan elhelyezett "use client" határ sok alkomponenst is a klienscsomagba húzhat.

4. Tedd kiszámíthatóvá a fontokat és az elrendezést

A későn érkező webfont vagy méret nélküli beágyazás elmozdíthatja a tartalmat. Adj helyet előre a képeknek, videóknak, cookie sávnak és dinamikus blokkoknak. Fontnál csak a használt készleteket és karaktertartományokat töltsd be, és ellenőrizd, hogyan viselkedik a tartalék betűtípus.

Ha egy marketingblokk később jelenik meg, ne tolja le azt a gombot, amelyre a látogató éppen kattintana. A CLS javítása sokszor elrendezési fegyelmet, nem új eszközt igényel.

5. Állíts be tartalomhoz illő cache-t

Az ujjlenyomatozott statikus fájlok — például app.abc123.js — hosszú ideig gyorsítótárazhatók, mert változáskor új fájlnevet kapnak. A HTML és az API-válaszok élettartama viszont a tartalom frissességétől függ.

Minden cache-szabálynál válaszold meg:

  1. Mennyi ideig lehet régi ez az adat?
  2. Hogyan érvénytelenítjük tartalomváltozáskor?
  3. Tartalmaz-e személyes vagy felhasználóspecifikus információt?

Privát választ ne tegyél nyilvános CDN-cache-be. A stale-while-revalidate hasznos lehet publikus tartalomnál, de csak akkor, ha az átmenetileg régi válasz elfogadható.

Javítás utáni ellenőrzőlista

  • Ugyanazon az eszköz- és hálózati profilon mértem előtte és utána.
  • Nem csak a pontszámot, hanem az LCP-, INP- és CLS-okot is ellenőriztem.
  • A fő tartalom JavaScript nélkül is benne van a szerver HTML-ben.
  • A képekhez tartozik megfelelő méret és reszponzív változat.
  • A változás nem rontotta el a navigációt, űrlapot vagy analitikát.
  • Élesítés után a valós felhasználói adatot is figyelem.

Mit jelent ez SEO szempontból?

A teljesítmény a felhasználói élmény egyik része; önmagában nem tesz egy oldalt relevánssá. A gyors technikai alap mellé továbbra is olyan tartalom, belső linkelés és keresési szándékhoz illő oldal kell, amely választ ad a látogató kérdésére. A sebességjavítás ezért kockázatot és súrlódást csökkent, nem garantált helyezésnövekedést ad.

Ha a mérés indexelési, renderelési vagy metadata-problémát is jelez, folytasd a Next.js technikai SEO ellenőrzőlistával. Ismétlődő ellenőrzéshez nézd meg, mit jelent nálunk a WordPress- és Next.js-weboldalak karbantartása. Ha a saját oldalad teljesítményéről írnál, küldd el a projekt URL-jét; egy rövid emailből is el tudunk indulni.