Why Do Webflow Sites Slow Down After Launch?

Why do Webflow sites slow down after launch?

Because nothing is removed and everything is added. The build ships fast, then over eighteen months the site collects a chat widget, two analytics tools, a heatmap script, a consent banner, three marketing tags, and a hero video nobody compressed. No single addition looks expensive. The total is.

This is not a Webflow problem. It happens on every platform, and it happens because the incentives are lopsided. Adding a script is a five minute task somebody gets credit for. Removing one is a risky task nobody gets credit for.

What follows is how the drift actually happens, how to measure it honestly, and what to do about it without turning into the team that says no to everything.

What actually gets added after launch?

Third party scripts, mostly, and they arrive one at a time from different people. Marketing adds a tag manager container. Sales adds a chat widget. Someone in leadership asks for session recording. Legal adds a consent tool. Each request is reasonable in isolation.

The second source is content. A CMS collection fills up with images uploaded straight from a camera roll. A blog post embeds a video that autoplays. A team member adds a background animation to a section because the page felt static.

The third is well meant custom code. A snippet to fix a layout quirk, another to track a button, a third to hide something on mobile. Nobody documents any of it, and two years later nobody can say which snippets are still doing anything.

How bad is the third party problem generally?

Close to universal. The HTTP Archive Web Almanac's 2025 chapter on third parties, published on 15 January 2026, found that over 90 percent of pages use at least one third party resource. The median page in the wider dataset makes 83 third party requests on desktop and 79 on mobile.

It is also getting worse rather than better. The Almanac reported that those medians rose year over year, by roughly 5 requests across the broader dataset and around 15 for the top tier of sites. Nobody set out to add fifteen more requests. They accumulated.

The biggest names are predictable. The Almanac found Google owned services dominate, with Google Fonts, Google Tag Manager, and Google Analytics ranking highest, and Facebook appearing at rank seven. Our piece on third party script performance covers how to measure what each one actually costs you.

Why does the score drop while the site still feels fine?

Because you are not the visitor. You load the site on a fast laptop, on office broadband, with everything already cached. Your visitor is on a mid range phone, on mobile data, arriving cold. Those are different websites.

The field data shows the gap plainly. The Web Almanac's 2025 performance chapter, drawing on the Chrome UX Report with a primary analysis from July 2025, found 48 percent of origins pass all three Core Web Vitals on mobile against 56 percent on desktop. The mobile penalty is real and it is where most of your traffic is.

The other reason is that scripts hurt interaction rather than appearance. The page looks finished while the main thread is still busy. The Almanac reported that the median Total Blocking Time on mobile rose to 1,916 milliseconds in 2025. That is close to two seconds where a tap may do nothing. Our notes on field data versus lab data cover why the two disagree.

Which Core Web Vital breaks first?

Largest Contentful Paint, usually, and it is normally an image or a video. The Almanac's 2025 figures show good LCP on 62 percent of origins on mobile and 74 percent on desktop, making it the weakest of the three metrics by a clear margin.

Interaction to Next Paint holds up better at 77 percent on mobile, though the desktop figure of 97 percent hides how much worse the mobile experience is once several scripts are competing. Cumulative Layout Shift sits at 81 percent on mobile and, oddly, 72 percent on desktop.

In our experience the LCP regression almost always traces to one of two things. Somebody replaced the hero image with a larger one, or somebody added a video that starts loading before anything else does. Both are content changes, not code changes, which is why the development team never sees them coming.

Whose job is this after handover?

This is the real question, and the honest answer is that on most sites it is nobody's. The agency finished. The marketing team owns the content. The developer who knew the build has moved on. Performance becomes everyone's concern and therefore no one's task.

The fix is boring and organisational rather than technical. Give one named person the job of checking the numbers monthly, and give them the authority to say a script needs a reason. Not a veto. A reason, written down, with the name of the person who asked.

That one habit stops most of the drift, because half of the accumulated scripts on a typical site are from a campaign that ended two years ago. Nobody removed them because nobody was looking.

How do you set a budget that marketing will accept?

Frame it as a trade rather than a ban. The rule we like is that a new script can go on, and something has to come off, or the request needs a sponsor who accepts the measured cost. That turns an argument about principles into a specific conversation about this script.

Pick two numbers and publish them. A maximum LCP on mobile and a maximum number of third party requests. Both are easy to check and hard to argue with. When a request would break one, you have a fact to discuss instead of an opinion.

Measure the cost before the debate, not during it. Load the page with and without the script on a throttled connection and write down the difference. A chat widget that adds 300 milliseconds is a different conversation from one that adds two seconds. Our performance budget guide covers how to set the numbers.

What can you do inside Webflow specifically?

Three things that carry most of the weight. Keep uploaded images sensible, because the CMS will happily serve whatever somebody uploaded. Be deliberate about what sits in the site wide custom code areas, since anything there runs on every page whether it is needed or not. And be careful with interactions that run on scroll across long pages.

Route everything you can through a tag manager rather than pasting snippets directly into the site settings. Not because a tag manager is free, it is not, but because it gives you one place to see everything and one place to remove it. Scattered snippets are the reason nobody can audit the site later.

Then keep a plain document listing every third party on the site, who asked for it, and when it was last reviewed. It takes twenty minutes to create and it is the single most useful artefact when someone asks why the site got slow. Our Webflow PageSpeed guide covers the build side of the same problem.

How often should you re-test?

Monthly for field data, and before and after anything that touches the homepage or a template. Field data moves slowly because it is a rolling window of real visits, so checking daily tells you nothing and checking annually tells you too late.

Use the real user numbers as the source of truth and lab tools for diagnosis. A lab score is useful for finding what changed. It is not useful for deciding whether your visitors are having a good time, because it is one run on one machine that is not theirs.

Watch the trend rather than the number. A score that moved from 84 to 79 is noise. A score that has moved from 92 to 71 over six months is a story, and the story is usually in the third party list. Core Web Vitals affect more than search rankings, and the trend line is the part worth reporting to anyone outside the team.

What would we do first?

Open the site, list every third party request, and ask who asked for each one. You will find two or three nobody can account for. Remove those first, because they carry no political cost and they are usually worth more than any clever optimisation.

Then look at your largest image on the most visited template and check what a phone on mobile data actually receives. That single check catches the most common LCP regression, and fixing it takes an afternoon.

After that, assign the owner and the monthly check. Everything else is refinement. If you want help auditing what has accumulated on your Webflow site since launch, we are happy to take a look. You can find us at phoenix.studio.