暫定日本語訳：Font Loading

暫定日本語案: TL;DR — A custom web font is a file the browser has to download before it 暫定日本語案: can show your text in it. While it waits, it either hides the text or shows a 暫定日本語案: backup font and swaps later — and either choice can slow down or visually jump 暫定日本語案: your ページ. You control that behavior with one CSS line (font-display), and you 暫定日本語案: can speed the font up by preloading it. If you don’t need a custom font, a system 暫定日本語案: font has nothing to load and nothing to shift.

暫定日本語案: What font loading is

暫定日本語案: When you use a custom font — a brand font, a Google Font, anything that isn’t 暫定日本語案: already on the visitor’s device — the browser has to go fetch that font file 暫定日本語案: before it can paint your text in it. That download takes time, and the browser has 暫定日本語案: to decide what to show in the meantime.

暫定日本語案: It has two basic options, and both have annoying names:

• 暫定日本語案: FOIT (Flash of Invisible Text): hide the text until the custom font arrives. 暫定日本語案: The ページ looks blank where the text should be, then it pops in.
• 暫定日本語案: FOUT (Flash of Unstyled Text): show a normal backup font right away, then 暫定日本語案: swap to the custom font once it loads. You see text immediately, but it can 暫定日本語案: visibly “jump” when the swap happens if the two fonts aren’t the same size.

暫定日本語案: Why it matters for SEO

暫定日本語案: Neither of those is free. FOIT can delay when your main text appears, which hurts 暫定日本語案: Largest Contentful Paint (LCP). FOUT can cause a layout shift when the font 暫定日本語案: swaps in, which hurts Cumulative Layout Shift (CLS). Both LCP and CLS are 暫定日本語案: Core Web Vitals — real-user 暫定日本語案: metrics Google uses as part of ページ experience. So font loading isn’t just a design 暫定日本語案: detail; it’s a technical SEO lever.

暫定日本語案: The simple fixes

• 暫定日本語案: Use a system font if you can. There’s nothing to download, so there’s no 暫定日本語案: delay and no shift. This is the most reliable fix, full stop.
• 暫定日本語案: If you need a custom font, set font-display. Adding font-display: swap (or 暫定日本語案: optional) to your font tells the browser not to leave text invisible while it 暫定日本語案: waits.
• 暫定日本語案: Preload the important font. A <link rel="preload"> tag tells the browser to 暫定日本語案: grab the font early instead of stumbling on it later.

暫定日本語案: Want the full version — the font-display value table, the preload + optional 暫定日本語案: combo, matching your fallback font’s metrics, and Google vs. self-hosting? Switch 暫定日本語案: to the Advanced tab.

暫定日本語案: TL;DR — Custom web fonts are render-affecting external resources. They hit 暫定日本語案: LCP when a render-blocking font delays your largest text element, and CLS 暫定日本語案: when the fallback-to-web-font swap reflows the layout. The two default behaviors — 暫定日本語案: FOIT (invisible until loaded) and FOUT (fallback then swap) — each fail 暫定日本語案: differently. font-display is the primary lever (swap guarantees FOUT; 暫定日本語案: optional gives a ~100ms window and then commits, killing the later swap). 暫定日本語案: Preloading fixes late font discovery; preload + font-display: optional is 暫定日本語案: the combo Google’s own engineering singled out for eliminating layout jank. But 暫定日本語案: passing the Lighthouse font-display check doesn’t fix CLS — that needs a 暫定日本語案: metrically-matched fallback (or size-adjust/ascent-override overrides). None of 暫定日本語案: this is a direct ranking factor; it feeds CLS/LCP, which are ページ experience 暫定日本語案: signals.

暫定日本語案: Why fonts are a special case

暫定日本語案: Most パフォーマンス problems are about bytes — an image is too big, a script blocks 暫定日本語案: the main thread. Fonts are worse than that in one specific way: they’re an external 暫定日本語案: resource and they change the metrics of your text. So a font can hurt you two 暫定日本語案: different ways at once. It can delay when text paints (an LCP problem), and it can 暫定日本語案: change the size and shape of that text after it’s already on screen (a CLS problem).

暫定日本語案: The two default browser behaviors are worth naming because the whole topic hangs off 暫定日本語案: them:

• 暫定日本語案: FOIT (Flash of Invisible Text): text in the custom font is rendered invisible 暫定日本語案: until the font loads or a timeout is hit — historically up to a ~3-second block in 暫定日本語案: most browsers.
• 暫定日本語案: FOUT (Flash of Unstyled Text): the fallback font shows immediately, then gets 暫定日本語案: swapped for the web font once it loads.

暫定日本語案: FOIT feels “cleaner” (no jump) but risks a rendering delay. FOUT feels faster (text 暫定日本語案: now) but risks a layout shift on swap. Neither is automatically safe — that’s the 暫定日本語案: core idea to hold onto.

