Webes betűtípus optimalizálás 2026: WOFF2, font-display, subsetting és CLS minimalizálás

Hogyan csökkentsd a CLS-t és gyorsítsd az LCP-t webes betűtípus optimalizálással? WOFF2, font subsetting, variable fonts, font-display stratégiák és size-adjust technikák — gyakorlati kódpéldákkal, 2026-os best practice-ekkel.

Miért kulcsfontosságú a betűtípus-optimalizálás 2026-ban?

Amikor webes teljesítményoptimalizálásról van szó, a képek és a JavaScript kapják a legtöbb figyelmet — jogosan. De van egy terület, amit a legtöbb fejlesztő rendszeresen átsiklik: a webes betűtípusok. Pedig egy rosszul betöltött font simán tönkreteheti a Core Web Vitals mutatóidat.

Gondolj bele: megnyúlt FCP (First Contentful Paint), emelkedő LCP (Largest Contentful Paint), és a felhasználóid szemét irritáló CLS (Cumulative Layout Shift). Nem éppen ideális.

A 2026-os Google frissítések tovább növelték az oldalélmény-jelek (page experience signals) súlyát a rangsorolásban. Ha két oldal hasonló tartalmi relevanciával rendelkezik, a jobb Core Web Vitals mutatókkal bíró oldal kerül feljebb. A betűtípusok optimalizálása tehát nem csupán technikai finomhangolás — közvetlen SEO és üzleti hatása van.

Szóval, vágjunk bele. Végigmegyünk mindenen: formátumválasztás, font-display stratégiák, subsetting, layout shift megelőzés — kódpéldákkal és gyakorlati tippekkel.

A betűtípus-betöltés hatása a Core Web Vitals mutatókra

Mielőtt belevágunk az optimalizálási technikákba, érdemes megérteni, pontosan hogyan rontják el a betűtípusok az egyes mutatókat.

FCP és LCP: a renderelés blokkolása

A CSS alapértelmezetten render-blocking erőforrás. Ha a @font-face deklaráció külső stíluslapban van, a böngésző nem jeleníti meg a szöveget, amíg a betűtípus le nem töltődik — vagy le nem telik a várakozási idő. Ez közvetlenül késlelteti az FCP-t. És ha a fő tartalmi elem (mondjuk egy hero szekció címsora) egyéni betűtípust használ, az LCP is megérzi.

CLS: az elkerülhetetlen betűtípuscsere

Amikor a böngésző a font-display: swap stratégiát alkalmazza, először a rendszer tartalékbetűtípusát jeleníti meg, majd a webes betűtípus letöltése után cseréli ki. Na de ha a tartalék és az egyéni betűtípus méretei jelentősen eltérnek (sormagasság, betűköz, glífaméret), a csere pillanatában minden megugrik — ez pedig CLS.

A cél egyértelmű: CLS 0,1 alatt, LCP 2,5 másodperc alatt, és az FCP-t a lehető legközelebb vinni az első hálózati round-trip idejéhez.

WOFF2: az egyetlen formátum, amire szükséged van

Őszintén szólva, 2026-ban a WOFF2 az egyedüli betűtípus-formátum, amit érdemes használnod. Pont. A WOFF2 Brotli tömörítést alkalmaz, ami 27-30%-kal jobb tömörítési arányt biztosít a WOFF1-hez képest, és minden modern böngésző támogatja — Chrome, Firefox, Safari, Edge.

Miért felesleges a WOFF1 és a TTF?

Régebben szokás volt több formátumot is felsorolni a @font-face blokkban a kompatibilitás kedvéért. 2026-ban ez szükségtelen és kifejezetten kontraproduktív:

  • A WOFF2 böngészőtámogatottsága meghaladja a 97%-ot globálisan.
  • A több formátum feleslegesen bonyolítja a CSS-t.
  • Egyes böngészők tévedésből több formátumot is letölthetnek, ha a deklaráció nem pontos (igen, ez tényleg megtörténik).
/* 2026-os best practice: csak WOFF2 */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2');
  font-weight: 100 900;
  font-style: normal;
  font-display: swap;
}

Konvertálás WOFF2-re

Ha meglévő TTF vagy OTF betűtípusaid vannak, a fonttools Python csomag pyftsubset eszközével pillanatok alatt konvertálhatsz:

pip install fonttools brotli

# Egyszerű konverzió WOFF2-re
pyftsubset MyFont.ttf \
  --output-file=MyFont.woff2 \
  --flavor=woff2 \
  --layout-features='*'

