Miért lassítják a webfontok a weboldaladat?

Ismerős a jelenség: betöltöd az oldalt, egy pillanatra megjelenik a szöveg egy hétköznapi betűtípussal, aztán átvált a rendes betűre, és közben minden sor újratördel. Vagy még rosszabb: két másodpercig egyáltalán nincs szöveg, csak üres helyek. Mindkettő ugyanarra vezethető vissza, és ritkán derül ki magától, mert a fejlesztői eszközök nem hívják fel rá a figyelmet.

A betűtípus nem dizájn-kérdés, hanem betöltési kérdés. Az oldalad tud úgy is lassúnak látszani, hogy minden kép optimalizált, minden szkript késleltetve tölt, és a szerver 200 ezredmásodperc alatt válaszol. Elég hozzá annyi, hogy a szöveg két másodpercig rossz betűvel fest, aztán újrarajzolódik.

Mi történik, amíg a font tölt?

Amikor a böngésző egyedi betűtípust talál a stíluslapon, le kell töltenie egy fájlt. Két dolgot tehet addig, és ezt a font-display beállítás dönti el.

FOIT, vagyis láthatatlan szöveg. A böngésző megvárja a fontot, és addig nem fest szöveget. Ez az alapértelmezett viselkedés, ha nem adsz meg semmit: a böngésző körülbelül három másodpercig vár. Ilyenkor a látogató üres szövegmezőket lát, pedig az oldal többi része már kész.

FOUT, vagyis a szöveg előbb más betűvel jelenik meg. A böngésző azonnal kifesti a szöveget egy tartalék betűtípussal, majd cserél, amint megjött az igazi. Ezt a font-display: swap kapcsolja be.

@font-face {
  font-family: 'Raleway';
  src: url('/fonts/raleway-latin-400.woff2') format('woff2');
  font-weight: 400;
  font-display: swap;
}

A legtöbb oldalon a swap a helyes választás. Az olvasható szöveg többet ér, mint az, hogy a márkabetű az első képkockától tökéletes legyen. A swapnak viszont ára van, a szöveg cserénél újratördel, és erre a cikk végén még visszatérek.

A felfedezési lánc: mikor kezdi el a böngésző letölteni a fontot?

Itt van a lényeg, és ezt hagyja ki majdnem minden útmutató. A böngésző csak akkor kezdi el letölteni a betűtípust, ha két dolog egyszerre teljesül:

1. van rá @font-face szabály, amit már feldolgozott, és
2. van olyan megfestett szöveg az oldalon, ami hivatkozik rá.

Ebből következik, hogy a fájl mérete gyakran nem is számít. Ha a @font-face szabály egy olyan CSS-fájlban van, ami későn érkezik meg, akkor a font a betöltési sor végére kerül, akármilyen kicsi. Nem a letöltés lassú, hanem a felfedezés késik.

A saját esetem: hat szabály, ami eltűnt

2026 augusztusában a saját oldalamon ez volt a legnagyobb egyetlen tétel, és hónapokig nem vettem észre. A PageSpeed Speed Index mutatója makacsul 4,3 másodpercen állt, miközben a többi szám rendben volt.

Az oldalam úgynevezett critical CSS-t használ: egy eszköz kiszedi a stíluslapból azt a részt, ami a látható képernyőhöz kell, azt beleírja közvetlenül a HTML-be, a maradékot pedig háttérben tölti be. Ez általában komoly gyorsulást ad.

Csak éppen az eszköz (Beasties) alapértelmezésben kidobja az összes @font-face szabályt. A beépített CSS-ben nulla darab volt belőle, miközben a teljes stíluslapban hat.

A következmény pontosan az, ami a felfedezési láncból következik. A HTML fejlécében kézzel preloadolt három woff2 fájl rendben letöltődött, és használhatatlanul ült a gyorsítótárban, mert nem volt szabály, ami hozzákösse őket bármelyik szöveghez. A többi súly pedig, köztük a félkövér, el sem indult, amíg a háttérben töltődő teljes stíluslap meg nem érkezett. A waterfall ezt mutatta:

app.css (async)            287 ms  ->  2026 ms
raleway-latin-700.woff2   2049 ms  ->  2741 ms
ClashDisplay-Medium       2054 ms  ->  2610 ms
raleway-latin-ext-700     2102 ms  ->  2677 ms

A félkövér betűk 2049 ezredmásodpercnél indultak egy olyan oldalon, ami 672 ezredmásodpercnél már kifestette az első szöveget. Két késői újrafestés lett belőle, az utolsó vizuális változás 2754 ezredmásodpercnél. Ezt méri a Speed Index.