暫定日本語案: It also helps to separate the pipeline into distinct stages, because success at one 暫定日本語案: stage doesn’t guarantee success at the next. A @font-face rule only declares a 暫定日本語案: face — the browser fetches the actual font file only once matching styled text on 暫定日本語案: the ページ requires it (declaration and matching are separate steps from the fetch). 暫定日本語案: That fetch is subject to CORS if the font is served cross-origin, so a stylesheet 暫定日本語案: that loads cleanly doesn’t guarantee the font response itself carries the right 暫定日本語案: cross-origin permission — a missing header there fails silently as a font that 暫定日本語案: never renders. And a successful fetch still doesn’t guarantee a stable-looking ページ: 暫定日本語案: cold-cache, warm-cache, and already-cached font states can produce different 暫定日本語案: discovery and swap timing, so testing one repeat ページ load in DevTools doesn’t tell 暫定日本語案: you what a first-time visitor actually sees.

暫定日本語案: How fonts affect LCP

暫定日本語案: If the largest visible element on your ページ is text — a big headline, a hero 暫定日本語案: paragraph — then the font that text uses can become part of your LCP path. Per 暫定日本語案: web.dev’s LCP guidance, the LCP resource of a ページ, if it has one, will be either an 暫定日本語案: image or a web font. A render-blocking font that leaves that text invisible (FOIT) 暫定日本語案: pushes your LCP out until the font arrives.

暫定日本語案: The fix here is straightforward and comes straight from Google. On web.dev’s 暫定日本語案: Optimize Largest Contentful Paint guide:

暫定日本語案: “If you set a font-display value of anything other than auto or block, then 暫定日本語案: text will always be visible during load, and LCP won’t be blocked on an additional 暫定日本語案: network request.” 暫定日本語案: — web.dev

暫定日本語案: In other words: swap, fallback, or optional all keep text visible during load, 暫定日本語案: so your LCP isn’t hostage to the font request.

暫定日本語案: How fonts affect CLS

暫定日本語案: CLS comes from the swap. Your fallback font and your web font almost never have 暫定日本語案: identical character widths and line heights, so when the browser replaces one with 暫定日本語案: the other, the text reflows — and everything below it moves. That’s a layout shift.

暫定日本語案: The counterintuitive part, and the thing most people miss: FOIT causes CLS too. 暫定日本語案: Even invisible text is still laid out using the fallback font’s metrics, so the swap 暫定日本語案: still moves things. From web.dev’s 暫定日本語案: Optimize Cumulative Layout Shift guide:

暫定日本語案: “Both approaches can cause layout shifts. Even if the text is invisible, it’s 暫定日本語案: still laid out using the fallback font, so when the web font loads, the text block 暫定日本語案: and the surrounding コンテンツ shift” 暫定日本語案: — web.dev

暫定日本語案: The same ページ frames the two behaviors plainly:

暫定日本語案: “The fallback font is swapped with the web font, incurring a Flash of Unstyled 暫定日本語案: Text (FOUT). ‘Invisible’ text is displayed using the fallback font until a web 暫定日本語案: font is available and the text is made visible (FOIT—flash of invisible text).” 暫定日本語案: — web.dev

暫定日本語案: I’ve said the same thing in plainer terms in my Ahrefs write-up on 暫定日本語案: Cumulative Layout Shift: 暫定日本語案: when a font loads or changes, you end up with a noticeable shift — a FOIT or a FOUT. 暫定日本語案: It’s one of the most common real-world CLS causes, right alongside images without 暫定日本語案: dimensions and コンテンツ injected after load.

暫定日本語案: The font-display property

暫定日本語案: font-display is a @font-face descriptor that controls two windows: the block 暫定日本語案: period (how long the browser hides text waiting for the font) and the swap 暫定日本語案: period (how long, after the block period, it will still swap in the web font once 暫定日本語案: it arrives). Per web.dev’s Best Practices for Fonts:

暫定日本語案: MDN’s font-display reference, 暫定日本語案: which Google’s own docs リンク to as the spec source, describes them tersely: swap 暫定日本語案: gives an extremely small block period and an infinite swap period; optional gives 暫定日本語案: an extremely small block period and no swap period. That “no swap period” is the 暫定日本語案: whole point of optional — after the block period window closes, whatever font is 暫定日本語案: in use stays, so there’s no later swap to shift the layout.

暫定日本語案: One caution on the numbers in that table: the CSS specification itself only defines 暫定日本語案: block/swap period categories — short, extremely small, infinite, none — and 暫定日本語案: leaves the exact duration to the browser. The millisecond/second figures above are 暫定日本語案: web.dev’s documented Chromium behavior, not a cross-browser guarantee. Treat them as 暫定日本語案: illustrative rather than a spec promise, and check current numbers for whichever 暫定日本語案: browser/version you’re actually testing against.