Font subsetting: a betűtípus méretének akár 90%-os csökkentése

Ez az a pont, ahol a dolgok igazán érdekessé válnak. A legtöbb betűtípus-fájl több ezer glífát tartalmaz — latin, cirill, görög, matematikai szimbólumok, speciális karakterek. Ha az oldalad magyar nyelvű, az összes cirill vagy kínai karakter felesleges ballaszt, ami minden egyes oldalbetöltésnél letöltődik.

A subsetting lényege egyszerű: csak azt tartjuk meg, amire ténylegesen szükségünk van.

Gyakorlati méretcsökkentés

A megtakarítások drámaiak. Egy tipikus példa: a Lato-Black.ttf eredetileg 67,86 KB, míg a latin subset WOFF2 változata mindössze 12,51 KB. Ez több mint 80%-os csökkentés — egyetlen paranccsal.

# Magyar nyelv subset: alap latin + közép-európai kiterjesztés
pyftsubset Inter.ttf \
  --unicodes="U+0020-007F,U+00A0-00FF,U+0100-017F,U+0150,U+0151,U+0170,U+0171" \
  --layout-features='*' \
  --flavor=woff2 \
  --output-file=Inter-hu.woff2

A fenti parancs a Basic Latin (U+0020-007F), a Latin-1 Supplement (U+00A0-00FF) és a Latin Extended-A (U+0100-017F) tartományokat tartja meg, plusz az ő/ű karakterek variánsait. Ez tökéletesen lefedi a magyar nyelv igényeit.

A unicode-range CSS descriptor

A CSS unicode-range descriptorral még finomabb kontrollod van. A böngésző intelligensen csak azt a betűtípus-fájlt tölti le, amelyre az oldalon ténylegesen szükség van:

/* Latin subset — magyar oldalakra optimalizálva */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-latin-ext.woff2') format('woff2');
  font-weight: 100 900;
  font-display: swap;
  unicode-range: U+0000-017F, U+0150-0151, U+0170-0171;
}

/* Cirill subset — csak ha cirill tartalom is van */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-cyrillic.woff2') format('woff2');
  font-weight: 100 900;
  font-display: swap;
  unicode-range: U+0400-04FF;
}

Ha az oldalon nincs cirill szöveg, a böngésző egyáltalán nem tölti le a cirill subset fájlt. Nulla felesleges adat.

Variable fonts: egy fájl, végtelen variáció

A variable fonts (változó betűtípusok) valószínűleg a webes tipográfia legjelentősebb fejlesztése teljesítmény szempontjából. Egyetlen fájlban kódolják az összes design tengelyt — vastagságot, szélességet, dőlést —, szóval nem kell külön fájlokat letölteni a Regular, Bold, Italic és egyéb variánsokhoz.

Méretmegtakarítás a gyakorlatban

A számok magukért beszélnek. A Source Sans Pro variable (WOFF2) mindössze 27 KB, míg a Regular + Bold statikus fájlok együttesen 110 KB-ot tesznek ki. Ez 75%-os megtakarítás — és a variable font emellett minden köztes vastagságot is biztosít (ami designerek szemében aranyat ér).

/* Variable font deklaráció */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/Inter-VariableFont.woff2') format('woff2');
  font-weight: 100 900;  /* a teljes súlytartomány */
  font-style: normal;
  font-display: swap;
}

/* Használat: bármilyen súly elérhető */
h1 { font-weight: 800; }
h2 { font-weight: 650; }
p  { font-weight: 400; }
.emphasis { font-weight: 550; }

Variable fonts + subsetting

A legjobb teljesítményt a variable fonts és a subsetting kombinálásával érheted el. Egy fontos megjegyzés: ha variable fontot használsz, kizárólag WOFF2 formátumra kell támaszkodnod, mivel a variable fontokat nem támogató böngészők a WOFF2-t sem támogatják. Egy csapásra két legyet.

# Variable font subsetting magyar nyelvhez
pyftsubset InterVariable.ttf \
  --unicodes="U+0020-017F,U+0150-0151,U+0170-0171" \
  --layout-features='*' \
  --flavor=woff2 \
  --output-file=InterVariable-hu.woff2

A font-display stratégiák mélyreható összehasonlítása

A font-display CSS descriptor szabályozza, hogyan viselkedjen a böngésző, amíg a betűtípus letöltődik. A helyes választás döntő az FCP, LCP és CLS optimalizálásánál — és tapasztalatom szerint ez az, amit a legtöbben elrontanak.

