Where the Shopify Font Loading Lag Was Actually Coming From

Open a product page on your Shopify store in a Chrome incognito window. Open DevTools to the Network tab, filter by "Font", and reload with throttling set to Fast 4G. Count how many font files load, watch how many fire from fonts.gstatic.com, and time how long the headline stays in its fallback typeface before snapping into the real one. If that snap takes more than half a second, or if the same font file appears in the request list twice, this post is the story of one investigation where every piece of the obvious fix did nothing.

What I checked first

The store was a small home goods brand on Horizon, two weeks past launch. The merchant had pasted their PageSpeed Insights report into our chat and said the design felt "jittery" on phones. The mobile Lighthouse score was 64. The biggest red items were "Ensure text remains visible during webfont load" and a Largest Contentful Paint sitting at 3.8 seconds.

The setup looked standard. One Google Fonts URL in layout/theme.liquid requesting Inter in weights 100 through 900 on a single line. A custom heading font, woff2, uploaded to the theme's Assets folder via a font-picker app. The theme editor's typography panel showed both fonts selected. The live store rendered both. By every visible signal in the admin, this should have worked.

So I ran the standard playbook. Trimmed the Google Fonts URL down to weights 400 and 700, which is all Inter actually needed for this theme. Added font-display: swap to the heading font's @font-face declaration in assets/base.css. Added a manual <link rel="preload"> for the woff2 file at the top of <head>. Reran Lighthouse. The score moved by two points. The headline still flashed.

That is when this became a shopify font loading investigation rather than a fix.

Why the swap fix did nothing

The first piece of the standard shopify font loading playbook I had to throw away was font-display: swap in the CSS file. That fix is in every tutorial. It is wrong for most Shopify themes by default.

Here is the part that took me half a day to see. Shopify themes render their font declarations through a Liquid filter, not through static CSS. When theme.liquid contains {{ settings.type_body_font | font_face }}, that filter generates a complete @font-face block at render time, with its own font-display value baked in. Whatever you put in assets/base.css is a second @font-face block for the same font family, and the browser picks the one that wins the cascade. In this theme, the filter-generated block won, and my CSS edit was background noise.

The actual fix is appending the parameter to the filter call itself: {{ settings.type_body_font | font_face: font_display: 'swap' }}. That parameter has been documented in a Shopify Community thread since October 2020. It is not in Shopify's main help docs anywhere I can find. If your fonts are managed through the theme settings UI, the filter is where the fix lives. The CSS file is somebody else's stylesheet, and the filter overwrites it.

There is a related trap on Google Fonts specifically. font-display: swap only does anything for self-hosted font files. When a font is served from fonts.gstatic.com, the swap directive in your CSS never reaches the actual font request - Google's stylesheet has its own font-display behavior, which you do not control. So if your store uses Google Fonts at all, the CSS font-display: swap is doing nothing twice over: it is in the wrong file, and the file it lives in has no authority over a font served by a third-party CDN.

I appended font_display: 'swap' to the Liquid filter call for the body font. The body font stopped flashing. The headline, served through the custom font app, still flashed.

The preload tag that was lying to the browser

The next obvious move was preloading the heading font. I had already added a <link rel="preload"> for the woff2 file. The Network tab confirmed the preload was firing on time, around 80ms after the document started parsing. The font itself was downloading well before the H1 needed it.

And the headline still flashed.

I spent an embarrassing amount of time on this one. I checked the preload's as attribute (correct: font). The type attribute (correct: font/woff2). The URL matched the URL the @font-face rule was requesting. The file came back with a 200. The browser reported it as a preload hit in the Coverage panel. Everything looked right.

The thing I had missed was the crossorigin attribute. Without it, the browser treats the preloaded font as a separate resource from the font the @font-face rule asks for, because fonts are CORS-restricted by default. So the preload downloaded the file, the @font-face rule fired, the browser said "wait, that preload was for a different request" and downloaded the file again. The Network tab showed both requests, but in the noise of forty other resources I had stopped noticing them.

Adding crossorigin to the preload tag fixed the double download. It also moved the Lighthouse score four points, which was the first real signal of progress I had seen all afternoon.

There is a Shopify-specific version of this trap that is worse. The preload_tag Liquid filter, which Shopify's Theme Check tool tells you to use instead of hand-written preloads, did not include the crossorigin attribute until mid-2025. So any store that migrated to preload_tag between 2023 and mid-2025 in response to Theme Check's warning was silently double-loading its fonts on every page. The current correct syntax is {{ settings.type_body_font | font_url | preload_tag: as: 'font', type: 'font/woff2', crossorigin: true }}. If you have a Shopify store that was built any time in the last three years, this is worth grepping for.