暫定日本語案: Which value for which コンテンツ? web.dev’s own advice is that these can be mixed: 暫定日本語案: use swap for branding and other visually distinctive elements (where seeing the 暫定日本語案: brand font matters and a brief shift is acceptable), and optional for body text 暫定日本語案: (where CLS-sensitivity wins and you’d rather not shift). That’s a genuinely useful 暫定日本語案: rule of thumb — don’t apply one value サイト-wide by reflex.

暫定日本語案: Preloading fonts

暫定日本語案: Font requests are discovered late. The browser doesn’t know it needs a font until 暫定日本語案: it has parsed your CSS, matched a @font-face rule to an element on the ページ, and 暫定日本語案: decided that element is visible. Only then does it start the download. A 暫定日本語案: <link rel="preload"> short-circuits that:

<link rel="preload" href="/fonts/brand.woff2" as="font" type="font/woff2" crossorigin>

暫定日本語案: That tells the browser to start fetching the font immediately, in parallel with 暫定日本語案: everything else, instead of waiting to discover it. Bing’s engineering team 暫定日本語案: describes exactly this mechanism on their own 検索 ページ (more in the Quotes tab): 暫定日本語案: the preload tags in the <head> kick off the font downloads right away, whereas 暫定日本語案: without them the browser wouldn’t fetch the fonts until it had parsed the CSS and 暫定日本語案: found matching elements.

暫定日本語案: The strongest combination per Google’s own writeup is preload + 暫定日本語案: font-display: optional. web.dev’s 暫定日本語案: Prevent layout shifting and FOIT by preloading optional fonts 暫定日本語案: calls combining <link rel="preload"> with font-display: optional the most 暫定日本語案: effective way to guarantee no layout jank when rendering custom fonts, and notes 暫定日本語案: that Chrome (from version 83) eliminated the layout shifting that used to happen when 暫定日本語案: preloading optional fonts. The preload gives the font its best shot at arriving 暫定日本語案: inside the ~100ms window; optional guarantees that if it doesn’t, you don’t pay for 暫定日本語案: it with a shift.

暫定日本語案: When not to preload. Preloading isn’t free. web.dev warns that preload is 暫定日本語案: highly effective at making fonts discoverable early, but it comes at the cost of 暫定日本語案: taking browser resources away from loading other resources. Preload the one or two 暫定日本語案: fonts you actually need above the fold — preloading every font weight you own can 暫定日本語案: starve more important resources and make the ページ slower overall.

暫定日本語案: Make sure the preload actually gets reused. A preload only helps if the browser 暫定日本語案: can match it to the real font request — the href, as="font", type, and 暫定日本語案: crossorigin mode all have to line up with what the CSS @font-face rule ends up 暫定日本語案: requesting, or you’ll get an “unused preload” warning and a wasted second download 暫定日本語案: instead of a faster one. Preloading can also bypass unicode-range selection, 暫定日本語案: pulling down a subset you didn’t actually need for that ページ. Confirm the match in 暫定日本語案: DevTools’ Network panel: you want to see one request for that font, kicked off by 暫定日本語案: the preload, not two.

暫定日本語案: Fixing the shift itself: fallback metric matching

暫定日本語案: Here’s the trap: passing the Lighthouse font-display check does not fix CLS. 暫定日本語案: Google’s Lighthouse docs are explicit that FOIT and FOUT have the same impact on CLS 暫定日本語案: once the custom font replaces the temporary system font. So swap makes your text 暫定日本語案: visible (good for LCP and for the “invisible text” audit) but leaves the swap shift 暫定日本語案: in place.

暫定日本語案: To kill the shift when a swap does happen, you have to make the fallback font and 暫定日本語案: the web font take up the same space. Two levers:

1. 暫定日本語案: Pick a metrically-similar system fallback in your font-family stack, rather 暫定日本語案: than a single custom font name with nothing sensible behind it. The closer the 暫定日本語案: fallback’s character widths and line height are to the web font, the smaller the 暫定日本語案: shift.
2. 暫定日本語案: Override the web font’s metrics with size-adjust, ascent-override, 暫定日本語案: descent-override, and line-gap-override on the @font-face rule, so the web 暫定日本語案: font is forced to match the fallback’s box. web.dev lists these descriptors, and 暫定日本語案: Smashing Magazine’s 暫定日本語案: deep dive on CSS font descriptors 暫定日本語案: walks through them in detail if you want to go all the way.

暫定日本語案: Each of those four descriptors adjusts a different metric, and current browser 暫定日本語案: support varies by descriptor — check compatibility before leaning on any single one. 暫定日本語案: Validate against the actual weights, styles, and scripts you ship, too: a fix 暫定日本語案: confirmed on your regular-weight Latin text doesn’t guarantee bold, italic, or a 暫定日本語案: non-Latin script behave the same way.

