Web-fonttien optimointi vuonna 2026 tarkoittaa neljän tekniikan yhdistelmää: font-display: swap tekstin näkyvyyden takaamiseksi, WOFF2-pakkausta pienimpään mahdolliseen tiedostokokoon, alijoukotusta turhien merkistöjen poistamiseksi ja fallback-metriikkojen yliajoja (size-adjust, ascent-override) eliminoimaan layout shift fontin vaihtuessa. Näin toteutettuna tyypillinen 168 kt:n TTF-fontti pienenee 12 kilotavuun, ja Largest Contentful Paint (LCP) paranee 200–600 millisekuntia ilman että Cumulative Layout Shift (CLS) kärsii.
Käytä font-display: swap oletusarvona. Se poistaa näkymättömän tekstin (FOIT) ja on tuettu 100 %:ssa nykyselaimista.
Yhdistä muuntuva (variable) WOFF2 -fontti ja Latin-alijoukotus: Inter putoaa 303 kt:sta 22 kt:iin (−93 %).
Yliajaa fallback-fontin metriikat CSS Fonts Level 4 -ominaisuuksilla (size-adjust, ascent-override). Se on ainoa tapa saavuttaa CLS = 0 swap-arvon kanssa.
Preloadaa vain LCP-elementin käyttämä fontti, ei kaikkia leikkauksia. Turha preload kilpailee kriittisistä resursseista.
Itse-hostaus voittaa Google Fontsin CDN:n vuonna 2026: yksi HTTP/3-yhteys, täysi välimuistihallinta, ei kolmatta osapuolta.
unicode-range ei fyysisesti pienennä tiedostoa, vaan se ohjaa mitkä tiedostot ladataan. Alijoukotus on tehtävä erikseen työkalulla kuten fonttools.
Miksi web-fontit hidastavat sivustoa ja rikkovat Core Web Vitalsit?
Web-fontit ovat harvoin ensimmäisenä syytettyjen listalla, kun sivusto putoaa PageSpeed Insightsin punaiselle vyöhykkeelle. Silti ne osuvat yleensä ainakin kahteen kolmesta Core Web Vitals -mittarista. Kun selain kohtaa CSS:ssä @font-face-säännön, jonka lähde on ulkoinen tiedosto, se ei voi renderöidä kyseisellä fontilla asetettua tekstiä ennen kuin tiedosto on ladattu ja parsittu. Tämä luo kaksi ei-toivottua käyttäytymismallia: FOIT (Flash of Invisible Text), jossa selain piilottaa tekstin kokonaan, ja FOUT (Flash of Unstyled Text), jossa selain näyttää fallback-fontin ja vaihtaa myöhemmin varsinaiseen fonttiin.
FOIT osuu suoraan LCP:hen. Jos sivun suurin sisältöelementti on otsikko tai kappale, joka odottaa fonttitiedostoa, LCP-aika venähtää sekunneilla erityisesti mobiililla 3G/4G-yhteyksillä. FOUT puolestaan tuhoaa CLS-arvon. Kun 400-painoisen Interin metriikat eivät täsmää Arialin kanssa, tekstirivit katkeavat eri kohdista, kappaleet muuttavat pituuttaan ja kaikki alapuolella oleva sisältö hyppää. Chromen Field Data raportoi huhtikuussa 2026, että fonttien lataaminen aiheuttaa noin 12 % kaikista Core Web Vitals -epäonnistumisista mobiilissa.
Kolmas vaikutus näkyy Interaction to Next Paint (INP) -mittarissa. Fonttien myöhäinen swap-vaihe aiheuttaa uudelleenlayoutin, joka kilpailee JavaScript-tapahtumakäsittelyn kanssa. Jos käyttäjä painaa nappia juuri swap-hetkellä, päärenderöintisäie on jumissa 60–200 ms. Törmäsin tähän itse eräässä vanhassa verkkokauppaprojektissa, jossa "Osta"-napin klikkaus näytti jäätyvältä juuri fonttiswapin aikana, ja lopulta ratkaisu löytyi size-adjust-yliajosta. Optimoimalla fontit parannat siis kolmea mittaria kerralla, ja perusteellinen kattaus LCP-optimoinnista sekä CLS-optimoinnista löytyy erillisistä oppaistamme.
Mikä on paras font-display -arvo vuonna 2026?
Vuonna 2026 paras font-display -arvo tekstille on swap, ja päällystehokkuudelle optimoiduille sivustoille optional. CSS-ominaisuus font-display kertoo selaimelle, miten se käyttäytyy, kun web-fontti ei ole vielä valmis renderöitäväksi. Sillä on viisi arvoa: auto, block, swap, fallback ja optional. Näistä auto ja block aiheuttavat FOIT-käyttäytymisen, eikä niitä pitäisi enää käyttää leipätekstille tai LCP-elementeille.
Arvo swap antaa selaimelle nollasekunnin block-ajan ja äärettömän swap-ajan. Käytännössä teksti näytetään heti fallback-fontilla, ja custom-fontti korvaa sen heti, kun se on ladattu. Tämä on paras oletusarvo leipätekstille, otsikoille ja käyttöliittymän merkinnöille, koska sisällön näkyvyys on aina korkein prioriteetti. Kääntöpuolena on layout shift, joka on kuitenkin täysin poistettavissa fallback-metriikkojen yliajolla (katso alempi osio).
Arvo optional antaa selaimelle 100 ms block-ajan ja nollan swap-ajan. Jos fontti ei ole valmis 100 millisekunnin sisällä, selain hylkää sen kokonaan tämän sivunlatauksen osalta ja käyttää fallbackia. Fontti ladataan silti taustalla ja on käytettävissä seuraavalla sivunlatauksella. Tämä on paras valinta ehdottoman parhaan CLS-arvon tavoitteluun, koska swap ei koskaan tapahdu keskellä sivun käyttöä. Aiemmat "best practices" -oppaat suosittelivat vuosien 2020–2022 aikana fallback-arvoa, mutta se on käytännössä huonompi kompromissi swap:in ja optional:in väliltä, eikä sitä juuri enää nähdä uusissa toteutuksissa.
WOFF2 on ainoa fonttimuoto, jota kannattaa palvella vuonna 2026. Se käyttää sisäistä Brotli-pakkausta ja saavuttaa 60–70 % pienemmät tiedostokoot verrattuna pakkaamattomaan TTF:ään. Konkreettinen esimerkki: Roboto Regular painaa 168 kt TTF-muodossa mutta vain 53 kt WOFF2-muodossa. Kun tähän yhdistetään Latin-alijoukotus (katso seuraava luku), tiedosto putoaa vielä alle 15 kilotavuun, jolloin kokonaisreduktio on yli 90 %.
Caniuse.com-datan mukaan WOFF2:n selaintuki on globaalisti 99,3 % heinäkuussa 2026. Ainoa syy tarjota erillinen WOFF- tai TTF-fallback olisi Internet Explorer 11 -tuen ylläpitäminen, mutta Microsoft lopetti tuotteen tuen jo 2022 ja Windows 10:n loppupäivämääränä lokakuussa 2025. Käytännössä ainoastaan WOFF2 riittää. Kaksinkertaiset src-määritykset vain sekavoittavat CSS:ää ja johtavat joskus tuplalatauksiin selainbugeissa.
Älä käytä TTF- tai OTF-muotoja suoraan tuotannossa. Ne ovat pakkaamattomia työpöytäformaatteja, ja jos konvertointia WOFF2:ksi ei ole tehty, sivustoosi ladataan turhaan 3–5-kertainen tavumäärä. Konversio on triviaali: komentorivityökalu woff2_compress Googlen virallisesta WOFF2-repositoriosta pakkaa TTF:n WOFF2:ksi yhdellä komennolla. Vielä helpompi on käyttää fonttools-kirjastoa Pythonissa, joka mahdollistaa myös alijoukotuksen samalla ajolla.
Fonttien alijoukotus (subsetting) ja unicode-range
Alijoukotus (subsetting) tarkoittaa fonttitiedoston pienentämistä poistamalla merkit, joita sivustollasi ei koskaan käytetä. Tyypillinen kansainvälinen fontti sisältää Latin-, Cyrillic-, Greek- ja usein Vietnamese-merkistöt sekä satoja välimerkkejä ja symboleita. Suomen- tai englanninkielinen sivusto tarvitsee tästä kaikesta vain murto-osan. Alijoukottamalla vain Latinan perusmerkit sekä laajennettu Latin (jossa on ä, ö, å, ü ym. skandinaaviset ja saksalaiset merkit) fontin koko putoaa tyypillisesti 60–80 %.
Käytännön esimerkki fonttoolsilla. Komento pyftsubset työskentelee unicode-rangella U+0000-00FF (Basic Latin + Latin-1 Supplement), joka kattaa suomenkielisen tekstin:
Kriittinen erottelu, jonka moni jättää huomiotta: unicode-range CSS-descriptori ei fyysisesti pienennä fonttitiedostoa. Se kertoo vain selaimelle, millä sivuilla kyseinen tiedosto tulisi ladata. Jos määrittelet unicode-range: U+0000-00FF mutta viittaat 300 kt:n täysimittaiseen fonttitiedostoon, selain lataa silti koko 300 kt jos sivulla on yksikin merkki tuolta alueelta. Oikea resepti on tämä: alijoukota tiedosto fyysisesti pyftsubsetilla ja lisää sitten unicode-range-descriptori CSS:ään.
Jos sivustosi on monikielinen, unicode-range mahdollistaa ehdollisen latauksen. Venäjänkielinen sivu lataa vain kyrillisen alijoukon, suomenkielinen vain latinalaisen. Chrome, Firefox ja Safari tukevat tätä kaikki, mutta muista testata: joissakin selaimissa alijoukkoja ei uudelleenkäytetä eri sivujen välillä, joten monikielisen näkymän kokonaislatausaika voi joskus olla suurempi.
Muuntuvat fontit (Variable Fonts) käytännössä
Muuntuvat fontit (variable fonts, VF) pakkaavat useita leikkauksia (light, regular, medium, bold, black) yhteen tiedostoon, jossa paksuus, leveys ja optinen koko ovat säädettävissä akseleina. Käytännön hyöty on kaksinkertainen: yksi HTTP-pyyntö kaikkien leikkausten sijaan ja pienempi kokonaiskoko, kun leikkauksia on kolme tai enemmän.
Break-even-piste on yleensä kolmen leikkauksen kohdalla. Jos käytät vain Regular- ja Bold-versioita, kaksi erillistä staattista WOFF2:ta on pienempi kokonaispaino kuin yksi variable-fontti. Mutta jos design-järjestelmässäsi on Light (300), Regular (400), Medium (500), Semibold (600), Bold (700) ja Extrabold (800), yksittäinen muuntuva Inter-tiedosto (~120 kt raakana, ~22 kt Latin-alijoukotettuna) syrjäyttää kuusi erillistä tiedostoa (yhteensä ~300 kt).
Muuntuvien fonttien CSS-määritys eroaa staattisista vain font-weight-arvon osalta. Annetaan alue, ei yhtä numeroa:
@font-face {
font-family: 'Inter';
src: url('/fonts/inter-var-latin.woff2') format('woff2-variations');
font-weight: 100 900; /* koko akseli */
font-style: normal;
font-display: swap;
}
/* Käyttö on tavallista: */
h1 { font-weight: 800; }
body { font-weight: 400; }
strong { font-weight: 600; }
Muuntuvien fonttien selaintuki on nykyään käytännössä universaali (Chrome 66+, Firefox 62+, Safari 11+, kaikki nykyiset mobiiliselaimet). MDN:n muuntuvien fonttien opas listaa myös leveys- ja optisen koon akselit, joita voi tarvittaessa säätää font-variation-settings-ominaisuudella.
Miten estän layout shiftin fonttien lataamisessa?
Layout shift fonttien vaihtuessa syntyy siitä, että fallback-fontti (Arial, sans-serif tai vastaava) ja custom-fontti ovat eri kokoisia samalla pistekoolla. Interin kirjaimet ovat noin 7 % suurempia kuin Arialin, joten kun swap tapahtuu, jokainen rivi levenee hieman ja kappaleen korkeus muuttuu. Koko sivun alapuolinen sisältö hyppää.
Ratkaisu vuodesta 2023 lähtien on CSS Fonts Level 4 -moduulin tarjoamat fallback-metriikan yliajot: size-adjust, ascent-override, descent-override ja line-gap-override. Näillä säädetään paikallisen fallback-fontin metriikat vastaamaan custom-fonttia niin tarkasti, että swap on visuaalisesti näkymätön. Ideaalinen kaava on tämä: määrittele toinen @font-face, joka ei lataa mitään verkosta vaan viittaa local()-lähteellä käyttäjän koneella olevaan fonttiin (yleensä Arial), ja säädä sen metriikat.
Metriikkojen tarkat arvot lasketaan mittaamalla ero fallback- ja custom-fontin välillä. Tähän on kaksi käytännön työkalua: Malte Ubl'n Fontaine-kirjasto laskee arvot automaattisesti, ja verkkotyökalu Fontsource Preview generoi valmiin @font-face-lohkon leikkauspöydälle kopioitavaksi. Next.js:n next/font-integraatio tekee saman automaattisesti build-vaiheessa. Kun metriikat on säädetty oikein, CLS-arvon pudotessa 0.15:sta 0:aan on täysin realistinen tulos. (Näin kävi omassa portfolio-sivustossani, ja mittarit menivät vihreiksi ensimmäisellä yrittämällä.)
Kuinka esitallentaa fontteja LCP:n parantamiseksi?
Fontin preload tarkoittaa <link rel="preload"> -tagia HTML:n <head>-osassa. Se kertoo selaimelle: aloita tämän tiedoston lataus välittömästi, älä odota CSS:n parsimista. Jos LCP-elementti on otsikko, joka käyttää web-fonttia, preload voi leikata LCP:tä 200–600 millisekuntia mobiililla. Se on yksi kustannustehokkaimmista optimoinneista Core Web Vitals -profiilissa.
Kolme kriittistä yksityiskohtaa. 1.crossorigin="anonymous" vaaditaan aina, koska fonttitiedostoja käsitellään CORS-tilassa jopa samasta originista, ja ilman attribuuttia selain tekee kaksi pyyntöä. 2.as="font" ja type="font/woff2" antavat selaimelle oikean prioriteetin ja MIME-tyypin. 3.fetchpriority="high" (Chrome 101+, Safari 17+) nostaa preload-pyynnön prioriteettia entisestään, mikä on hyödyllistä jos sivulla on paljon kilpailevia korkean prioriteetin resursseja.
Älä preloadaa kaikkia fontteja. Sääntö on: vain LCP-elementin käyttämä leikkaus. Jos preloadaat Regular-, Bold-, Italic- ja Semibold-versiot, ne kilpailevat ensimmäisen LCP-kuvan tai kriittisen CSS:n kanssa ja voit itse asiassa hidastaa LCP:tä. Käytä muuntuvaa fonttia, silloin sinulla on vain yksi tiedosto preloadattavaksi. Voit optimoida latausstrategiaa vielä pidemmälle yhdistämällä sen Speculation Rules API:n prerender-strategioihin, jotka mahdollistavat fonttien esitallennuksen ennen kuin käyttäjä on edes navigoinut sivulle.
Onko Google Fonts nopea vuonna 2026?
Vuonna 2026 itse-hostaus on lähes aina nopeampi kuin Google Fontsin CDN. Kolme keskeistä syytä: (1) selaimet eivät enää jaa välimuistia eri origiinien välillä. Chrome, Firefox ja Safari kaikki toteuttavat "cache partitioning" -mallia, joten ajatus "Google Fontsin latasi jo joku toinen sivusto" ei enää päde. (2) Kolmannen osapuolen origini vaatii ylimääräisen DNS-kyselyn, TLS-kättelyn ja TCP-yhteyden, ja jopa HTTP/3:lla tämä lisää helposti 100–200 ms LCP:hen. (3) GDPR-vaatimusten (2022 Munich-tuomio) johdosta Google Fontsin käyttö kolmannen osapuolen CDN:ltä voi vaatia evästesuostumusta EU-alueella.
Itse-hostatun ratkaisun perussetupin vaiheet:
Lataa haluamasi fontti Google Fontsista tai suoraan valmistajalta (esim. Rasmus Andersson Inter-fontille) WOFF2-muodossa, mieluiten muuntuvana.
Alijoukota tiedostot pyftsubsetilla, vähintään Latin, tarvittaessa Latin Extended ja Cyrillic erillisiksi unicode-range-lohkoiksi.
Sijoita tiedostot omalle domainille polkuun kuten /fonts/ ja aseta CDN:sta pitkä Cache-Control-header (public, max-age=31536000, immutable).
Määrittele @font-face-säännöt CSS:ssä, lisää preload-tag ja fallback-metriikat.
Poikkeukset itse-hostaukseen: jos käytät jo Google Fontsin uutta CSS API v2 -rajapintaa ja HTTP/2-yhteyttä, latency on hallittavissa. Uudelleenkäytettävät kansainväliset sivustot, joilla on kymmeniä leikkauksia ja monta kieltä, voivat hyötyä Googlen automaattisesta unicode-range-jaosta. Kaikilla muilla (käytännössä 95 %:lla sivustoista) itse-hostaus on selkeästi parempi valinta. Etenkin kun se yhdistyy hyvään TTFB:hen, kokonaisvaikutus näkyy suoraan käyttäjäkokemuksessa; katso lisää TTFB-optimointioppaastamme.
Yleiset virheet ja miten välttää ne
Neljä virhettä toistuvat sivustoauditeissa yhä uudelleen. Ensimmäinen: font-display: block -käyttö leipätekstille. Tämä on FOIT-oletusarvo, joka piilottaa tekstin kokonaan kolme sekuntia. Jos tuotannossa on tämä asetus, LCP-arvo on takuulla huono. Vaihda välittömästi swap-arvoon.
Toinen: preload ilman crossorigin-attribuuttia. Selain tekee kaksi latausta samasta tiedostosta, yhden preloadin ja toisen varsinaisen CSS-parsimisen käynnistämänä. Tämä on hiljainen bugi, jonka näet vain Network-välilehdellä. Muista siis aina crossorigin="anonymous".
Kolmas: liikaa preloadeja. Kun preloadaat kaikki leikkaukset ja Italic-variantit "varmuuden vuoksi", ne syrjäyttävät kriittisemmät resurssit kuten LCP-kuvan tai kriittisen CSS:n. Preload on nollasummapeliä bandwidthin osalta. Preloadaa vain yksi fontti, LCP-elementin käyttämä.
Neljäs: ikonifonttien käyttö. Font Awesome ja Material Icons -kaltaiset ikonifontit ovat suuria (usein 100+ kt), niitä on vaikea alijoukottaa tarkasti, ja ne aiheuttavat aina jonkin verran layout shiftiä. Vuonna 2026 SVG-ikonit (joko inline tai spritena) ovat aina parempi valinta. SVG-ikonit ovat myös saavutettavampia ja tukevat värillisiä variantteja natiivisti. Uudemmat versiot suosituista ikonifonteista (mm. Material Symbols) tarjoavat suoran SVG-vaihtoehdon.
Usein kysytyt kysymykset
Mitä eroa on WOFF- ja WOFF2-formaateilla?
WOFF2 käyttää Brotli-pakkausta ja saavuttaa noin 30 % pienemmät tiedostot kuin WOFF, joka pohjautuu Zlibiin. WOFF2:n selaintuki on globaalisti 99,3 % vuonna 2026, joten WOFF-fallbackia ei enää tarvita. Käytä yksinomaan WOFF2:ta.
Kuinka monta fonttitiedostoa sivulla saa olla?
Käytännön ohje on korkeintaan 2 fontti-perhettä ja 4 leikkausta yhteensä. Muuntuvat fontit ovat vielä parempi ratkaisu: yksi tiedosto kattaa kaikki paksuudet. Jokainen ylimääräinen fonttitiedosto lisää HTTP-pyynnön ja voi hidastaa LCP:tä 50–150 ms.
Kannattaako fontti liittää suoraan CSS:ään base64-koodattuna?
Ei. Base64-koodaus kasvattaa tavukokoa 33 %, estää selaimen välimuistin toimimisen erikseen fontille ja lykkää CSS:n parsimista. Base64-fontit voidaan perustella vain hyvin pienissä erikoistapauksissa (esim. yksittäinen ikoniglyfi). Käytä normaalisti erillistä WOFF2-tiedostoa.
Auttaako HTTP/3 fonttien lataamisessa?
Kyllä, HTTP/3 (QUIC) parantaa fonttien lataamista poistamalla TCP:n head-of-line blocking -ongelman ja lyhentämällä TLS-kättelyä yhteen roundtrippiin. Jos palvelinta ja CDN:ää käyttäjät jakavat monella sivulla, HTTP/3 säästää 30–100 ms latenssia mobiilissa verrattuna HTTP/2:een.
Miten testaan, onko fonttien optimointini onnistunut?
Suorita Lighthouse-audit ja tarkista neljä kohtaa: LCP alle 2.5 s mobiililla, CLS alle 0.1, "Ensure text remains visible during webfont load" -audit vihreä ja Network-välilehdellä yksikään fonttitiedosto ei tuplaudu (kaksi identtistä pyyntöä samaan tiedostoon). Vahvista tulos kenttädatasta Chrome Search Consolen Core Web Vitals -raportilta 28 päivän jälkeen.
Speculation Rules API:n prerender-säännöt pudottavat LCP:n alle 200 millisekuntiin Chrome 134:ssä. Käytännön opas eagerness-tasoihin, kvoottiin, framework-integraatioon ja mittaukseen vuonna 2026.
Time to First Byte (TTFB) on Core Web Vitalsin hiljainen perustus – jokainen palvelimella menetetty millisekunti viivästyttää LCP:tä ja FCP:tä. Tässä oppaassa konkreettiset tekniikat (CDN-edge, HTTP/3, streaming SSR, indeksointi, Redis), joilla TTFB saadaan vuonna 2026 alle 200 ms.
CLS on Core Web Vitals -mittari, joka arvioi sivun visuaalista vakautta. Tässä oppaassa käydään läpi kuusi yleisintä CLS-ongelmaa ja niiden ratkaisut koodiesimerkein — fonttien size-adjust-säädöstä CSS containmentiin ja bfcache-optimointiin.