A négy fő stratégia

  • font-display: swap — Rendkívül rövid blokkolási periódus (kb. 100 ms), végtelen csereperiódus. A szöveg azonnal megjelenik a tartalékbetűtípussal, majd cserélődik. Előny: nincs láthatatlan szöveg (FOIT). Hátrány: layout shift kockázat.
  • font-display: fallback — Rövid blokkolási periódus (~100 ms), korlátozott csereperiódus (~3 mp). Ha a betűtípus nem töltődik le időben, a tartalékbetűtípus marad. Jó kompromisszum, de lassú kapcsolaton a felhasználó sosem látja az egyéni betűtípust.
  • font-display: optional — Rendkívül rövid blokkolási periódus, nincs csereperiódus. A böngésző dönt: ha a betűtípus gyorsan elérhető, használja; ha nem, marad a tartaléknál. Nulla CLS. Lassú kapcsolaton viszont az egyéni betűtípus nem jelenik meg.
  • font-display: block — Hosszú blokkolási periódus (akár 3 mp), végtelen csereperiódus. Késlelteti az FCP-t és potenciálisan az LCP-t. Kerülendő, kivéve ikonbetűtípusoknál.

Melyiket válaszd?

A 2026-os best practice nem egy egységes megoldás, hanem egy differenciált megközelítés. Íme, amit javaslok:

/* Címsor betűtípus — a brand identitás része, swap megfelelő */
@font-face {
  font-family: 'BrandHeading';
  src: url('/fonts/brand-heading.woff2') format('woff2');
  font-display: swap;
}

/* Törzs betűtípus — ha nem töltődik be, a rendszerbetűtípus tökéletes */
@font-face {
  font-family: 'BodyFont';
  src: url('/fonts/body-font.woff2') format('woff2');
  font-display: optional;
}

/* Ikon betűtípus — blokkolás szükséges, különben értelmetlen jelek */
@font-face {
  font-family: 'Icons';
  src: url('/fonts/icons.woff2') format('woff2');
  font-display: block;
}

A CLS minimalizálása: size-adjust és tartalékbetűtípus finomhangolás

Na, itt jön a cikk talán legfontosabb része. A font-display: swap használatakor a legnagyobb kihívás a layout shift. Amikor a rendszer tartalékbetűtípusa (pl. Arial) és az egyéni webes betűtípus (pl. Inter) eltérő metrikákkal rendelkezik, a csere pillanatában az elemek mérete megváltozik — és jön a CLS.

A size-adjust descriptor

A size-adjust a @font-face egy viszonylag új (de már kiválóan támogatott) descriptora, amellyel a tartalékbetűtípus méretét igazíthatod az egyéni betűtípuséhoz. Az eredmény: a csere szinte észrevehetetlen.

/* Tartalékbetűtípus finomhangolása az Interhez */
@font-face {
  font-family: 'Inter Fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

/* Az Inter betűtípus */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2');
  font-weight: 100 900;
  font-display: swap;
}

/* Használat: a fallback a fontstack második eleme */
body {
  font-family: 'Inter', 'Inter Fallback', sans-serif;
}

Automatikus fallback metrikák generálása

A fallback metrikák kézi kiszámítása — hogy őszinte legyek — elég fáradságos munka. Szerencsére vannak modern eszközök, amelyek automatizálják az egészet:

  • Next.js next/font: A Next.js beépített fontkezelője automatikusan generálja a fallback metrikákat, alkalmazza a font-display: swap-ot és self-hostolja a Google Fonts-ot. Nulla CLS a betűtípus-betöltésből — ha Next.js-t használsz, ez a legegyszerűbb út.
  • Fontaine: Framework-agnosztikus eszköz, amely automatikusan kiszámítja és beilleszti a fallback @font-face deklarációkat a size-adjust értékekkel. Vite-hoz és Webpack-hez is van pluginja.
  • Google Fonts CSS API v2: A legújabb API már optimalizált unicode-range részhalmazokat és metrika-adatokat biztosít.

Betűtípusok preloadolása: mikor és hogyan

A <link rel="preload"> használatával korábban kezdheted el a kritikus betűtípusok letöltését, még mielőtt a böngésző a CSS feldolgozása során felfedezné őket. Egyszerű koncepció, de meglepően könnyű elrontani.

