More font files, lower score — except on the platforms that choose the fonts for you

Five files, 200 kilobytes, six per cent of the page

436 of the 452 sites load at least one font file. Here is what they load:

	Files	Weight	Families
10th percentile	2	57 KB	1
25th percentile	3	102 KB	2
Median	5	200 KB	4
75th percentile	8	348 KB	6
90th percentile	12	536 KB	8
Maximum	38	4.7 MB	21

The last column is the fuzziest and the most interesting. Four families at the median means the median site is not shipping four weights of one typeface; it is shipping four different typefaces, most of them at roughly one file each. The heaviest site in the sample reaches for 21 of them.

Against the page they sit in, none of this is large. Fonts are 5.95% of total page weight at the median and 21.6% at the 90th percentile, on sites whose pages we have already weighed in full and found to run to megabytes. That is the first thing to settle, because it decides how the rest of this study can be read: if font count turns out to track the score, the reason cannot be the bytes.

Where they come from is more lopsided than what they weigh. 162 of the 436 sites pull at least one font from Google Fonts. Only 111 serve every font from the host that served the document; 237 serve none of them from it. That second number says less than it looks like: on a hosted builder the whole page arrives from the vendor’s asset domain, fonts included, so “not the document host” is a structural fact about the platform rather than a decision anyone made.

The count sorts the sample, and half of that is page size

Putting each site into a band by font-file count and taking the median mobile score of each band produces a clean slope:

Font files	Sites	Median mobile score
0	16	95
1–2	79	70
3–5	140	60.5
6–10	155	55
11 or more	62	52

Ignore the first row. Five of those sixteen sites returned fewer than ten requests in total, which describes a parking page or a blocked crawl rather than a fast site, and a band that small cannot survive losing a third of itself.

The rest of the slope is real and mostly borrowed. A site with twelve font files is a site with more of everything, so we split the sample by total request count first and looked at the font bands inside each slice:

Requests on the page	1–2 files	3–5 files	6–10 files	11+ files
Under 50	88 (n=28)	74.5 (n=22)	71 (n=9)	–
50–99	65 (n=18)	61.5 (n=58)	61 (n=51)	60 (n=21)
100–149	63 (n=19)	48.5 (n=22)	50.5 (n=40)	49 (n=19)
150 or more	55.5 (n=14)	54 (n=38)	47 (n=55)	41 (n=21)

Read down a column and you see page complexity doing its work: the same font count loses between 20 and 33 points as the page grows. Read across a row and the font count is still doing something, at roughly half the strength of the raw table. Seventeen points across the light pages, fifteen across the heaviest. The 50–99 row is the exception and it is flat, which we have no explanation for and are not going to invent one for.

The slope needs someone to have chosen

Splitting the same comparison by platform is where the study stops being a restatement of “heavy pages score badly”. These are the ten platforms with at least twenty sites in the sample:

Platform	Sites	Median files	1–2	3–5	6–10	11+
WordPress	55	5	70	66	54.5	32
WooCommerce	56	6.5	73	62	48	41.5
Elementor	30	6	82	69	57.5	53.5
Wix	30	4.5	78	71	64	–
Bitrix	23	4	62	57	49	–
Tilda	34	5	51.5	55	50.5	46
Duda	48	8	85	72	64	70.5
Webflow	32	5	57.5	46	36	58
Squarespace	35	9	–	42	50	49
Next.js	29	6	55	46	51	–

On the WordPress family the slope is not just present, it is the steepest thing in this study: 70 down to 32 on WordPress itself, 73 down to 41.5 on WooCommerce. On Duda, Webflow and Squarespace it reverses at the heavy end — the sites loading the most fonts score the same or better than the sites loading a middling number.

Those reversals sit on small bands (nine to fifteen sites each) and we would not build a theory on any one of them. Three platforms breaking the same way is harder to wave off, and the thing those three share is who picks the fonts. On WordPress the font count is a by-product of decisions: this theme, that page builder, a plugin that brings its own icon set, a second typeface for headings someone liked. Each of those decisions brings other things with it, and the font count is a cheap way of counting them. On a hosted builder the template arrives with its font set already chosen and served from infrastructure the vendor tuned, so a site with eleven font files is not a site where eleven decisions were made.

The count, in other words, is not measuring fonts. It is measuring how much was added to the page by hand, and it only works where things are added by hand.

Font Awesome is 38% of the payload and none of the score

75 of the 452 sites load an icon font. 70 of those are Font Awesome; the rest are IcoMoon, Fontello, Remix Icon and Simple Line Icons, one or two each. They live mostly on Duda (27 sites), WooCommerce (18) and Elementor (11).

The median icon font on those sites is 96 KB, and that is 38% of everything the site spends on fonts. Sites carrying one ship 314 KB of fonts at the median; sites with web fonts but no icon font ship 165 KB. One icon set roughly doubles the font budget.

It buys a handful of arrows and social glyphs, because a full icon font contains the entire catalogue. web.dev puts the general case plainly:

Font files typically include a large number of glyphs for all the various characters they support. But you may not need all the characters on your page and can reduce the size of font files by subsetting fonts.

And then the part we did not expect. The median mobile score of the 75 sites with an icon font is 56. For sites with web fonts and no icon font it is 58. The single largest identifiable chunk of the font payload, the one with the clearest waste story attached to it, does not show up in the score at all.

That is consistent with the rest of this study rather than against it: at 96 KB the icon font is about 3% of the median page, and Lighthouse’s mobile score is not sensitive to 3% of the bytes. It is inconsistent with how the problem is usually sold, ours included. An icon font is a bandwidth and data-cost finding. It is not a score finding, and a study that let those blur would be the kind we complain about.

What subsetting actually gives back

We can measure the ceiling on that waste, because our proxy subsets icon fonts to the glyphs the page uses and both sides of the comparison are in the same audit. On the 64 sites where the original run and the proxied run both produced a comparable inventory, the icon payload shrank on 41 of them, from a median of 96 KB to 1 KB — just under 4 MB removed across those 41 sites in total. Four Duda sites went from 172 KB to 1 KB each.

On the remaining 23 it did not shrink, and on three of those the proxied run came back with a materially larger font payload than the original. We have not established why for every case and are not going to guess in public; part of it is by design, since ligature-based icon fonts are left alone deliberately, and part of it is ours to go and find. The honest summary of our own number is that subsetting works on roughly two thirds of the sites where it applies, and the number to quote is 41 of 64 rather than the median cut.

What the count is good for

It is a triage signal, and a narrow one. Count the font files on a slow page: it takes one filter in a network panel.

If the site runs WordPress and the answer is in double digits, the fonts are worth opening, not because 500 KB of fonts will cost the score by itself but because in this sample that count reliably came with everything else that does. If the site is on a hosted builder, the count told us nothing we could rely on, and the time is better spent elsewhere.

If there is an icon font in the list, it is probably a third of the font weight and it is probably drawing six icons. Removing it will not move the score in the direction anyone promised. It will make the page smaller for every visitor on a metered connection, which is a smaller claim and a true one.