How Web Font Formats Evolved
To understand why so many stores are still loading unnecessary font files, it helps to know a bit of history.
In the early days of custom web fonts, browser support was a mess. Different browsers required different file formats. EOT was a Microsoft format built for Internet Explorer. TTF was the standard desktop format that browsers eventually started accepting for web use. WOFF came along as a compressed, web-optimized container for that same data. WOFF2 followed with better compression still.
Developers responded to this fragmentation the only sensible way they could: include every format and let the browser pick whichever one it understood. A typical font declaration from that era might list four or five formats in sequence. This was not bad practice. It was the correct approach at the time.
The problem is that it became baked into themes, starter templates, and code snippets that are still in circulation today, long after the browsers that needed those formats stopped mattering.
What the Current Browser Landscape Actually Looks Like
WOFF2 now has roughly 97 percent browser support. Every major browser on every major platform has supported it for years. The ones that do not are either ancient or obscure enough that they are unlikely to show up in your analytics in any meaningful number.
EOT has been irrelevant since Internet Explorer reached end of life. TTF files carry no compression and can run three to four times larger than the WOFF2 equivalent for the same font. WOFF was a real improvement over TTF when it arrived, but it has been superseded.
When a browser encounters a font declaration listing multiple formats, it downloads the first one it supports and ignores the rest. So for nearly all your visitors, WOFF2 is what gets used regardless of what else is listed. The other entries are parsed but the files go unloaded.
Where things go wrong is when theme code is outdated or sloppily maintained. We regularly see CSS that declares fallback formats pointing to files that do not actually exist in the store’s assets. The browser still tries to resolve those references. Failed requests carry a cost even when they fail fast.
A Real Example
Mobile PageSpeed score when we started: 41. During the audit, we found the theme was declaring multiple font formats for every weight — and several of the referenced fallback files were simply missing from the assets folder.
We removed the legacy format declarations, kept only WOFF2, and confirmed the Regular and Bold weights were loading cleanly without broken references. That change alone moved the mobile score up by 10 points.
The store finished at 71. The rest of the improvement came from image optimization, fixing how the hero image was being lazy loaded, and deferring some slider scripts that were blocking render. The font cleanup took far less time and produced a result in the same range.
The Tradeoff Worth Understanding
Cutting legacy font formats means that visitors on browsers without WOFF2 support will not see your custom typeface. They will get your system font stack instead, typically something like Helvetica or Arial depending on their device.
For most Shopify stores this is a reasonable call. The number of people affected is genuinely small, and the experience they get is still functional. You are not breaking anything for them, just serving a different font. The performance benefit for everyone else is real and measurable.
If typographic consistency across every possible visitor is a hard requirement for your brand, it is worth thinking through. But optimizing for the 97 percent rather than defending against the 3 percent is the right tradeoff for the vast majority of stores.
How to Audit Your Font Stack
Open your theme code and search for instances of @font-face. Look at the src property in each one. If you see eot, ttf, or woff listed alongside woff2, those are the candidates to remove.
Then cross-reference the file names against your assets folder. If a referenced file is not there, that declaration needs to go or be corrected. A missing file generates a failed network request on every page load regardless of whether any visitor would have used it.
Here is what a cleaned-up font declaration looks like:
Once you know what to clean up, consolidate each font declaration to a single WOFF2 source and confirm the file exists. While you are in there, check that you are only loading weights your design actually uses. Loading a font weight that never appears on a page is a separate but related issue worth catching at the same time.
Keeping It in Perspective
Font cleanup is not a replacement for a broader performance strategy. Image optimization, proper lazy loading, and JavaScript management will always move bigger numbers on most stores.
But font issues are common, easy to miss, and straightforward to fix once you know what you are looking at. If your store runs on an older theme or one that has been modified over the years, there is a real chance something in your font declarations is outdated. It is a low-effort audit with meaningful upside, and it is worth checking before you assume the problem is somewhere more complicated.