<head>
  <!-- Kritikus betűtípus preloadolása -->
  <link rel="preload"
        href="/fonts/inter-var-latin-ext.woff2"
        as="font"
        type="font/woff2"
        crossorigin>

  <!-- Inline @font-face a head-ben a leggyorsabb felfedezésért -->
  <style>
    @font-face {
      font-family: 'Inter';
      src: url('/fonts/inter-var-latin-ext.woff2') format('woff2');
      font-weight: 100 900;
      font-display: swap;
      unicode-range: U+0000-017F;
    }
  </style>
</head>

Fontos figyelmeztetések a preloadnál

  • Csak a kritikus betűtípus(oka)t preloadold — ideális esetben egyet, maximum kettőt. A túl sok preload kontraproduktív, mert más fontos erőforrásoktól veszi el a sávszélességet.
  • A crossorigin attribútum kötelező — betűtípusoknál mindig szükséges, még saját domainről kiszolgálva is. Enélkül a böngésző kétszer tölti le a fájlt. Komolyan, kétszer. Ez egy klasszikus „miért-van-dupla-request" hibaforrás.
  • A preload megkerüli a unicode-range-et — ha a CSS-ben unicode-range-et használsz, a preload figyelmen kívül hagyja azt, és mindenképpen letölti a fájlt. Ezért csak a fő nyelvhez szükséges betűtípus-fájlt preloadolj.

Betűtípusok self-hostolása vs. Google Fonts CDN

Éveken át a Google Fonts CDN volt az alapértelmezett választás — egyszerű, gyors, és a böngészők cache-elhették a fájlokat. De 2026-ban a self-hosting egyértelműen a jobb megoldás.

Miért érdemes self-hostolni?

  • Adatvédelem (GDPR): 2022-ben a német bíróságok kimondták, hogy a Google Fonts CDN-ről történő betöltés a felhasználó IP-címét továbbítja a Google szervereihez, ami GDPR-sértést jelent hozzájárulás nélkül. Azóta több európai ország is hasonló álláspontra helyezkedett. Ez nem elméleti kockázat — a bírságok valósak.
  • Teljesítmény: A külső CDN-hez való kapcsolódás extra DNS-feloldást, TLS handshake-et és kapcsolatfelépítést igényel. A self-hostolt betűtípusok ugyanarról a domainről érkeznek — nincs extra hálózati overhead.
  • Cache kontroll: Saját szerverről kiszolgálva te határozod meg a cache-fejléceket. Hosszú távú max-age értékkel és revalidation tokennel hatékonyan gyorsítótárazhatod a betűtípusokat.
  • HTTP/2 és HTTP/3: Saját domain esetén a betűtípusok ugyanazon a multiplexelt kapcsolaton érkeznek, mint a többi erőforrás — a párhuzamos letöltés sokkal hatékonyabb.

Self-hosting megvalósítása

# 1. Betűtípus letöltése (pl. google-webfonts-helper segítségével)
# 2. Subsetting és WOFF2 konverzió
pyftsubset Inter-VariableFont.ttf \
  --unicodes="U+0020-017F" \
  --flavor=woff2 \
  --output-file=inter-var.woff2

# 3. Cache fejlécek beállítása (nginx példa)
# location ~* \.(woff2)$ {
#   expires 1y;
#   add_header Cache-Control "public, immutable";
# }

A teljes optimalizálási checklist

Tudom, hogy ez sok információ volt egyszerre. Összeszedtem a legfontosabb lépéseket egy egyszerű ellenőrzőlistában:

  1. Kizárólag WOFF2 formátum — nincs szükség WOFF1, TTF vagy EOT fallbackre.
  2. Font subsetting — csak a szükséges unicode tartományok megtartása (magyar oldalhoz: U+0020-017F).
  3. Variable fonts használata — egyetlen fájl a Regular, Bold és minden köztes súly számára.
  4. Differenciált font-displayswap a címsorokhoz, optional a törzsszöveghez.
  5. size-adjust a tartalékbetűtípuson — minimális CLS a betűtípuscsere során.
  6. Preload a kritikus betűtípushoz — maximum 1-2 fájl, crossorigin attribútummal.
  7. Inline @font-face a <head>-ben — a leggyorsabb felfedezés a böngésző számára.
  8. Self-hosting — GDPR-kompatibilis, jobb teljesítmény, teljes cache kontroll.
  9. Maximum 2-3 betűtípuscsalád — kevesebb HTTP kérés, konzisztensebb design.
  10. Hosszú távú gyorsítótárazásCache-Control: public, max-age=31536000, immutable.