暫定日本語案: DebugBear’s 暫定日本語案: Fixing Layout Shifts Caused by Web Fonts 暫定日本語案: is a good end-to-end walkthrough of this: measure the impact, identify the problem 暫定日本語案: font, apply font-display, choose a better fallback, then adjust font metrics.

暫定日本語案: Google Fonts vs. self-hosting

暫定日本語案: You don’t have to self-host to control font-display. The 暫定日本語案: Google Fonts CSS2 API accepts a 暫定日本語案: display query parameter — https://fonts.googleapis.com/css2?family=Roboto&display=swap 暫定日本語案: sets font-display directly on the served @font-face rules. Addy Osmani’s 暫定日本語案: post on shipping font-display to Google Fonts 暫定日本語案: covers the change: previously the only way to specify font-display for Google 暫定日本語案: Fonts was to self-host them, and this removed that need.

暫定日本語案: Self-hosting still wins on one thing: it eliminates the extra DNS lookup and 暫定日本語案: connection to fonts.googleapis.com and fonts.gstatic.com. That’s a real latency 暫定日本語案: cost, and one of the reasons a 暫定日本語案: preconnect resource hint to those 暫定日本語案: origins helps if you do use Google Fonts. Weigh the connection overhead against the 暫定日本語案: convenience — and don’t assume “it’s from Google, so it’s fine.” A copy-pasted Google 暫定日本語案: Fonts embed is still a render-blocking stylesheet request plus a font request, and 暫定日本語案: older embeds may not carry a display value at all.

暫定日本語案: There’s no universal winner between the two options — it comes down to which scripts 暫定日本語案: and weights you actually ship, your caching setup, and the font’s license terms. Run 暫定日本語案: the comparison against your own ページ rather than defaulting to whichever one a 暫定日本語案: tutorial recommended.

暫定日本語案: Variable fonts

暫定日本語案: A variable font packs many weights and styles (regular, bold, condensed, italic) 暫定日本語案: into a single file with adjustable axes. That can be a net win — one request instead 暫定日本語案: of six — if you actually use several of those variants. But a full variable font is a 暫定日本語案: bigger single file than one static weight, so if you only ever render one weight, 暫定日本語案: shipping the whole variable font can be slower, not faster. Subset it to the axes 暫定日本語案: and characters you use, serve it as WOFF2 so it’s compressed, and check the font’s 暫定日本語案: license — not every foundry permits subsetting or self-hosting.

暫定日本語案: Reducing the file in the first place

暫定日本語案: Everything above manages when the font loads. You can also shrink what loads. 暫定日本語案: Font subsetting strips out glyphs you don’t use (an all-Latin サイト doesn’t need 暫定日本語案: Cyrillic and CJK ranges), and WOFF2 is the well-compressed format to serve. A 暫定日本語案: smaller font file is more likely to arrive inside optional’s window and less likely 暫定日本語案: to block LCP — subsetting and compression are the complementary lever to 暫定日本語案: font-display and preload, not an alternative to them.

暫定日本語案: There’s no single “correct” subset or universal byte-savings percentage here, though 暫定日本語案: — it depends on the scripts, characters, and weights your specific audience actually 暫定日本語案: needs. A number you saw in someone else’s case study or benchmark isn’t a promise for 暫定日本語案: your ページ; measure your own font requests before and after.

暫定日本語案: Is this a ranking factor?

暫定日本語案: Be precise here. Font loading is not a direct ranking factor. What it affects is 暫定日本語案: CLS and LCP, which are Core Web Vitals and part of Google’s ページ experience 暫定日本語案: signals. And ページ experience is a lightweight, tiebreaker-style signal — relevance 暫定日本語案: and quality dominate; it helps decide between otherwise comparable results, not 暫定日本語案: between a great ページ and a poor one. So the honest framing is: fix your font loading 暫定日本語案: because it’s a genuine user-experience problem that happens to feed two ranking 暫定日本語案: inputs — not because a font-display value will move you up the results on its own.

暫定日本語案: My own take

暫定日本語案: Across my Ahrefs 暫定日本語案: CLS and 暫定日本語案: LCP guides I’ve landed on 暫定日本語案: the same priority order, and it still holds. If you can use a system font, do that — 暫定日本語案: there’s nothing to load, so there are no delays or changes that cause a shift. If you 暫定日本語案: have to use a custom font, the current best method for minimizing CLS is to combine 暫定日本語案: <link rel="preload"> (grab the font as soon as possible) with font-display: 暫定日本語案: optional (give it a small window to load); if it doesn’t make it in time, the ページ 暫定日本語案: just shows a default font, and your custom font gets cached and shows up on 暫定日本語案: subsequent loads. Preload, then optional, then — best of all — just don’t use a 暫定日本語案: custom font. That’s the whole ladder.

暫定日本語案: AI summary

暫定日本語案: A condensed take on the Advanced version:

• 暫定日本語案: Font loading = what the browser shows while a custom font downloads. It’s a 暫定日本語案: special case because fonts are both an external resource and they change text 暫定日本語案: metrics — so they can hurt two Core Web Vitals at once.
• 暫定日本語案: LCP: a render-blocking font that hides your largest text element (FOIT) delays 暫定日本語案: LCP. Any font-display value other than auto/block keeps text visible so LCP 暫定日本語案: isn’t blocked on the font.
• 暫定日本語案: CLS: the fallback-to-web-font swap reflows the layout. FOIT causes CLS too — 暫定日本語案: invisible text is still laid out in the fallback’s metrics, so the swap still 暫定日本語案: shifts.
• 暫定日本語案: font-display is the main lever: swap = FOUT (fast text, still swaps); 暫定日本語案: optional = ~100ms window then commits, so no later swap and no swap-related 暫定日本語案: shift. web.dev suggests mixing them: swap for branding, optional for body.
• 暫定日本語案: Preload fixes late font discovery. Preload + font-display: optional is 暫定日本語案: Google’s singled-out combo for eliminating layout jank (Chrome 83+). Don’t 暫定日本語案: over-preload — it steals resources from other loads.
• 暫定日本語案: Passing the Lighthouse font-display audit ≠ fixing CLS. The swap shift is a 暫定日本語案: separate fix: a metrically-matched fallback, or size-adjust/ascent-override/ 暫定日本語案: descent-override/line-gap-override.
• 暫定日本語案: Google Fonts can set font-display via the &display= URL parameter (no 暫定日本語案: self-hosting needed); self-hosting still removes the extra connection hop.
• 暫定日本語案: Not a direct ranking factor — it feeds CLS/LCP, which are ページ experience 暫定日本語案: signals (a tiebreaker). Best fix of all: use a system font.

暫定日本語案: Official documentation

暫定日本語案: Primary-source documentation from Google and Bing.

暫定日本語案: Google

• 暫定日本語案: Best Practices for Fonts (web.dev) — the font-display value table (block/swap periods) and the mix-strategy advice.
• 暫定日本語案: Optimize Cumulative Layout Shift (web.dev) — the FOIT/FOUT explanation and why both cause layout shift.
• 暫定日本語案: Optimize Largest Contentful Paint (web.dev) — when a web font is the LCP resource and how font-display keeps text visible.
• 暫定日本語案: Prevent layout shifting and FOIT by preloading optional fonts (web.dev) — the preload + font-display: optional combo and the Chrome 83 fix.
• 暫定日本語案: Optimize WebFont loading and rendering (web.dev) — broader font-loading パフォーマンス guide.
• 暫定日本語案: Learn: Optimize web fonts (web.dev) — the structured lesson version.
• 暫定日本語案: Ensure text remains visible during webfont load (Chrome for Developers) — the Lighthouse font-display audit. Note: as of Lighthouse 13 this moved from a standalone audit into a broader “Font display insight” panel, so older screenshots and guides use the old naming.
• 暫定日本語案: Google Fonts CSS2 API — display parameter — setting font-display via URL without self-hosting.
• 暫定日本語案: MDN — font-display — the CSS spec reference Google’s own docs リンク to for value definitions.

暫定日本語案: Bing / Microsoft

• 暫定日本語案: Fast Front-End パフォーマンス for Microsoft Bing (Bing 検索 Quality Insights, Aug 2022) — documents font preloading as a production technique on Bing’s own results ページ. Note: this post confirms the preload mechanism only; it doesn’t cover font-display, FOIT/FOUT, CLS, or LCP by name.

暫定日本語案: Quotes from the source

暫定日本語案: On-the-record statements from Google’s Chrome/web.dev docs and Bing engineering. Font 暫定日本語案: loading lives in the rendering/パフォーマンス spec area, so the primary sources here are 暫定日本語案: the Chrome and web.dev teams (not 検索 Relations) — there is no on-record 検索 暫定日本語案: team quote calling font-display a ranking topic, and I’m not going to invent one.

暫定日本語案: Google — web.dev (Chrome team)

• 暫定日本語案: “Both approaches can cause layout shifts. Even if the text is invisible, it’s 暫定日本語案: still laid out using the fallback font, so when the web font loads, the text block 暫定日本語案: and the surrounding コンテンツ shift” 暫定日本語案: — web.dev, Optimize Cumulative Layout Shift. 暫定日本語案: Jump to quote
• 暫定日本語案: “The fallback font is swapped with the web font, incurring a Flash of Unstyled 暫定日本語案: Text (FOUT). ‘Invisible’ text is displayed using the fallback font until a web font 暫定日本語案: is available and the text is made visible (FOIT—flash of invisible text).” 暫定日本語案: — web.dev, Optimize Cumulative Layout Shift. 暫定日本語案: Jump to quote
• 暫定日本語案: “If you set a font-display value of anything other than auto or block, then 暫定日本語案: text will always be visible during load, and LCP won’t be blocked on an additional 暫定日本語案: network request.” 暫定日本語案: — web.dev, Optimize Largest Contentful Paint. 暫定日本語案: Jump to quote

