Why no-code sites plateau on Core Web Vitals
Most Webflow and Bubble sites we audit land somewhere in the 50s and 60s on mobile Lighthouse, and then they stop. The team compresses the images, sets explicit dimensions, defers the chat widget, and the number moves four points. That plateau is not carelessness. It is the shape of the score meeting the shape of the platform, and knowing which half is which saves you a month of tuning things that were never going to matter.
The score is mostly about JavaScript
Lighthouse 10 weights five metrics. Total Blocking Time carries 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10%, Speed Index 10%. So more than half the score, TBT plus the interactivity it stands in for, comes down to how long the main thread is busy parsing and running script. Images and fonts matter, but they are the quarter of the score people spend all their time on.
The field metrics tell the same story from the user's side. Google's thresholds are 2.5 seconds for LCP, 0.1 for CLS, and 200 milliseconds for Interaction to Next Paint, all measured at the 75th percentile of real page loads. INP exists because Chrome's own usage data shows 90% of a user's time on a page happens after it has finished loading. A site can paint fast and still feel broken when someone taps the menu.
That is why the plateau is so consistent. You can fix the loading quarter with effort. The blocking half is a function of what runs, and on a hosted platform you do not decide everything that runs.
What you can genuinely fix without leaving
Layout shift is usually winnable. Injected elements, banners and embeds that arrive late and push content down are the common cause, and reserving space for them with fixed dimensions is something the Designer lets you do. So is sizing images properly and pointing the LCP element at a responsive source rather than a 3000px original scaled down in the browser. We have seen sites go from a failing CLS to under 0.1 on-platform, purely by giving every late-arriving block a reserved box.
Third-party scripts are the other lever. Webflow's Head code and Footer code fields each accept up to 50,000 characters, and its own documentation notes that adding external script tags to the head can slow page loads. Moving analytics, chat and heatmap tags to the footer, or loading them after first interaction, buys back real main-thread time. Audit that list honestly. Half the tags on a five-year-old marketing site belong to tools nobody has opened since 2023.
Do this work first, whatever you decide afterwards. It is cheap, it is reversible, and it tells you where the actual floor is. If those changes take you to 85, the rest of this post is not your problem.
The part that is not yours to touch
Webflow's documentation states that every site published since August 2020 includes jQuery v3.5.1, and warns that importing a different version causes conflicts. That library ships whether your page uses it or not, alongside the runtime that drives interactions and animations. You cannot open the bundle and tree-shake it. The docs are candid about the boundary: the custom code sections accept HTML, CSS and JavaScript only, server-side languages are out, and Webflow says plainly it cannot guarantee compatibility of custom code with its own functionality.
So the ceiling is structural rather than accidental. Your team controls what it adds. The platform controls the baseline, and the baseline is sized for every site on the platform, not for yours. On Stay World Class we moved a Webflow plus Xano stack onto Next.js, NestJS and Supabase, with a four-stage ETL that mapped every legacy ID onto PostgreSQL UUIDs so nothing lost its history. Lighthouse went from 55.91 to 91 out of 100 and LCP came down 77%. Very little of that came from clever optimisation. Most of it came from being able to decide what shipped to the browser.
None of this means the original build was wrong. Webflow got that site launched years earlier than a custom stack would have, and those years of traffic and revenue are real. What changed is the price of the alternative. Rebuilding a marketing site with AI-assisted engineering in 2026 is no longer the six-month project it was when the platform decision was made, so the performance ceiling is now something you are paying for rather than something you are trading for speed.
When staying put is the right answer
If your traffic converts fine and nobody is complaining, a Lighthouse number is not a business problem. Scores fluctuate between runs on the same page, and chasing green for its own sake is how teams spend a quarter on something no customer noticed. Look at your field data in the Chrome UX Report before you look at the lab score.
Stay if your site is mostly content that people read once and leave, where LCP dominates and the interactivity half of the score barely applies. Stay if editing without a developer is what keeps your marketing team shipping, because a custom build that requires a pull request for every headline change will quietly cost you more than the two seconds it saved. Stay if you are still finding product-market fit and the site changes every week.
The case for moving is narrower than the internet suggests. It applies when performance is tied to revenue you can measure, when the interactive parts of the product live on the same domain as the marketing pages, and when you have already done the on-platform work and hit the floor. If you have not measured, you do not know which of those you are.
