Webflow has a PR problem, and it's not one the Webflow team can fix. The sites that come out of Webflow look gorgeous on launch day. Six months later, a significant fraction of them are visibly broken — slow load times, layout shifts, components that behave strangely on mobile, interactions that stutter or fail, animations that don't fire, forms that randomly stop working.

This isn't because Webflow is a bad product. It isn't. Webflow is an impressive piece of engineering — arguably the most capable visual site builder ever made. The problem is that the way Webflow works invites a specific kind of decay, and the people building Webflow sites rarely know how to prevent it.

If your Webflow site is starting to feel slower, buggier, or more fragile than it did on launch day, you're not imagining it. Here's what's actually happening.

What "broken" means in this context

To be precise about what we're talking about. A "broken" Webflow site at the six-month mark usually shows some combination of:

Noticeable slowdown — pages that used to load in 2 seconds now take 4–6
Layout shift on scroll or interaction (elements jumping around mid-load)
Forms that silently fail — users submit them, Webflow collects the data, nothing gets to your email
Broken animations or interactions — elements that fade in, but only sometimes
Mobile rendering problems — things that look right on desktop but break on iPhone Safari
SEO visibility drop — pages ranking worse than they did at launch
Interactive components (sliders, tabs, accordions) getting stuck or doubling up

Not every Webflow site hits all of these. But most hit at least two within a year.

Why it happens — the seven causes

There are seven specific technical reasons Webflow sites degrade in predictable ways. Understanding them is the only way to know whether your site is about to hit them or already has.

1. CMS field sprawl

Webflow's CMS is powerful, and the temptation is to lean on it for everything. Every page becomes a CMS template. Every section pulls from a collection. Every button routes through a dynamic link.

This is fine at launch with 20 items in your collections. But Webflow collections have hard limits — 10,000 items on the Business plan, slower query times as collections grow. More important: every CMS query adds round-trip time to the page render.

A site that launches with 3 CMS collections and 40 items can feel perfectly fast. The same site at 12 collections and 400 items is measurably slower. At 20 collections and 1,500 items, it's painful.

What to watch for: Pages that used to render instantly now hang for a beat before content appears. If you've added collections since launch, this is probably why.

2. Custom code soup

Webflow lets you inject custom code in three places: site-level, page-level, and embed blocks. This is a lifesaver for developers trying to do things Webflow doesn't support natively, and a disaster for the next person who inherits the site.

Every custom code block you add is a potential point of failure. These blocks:

Don't participate in Webflow's build pipeline, so errors don't show up in the editor
Can conflict with each other in ways that are invisible until they aren't
Often load third-party scripts (analytics, heatmaps, chat widgets) that each add render-blocking weight
Get copied between sites without being adapted, so they silently reference elements that no longer exist

A Webflow site with 8–10 custom code blocks — which is common for anything non-trivial — is basically a ticking bomb. One of those blocks will break when Google updates its ad scripts, or when a third-party service deprecates an API, or when a browser version shifts.

What to watch for: Features that used to work (a tracking pixel, a chat widget, a form submission) just stop working. Nobody touched the site. It still broke.

3. Webflow Interactions that don't scale

Webflow Interactions (IX2) are the visual animation system. They're genuinely elegant for simple animations — fade-ins, slide-ups, parallax effects. They become fragile when you chain them.

Common failure mode: a homepage with 15–25 interactions — scroll triggers, hover states, load animations, delayed reveals. On launch day, they all fire correctly because you tested on a fast desktop. On a mid-tier Android phone six months later, they fight each other for the same animation frames. Elements appear in the wrong order. Some animations get skipped entirely. The page feels janky.

Webflow cannot fix this because IX2 is fundamentally a visual abstraction over CSS animations and JavaScript scroll observers. It works within the limits of what browsers can render. When you push past those limits, the abstraction leaks.

What to watch for: Animations that "work fine on your laptop but feel weird on my phone" — classic IX2 scaling problem.

4. The style system that never stays consistent

Webflow's class system (classes, combo classes, nested selectors) is one of its most powerful features and its biggest long-term liability. Teams that don't maintain strict class discipline end up with:

5+ variations of the same button class ("btn-primary", "btn-primary-2", "btn-primary-cta", "btn-primary-new", "btn-primary-fixed")
Orphan classes left behind from removed sections
Specificity wars where one class overrides another in ways nobody understands
Inline style overrides that grow over time

A Webflow project with no naming convention is usually readable for the first 3–6 months. After that, it becomes unmaintainable by anyone except the original builder. Which means every change after month 6 either takes twice as long, or introduces regressions.

What to watch for: Making a change in one place breaks layout in another seemingly-unrelated place.

5. Third-party script creep

Every marketing team wants to add tools: HubSpot, Google Analytics, Facebook Pixel, LinkedIn Insights, Hotjar, Intercom, Drift, Typeform, Calendly, Stripe, Mailchimp. Each one adds a script to the page. Each script adds kilobytes of JavaScript, render-blocking behaviour, and potential conflict with Webflow's own runtime.

At launch, a Webflow site typically loads Webflow's core JS (~90KB) plus maybe 2–3 analytics scripts. At the six-month mark, the same site typically loads 8–15 scripts for a combined 600KB–1.5MB of additional JavaScript.

