You have already checked. Someone opened the site on a work laptop, clicked through a few pages, maybe ran PageSpeed Insights on the homepage once, and nothing looked broken. So the site is fine, and the question is closed.
Most marketing teams already accept that speed matters. They have also concluded, usually on one casual check, that their own site is fine. The ceiling stays invisible until you watch a page heavier than yours load faster than yours, and that matters most when a migration is on the table, because “is our site fast enough” is usually the sentence that decides whether the project gets funded.
Why does your site always pass your own test?
Every condition of the test favors the site. Fast device, fast connection, the one page that got attention, assets already cached, and a bar amounting to “does this feel broken”. Almost nothing fails that. Here is the same check, run twice.
| What your check used | What a real visitor brings |
|---|---|
| A current work laptop | A mid-range phone that is two or three years old |
| Office fiber or good home wifi | Mobile data, on a train, in a car park, on hotel wifi |
| The homepage | A blog post or a landing page nobody has looked at since it shipped |
| A warm cache from your last visit | An empty cache, every asset downloaded from scratch |
| The question “does this feel broken” | No question at all, and one tap back to the search results |
That is the only check available to someone who will never open a field-data report, which is why “our site is fine” survives everything a marketing team runs. On sites we have migrated, clients have noticed the difference themselves, without anyone pointing them at a metric or a report. The gap between those columns is one of the things a website audit turns up.
What counts as fast, as a number?
Google publishes three thresholds, and its ranking systems use them. The one worth carrying around is the first: the main content of the page should become visible in under 2.5 seconds.
| Metric | What it measures | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | Time until the main content is visible | Under 2.5 seconds |
| Interaction to Next Paint (INP) | Delay between a tap and the page reacting | Under 200 milliseconds |
| Cumulative Layout Shift (CLS) | How much the layout jumps while loading | Under 0.1 |
INP sounds like the least relevant of the three on a site where people mostly read. The taps that matter on a B2B site are the navigation, a resource-library filter, the consent banner and a form’s submit button. When those lag people tap again, and a form that appears not to respond does not get sent.
The measurement that counts is taken at the 75th percentile of real visits over a 28-day window, assessed separately for mobile and desktop. A quarter of your visitors can be slower than the threshold and the page still passes, which tells you how forgiving the bar is. Across every origin in the HTTP Archive Technology Report, and an origin here means one whole domain rather than a single page, 53.2% clear all three on mobile as of July 2026. That is field data, a different number from the score PageSpeed Insights shows at the top of its report, as we set out in the first 30 days after a migration.
Why does the architecture set the ceiling?
A traditional CMS builds every page on demand. The browser asks, the server runs code, the code queries a database, a theme renders HTML, and only then does anything reach the visitor. A pre-rendered site does that work once at deploy time and serves a finished file from a machine close to the reader. No amount of tuning reaches that difference in order of operations.
| What accumulates on a per-request site | What a pre-rendered site does instead |
|---|---|
| Plugins add a stylesheet, a script and database queries to every page | The page ships only the CSS and JavaScript it needs |
| The server rebuilds the page per visitor, which a CDN cannot safely reuse | Finished HTML sits on an edge node, so a reader in Vienna gets it from Europe, not Virginia |
| Images are resized wherever someone remembered to | Resizing and WebP or AVIF conversion happen at build time |
You can make a WordPress site faster. Caching, image compression, dropping unused CSS, better hosting. Those work, and the platform has moved: WordPress origins went from 44.3% passing on mobile in July 2025 to 49.5% in July 2026. None of it changes when the page gets assembled.
Platform pass rates are the figure everyone quotes, and they need the caveat attached.
| Technology | Origins passing Core Web Vitals on mobile |
|---|---|
| Duda | 85.7% |
| Wix | 80.4% |
| Jekyll | 79.1% |
| Hugo | 78.9% |
| Shopify | 77.0% |
| Ghost | 73.0% |
| Squarespace | 71.7% |
| Webflow | 69.84% |
| Astro | 69.81% |
| Storyblok | 50.7% |
| SvelteKit | 50.6% |
| WordPress | 49.5% |
| Gatsby | 45.4% |
| Contentful | 38.7% |
| Next.js | 33.9% |
| Nuxt.js | 28.1% |
HTTP Archive Technology Report, July 2026 data, mobile, all countries. Sample sizes are not comparable: WordPress rests on 2,762,568 origins and Astro on 38,870, against Jekyll on 1,913 and Hugo on 5,974, so the two static-site-generator rows describe very few sites.
Read that as a range rather than a verdict, because it measures technologies together with the people who choose them and with how much those people are allowed to change. Most platforms at the top constrain what you can build. Squarespace ships a median of 165 KB of CSS to a mobile visitor against WordPress’s 119 KB (Web Almanac 2025 CMS chapter, July 2025 crawl, a year older than these pass rates) and still passes far more often, because Squarespace runs the hosting and limits what a template can do. Duda, Wix and Ghost score well for the same reason: a high floor bought with a low roof. Page weight is not what decides this.
WordPress offers neither the constraint nor the ceiling, and its share includes an enormous number of small sites on cheap shared hosting and long plugin lists. Astro reflects who is choosing Astro today, and Webflow edges it on this crawl. The allowance for an average build has to cover the stacks we sell and the ones we argue against, or it is not an allowance. The spread is wide, and the table does not show that changing technology moves you up it.
We moved eversportsmanager.com off WordPress to Storyblok with a Next.js frontend. Both sit mid-table above, which is the same point: those rows average everything built on them, and one build is not its average.
The question that usually arrives first is whether the people who publish every week can still do it without booking developer time. The content model and the editing setup decide that, which is the subject of why editor experience determines what a team ships. It is a separate question from speed and often the one that settles the decision.
What does the failing half usually look like?
Half of WordPress origins do not clear the thresholds, so it is fair to ask which side you are on. The failing ones tend to have several of these at once.
- A page builder used site-wide, producing deeply nested markup on every page.
- A purchased multipurpose theme, loading styles and scripts for features nobody switched on.
- Twenty or more active plugins, several adding a stylesheet or a script site-wide.
- Hero and blog images uploaded at camera resolution and shrunk in the browser.
- Shared or entry-level hosting, busiest at the hours your traffic is.
- A marketing stack on top: tag manager, consent banner, chat widget, analytics, heatmap script.
Sites that pass tend to have an image pipeline and hosting somebody chose deliberately. Four or more of that list tells you which half you are in before measuring.
What is it worth on your site?
We cannot tell you what a second is worth to your business, and neither can anyone quoting a conversion figure from someone else’s retail study. The size of the effect depends on your traffic mix and what your pages are for. Your exposure is a different matter, and you can size it this week for nothing.
- Open the Core Web Vitals report in Google Search Console and list the URLs in the failing group. That is your own field data, from real visits, grouped by URL, and it is the one set of numbers your laptop cannot argue with.
- Run PageSpeed Insights on one of them, mobile tab. Pick a page people land on from search or an ad. The homepage got the most attention, so it is the least representative thing you own.
- Total the sessions those URLs took over 90 days, then multiply by your lead conversion rate and your average deal value.
That figure is not what you would gain. It is the pipeline running through pages that sit under the threshold, and it is the version of this argument that survives a conversation with a CFO. If it comes out small, the honest conclusion is that speed is not your constraint and the budget belongs somewhere else.
What if the numbers come back bad?
Then the next thing to settle is whether tuning the current site can close the gap or whether the architecture is the thing in the way. That is what a headless audit answers, for a flat fee with a fixed scope.
What arrives, in the order it is useful to you: async video walkthroughs recorded one topic at a time, so you can rewatch them and send a specific part to a specific person; a recommendation with the real tradeoffs named; and underneath those, the crawl exports and Lighthouse reports in full, for whoever does the work. It covers the stack, performance, editorial workflows, redirect risk and migration feasibility, and building the internal business case is one of the things it is for. There is no commitment to a migration afterwards, and it is not a free consultation.
If you have already concluded the architecture is the problem, how we handle headless migrations covers the process and WordPress to headless covers that move, down to the redirect map. Before any of it, open the Search Console report. It holds the only numbers in this piece that are about your site.