A javítás egyetlen konfigurációs sor volt, az eszköznek szólva, hogy a font-szabályokat vigye át. Az eredmény éles mérésen, mobilon:

LCP           3,2 s  ->  2,7 s
Speed Index   4,3 s  ->  3,1 s
a félkövér fontok indulása
             2049 ms ->  466 ms

Semmit nem tömörítettem újra, semmit nem hagytam el. Ugyanaz a hat fájl, ugyanaz a méret, csak a böngésző időben tudott róluk.

A preload önmagában nem elég

Ez a cikk legfontosabb mondata. A <link rel="preload"> annyit csinál, hogy korán letölti a fájlt. Ha nincs hozzá @font-face szabály, a letöltött font nem kapcsolódik semmilyen szöveghez, tehát a sávszélességet elvitte, hasznot nem hozott.

<link rel="preload" href="/fonts/raleway-latin-400.woff2"
      as="font" type="font/woff2" crossorigin>

A crossorigin attribútum kötelező a fontnál, akkor is, ha a fájl a saját szerveredről jön. Nélküle a böngésző kétszer tölti le ugyanazt.

Preloadolni pedig nem mindent kell. A preload elveszi a sávszélességet az LCP elemtől, tehát attól a képtől vagy szövegtől, amire a látogató valójában vár. Nálam hat font van, ebből hármat preloadolok: azokat, amik biztosan látszanak a hajtás felett minden oldalon. A többi megvárja a sorát. Ha az LCP-d amúgy is szoros, érdemes összevetni a kettőt, erről bővebben az LCP javítás cikkben írtam.

Az ő és az ű: miért töltődik le mindig a latin-ext fájl is?

Ez a rész kifejezetten a magyar oldalakról szól, és ritkán kerül szóba, mert az angol nyelvű útmutatók értelemszerűen nem térnek ki rá.

A modern betűkészleteket a szolgáltatók karakterkészletek szerint darabolják fel. A latin darab tartalmazza az angol ábécét és a leggyakoribb ékezeteket, a latin-ext pedig a ritkábbakat. A magyar ő és ű az utóbbiban van.

Vagyis egy magyar nyelvű oldalon a latin-ext fájl gyakorlatilag mindig letöltődik, hiszen alig van olyan bekezdés, amiben ne lenne ő vagy ű. Ha csak a latin darabot preloadoltad, mert egy angol nyelvű útmutatóból másoltad a beállítást, akkor a valódi szövegtörzsedhez tartozó fájl marad kifelejtve.

A gyakorlati tanács: nézd meg a Network fülön, melyik font-fájlok töltődnek le ténylegesen egy magyar oldaladon, és a preloadot azokra igazítsd, ne arra, amit a dokumentáció példája mutat.

Hány betűvastagság kell valójában?

A tipikus beállítás négy-hat súlyt tölt be, mindegyikhez dőlt változattal. Ez könnyen tíz fájl. A legtöbb oldalnak ebből három is elég: egy normál, egy félkövér, és a címsorokhoz egy harmadik.

Nálam a címsorok egységesen egyetlen súlyra kerültek, a dőlt változatokat pedig kidobtam. Ha a designod tényleg igényel egy adott súlyt, hagyd meg, de a „hátha kelleni fog" alapon betöltött súlyok tiszta veszteséget jelentenek. Amit nem használsz megfestett szövegen, azt a böngésző amúgy sem tölti le, viszont a felesleges preload igen.

A swap ára: újratördelés és CLS

A font-display: swap megoldja a láthatatlan szöveg problémáját, de cserébe a szöveg kétszer tördelődik: egyszer a tartalék betűvel, egyszer az igazival. Mivel a két betűtípus más szélességű, a sorok elcsúsznak, a bekezdések magassága változik, és a szöveg alatti tartalom megugrik. Ez az elmozdulás beleszámít a CLS mutatóba, amiről külön írtam a CLS javítás cikkben.

Erre van CSS-megoldás: a tartalék betűtípushoz megadható, hogy méretében és metrikáiban közelítsen az igazihoz.

@font-face {
  font-family: 'Raleway fallback';
  src: local('Arial');
  size-adjust: 96%;
}