A two-stage flash hiding underneath

The body font had stopped flashing. The heading font's double download was gone. The Lighthouse score was now 78. And the headline still, infuriatingly, flashed - just for a shorter duration than before.

This is where the investigation went somewhere I had not expected. The merchant had added an "Additional CSS" block in the theme editor that overrode the heading font-family one more time, with a slightly different weight. That override was being injected at the bottom of the page's stylesheet bundle, after the main theme CSS, and therefore after the @font-face declarations had already resolved against the theme default. The browser would paint the headline once in the theme's default heading font (which had finished loading), and then a second time when the override's font-family applied.

This is a two-stage FOUT. The first stage is the standard fallback-to-real swap. The second stage is the override re-pointing the heading to a different font that had not been preloaded. From the merchant's perspective, the headline flickers twice and they assume the first fix failed; really, it succeeded, and a second fix is needed.

There is no clean way to control the injection order of Shopify's "Additional CSS" block from inside the theme editor. The only resolution I could find was moving the override out of "Additional CSS" entirely and into a <style> tag inside <head> in theme.liquid, above the main stylesheet link. This is a theme code edit, which is exactly where most non-developer merchants stop. If you have a developer on retainer for one hour, this is what you spend the hour on; if you do not, the first 15 minutes with a help1 expert is free and that is usually plenty to get you to the right line.

What we actually did

Here is the shopify font loading sequence that worked, after the dead ends:

Trimmed the Google Fonts URL to two weights (400 and 700) and confirmed both were actually used by the theme.
Appended font_display: 'swap' to the Liquid font_face filter call for the body font, in theme.liquid.
Added a <link rel="preload"> for the heading woff2, with crossorigin set, immediately below the main <style> block in <head>.
Moved the merchant's font-family override out of "Additional CSS" and into an inline <style> block inside <head>, above the main stylesheet, so the override resolved before first paint.
Verified in Chrome DevTools that there was only one network request per font file, that the preload was a cache hit when the @font-face rule fired, and that the headline rendered in the correct font on the first paint.

Lighthouse moved from 64 to 88. The headline stopped flashing on Fast 4G. On Slow 4G there was still a 200ms shimmer, which is the cost of using a custom heading font at all on a throttled connection. The only fix beyond that is switching to a system font, which the merchant did not want to do.

There were also two things I almost did and decided against. I did not try to subset the heading font, because at 38KB compressed it was not the bottleneck; subsetting matters when you are dealing with a font file in the megabytes. I did not move the heading font upload from the Assets folder to the Content section (which would mean using file_url instead of asset_url), because the existing file was not visibly corrupted. If you ever upload a font and it renders as a different typeface than the source file - same name, completely wrong shapes - that is the Assets folder silently transforming your binary, and you do need to move it to Content. It is a real trap, just not the one I was in.

One thing I have not tested: this investigation was on Horizon, where heading typography is bound to specific CSS custom properties on the body selector. On Dawn or a third-party premium theme, the override mechanics are different, and the "Additional CSS" injection-order problem may not be the load-bearing fix. If you are on Dawn, start at step 2 and stop when the flash stops; you may not need step 4 at all. I have not run the same investigation on a Prestige or Impulse store, and would not assume the same fix works there.

If you want a second pair of eyes on the network waterfall before you start cutting things out of your theme, help1's chat has a saved diagnostic for exactly this shape of problem. We also keep notes on the adjacent symptom in the Shopify page speed CLS questions post, since FOUT and CLS often surface as the same complaint to the merchant even though the fixes are different files.

What I would tell you to check tomorrow morning

The thing I keep coming back to with shopify font loading bugs is that the obvious fix is in the wrong file. Almost every tutorial assumes a static @font-face block in a CSS file. Almost every Shopify theme generates that block dynamically through a Liquid filter, which means the static fix never runs. The first thing to grep for in any shopify font loading investigation is the string | font_face in your theme. If you find it, the fix lives there.

So here is the question worth answering before you reach for a tool: how many font files does your store load on a cold first paint, and how many of them are loading twice? You do not need anyone's app to answer that. You need ten minutes and a Chrome incognito window. The answer is almost always either fine or surprising. Which one is it on your store?