Page speed is one of those things that's easy to deprioritize until you're staring at a PageSpeed Insights report wondering why your clean, minimal Webflow site is making external API calls you didn't ask for.

That's exactly what happened to me recently. I ran a speed test on a site I'd built, and buried in the results were calls going out to the Google Fonts API. The problem? I hadn't installed a single Google Font on the site. System fonts only. So what was going on?

The Gotcha

Here's what Webflow doesn't make obvious: removing Google Fonts from your Site Settings doesn't automatically remove them from your site. If any class or HTML element still has a Google Font assigned to it in the Style panel, Webflow will continue loading the Google Fonts API script on every page load — even if that font is technically "uninstalled."

In my case, four classes had Google Fonts hanging on from an earlier stage of the project. They weren't visible in any meaningful way. The site looked fine. But under the hood, the browser was still making that external request on every load, adding latency before the page could fully render.

Why It Matters

Every external request your site makes adds load time. The Google Fonts API call isn't catastrophic, but it's a render-blocking resource — meaning the browser has to wait on it before it can finish painting the page. On a site you've otherwise optimized, it sticks out. It also has GDPR implications, since loading the Google Fonts API sends your visitors' IP addresses to Google's servers.

How to Fix It

The fix is quick once you know where to look. In Webflow's Designer:

1. Open the Style Selector panel and search for the name of the Google Font showing up in your source code or speed test
2. This will surface every class and HTML tag that still has that font assigned
3. Go into each one and update the font to your actual intended font — a system font, a custom uploaded font, whatever you're using
4. Once every instance is cleared, go to Site Settings → Fonts → Google Fonts and delete the font entry
5. Republish the site
6. Verify by opening Chrome DevTools, going to the Network tab, refreshing the page, and confirming that webfont.js is no longer loading

That last step is worth doing. It's a quick sanity check that confirms the API call is actually gone and not just hidden somewhere you haven't found yet.

The Takeaway

Page speed wins aren't always dramatic. Sometimes it's catching a rogue API call that's been quietly adding latency to every page load. If you're doing a speed audit on a Webflow site — yours or a client's — this is worth checking early. It takes five minutes to diagnose and fix, and it's one less external dependency your site is carrying.

If you're serious about performance, get in the habit of auditing your Network tab after every major redesign or font system change. What you think is gone isn't always gone.