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 afont-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-facedeklarációkat asize-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-rangeré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
crossoriginattribú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-benunicode-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:
- Kizárólag WOFF2 formátum — nincs szükség WOFF1, TTF vagy EOT fallbackre.
- Font subsetting — csak a szükséges unicode tartományok megtartása (magyar oldalhoz: U+0020-017F).
- Variable fonts használata — egyetlen fájl a Regular, Bold és minden köztes súly számára.
- Differenciált
font-display—swapa címsorokhoz,optionala törzsszöveghez. size-adjusta tartalékbetűtípuson — minimális CLS a betűtípuscsere során.- Preload a kritikus betűtípushoz — maximum 1-2 fájl,
crossoriginattribútummal. - Inline
@font-facea<head>-ben — a leggyorsabb felfedezés a böngésző számára. - Self-hosting — GDPR-kompatibilis, jobb teljesítmény, teljes cache kontroll.
- Maximum 2-3 betűtípuscsalád — kevesebb HTTP kérés, konzisztensebb design.
- Hosszú távú gyorsítótárazás —
Cache-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-displaybeá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.