This isn't Webflow's fault — it's a problem on every CMS. But Webflow's lack of a real build pipeline means there's no way to bundle, dedupe, or code-split these scripts. Every one loads in full, every page, forever.

What to watch for: Sites where Lighthouse scores used to be 85+ and are now 45–60. Almost always script creep.

6. Mobile-first that isn't

Webflow Designer lets you build a desktop version first and then adapt for mobile with "mobile breakpoint overrides." This is faster than building mobile-first, which is why most Webflow sites are built this way.

The problem: mobile-first and desktop-first are not interchangeable approaches. A site designed desktop-first and adapted for mobile has 5× more mobile-specific CSS rules than one designed mobile-first from the start. Those overrides compound. Six months later, a simple change to a desktop layout breaks three mobile-specific overrides that nobody documented.

This is why many Webflow sites have a mobile experience that's clearly second-class. The breakpoints get slightly out of sync. Some elements overflow their containers. Fonts scale to illegible sizes. Buttons end up 30px tall on iPhones.

What to watch for: A site that looked flawless on iPhone at launch and now has obvious mobile bugs you can't quite pin down.

7. Webflow's own platform changes

Webflow updates its platform every week. Most of these updates are invisible. Some of them aren't. In the last two years, Webflow has:

Deprecated their old forms system, forcing a migration
Changed how CMS item routing works for dynamic pages
Updated the IX2 interaction engine multiple times
Changed billing tiers (again)
Introduced "Webflow DevLink" which broke some third-party custom code integrations

Every platform change has the potential to break something your site relied on. If your site has 10+ custom code blocks and complex interactions, the probability that something breaks on every Webflow platform update is close to 100%. You just don't find out until it's been broken for a while.

What to watch for: Random features that worked last month now don't, with no obvious cause.

"But my Webflow site is fine" — how to actually check

Run these five tests on your live Webflow site:

Lighthouse audit (desktop and mobile) via chrome.google.com/lighthouse or PageSpeed Insights. If Performance is under 70, your site is slow. If it's under 50, it's actively hurting your business.
Total page weight check via webpagetest.org. Anything over 2MB for a small-business homepage is too much.
Mobile reality check — on a real iPhone and a real mid-range Android, navigate the site with a slow 4G simulated connection. Where does it get janky?
Form test — fill out every form on the site and confirm the email actually arrives within 60 seconds.
Console check — open Chrome DevTools on each main page. Are there red errors in the console? They indicate broken JavaScript that might be affecting more than you realise.

If three or more of those tests fail, your site has entered the decay phase. Whatever made it feel premium at launch is actively reversing.

What to do if your Webflow site is already broken

You have three options.

Option 1: Fix it in place. Hire a Webflow-native developer to audit and rebuild the broken sections. Expect $2,000–$6,000 for a thorough cleanup. Expect the same problems to reappear in 6–12 months. This is treating symptoms.

Option 2: Migrate to a custom-coded site. Rebuild in React or Next.js, owned entirely by you. Initial cost $8,000–$15,000. Eliminates the recurring decay problem permanently. Takes 4–6 weeks including migration.

Option 3: Do nothing. Accept that the site is slowly reverse-compounding against your brand. Continue paying the Webflow subscription. Lose 1–3% of conversions per month to the slowdown. This option is often the actual choice most businesses make because they can't justify the rebuild cost — which means the decision is being made by default rather than by strategy.

The pattern we see on audits

Pryce Digital runs free 10-point audits on existing business sites. On Webflow sites specifically, the most common audit findings:

Average Lighthouse Performance score: 54 (healthy = 90+)
Average total page weight: 3.2MB (healthy = under 1MB)
Average custom code blocks: 11 (dangerous = 5+)
Percentage with broken forms on audit day: 23%
Percentage with visible console errors: 78%

These aren't edge cases. This is the median Webflow site in production for 12+ months.

The argument we get from Webflow defenders

Every time we publish this kind of analysis, we get the same response: "You can build a fast, maintainable Webflow site if you know what you're doing."

Yes, you can. It requires:

Strict class naming discipline from day one
Aggressive IX2 interaction budget (cap at 8 per page)
A custom code governance policy (every block reviewed, documented)
Monthly audits of page weight and Lighthouse scores
A dedicated Webflow specialist who owns the site

If you have all of those, Webflow can be kept healthy indefinitely. Realistically, almost nobody has all of those. Most Australian small businesses end up with a Webflow site built once by a freelancer, handed over, and then slowly decomposing because nobody on the team owns its maintenance.

Custom-coded sites don't require that discipline in the same way. When the code is hand-written and the stack is owned, there's no platform churn, no IX2 regressions, no class soup. The codebase is version-controlled, every change is reviewed, and the same skills that built it maintain it.

The honest recommendation

If your Webflow site is less than 6 months old and built by a rigorous Webflow specialist who maintains it monthly, you're fine. Keep it.

If your Webflow site is 6+ months old, built by a freelancer who handed it over, and nobody has touched it since — it's decaying. The question is whether the decay costs you less than a rebuild. For most businesses whose website is a real source of customers, the rebuild pays for itself within a year.

If you want the diagnosis on your specific site, book a free audit. We'll run the five tests above on your live Webflow build, send the report back within 48 hours, and tell you honestly whether your site needs a rebuild or just a polish. No pitch, no pressure, keep the audit either way.