Google Fonts Costs 9 Points of Good LCP

Google Fonts reaches roughly 4.1 million mobile origins, about 43% of the web, and where it loads the site is good on Largest Contentful Paint just 63.0% of the time on mobile versus 72.3% without, a 9.3-point loading gap. Overall Core Web Vitals pass follows the same shape, 40.3% with Google Fonts against 43.9% without. Widen the lens to any web-font loader and the effect holds at 64.4% good loading with versus 73.4% without. That is what typography costs when it is served the default way.

Loading is the part of performance a visitor feels first. A page that stalls before showing its main content loses readers before they see a word, converts fewer of the ones who wait, and ranks lower in Google's index. Largest Contentful Paint captures that exact moment, when the biggest piece of content, often a headline or hero image, finally appears, and when a font is blocking it the whole page feels slow.

The analysis pairs HTTP Archive's technology crawl, which flags whether each site loads Google Fonts or any web-font loader, with the Chrome UX Report, Google's field record of Core Web Vitals from real Chrome users on real devices and networks. Joined together, they cover 9.58 million mobile origins with a field reading, split by whether a font loader was detected. That is the same field signal Google uses for search ranking, not a synthetic lab test.

The pass bar throughout is Google's own. An origin is considered to pass Core Web Vitals only when the 75th percentile of its visitors is good on all three metrics at once: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. Because a font penalty is fundamentally a loading penalty, Largest Contentful Paint is the metric that surfaces it most cleanly, and it is the one this study leans on throughout.

A custom font has to be requested, downloaded, and applied before the text it styles can render the way the designer intended. Until it arrives, the browser either shows nothing or a fallback that later swaps, and either way the largest content element can be delayed. That delay is measurable at scale.

Sites loading Google Fonts are good on Largest Contentful Paint 63.0% of the time on mobile, versus 72.3% for sites without them, one of the larger single-cause loading gaps in our research. Overall Core Web Vitals pass follows the same shape, 40.3% with Google Fonts against 43.9% without. Widen the lens to any web-font loader and the pattern holds, 64.4% good loading with versus 73.4% without.

This is not a niche cost. Google Fonts loads on about 43% of the mobile web, roughly 4.1 million origins, which makes it the single most common way a site takes on the font penalty. The convenience of a one-line embed is real, and so is the third-party connection it opens during the most time-sensitive part of the load.

Because the fonts arrive from another server, the browser has to open a fresh connection, resolve DNS, and negotiate a secure handshake before it can even request the file, and the styled text cannot settle until all of that finishes. Multiply that by the number of weights a typical design pulls in, a regular, a bold, an italic, and the loading budget erodes quickly during the exact window when the page is trying to paint its main content.

One number in the data runs the other way, and it is worth explaining. Font-loading sites actually score higher on responsiveness, 88.1% good Interaction to Next Paint versus 82.4%. That is not the fonts helping. Google Fonts is overwhelmingly deployed on classic and WordPress sites, which run little main-thread JavaScript and therefore respond quickly, while many of the no-font sites are heavier JavaScript apps.

Strip that out and the clean, font-attributable effect is the loading penalty. Layout stability is essentially level between the groups too, so nothing else in the data pulls the pass rate around the way loading does. Fonts are a loading cost, and the more of the critical render they sit in front of, the more they cost. If your largest contentful element is text, a big headline or hero heading, a slow font simply is your Largest Contentful Paint, because the browser has nothing final to paint until the typeface arrives.

The "without" group includes both system-font-only sites and sites self-hosting fonts, so it is not a pure system-font baseline.

The 9.3-point LCP gap, 63.0% good with Google Fonts versus 72.3% without, is the font-attributable cost, and the higher INP on font sites, 88.1% versus 82.4%, is not the fonts helping. Google Fonts clusters on classic and WordPress sites that run little main-thread JavaScript, so they respond quickly for reasons that have nothing to do with the typeface. Strip that confound out and fonts are a loading cost, which is why overall pass still falls to 40.3% from 43.9%.

The cost comes from when and how the font arrives, not from having one. A third-party embed opens a fresh connection, resolves DNS, and negotiates a handshake before it can even request the file, all during the window the page is trying to paint. Self-hosting removes that connection, preloading the one or two critical faces fetches them early, font-display swap keeps text visible immediately, and subsetting ships only the characters you use.

So if you load Google Fonts, the way 4.1 million origins do, and fall short on mobile, treat the typeface as a prime suspect for Largest Contentful Paint, especially when your largest element is a headline. Cut the weights you do not need and load the rest deliberately, and most of the nine points comes back while the design stays exactly as drawn.

Embed this research

Cite this study