Can an ultra-fast but empty page rank thanks to Core Web Vitals?

Why does Google use this extreme example?

The example of the ultra-fast empty page is a direct response to sites that over-invest in technical optimization while neglecting content. Since Core Web Vitals were integrated as a ranking signal, some SEOs have focused their efforts on pure performance — without asking themselves whether the content justified the click.

Google is refocusing the debate here. Yes, performance metrics matter. No, they are not a shortcut to the top positions if the page brings nothing to the user.

What does this concretely change for ranking?

The Core Web Vitals are one signal among hundreds. Their weight remains modest compared to content relevance, backlink quality, or search intent. A technically perfect page but poor in information will be crushed by a slower page that's actually useful.

The underlying message: technique serves content, not the other way around. If your SEO strategy prioritizes millisecond optimizations at the expense of editorial substance, you're barking up the wrong tree.

What pitfalls should you avoid?

• Removing content to improve performance scores — that's exactly what Google discourages
• Treating Core Web Vitals as an end goal rather than a means to improve user experience
• Neglecting E-E-A-T and thematic depth in favor of minimalist fast pages
• Forgetting that Google measures real engagement: time on page, bounce rate, pogo-sticking

Is this position consistent with what we observe in the field?

Yes, unsurprisingly. Sites that sacrificed quality content to gain a few Lighthouse points haven't seen notable improvements in organic traffic. Conversely, sites with average CWV but solid content continue to dominate their SERPs.

What we observe: Core Web Vitals mainly act as a tiebreaker between pages equivalent in content. If two articles cover the same subject with the same depth, the one that loads faster will have the advantage. But a mediocre ultra-fast article will never beat a comprehensive guide that's slightly slower.

What nuances should be added to this statement?

Google remains vague on the minimum acceptable content threshold. Between an empty page and a 3000-word page, where do we draw the line? [To verify] because Google provides no quantitative metrics — word count, semantic depth, etc.

Another point: this statement says nothing about transactional pages or SaaS, where textual content is naturally limited. A fast and functional product configurator can outperform a long article that isn't relevant for a commercial query.

In what cases could this rule potentially be circumvented?

Let's be honest: for ultra-specific queries with little competition, a lightweight fast page can temporarily suffice. But that's a house of cards — as soon as a competitor publishes serious content, you'll plummet.

What should you concretely do to balance performance and content?

First, audit your high-performing pages: do they have enough thematic depth to meet user expectations? If your CWV are green but average time on page is under 30 seconds, that's a red flag.

Next, optimize without compromising. Use lazy loading for images, defer non-critical scripts, but keep essential content above the fold. The goal: accelerate without impoverishing.

What mistakes should you absolutely avoid?

Don't turn your pillar pages into minimalist landing pages under the guise of speed. Pages that rank durably are those that cover the subject in depth, even if it means heavier HTML.

Also avoid hiding content to artificially improve your metrics. Google detects hidden text through abusive accordions or tabs — and if the user doesn't see the content at first glance, its SEO impact is diluted.

How can you verify that your site respects this balance?

• Measure your Core Web Vitals via PageSpeed Insights and Search Console across a sample of strategic pages
• Compare the content volume (word count, semantic richness) of your top 3 pages vs direct competitors
• Analyze engagement metrics in GA4: session duration, pages/session, scroll depth
• Test your pages on real mobile devices (not just emulation) to detect actual UX friction
• Audit long-tail queries: do your pages actually answer user questions or just target keywords?