Itt viszont figyelj: a size-adjust ma minden nagy böngészőben működik, az ascent-override és a descent-override viszont a Safariban jelen pillanatban sem támogatott. Ezek együtt lennének igazán hasznosak, mert a magasságot is korrigálnák. Ha csak a méretet állítod, a magasságot nem, a Safari-felhasználók akár rosszabbul is járhatnak, mintha semmit nem csináltál volna.

A biztonságos irány ezért az, hogy olyan tartalék betűtípust adsz meg a stíluslapon, ami eleve közel áll az igazihoz, és csak akkor nyúlsz a finomhangoláshoz, ha a mérés valóban elmozdulást mutat.

Google Fonts CDN vagy saját kiszolgálás?

A Google Fonts beillesztése két sor, és ezért használja szinte mindenki. Régen volt egy komoly előnye: ha a látogató már járt másik oldalon ugyanazzal a betűtípussal, a font a gyorsítótárból jött. Ez már nem így van, a böngészők évek óta látogatott oldalanként külön tárolják, tehát ez az érv elesett.

Ami maradt, az inkább hátrány: egy külön kapcsolat egy idegen szerverhez, amit fel kell építeni, mielőtt bármi letöltődne, és a fontok járnak a Google szerverének gyorsítótár-fejléceivel, nem a tieddel. A saját kiszolgálás mellett szól az adatvédelem is, mert a látogató IP-címe nem megy át harmadik félhez. Ez a GDPR miatt Európában külön szempont, német bíróság már marasztalt el oldalt emiatt.

Nálam ezért került minden font a saját /fonts mappába. A művelet fél óra: letöltöd a woff2 fájlokat, beírod a @font-face szabályokat, és kiveszed a Google-linket a fejlécből.

Hogyan ellenőrizd a saját oldaladon?

Ehhez nem kell fejlesztőnek lenned. Nyisd meg az oldalad Chrome-ban, nyomj F12-t, válaszd a Network fület, a szűrősorban kattints a Font gombra, és pipáld be a Disable cache jelölőnégyzetet. Ez utóbbi nélkül a fontok a böngésző gyorsítótárából jönnek, és üres listát fogsz látni. Ezután frissítsd az oldalt.

A táblázatban két dolgot nézz meg. Az egyik, hogy mikor indul a letöltés, nem az, hogy meddig tart. Ha a fontok csak egy-két másodperc után indulnak el, akkor a felfedezési lánccal van baj, nem a fájlmérettel, és a tömörítgetés nem fog segíteni. A másik, hogy hány fájl töltődik le egyáltalán. Ha nyolc-tíz sort látsz, ott van mit elhagyni.

Ha critical CSS-t vagy valamilyen gyorsító bővítményt használsz, van még egy ellenőrzés. Nézd meg az oldal forrását (jobb klikk, oldal forrásának megtekintése), és keress rá a @font-face kifejezésre. Ha a fejlécbe beillesztett stílusok között egyetlen találat sincs, viszont preloadolsz fontokat, akkor pontosan abban a helyzetben vagy, ami nálam is volt.

Egy figyelmeztetés a méréshez

A font-swap okozta elmozdulást a saját gépeden futtatott Lighthouse másképp méri, mint a PageSpeed Insights. Az ok egyszerű: a tartalék betűtípus gépfüggő, tehát a swap máshogy tördeli újra a szöveget nálad, mint a Google mérőszerverén.

Konkrét eset a saját oldalamról: a saját mérésem a főoldalra 0,152-es CLS-t adott, miközben a PageSpeed ugyanarra az oldalra 0-t. Egyik sem hibás, egyszerűen más betűkészlettel dolgoztak. CLS-ügyben a PageSpeed és a valós látogatóktól gyűjtött adat a mérvadó, nem a lokális futtatás. Arról, hogy a pontszámok miért ingadoznak ennyire, a Miért lassú a weboldalad? cikk mérésről szóló szakaszában írtam részletesen.

Összefoglalva

A webfont akkor lassít, ha a böngésző későn tud róla. Ezért a sorrend a következő: előbb nézd meg, mikor indulnak a font-letöltések, és csak utána foglalkozz azzal, mekkorák. Adj minden fontnak font-display: swap beállítást, győződj meg róla, hogy a @font-face szabályok tényleg benne vannak abban a CSS-ben, ami elsőként megérkezik, preloadold azt a két-három fájlt, ami a hajtás felett biztosan látszik, és dobd ki a súlyokat, amiket nem használsz.

A teljes képhez, a méréstől a többi gyakori okig, itt találod az átfogó útmutatót: Miért lassú a weboldalad, és hogyan gyorsítsd fel?