Prefer English?
Prefer English? Switch the website language for a better experience.
A performance audit on Webflow follows the same logic as on any CMS -- LCP, INP and CLS remain the three metrics that matter -- but the root causes differ radically. On WordPress, you hunt for poorly coded plugins and bloated themes. On Webflow, the problems almost always come from somewhere else entirely: badly exported images, Interactions animations stacked without any restraint, custom fonts loading in a cascade, or third-party scripts pasted into Custom Code without a second thought.
At Mazette.co, we took over a Webflow e-commerce site whose mobile LCP was over 4.2 seconds. The client's initial diagnosis pointed to "Webflow being slow." After a full audit, the cause boiled down to three things: an uncompressed 3.8 MB hero image, a Google Font loading synchronously and blocking rendering, and a third-party chat script injected at the top of the page. Zero lines of Webflow code were to blame. LCP dropped back down to 1.6 seconds after fixing these -- without touching the site's structure.
LCP measures the time needed to display the largest visible element on screen -- often a hero image, sometimes a text block with a background. On Webflow, it's almost always tied to image weight and to when custom fonts load.
A good LCP sits under 2.5 seconds. Between 2.5 and 4 seconds, it "needs improvement." Beyond that, it's a genuine problem that directly affects rankings and bounce rate.
INP replaced FID in 2024 and remains the least understood metric in 2026. It measures the delay between a user interaction (click, tap, keystroke) and the visual rendering of the response. On Webflow, the usual suspects are heavy Interactions animations triggered on scroll, poorly configured Finsweet scripts, or a stack of multiple third-party JavaScript libraries blocking the main thread.
A site packed with polished micro-interactions -- which is exactly Webflow's creative strength -- can see its INP degrade if those animations aren't optimized. It's a genuine balancing act between visual experience and technical performance, one we cover in more detail in our article on the subtle art of interface animations.
CLS measures layout shifts that happen while the page is loading -- that frustrating moment when a button moves right before the user clicks it. On Webflow, common causes are images without defined dimensions, custom fonts causing a "flash" of unstyled text (FOUT), or third-party embeds (videos, widgets) that reserve their space too late.
A good CLS score stays under 0.1. It's often the easiest metric to fix once identified -- yet the most overlooked in quick audits.
| Metric | Good threshold | Common cause on Webflow |
|---|---|---|
| LCP | Under 2.5s | Uncompressed images, blocking fonts |
| INP | Under 200ms | Heavy Interactions animations, third-party scripts |
| CLS | Under 0.1 | Images without dimensions, FOUT, late embeds |
The most common mistake is relying solely on a single PageSpeed Insights score. That score is lab data, measured under controlled conditions. It tells you nothing about the real experience your visitors have on varying mobile networks, entry-level devices, or congested connections.
The real source of truth is the Core Web Vitals report in Google Search Console, powered by CrUX (Chrome User Experience Report) -- real data collected from Chrome users who visited the site over the past 28 days. It's always the first thing we open in a Mazette.co audit, even before running a single test.
Once problem pages are identified through Search Console, we move on to detailed diagnostic tools:
It's usually the WebPageTest waterfall that reveals the real cause: a third-party script blocking everything, a font loading too early, a resource that should be deferred but isn't.
In most of the audits we run, images account for 60 to 80% of total page weight. Webflow offers decent automatic WebP compression, but it doesn't replace careful export work upstream: sizing images to match their actual display format, manually compressing them before upload, and consistently using lazy loading on anything not immediately visible (below the fold).
Live chat, ad pixels, multiple analytics tools, booking widgets -- every script added to Webflow's Custom Code has a performance cost. The audit should list every third-party script present, measure its individual impact via the Network tab in Chrome DevTools, and ask one simple question: does this script justify its performance cost?
For example, on an events client's site, we removed three redundant analytics tools -- an immediate 400ms gain on mobile LCP, with zero loss of functionality.
Custom fonts (other than the Google Fonts native to Webflow) should be self-hosted and preloaded using the preload attribute. On the Interactions side, the audit involves spotting animations triggered on scroll across too many elements at once, or triggers set to "While scrolling in view" on entire sections rather than targeted elements.
This is the objection we hear most often during the pre-sales phase, and it deserves to be debunked. Webflow generates clean, semantic code and runs on a CDN infrastructure (Fastly) that fully holds up to current standards. The audits we carry out at Mazette.co show, year after year, that slow Webflow sites are slow because of configuration issues -- not the platform.
The nuance worth knowing: a custom-coded site offers finer control over certain very specific aspects (an ultra-minimal JavaScript bundle, complex SSR). But for the vast majority of marketing sites, showcase sites, and mid-sized e-commerce sites, a well-built Webflow site holds its own against custom code without any complexes -- for a fraction of the development and maintenance cost.
Here's the stack we recommend, from quick diagnosis to fine-grained analysis:
Not all recommendations in a Lighthouse report are worth acting on. Some suggested optimizations (like eliminating certain unused CSS automatically generated by Webflow) bring marginal gains with a real risk of breaking the design. We knowingly ignore those.
On the other hand, three actions come up at the top of our correction plans almost every time:
In our experience, these three levers account for roughly 80% of the performance gains achieved -- for 20% of the technical effort. This is what we consistently document and prioritize in our audits, in line with our broader approach to technical SEO on Webflow.
A one-off audit has a limited shelf life. Every new section added, every third-party script integrated by a marketing team, every new image uploaded without compression can cause scores to drift. We recommend a quarterly check via Search Console, and an in-depth audit after any redesign or significant feature addition -- particularly before a major acquisition campaign, when every second of load time directly impacts conversion rate.
For teams managing several Webflow sites in parallel, we also recommend keeping an eye on the evolving Webflow analytics reporting, which is regularly enriched with new indicators useful for the overall health diagnosis of a site.
Code
Over 120 companies have already stepped out of the shadows with us.
PageSpeed measures precise metrics like LCP or INP that do not always match the visual perception of speed. A site can feel smooth to use while still having heavy images or third-party scripts that hurt the technical score. You need to cross-reference lab data with real-world Search Console data to get a reliable picture.
No, Webflow generates clean code and runs on a solid CDN. Performance issues almost always come from poor configuration -- unoptimized images, mismanaged third-party scripts, overly heavy animations -- not from the platform itself. A well-built Webflow site holds its own against custom code for the vast majority of marketing and e-commerce sites.
The Core Web Vitals report in Google Search Console remains the benchmark because it relies on real data collected from actual visitors over 28 days. PageSpeed Insights and WebPageTest are then useful for pinpointing the exact technical causes once an issue has been detected.