暫定日本語案: Bing — preloading fonts in production

• 暫定日本語案: Bing’s engineering team describes preload tags in the <head> that tell the 暫定日本語案: browser to start downloading its custom web fonts immediately; without those tags, 暫定日本語案: the browser wouldn’t fetch the fonts until it had parsed the CSS and encountered 暫定日本語案: matching elements — so preloading makes them available in time for text rendering. 暫定日本語案: Read the post

暫定日本語案: Note: the Bing point above is paraphrased from the Aug 2022 Bing post rather than quoted verbatim; the post confirms the preload technique in production, not a full CWV/font-display doctrine, so don’t read a broader Bing stance into it. The web.dev quotes with #:~:text= deep リンク jump straight to the quoted passage on the live ページ.

暫定日本語案: Font-loading checklist

暫定日本語案: A quick pass to make sure fonts aren’t quietly wrecking your Core Web Vitals:

• 暫定日本語案: [ ] Every custom @font-face (or Google Fonts URL) sets a deliberate 暫定日本語案: font-display value — not the browser default.
• 暫定日本語案: [ ] Body text uses font-display: optional (or a metrically-matched swap) to 暫定日本語案: avoid a swap-driven layout shift.
• 暫定日本語案: [ ] The one or two fonts used above the fold are preloaded with 暫定日本語案: <link rel="preload" as="font" type="font/woff2" crossorigin>.
• 暫定日本語案: [ ] You’re not preloading every weight — only what’s needed for the initial 暫定日本語案: render.
• 暫定日本語案: [ ] The preload’s href, as="font", type, and crossorigin match the real 暫定日本語案: @font-face request (checked in the Network panel) — no unused preload, no 暫定日本語案: duplicate download.
• 暫定日本語案: [ ] Your font-family stack names a sensible system fallback, not just the custom 暫定日本語案: font.
• 暫定日本語案: [ ] If a swap still shifts, fallback metrics are matched (size-adjust, 暫定日本語案: ascent-override, descent-override, line-gap-override).
• 暫定日本語案: [ ] Fonts are served as WOFF2 and subset to the characters/weights you 暫定日本語案: actually use.
• 暫定日本語案: [ ] Google Fonts embeds include a display parameter and a preconnect to 暫定日本語案: fonts.gstatic.com.
• 暫定日本語案: [ ] Variable fonts are only used when you render multiple variants — otherwise a 暫定日本語案: single static weight may be lighter.
• 暫定日本語案: [ ] You’ve confirmed with PageSpeed Insights / Lighthouse that fonts aren’t the LCP 暫定日本語案: element or a CLS culprit.

暫定日本語案: The mental models

暫定日本語案: 1. Fonts hit two vitals through two mechanisms. 暫定日本語案: LCP: a render-blocking font hides your largest text element until it loads. CLS: the 暫定日本語案: fallback→web-font swap changes text metrics and reflows. Fix them as two separate 暫定日本語案: problems, because one fix (swap) helps LCP but leaves CLS untouched.

暫定日本語案: 2. FOIT vs. FOUT — both fail, differently. 暫定日本語案: FOIT (invisible until loaded) risks a rendering delay → LCP. FOUT (fallback then 暫定日本語案: swap) risks a layout shift → CLS. There is no “safe default”; you have to choose and 暫定日本語案: mitigate.

暫定日本語案: 3. The font-display decision. 暫定日本語案: optional = a ~100ms window, then commit with no later swap (best for CLS-sensitive 暫定日本語案: body text). swap = show text now, guarantee the brand font eventually (best for 暫定日本語案: branding, accept a small shift). Mix them per element rather than one value 暫定日本語案: everywhere.

暫定日本語案: 4. Discovery vs. render. 暫定日本語案: Preload fixes discovery (the browser learns about the font early). font-display 暫定日本語案: fixes render behavior (what shows while it loads). Fallback-metric matching fixes 暫定日本語案: the shift itself. They’re three different levers — you often want all three.

暫定日本語案: 5. The good / better / best ladder. 暫定日本語案: Good: preload your fonts (better still, same-origin, to drop the extra connection). 暫定日本語案: Better: font-display: optional, paired with preload, so a slow font just shows a 暫定日本語案: default and caches for next time. Best: use a system font — nothing loads, so no 暫定日本語案: delay and no shift.

暫定日本語案: Font loading — cheat sheet

暫定日本語案: font-display values (block / swap periods, per web.dev):

暫定日本語案: Figures above are web.dev’s documented Chromium behavior. The CSS spec itself only 暫定日本語案: defines block/swap period categories (short, extremely small, infinite, none) and 暫定日本語案: leaves exact timing to the browser — verify current numbers for the browser you’re 暫定日本語案: testing.

