Why page builders fail Core Web Vitals, and what fixes it
Three numbers decide the assessment: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, measured at the 75th percentile of real visits. Almost every page builder failure is one cause with three symptoms, and the cheapest fix is subtraction.
"Core Web Vitals assessment failed" is a sentence that arrives with no instructions. Search Console says it, the page looks fine to you, and the advice you find is a list of thirty things to try.
It is actually three numbers, and on a page-builder site the cause is usually one thing wearing three different costumes.
The three numbers
Those thresholds are Google's, from web.dev, and they have not moved: LCP within 2.5 seconds, INP of 200 milliseconds or less, CLS of 0.1 or less.
INP is the one people have not caught up with. It replaced First Input Delay and became a stable Core Web Vital in 2024, and it is stricter in a way that matters: FID measured how long before the browser started responding to a tap, while INP measures how long until the screen actually changes. A site that passed FID comfortably can fail INP, and nothing about the site changed.
Why your laptop says the page is fine
Because your laptop is not the measurement.
The assessment is taken at the 75th percentile of real visits, split by device. That means three-quarters of your actual visitors have to be inside the threshold — so the number is set by your slower visitors, on their phones, on their networks, not by the machine you built the site on.
This is the whole explanation for the most common complaint about Core Web Vitals: the lab test passes and the report fails. Both are true. One of them is your computer and one of them is your customers.
Which builder habit breaks which number
Read down that list and you will notice they are mostly the same sentence: something has to run before the page means anything.
A builder that assembles the page in the browser cannot produce a fast LCP, because the text does not exist until the script has downloaded, parsed and executed. The same script is what INP is waiting behind when somebody taps. And a layout that is computed after the fact is a layout that moves, which is CLS. One cause, three failing metrics, three separate tickets in most people's task lists.
The two that are not about script are worth naming separately, because they are free to fix:
- Images without width and height attributes. The browser cannot reserve space for something whose size it does not know, so the page jumps when each one lands. Adding the two attributes is a pure CLS win and costs nothing.
- Web fonts with no fallback. The text either waits invisibly for the font, which hurts LCP, or swaps and reflows, which hurts CLS. Pick one deliberately rather than getting whichever your builder chose.
The cheapest fix is subtraction
The instinct is to add: a caching plugin, a minifier, a CDN, a performance plugin to fix the performance plugin. Those help at the margins and none of them removes work that should not have been there.
The fix that actually moves the numbers is taking things out. In order:
- Count the sliders, popups, counters and animated statistics on your page. Ask which one a customer has ever mentioned. Remove the rest — each one is script that has to arrive, run, and then be waited on.
- Put width and height on every image. Free, immediate, pure CLS.
- Decide your font fallback on purpose, or drop to system fonts for body text and keep the web font for headings only.
- Then cache and compress. Now you are optimising a page instead of hiding one.
A section that ships no JavaScript cannot fail INP. That is not a clever trick, it is arithmetic, and it is available to anyone regardless of which builder they use.
Fast because there is nothing to wait for. Class-based HTML and CSS. Script ships only for the sections that need it. Browse the Market.
Where we sit, plainly
A published DragGo page is class-based HTML and CSS with no JavaScript by default — script ships only when a section genuinely uses something that needs it. That removes the common cause rather than optimising around it, which is why the JavaScript question is the one we keep coming back to.
It is not a guarantee of a pass. You can still put a 4MB hero image on a DragGo page and fail LCP on a phone, and no builder can save you from that. What it does is remove the failure you cannot fix from inside the tool.
The useful thing to take from this
Core Web Vitals is not really a performance test. It is a test of how much your page needs before it is useful — and that is a design decision made early, not a plugin installed late.
If you are choosing a builder now, the question that predicts your future report card is: how much JavaScript does a plain page of text ship? Ask for the number. It is knowable, it varies enormously, and it is the thing you will be measured on for as long as the site exists.