Ang mga web font pa rin ang pinakamadaling panalo sa performance sa karamihan ng site

Ang pattern na paulit-ulit lumilitaw

Kung mag-audit ka ngayon ng sampung random na production website, makikita mo ang halos parehong sitwasyon sa font sa karamihan sa kanila:

• Anim hanggang sampung font file ang nilo-load sa home page
• Lahat ay nasa WOFF2 (maganda) pero walang font-display strategy (hindi maganda)
• Ilang weight at style na hindi ginagamit kahit saan sa page
• Ang buong stack ay sine-serve mula sa third-party domain (karaniwan, Google Fonts) kasama ang lahat ng DNS, TLS at privacy cost na kaakibat nito
• Walang unicode-range subsetting, kaya dina-download ng bawat visitor ang Cyrillic at Greek glyphs kahit nasa English ang page

Hindi lang ito problema ng maliliit na site. Maraming marketing page na may maayos na pondo ang naglo-load pa rin ng 600 KB ng fonts bago maging paintable ang unang talata. Kapag napansin mo na ang pattern, hindi mo na ito maaalis sa paningin.

Hindi exotic ang solusyon. Ilang teknik lang ito na matagal nang naiintindihan at ilang taon nang nasa browsers.

Gumamit ng isang variable font sa halip na anim na static

Kung nilo-load mo ang Inter Regular, Inter Medium, Inter SemiBold, Inter Bold at ang kanilang italics, nagda-download ka ng halos anim na beses na mas maraming bytes kaysa kailangan mo. Saklaw ng isang Inter variable font ang buong weight axis (at slant, sa ilang build) sa isang file na bahagya lang na mas malaki kaysa dalawang static weight.

Matagal nang settled ang kuwento ng browser support — gumagana ang variable fonts saanman mahalaga. Ang natitirang pag-aalinlangan ay kadalasang minanang muscle memory mula sa static-font era.

Praktikal na rule of thumb: isang variable font file bawat script, bawat family. Latin sa isang file, Cyrillic sa isa pa, Greek sa ikatlo, na nilo-load nang conditional gamit ang unicode-range. Iyon lang.

Magtakda ng makatwirang font-display

Ang default na kilos kapag naglo-load pa ang custom font ay magpakita ng wala — invisible text — nang hanggang tatlong segundo. Ito ang pinakamasamang posibleng default. Nakakakita ang users ng blank page at inaakalang may sira.

Idagdag ito sa bawat @font-face rule:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-display: swap;
}

Ipinapakita ng swap ang fallback font agad at ipinapalit ang custom font kapag na-load ito. Mababasa ng user ang page mula millisecond zero. Ang kapalit ay isang maikling layout shift kapag nangyari ang swap, na mababawasan mo gamit ang susunod na teknik.

Itugma ang iyong fallback metrics

Nagiging nakakagulat lang ang flash of unstyled text kapag magkaibang-magkaiba ang metrics ng fallback at custom font. Inaayos ito ng modernong CSS gamit ang size-adjust, ascent-override at mga kaugnay nito:

@font-face {
  font-family: 'Inter Fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

Kapag naka-tune ang fallback metrics, halos hindi napapansin ang swap — pareho ang horizontal space na kinukuha ng mga salita bago at pagkatapos dumating ang custom font.

Ang gawain ng Google sa --allow-fallback-font-metrics ay bahagi na ngayon ng baseline browser support, at may tooling pipeline (ang fontaine library at mga katulad nito) na kumakalkula ng tamang mga numero para sa iyo sa loob ng ilang segundo.

Mag-self-host

Maginhawa at libre ang Google Fonts, at may dala itong dalawang tunay na gastos:

1. Isang pangalawang TLS handshake. Kahit may HTTP/3 at connection coalescing, bihirang libre ang dagdag na origin.
2. Isang tanong sa privacy at compliance. Ilang korte sa Europe ang nagpasya na ang pag-load ng Google Fonts mula sa fonts.gstatic.com ay nangangahulugang pagpapadala ng personal data (ang IP address) sa third party. Ganap na inaalis ng self-hosting ang tanong.

Ang download-and-host pipeline ay:

1. Kunin ang WOFF2 file (variable build kung mayroon)
2. I-subset ito sa mga script na aktuwal na ginagamit ng audience mo
3. I-serve ito mula sa parehong origin ng natitirang bahagi ng site mo, gamit ang mahabang Cache-Control: max-age=31536000, immutable
4. I-preload ang pinakamahalagang weight: <link rel="preload" as="font" type="font/woff2" href="/fonts/inter-var.woff2" crossorigin>

Iyan ang buong pipeline. Kailangan nito ng isang hapon para sa kasalukuyang site, at halos hindi ka na babalik.

Kailan dapat laktawan nang buo ang custom fonts

Sulit sabihin nang malinaw: hindi lahat ng site ay nangangailangan ng custom font. Tunay nang maganda ang system font stack sa bawat operating system:

font-family: system-ui, -apple-system, 'Segoe UI', Roboto, Inter, sans-serif;

Tama ang weight, tama ang metrics, naka-tune ang rendering para sa device, at eksaktong zero ang bytes-on-the-wire cost. Para sa tools site, internal app, portfolio na inuuna ang content, o anumang nakatuon sa users na nasa mababagal na network, ang system stack ang tamang sagot.

<!-- tool-cta:start -->

💡 Subukan ito: I-convert ang iyong mga TTF o OTF file sa modernong WOFF2 na may handa nang gamiting CSS gamit ang Webfont Generator, na siyang format swap na inirerekomenda ng post.

<!-- tool-cta:end -->

Ang tapat na buod

Para sa tipikal na maliit na site, apat na hakbang ang sumasaklaw sa buong kuwento ng web-font performance:

1. Isang variable font bawat family bawat script
2. font-display: swap na may tugmang fallback metrics
3. Self-hosted na may mahahabang cache header at preload para sa critical weight
4. O laktawan nang buo ang fonts at gamitin ang system stack

Gawin ito nang isang beses at mababawi mo ang ilang daang kilobyte mula sa home page, makakakuha ng ilang daang millisecond ng perceived performance, at maaalis ang isang third-party dependency habang ginagawa ito. Kakaunti ang mga pagbabago na may mas magandang effort-to-payoff ratio.