A legtöbb magyar kkv-oldalon a lassúság okát a képeknél keresik, pedig a betűtípus sokkal alattomosabb. A nagy kép legalább látszik, hogy nagy. A betűfájl nem. Egy igényes arculatú oldal kényelmesen elvisz hat-nyolc betűfájlt úgy, hogy senkinek nem tűnik fel, és közben pont a legfontosabb dolgot késlelteti: hogy megjelenjen a szöveg. Ez a cikk végigveszi, mi történik betöltés közben, mit lehet állítani rajta, és hogyan méred meg, hogy tényleg jobb lett. A megállapítások mellett jelölöm, mi hivatalosan igazolt (specifikáció vagy gyártói dokumentáció), mi saját tapasztalat (ügyfélmunkából) és mi szakmai feltételezés.
Mi történik a szöveggel, amíg a betűtípus letöltődik?
Rövid válasz: a böngésző vagy elrejti a szöveget, amíg megérkezik a betűfájl (ez a FOIT), vagy azonnal kiírja rendszerbetűvel és később lecseréli (ez a FOUT). Harmadik út nincs, csak az a kérdés, melyiket választod tudatosan.
Tovább a témában: CLS-hibák felkutatása és javítása
A FOIT a Flash of Invisible Text, vagyis a láthatatlan szöveg villanása: a hely megvan, a doboz megvan, de a betűk hiányoznak. A FOUT a Flash of Unstyled Text: a szöveg olvasható rendszerbetűvel, aztán egyszer csak átvált a márkabetűre. Hivatalosan igazolt: a CSS Fonts Module Level 4 három szakaszt ír le a betű betöltésére. Az első a blokkolási szakasz, amikor a szöveg láthatatlan. A második a csereszakasz, amikor tartalék betűvel látszik, de még kicserélhető. A harmadik a hibaszakasz, amikor a böngésző lemond a letöltésről és marad a tartalék.
Saját tapasztalat: a mai motorok alapértelmezésben nagyjából három másodperc blokkolást engednek meg, ami jó kapcsolaton észrevehetetlen, gyenge mobilneten viszont pontosan az a három másodperc, amikor a látogató visszalép. A hazai kkv-oldalak forgalmának nagy része mobilról jön, ezért ezt nem érdemes a böngészőre bízni.
Melyik font-display értéket érdemes választani?
Rövid válasz: a legtöbb oldalon a swap a helyes alapértelmezés, ha mellé rendes tartalék betűt is beállítasz. Ha nem állítasz be, az optional biztonságosabb.
auto: a böngészőre bízod. Ez gyakorlatilag ablockviselkedés, tehát rejtett szöveg.block: rövid blokkolási szakasz, majd korlátlan csereszakasz. Klasszikus FOIT. Csak ikonbetűnél van értelme, ahol a tartalék karakter értelmetlen szimbólum lenne.swap: gyakorlatilag nincs blokkolás, a szöveg azonnal látszik tartalék betűvel, és amint megjön a fájl, kicserélődik. Az olvasó előbb olvashat, cserébe elrendezés-elmozdulást kockáztatsz.fallback: nagyon rövid blokkolás, majd rövid csereszakasz. Ha a betű késik, ezen az oldalletöltésen marad a tartalék, de a fájl bekerül a gyorsítótárba, így a következő oldalon már jó.optional: rövid blokkolás, csereszakasz gyakorlatilag nincs. Ha nem ér oda időben, a böngésző ezen a betöltésen egyszerűen nem használja. Ez az egyetlen érték, amely a betűcseréből eredő elmozdulást teljesen kizárja.
Szakmai feltételezés: ha a márkabetű valóban hordozza az arculatot (például egyedi licencelt fejlécbetű), a swap plusz hangolt tartalék a jobb üzlet. Ha csak egy sokadik ingyenes talpatlan betűről van szó, amit a látogató úgysem különböztet meg, az optional gyakorlatilag ingyen sebesség.
Miért mozdul el az elrendezés a betűcserétől?
Rövid válasz: mert a tartalék betű és a márkabetű nem egyforma széles és nem egyforma magas, így a szöveg más helyen tördelődik, és a doboz magassága megváltozik.
Vegyünk egy tipikus esetet. A hero szekció főcíme rendszerbetűvel három sorba tördelődik, a márkabetű megérkezése után kettőbe. A különbség egyetlen sormagasság, mondjuk ötven képpont, csakhogy alatta ott van a bevezető, a gomb és minden más szekció, tehát az egész oldal feljebb ugrik. Ezt méri a Cumulative Layout Shift, és hivatalosan igazolt, hogy ez a Core Web Vitals egyik mutatója. A látogató szempontjából ennél is rosszabb, hogy pont akkor rándul meg az oldal, amikor a hüvelykujja már a gomb fölött van.
Saját tapasztalat: a betűből eredő elmozdulás a legnehezebben azonosítható CLS-forrás, mert gyors gépen, meleg gyorsítótárral soha nem reprodukálódik. Csak lassított hálózaton és üres gyorsítótárral jön elő.
Hány betűvastagságra van valóban szükséged?
Rövid válasz: kettő vagy három, ennél többre a magyar kkv-oldalak elsöprő többségének nincs szüksége.
A gyakorlatban egy normál törzsszöveg-vastagság (400) és egy kiemelés (700) mindent lefed, amit a szöveg tartalmilag igényel. Ha a fejléc külön karaktert kap, jöhet egy harmadik (600). Innentől minden további letöltendő fájl. Fontos, amit sokan kihagynak a számolásból: minden vastagság és minden dőlt változat külön fájl. Négy vastagság dőlttel együtt nyolc fájl. Ha ezt megszorzod a latin és latin-ext részhalmazzal, tizenhat kérés.
Nyiss egy táblázatot és írd össze, melyik vastagságot használja ténylegesen a CSS-ed. Amelyikre nincs szabály, az felesleges. Saját tapasztalat: weboldal-átvételeknél rendszeresen találunk hat-nyolc betöltött vastagságot, amiből az oldal ténylegesen kettőt használ, mert a témabeállító felület alapból mindent behúz. Ez egyetlen legördülő menü átállításával megszűnik.
A variábilis betű (variable font) alternatíva: egyetlen fájl, amely folyamatosan állítható vastagságokat ad. Cserébe nagyobb, mint egy statikus vágat. Szakmai feltételezés: ha háromnál több vastagságra tényleg szükség van, a variábilis változat jó eséllyel kisebb összméretet ad, három alatt viszont általában a statikus vágatok nyernek.
Hogyan válts Google Fonts CDN-ről helyben tárolt WOFF2-re?
Rövid válasz: letöltöd a szükséges WOFF2 fájlokat, felteszed a saját domainedre hosszú gyorsítótár-beállítással, megírod a saját @font-face szabályaidat, és kiirtod az összes külső hivatkozást.
Ez sebességben azért nyer, mert megszűnik egy külső domain DNS-feloldása és TLS-kézfogása, ráadásul a betűfájl ugyanazon a kapcsolaton érkezik, mint a HTML. Adatvédelmi oldalról is számít: a CDN-es beágyazásnál a látogató böngészője kérést küld egy külső szolgáltatóhoz, amely látja az IP-címét. Hivatalosan igazolt: a müncheni tartományi bíróság 2022-ben (3 O 17493/20 ügyszám) egy konkrét ügyben megállapította, hogy a Google Fonts CDN-es beágyazása hozzájárulás nélkül jogsértő volt. Szakmai feltételezés: ez egyedi német ítélet, nem magyar hatósági gyakorlat, de a mögötte lévő logika (hozzájárulás nélküli adattovábbítás) a hazai adatvédelmi keretben is védhető érv, ezért a helyi tárolás a kockázatmentesebb út. Jogi minősítést ez a cikk nem ad.
A lépéssor:
- Nyisd meg a fejlesztői eszközök hálózati fülét, szűrj a betűfájlokra, és írd fel, mi töltődik le ténylegesen.
- Szerezd be a szükséges vágatokat WOFF2 formátumban, latin és latin-ext részhalmazzal. WOFF2-n kívül másra ma már nincs szükség.
- Tedd a fájlokat a saját kiszolgálóra, például
/fonts/mappába, és állíts be hosszú gyorsítótárat:Cache-Control: public, max-age=31536000, immutable. - Írd meg a szabályt:
@font-face { font-family: 'Sajat'; src: url('/fonts/sajat-400.woff2') format('woff2'); font-weight: 400; font-style: normal; font-display: swap; } - Töröld az összes
fonts.googleapis.comésfonts.gstatic.comhivatkozást. WordPressen ez általában több helyen van: a téma beállításai, az oldalépítő tipográfiája, egy ikonkészlet és néha egy bővítmény is behúzza. - Frissítsd üres gyorsítótárral, és ellenőrizd a hálózati fülön, hogy egyetlen Google-domain sem szerepel a listában.
Melyik betűfájlt töltsd elő, és melyiket ne?
Rövid válasz: pontosan azt az egyet, amelyik a képernyő tetején elsőként látszó szöveget rajzolja, jellemzően a törzsszöveg normál vastagságát vagy a főcím vágatát.
A betűfájl felfedezése láncban történik: a böngésző letölti a HTML-t, abból a CSS-t, a CSS-t értelmezve derül ki, hogy kell egy betű, és csak akkor indul a letöltés. A preload ezt a láncot rövidíti le:
<link rel='preload' href='/fonts/sajat-400.woff2' as='font' type='font/woff2' crossorigin>
A crossorigin attribútum akkor is kötelező, ha a fájl a saját domainen van. Hivatalosan igazolt: a betűk letöltése névtelen CORS-módban történik, és enélkül a böngésző kétszer tölti le ugyanazt a fájlt. Ez az egyik leggyakoribb hiba.
Az előtöltés nem ingyenes: elveszi a sávszélességet a hero képtől és a CSS-től. Egy fájl, kivételes esetben kettő. Ha négy betűfájlt töltesz elő, valószínűleg lassítottál.
Hogyan hangold a tartalék betűt, hogy ne ugorjon a szöveg?
Rövid válasz: készíts egy külön @font-face szabályt, amely egy rendszerbetűt csomagol be, és méret-leírókkal közelíti a márkabetűd arányait.
Hivatalosan igazolt: a CSS Fonts Module Level 5 négy leírót ad erre: size-adjust, ascent-override, descent-override és line-gap-override. A minta így néz ki:
@font-face { font-family: 'Sajat Tartalek'; src: local('Arial'); size-adjust: 107%; ascent-override: 90%; descent-override: 22%; line-gap-override: 0%; }
Utána a családot így add meg: body { font-family: 'Sajat', 'Sajat Tartalek', system-ui, sans-serif; }
A százalékokat nem kell fejből tudni, létező kalkulátorok kiszámolják a két betű metrikáiból. A cél nem a tökéletes egyezés, hanem hogy a sortörések ugyanoda essenek. Saját tapasztalat: a betűből eredő elmozdulás nagy része már attól eltűnik, hogy a size-adjust értéket egy-két százalékos lépésekben addig állítod, amíg a főcím sortörése nem változik meg a cserekor.
Miért tűnik el az ő és az ű a részhalmazolásnál?
Rövid válasz: mert az ő, Ő, ű és Ű nem a latin, hanem a latin-ext készletben van, így aki csak latin részhalmazt tölt be, pont ezt a négy karaktert veszíti el.
Az á, é, í, ó, ú, ö és ü karakterek a Latin-1 kiegészítő tartományban vannak, ezért a szokásos latin részhalmaz tartalmazza őket. A kettős hosszú ékezetes betűk viszont a Latin Extended-A blokkba esnek (U+0150, U+0151, U+0170, U+0171), amit csak a latin-ext hoz magával. Az eredmény jellegzetes: a szöveg nagy része a márkabetűvel jelenik meg, de minden ő és ű helyén egy másik betűtípus karaktere ül, más vastagsággal és más szélességgel. Ez a magyar szövegben nem ritka kivétel, hanem szinte minden bekezdésben előfordul.
Ha saját részhalmazt gyártasz betűvágó eszközzel, add meg kézzel a unicode-range értékben a U+0100-017F tartományt, vagy legalább a négy karaktert. Az ellenőrzés viszont sokkal egyszerűbb: írd be tesztszövegnek az Árvíztűrő tükörfúrógép kifejezést, és nagyítsd fel. Ha bármelyik betű kilóg a sorból, hiányos a részhalmazod.
Hogyan méred meg, mit nyertél?
Rövid válasz: ugyanazon az URL-en, ugyanolyan körülmények között mérsz előtte és utána, laborban azonnal, terepen néhány hét múlva.
- Kiindulás rögzítése. Futtass Lighthouse mérést mobil beállítással, háromszor, és a mediánt jegyezd fel. Írd le a LCP, CLS és TBT értéket, valamint a betűfájlok számát és összméretét a hálózati fülről, kikapcsolt gyorsítótárral.
- Egy változtatás egyszerre. Előbb a vastagságok ritkítása, mérés. Aztán a helyi tárolás, mérés. Aztán a font-display és a tartalék hangolása, mérés. Ha egyszerre nyúlsz mindenhez, nem tudod, mi hatott.
- Nézd meg filmszalagon. A Performance panel vagy a WebPageTest képkockái megmutatják, hányadik másodpercben jelenik meg először olvasható szöveg. Ez a szám mond többet, mint a pontszám.
- Terepadat. A Search Console Core Web Vitals jelentése és a valós felhasználói adat huszonnyolc napos ablakkal dolgozik, tehát a tényleges hatás csak hetekkel később látszik. Ezt előre kommunikáld, különben a második napon jön a kérdés, hogy miért nem javult.
Saját tapasztalat: tipikus kkv-oldalon hat-nyolc betűfájl és nagyjából 150-300 kB betűforgalom szokott lecsökkenni két-három fájlra és 60-90 kB-ra. Ez mobilon érzékelhető javulást hoz a szöveg megjelenésének idejében, de konkrét számot vagy keresési helyezést senki nem ígérhet, mert a mérés az adott oldal, sablon és kiszolgáló függvénye.
Mi legyen az ellenőrzőlistán?
- Legfeljebb két-három betűvastagság, dőlt csak akkor, ha tényleg használod.
- Minden betűfájl WOFF2, saját domainről, hosszú gyorsítótár-fejléccel.
- Nulla hivatkozás külső betű-CDN-re a teljes oldalon, beleértve az oldalépítőt és az ikonkészletet.
- Minden @font-face szabályban ott a
font-display, tudatosan választott értékkel. - A részhalmaz tartalmazza a latin-ext tartományt, az Árvíztűrő tükörfúrógép teszt hibátlan.
- Pontosan egy (legfeljebb két) előtöltött betűfájl,
crossoriginattribútummal. - Hangolt tartalék betűcsalád
size-adjustés felülíró leírókkal. - Üres gyorsítótárral, lassított hálózaton nem ugrik a főcím a betűcserekor.
- Az előtte-utána mérés adatai dokumentálva, dátummal.
A betűtípus azért marad ilyen sokáig észrevétlen adósság, mert a hibája nem hibaüzenet, hanem egy fél másodperc kellemetlenség, amit a tulajdonos a saját gépén, meleg gyorsítótárral soha nem tapasztal meg. Az itt leírt lépések többsége egyszeri munka, és utána évekig dolgozik.
Források és további olvasnivalók
- W3C CSS Fonts Module Level 4 és Level 5 specifikáció
- MDN Web Docs: @font-face, font-display, size-adjust, ascent-override
- web.dev: Best practices for fonts, Optimize WebFont loading and rendering
- Google Search Central: Core Web Vitals és oldalélmény dokumentáció
- Chrome for Developers: Chrome DevTools Performance és Network dokumentáció
- The Unicode Standard: Latin-1 Supplement és Latin Extended-A kódtáblák
- Landgericht München I, 3 O 17493/20 (2022) ítélet
- Nemzeti Adatvédelmi és Információszabadság Hatóság tájékoztatói a harmadik országba történő adattovábbításról
- A FOIT (láthatatlan szöveg) és a FOUT (villanó betűcsere) között a font-display értékével te döntesz, nem a böngésző.
- Két-három betűvastagság szinte minden kkv-oldalnak elég; minden további vastagság és dőlt változat külön letöltendő fájl.
- A Google Fonts CDN-ről helyi WOFF2-re váltás sebességben és adatvédelmi kockázatban is javít, mert nem megy ki látogatói IP-cím külső szolgáltatóhoz.
- A latin részhalmaz nem tartalmazza az ő és ű betűket, azokhoz latin-ext (U+0100-017F) kell.
- Az elrendezés-elmozdulás nagy részét a tartalék betű size-adjust és ascent-override hangolása szünteti meg, nem a preload.
Gyakori kérdések
Melyik font-display értéket állítsam be, ha nem akarok sokat foglalkozni vele?
Ha csak egy értéket állítasz be és mást nem, válaszd az optional értéket: ez zárja ki teljesen a betűcseréből eredő elrendezés-elmozdulást, cserébe lassú kapcsolaton az adott oldalletöltésen rendszerbetűvel látszik a szöveg. Ha viszont hajlandó vagy a tartalék betűt is méretben hangolni, a swap ad jobb élményt, mert a márkabetű így is megjelenik, csak nem ugrik tőle az oldal.
Tényleg tilos a Google Fonts CDN-ről betölteni a betűtípust?
Hivatalosan nincs általános tiltás, és magyar hatósági döntést erről nem ismerünk. Van viszont egy német tartományi bírósági ítélet (Landgericht München I, 3 O 17493/20), amely egy konkrét ügyben jogsértőnek találta a hozzájárulás nélküli beágyazást, mert a látogató IP-címe kikerül egy külső szolgáltatóhoz. Mivel a helyi tárolás sebességben is jobb, és néhány óra munka, a kockázatmentesebb utat érdemes választani. Jogi minősítést ez nem helyettesít.
Miért tűnik el pont az ő és az ű betű, a többi ékezetes viszont jó?
Mert az á, é, í, ó, ú, ö és ü a latin részhalmazban van, az ő, Ő, ű és Ű viszont a Latin Extended-A tartományba esik (U+0150, U+0151, U+0170, U+0171), amit csak a latin-ext részhalmaz tartalmaz. Ha csak latin készletet töltesz be, ezt a négy karaktert a böngésző más betűtípusból rajzolja ki, ami vegyes, hullámzó szöveget eredményez. Gyors teszt: írd be az Árvíztűrő tükörfúrógép szöveget és nagyítsd fel.
Miért kell a crossorigin attribútum a preload sorba, ha a fájl a saját szerveremen van?
Mert a böngésző a betűfájlokat névtelen CORS-módban tölti le, függetlenül attól, hogy azonos vagy külső domainről jönnek. Ha a preload sorból hiányzik a crossorigin, az előtöltött fájl nem párosul a CSS által kért fájllal, és a böngésző kétszer tölti le ugyanazt. Ez a leggyakoribb preload-hiba.
Hány betűfájl az elfogadható egy kkv-weboldalon?
Két-három fájl a reális cél: egy normál törzsszöveg-vastagság, egy félkövér, és legfeljebb egy külön fejlécvágat. Ha dőlt változatot is használsz, számold hozzá. A gyakorlatban ritkán találkozunk olyan oldallal, ahol négynél több vastagság látható különbséget hozna, viszont minden fájl külön letöltés.
Mennyivel lesz gyorsabb az oldalam ezektől a beállításoktól?
Ezt nem lehet előre megmondani, mert a sablontól, a kiszolgálótól és a mostani állapottól függ. Tipikus induló helyzetből a betűforgalom jelentős csökkenése és a szöveg korábbi megjelenése reális várakozás, de garantált számot vagy keresési helyezést senki nem ígérhet. Mérd meg előtte és utána ugyanazon az URL-en, mobil beállítással, három futás mediánjával, a valós felhasználói adatot pedig néhány hét múlva nézd vissza.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.