暫定日本語案: The two failure modes

• 暫定日本語案: FOIT = invisible until loaded → risks delaying LCP.
• 暫定日本語案: FOUT = fallback then swap → risks a layout shift → CLS.
• 暫定日本語案: Both cause CLS once the swap happens; only fallback-metric matching or optional 暫定日本語案: prevents it.

暫定日本語案: The fixes, in priority order

1. 暫定日本語案: Use a system font (nothing loads).
2. 暫定日本語案: Preload the critical font (as="font" type="font/woff2" crossorigin).
3. 暫定日本語案: Set font-display (optional for body, swap for branding).
4. 暫定日本語案: Match the fallback’s metrics (size-adjust, ascent-override, 暫定日本語案: descent-override, line-gap-override).
5. 暫定日本語案: Subset + WOFF2 to shrink the file itself.

暫定日本語案: Google Fonts fast facts

• 暫定日本語案: Add &display=swap (or optional/fallback) to the CSS2 URL to set 暫定日本語案: font-display without self-hosting.
• 暫定日本語案: Still a render-blocking stylesheet + a separate font request — add preconnect to 暫定日本語案: fonts.gstatic.com.
• 暫定日本語案: Self-hosting removes the extra DNS/connection hop.

暫定日本語案: Diagnose

• 暫定日本語案: PageSpeed Insights / Lighthouse “Font display insight” (was the standalone “Ensure 暫定日本語案: text remains visible during webfont load” audit before Lighthouse 13).
• 暫定日本語案: Chrome DevTools パフォーマンス + Network panels — see when fonts load relative to 暫定日本語案: first paint and shifts.

暫定日本語案: Font-loading myths and mistakes

暫定日本語案: Each of these is a real, common audit finding — with why it’s wrong and what to do 暫定日本語案: instead.

暫定日本語案: “font-display: swap fully solves my CLS problem.” 暫定日本語案: Why it’s wrong: swap fixes FOIT (text is visible immediately, good for LCP and 暫定日本語案: the Lighthouse audit) but it guarantees FOUT — and if the fallback and web font 暫定日本語案: differ in size, the swap still shifts the layout. Google’s Lighthouse docs note FOIT 暫定日本語案: and FOUT have the same impact on CLS once the swap happens. 暫定日本語案: Do instead: pair it with a metrically-matched fallback (or use optional), so the 暫定日本語案: swap doesn’t move anything.

暫定日本語案: “Preloading a font always speeds up my ページ.” 暫定日本語案: Why it’s wrong: web.dev is explicit that preload comes at the cost of taking 暫定日本語案: browser resources away from loading other resources. Preloading fonts you don’t need 暫定日本語案: above the fold delays more important work. 暫定日本語案: Do instead: preload only the one or two fonts needed for the initial render.

暫定日本語案: “font-display: optional means the custom font never loads.” 暫定日本語案: Why it’s wrong: it loads and is cached — it’s just not used on that specific ページ 暫定日本語案: load if it misses the ~100ms window. Once cached, later ページ views typically show it 暫定日本語案: immediately. 暫定日本語案: Do instead: use optional for CLS-sensitive body text without worrying that 暫定日本語案: returning visitors miss the brand font.

暫定日本語案: “Any font-display value fixes the Lighthouse ‘invisible text’ warning, so I’m 暫定日本語案: done.” 暫定日本語案: Why it’s wrong: passing that audit is necessary but not sufficient — the swap 暫定日本語案: layout shift is a separate, related-but-distinct problem. 暫定日本語案: Do instead: after clearing the audit, check CLS and fix the fallback metrics if the 暫定日本語案: swap still shifts.

暫定日本語案: “Google Fonts are auto-optimized and can’t cause CWV problems.” 暫定日本語案: Why it’s wrong: a copy-pasted Google Fonts embed is still a render-blocking 暫定日本語案: stylesheet request plus a separate font request unless display and 暫定日本語案: preconnect/preload are configured. “It’s from Google so it’s fine” is a common 暫定日本語案: real-world audit miss. 暫定日本語案: Do instead: add &display=, preconnect to fonts.gstatic.com, and preload the 暫定日本語案: critical weight.

暫定日本語案: “Font loading is a UX-only concern with no SEO relevance.” 暫定日本語案: Why it’s wrong: CLS and LCP are Core Web Vitals and part of Google’s ページ 暫定日本語案: experience signals. Font choices sit directly in a technical SEO’s remit. 暫定日本語案: Do instead: treat font loading as part of your CWV work — while keeping it in 暫定日本語案: proportion (ページ experience is a tiebreaker, not a primary factor).

暫定日本語案: Find the fonts loading on a ページ

暫定日本語案: A quick DevTools Console snippet to list every font face the browser actually loaded, 暫定日本語案: and whether each is done — useful for spotting a heavy or slow font.

暫定日本語案: Chrome DevTools Console

