Anatomy of a 17-Second Page: How One Font Slowed Our Site
4 November 2026 / 5 min read
A studio that sells well-built websites should not have a slow one. Ours did.
When we ran a technical audit of our own site in September, the mobile test reported a Largest Contentful Paint of 17.1 seconds, meaning that on a simulated mid-range phone it took that long for the main content to appear. Desktop came in at 4.2 seconds. Google's target is under 2.5.
We had written about this problem for clients. Why your website is slow explains what the metrics measure and the usual fixes. This post is different: it is a teardown of our own page, because the cause was not any of the usual suspects.
What the audit found
The total page weight was 3,946 KiB. A single custom font file accounted for 1,443 KiB of that, more than a third of everything the page downloaded.
Resource | Size | Share of page |
One custom font file | 1,443 KiB | Over a third |
Everything else (images, scripts, styles, other fonts) | About 2,500 KiB | The rest |
Total | 3,946 KiB | 100% |
A good display font, properly prepared for the web, is usually between 15 and 40 KiB. This one was more than thirty times the upper end of that range.
The same audit found 29 or so other issues, and most were worth fixing. But none of them came close. Fixing this one file would do more than the rest combined.
Why a font can do this
It feels wrong that a font, which is just letter shapes, could outweigh photographs. It happens for four reasons.
Full character sets. A font file made for print includes thousands of glyphs: every accented letter, symbol and script a designer might ever need. A website in English needs a few hundred at most.
Variable or multi-style fonts. A single file can contain many weights and widths. That is convenient for design and expensive for download.
The wrong format. Older formats are larger than WOFF2, the compressed format built for the web.
The font blocks the page. Until the font loads, the browser may hide the text, or swap it late and shift the layout. When the largest element on the page is a headline, the headline waits for the font, so the font decides your LCP.
That last point is the real mechanism. It is not just that 1.4 MB is large. It is that the biggest thing on the page was waiting for it.
How to find the same problem on your own site in 15 minutes
Run the page through PageSpeed Insights and note the Largest Contentful Paint. Check mobile, not desktop.
Open the "Diagnostics" section and look for items such as "Avoid enormous network payloads" and "Ensure text remains visible during webfont load".
Open Chrome's developer tools, go to the Network tab, filter by Font and reload. Sort by size.
Compare each file against a sensible budget. Anything over about 100 KiB for a single font deserves a question.
Check what is being loaded that you never use. Every weight and style listed costs time even if nothing on the page uses it.
If one font file dominates, you have found your problem.
What we did about it
The fix has four steps, and the same four apply to most sites.
1. Subset the font. Remove every glyph the site does not use, keeping the Latin characters and punctuation we need. This is where most of the savings come from.
2. Serve it as WOFF2. It compresses better than older formats and is supported by every current browser.
3. Limit the weights. Two or three styles are plenty. Each extra one is another download.
4. Tell the browser how to behave while it loads. Use a swap or optional display setting so text appears immediately in a fallback font instead of waiting. And preload the one font that the headline needs, so the browser asks for it early.
We made these changes as part of rebuilding the site. The font file is now about 40 KiB, at the top of the range we were aiming for. On 31 October 2026 we re-ran Lighthouse, a lab test like the one behind the original number, on the home page. The Largest Contentful Paint on a simulated mobile phone is 1.6 seconds, down from 17.1, and the page scores 96 out of 100 for performance.
The Wix factor
Our site runs on Wix, which matters for this fix. In the standard Wix editor, custom fonts are uploaded through the font manager, and you do not control the file format or subsetting in the way you would on a hand-built site. Our site has since been rebuilt as a custom front end on Wix, so we now handle fonts in code. For a site built in the editor, the practical options are to upload a pre-optimised, subsetted WOFF2 version of the font, to switch to a lighter font from the platform's own library for body text, or to reserve the custom font for the headline only.
That is a limitation, and we will not pretend otherwise. It is also why we raise font strategy early in design, instead of discovering it in an audit. We write more about what Wix does and does not handle in our guide to SEO on Wix.
What this taught us
Lab numbers are worth taking seriously. A simulated test is not a field measurement, as we explained in the earlier post, but a gap this large is real.
The biggest problem is often not the one you would guess. We expected images or scripts. The cause was a single asset chosen for aesthetic reasons and never weighed.
Design decisions have performance costs. Typography is a design choice with a download size. The two conversations should happen together.
Fix the biggest item first. A list of 30 issues is demoralising and unnecessary. One of them was worth more than the other 29.
Frequently asked questions
Why is my website slow on mobile but fast on desktop? Mobile tests simulate slower processors and networks, so heavy assets hurt far more. Check mobile results first, because that is where most visitors and Google's assessment are.
How big should a web font file be? A well-prepared display font is typically 15 to 40 KiB as WOFF2. Body fonts with several weights add up, so keep the total font download modest.
Can a custom font hurt my SEO? Indirectly. A heavy font can slow the page and worsen Largest Contentful Paint, one of Google's Core Web Vitals, which can affect how the page performs for visitors.
What is font subsetting? Removing the characters you do not need from a font file, so the browser downloads only what the site uses.
Does Wix let me control font loading? Only partly in the standard editor. You can choose which fonts and weights to use and upload your own files, but you have less control over loading behaviour than on a custom-built site.
Want to find the heaviest file on your site? Our free audit identifies the assets and scripts slowing your pages, and ranks what to fix first. Request your Free Website Audit →