Mérés és monitorozás

Optimalizálni optimalizálhatsz, de az eredmény csak mérésekkel bizonyítható. A következő eszközöket érdemes rendszeresen használnod:

  • Lighthouse: Az „Ensure text remains visible during webfont load" audit közvetlenül a font-display beállítást ellenőrzi.
  • Chrome DevTools Network panel: Szűrj „Font" típusra — így azonnal látod a betűtípus-fájlok méretét, letöltési idejét és a cache-elés működését.
  • WebPageTest: A filmstrip nézetben vizuálisan nyomon követheted, mikor jelenik meg a szöveg és mikor történik a betűtípuscsere.
  • CrUX (Chrome User Experience Report): Valós felhasználói adatok a CLS és LCP mutatókról. Ez az, amit a Google a rangsoroláshoz ténylegesen használ, szóval ez a végső mérce.
// Betűtípus-betöltés monitorozása JavaScript-tel
if ('fonts' in document) {
  document.fonts.ready.then(() => {
    console.log('Minden betűtípus betöltődött');

    // Performance API-val mérjük a betöltési időt
    const fontEntries = performance.getEntriesByType('resource')
      .filter(entry => entry.name.includes('.woff2'));

    fontEntries.forEach(entry => {
      console.log(`${entry.name}: ${Math.round(entry.duration)}ms`);
    });
  });
}

// Layout shift figyelése PerformanceObserver-rel
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.sources) {
      entry.sources.forEach(source => {
        if (source.node && source.node.tagName) {
          console.log('Layout shift forrás:', source.node.tagName, entry.value);
        }
      });
    }
  }
});
observer.observe({ type: 'layout-shift', buffered: true });

Gyakran ismételt kérdések (GYIK)

Hogyan befolyásolják a webes betűtípusok a Core Web Vitals pontszámot?

Három mutatóra is hatással lehetnek. Az FCP-t és az LCP-t a render-blocking betöltés késlelteti: ha a betűtípus nem érhető el, a böngésző nem jelenít meg szöveget (FOIT). A CLS-t pedig a betűtípuscsere okozza, amikor a tartalék- és az egyéni betűtípus méretei eltérnek. A font-display: swap + size-adjust kombináció a legjobb megoldás mindkét probléma kezelésére.

Mi a különbség a font-display swap és optional között?

A swap mindig megjeleníti az egyéni betűtípust, amint az letöltődik — akár percekkel az oldal betöltése után is. Ez garantálja a design konzisztenciát, de layout shiftet okozhat. Az optional ezzel szemben a böngészőre bízza a döntést: ha a betűtípus nem töltődik le gyorsan (jellemzően 100 ms-on belül), a tartalékbetűtípus marad — nulla CLS, cserébe lassú kapcsolaton az egyéni betűtípus nem jelenik meg. A legjobb stratégia: swap a márkajegyű címsorokhoz, optional a törzsszöveghez.

Szükséges-e még WOFF és TTF formátumot is megadni?

Röviden: nem. A WOFF2 böngészőtámogatottsága 2026-ban meghaladja a 97%-ot, és a fennmaradó böngészők piaci részesedése elhanyagolható. A több formátum csak bonyolítja a CSS-t és növeli a karbantartási terheket. Használj kizárólag WOFF2-t.

Mekkora teljesítményjavulás érhető el font subsettinggel?

Jellemzően 75-95%-os fájlméret-csökkentés. Egy tipikus betűtípus-fájl 200-500 KB lehet minden glíffal, míg egy latin + közép-európai subset WOFF2-ben általában 10-25 KB. Ez főleg mobil hálózaton jelent hatalmas különbséget, és közvetlenül javítja az FCP és LCP mutatókat.

Hogyan hosztoljam a betűtípusokat GDPR-kompatibilisen?

A legegyszerűbb és legbiztonságosabb megoldás a self-hosting: töltsd le a betűtípus-fájlokat, optimalizáld (subset + WOFF2), és szolgáld ki a saját szerveredről. Így a felhasználó IP-címe nem kerül harmadik félhez. Ha mégis Google Fonts-ot használsz CDN-ről, a GDPR értelmében előzetes felhasználói hozzájárulás szükséges — amit a legtöbb CMP (consent management platform) tud kezelni, de ez késlelteti a betűtípus letöltését.

A Szerzőről Editorial Team

Our team of expert writers and editors.