// List loaded font faces and their status
[...document.fonts].map(f => ({
  family: f.family,
  weight: f.weight,
  style: f.style,
  status: f.status,          // "loaded", "loading", "unloaded", "error"
  display: f.display,        // the font-display value in effect
}));

// When did fonts finish loading? (relative to navigation start)
document.fonts.ready.then(() =>
  console.log("All fonts ready at", performance.now().toFixed(0), "ms")
);

暫定日本語案: Watch for font-driven layout shifts

暫定日本語案: Paste this in the Console to log CLS entries as they happen, including the elements 暫定日本語案: that moved — handy for confirming a font swap is the culprit.

暫定日本語案: Chrome DevTools Console

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (!entry.hadRecentInput) {
      console.log("Layout shift", entry.value.toFixed(4),
        entry.sources?.map(s => s.node));
    }
  }
}).observe({ type: "layout-shift", buffered: true });

暫定日本語案: Check that a font file is WOFF2 and reasonably sized

暫定日本語案: Fonts should be WOFF2 and subset. Point these at a font URL to check its size and 暫定日本語案: type.

暫定日本語案: macOS / Linux

curl -sI https://example.com/fonts/brand.woff2 \
  | grep -iE "content-type|content-length"

暫定日本語案: Windows / PowerShell

$r = Invoke-WebRequest -Method Head https://example.com/fonts/brand.woff2
$r.Headers["Content-Type"]; $r.Headers["Content-Length"]

暫定日本語案: A large content-length (well into the hundreds of KB for a single weight) is a 暫定日本語案: subsetting/compression opportunity.

暫定日本語案: Which font-loading strategy fits the ページ?

暫定日本語案: Prove a font-loading change worked

暫定日本語案: Critical-font preload test

暫定日本語案: Test to run: reload with cache disabled and inspect the font request’s initiator and start time in the Network panel. Expected result: the intended critical font starts early and is reused by CSS without a duplicate download. Failure interpretation: the preload attributes do not match the CSS request or the font is not actually critical. Monitoring window: immediate. Rollback trigger: duplicate requests, console errors, or contention that delays more important resources.

暫定日本語案: Font-swap stability test

暫定日本語案: Test to run: throttle the load while recording the パフォーマンス panel Layout Shifts track. Expected result: fallback text remains visible and the final font does not create a measurable shift. Failure interpretation: fallback metrics still differ or the swap happens too late. Monitoring window: immediate across supported breakpoints. Rollback trigger: hidden text, clipped text, or worse CLS.

暫定日本語案: Field-vitals test

暫定日本語案: Test to run: compare post-release LCP and CLS for the changed template with the prior RUM baseline. Expected result: the targeted metric improves without degrading the other. Failure interpretation: the font was not the bottleneck or the strategy traded loading speed for instability. Monitoring window: RUM as traffic arrives; CrUX over its rolling window. Rollback trigger: either field metric worsens consistently.

暫定日本語案: Resources worth your time

暫定日本語案: My related writing

• 暫定日本語案: What Is Cumulative Layout Shift (CLS) & How To Improve It (Ahrefs) — my CLS guide, including the preload + font-display: optional fix for font-driven shifts.
• 暫定日本語案: What Is Largest Contentful Paint (LCP) & How To Improve It (Ahrefs) — the good/better/best font ladder for LCP.
• 暫定日本語案: What Are Core Web Vitals (CWVs) & How To Improve Them (Ahrefs) — where CLS and LCP fit in the bigger CWV picture.
• 暫定日本語案: Patrick Stox on the Ahrefs blog — the rest of my technical SEO writing.

暫定日本語案: From around the industry

• 暫定日本語案: Fixing Layout Shifts Caused by Web Fonts (DebugBear, Umar Hansa) — end-to-end: measure → find the font → font-display → better fallback → adjust metrics.
• 暫定日本語案: Ensure text remains visible during webfont load (DebugBear) — the Lighthouse-audit-specific troubleshooting angle.
• 暫定日本語案: How to avoid layout shifts caused by web fonts (Simon Hearne) — a practitioner-level deep dive.
• 暫定日本語案: FOUT, FOIT, FOFT (CSS-Tricks) — the canonical explainer for the terminology.
• 暫定日本語案: A New Way To Reduce Font Loading Impact: CSS Font Descriptors (Smashing Magazine) — the size-adjust/ascent-override/descent-override/line-gap-override technique in depth.
• 暫定日本語案: How to Reduce Layout Reflow When Using Web Fonts (Material Design) — a practical CSS-descriptor walkthrough from Google’s Material team.
• 暫定日本語案: We shipped font-display to Google Fonts (Addy Osmani) — the display URL parameter and why it removed the need to self-host for font-display control.

暫定日本語案: Test yourself: Font Loading

暫定日本語案: Five quick questions on how web fonts affect Core Web Vitals. Pick an answer for each, then check.

変更履歴