Performance·May 2025·9 min read

Why Page Speed Matters More Than Ever in 2025?

Page speed is not the ranking lever some SEO advice makes it out to be. Google's own documentation says page experience is one signal among many, and relevant content still wins over a faster but less relevant page. The honest case for investing in speed rests on real-user data and a small number of independently verifiable outcomes, not a universal conversion formula.

What Google actually says about speed and rankings

Google's page experience documentation states plainly: "there is no single signal" and "our core ranking systems look at a variety of signals that align with overall page experience" (Google Search Central — Understanding Google Page Experience). The same page adds that Google Search "always seeks to show the most relevant content, even if the page experience is sub-par."

Where speed actually earns its keep in ranking is the tie-break: when two pages are similarly relevant to a query, the page with better page experience, including Core Web Vitals, has an edge (Google Search Central — Understanding Core Web Vitals and Google Search results). That's a narrower, more honest claim than "faster pages rank higher," and it's the one worth building a business case around.

Why this framing matters for prioritization

If speed were a dominant ranking factor, the correct move would be to chase a perfect Lighthouse score everywhere. Since it's a tie-break plus a direct effect on user behavior, the correct move is to fix speed where it's actually costing conversions or engagement, which requires the field data covered next, not a lab score.

Field data: what Core Web Vitals actually measure

The Chrome UX Report (CrUX) is the real-user dataset behind every Core Web Vitals number that touches ranking or Search Console. It aggregates anonymized field data from actual Chrome users, on their actual devices and networks, over a rolling 28-day window (Chrome for Developers — Overview of CrUX).

Metric	What it measures	Good threshold
LCP	Time to render the largest visible element	≤2.5s at the 75th percentile
INP	Responsiveness across every click, tap, and keypress	≤200ms at the 75th percentile
CLS	Unexpected layout movement across the session	≤0.1 at the 75th percentile

All three are measured at the 75th percentile of page loads, split by device, which means the number represents your slower real users, not your best-case demo (web.dev — Web Vitals).

A lab tool showing a perfect score proves nothing about the customer on a mid-range Android phone with a weak connection. CrUX field data is the only number that reflects what your actual traffic experiences.

What the verifiable evidence actually shows

Google publishes a set of case studies on web.dev documenting specific companies' own reported outcomes after Core Web Vitals optimization work. These are first-party, company-reported figures curated by Google, not aggregated industry averages, and each one is tied to a specific, described methodology.

Rakuten 24: a controlled A/B test, not a before/after guess

Rakuten 24 ran a month-long A/B test on a high-traffic landing page, splitting traffic 50/50 between a performance-optimized version and the original, with both versions visually and functionally identical apart from performance. The optimized version reported a 53.37% increase in revenue per visitor and a 33.13% increase in conversion rate, alongside a 92.72% improvement in CLS (web.dev — How Rakuten 24's investment in Core Web Vitals increased revenue per visitor).

The methodology is what makes this citable: a controlled split test isolating performance as the only variable, not a correlation drawn from two unrelated time periods.

Why one company's A/B test isn't a universal conversion formula

Rakuten 24's result is real and sourced, but it's one retailer, one landing page, one traffic mix, and one starting point. Treating it as "every 1-second improvement equals X% more revenue" for an unrelated site is exactly the kind of unsourced generalization that erodes trust in a business case. Use case studies like this to justify running your own controlled test, not as a drop-in multiplier for your own numbers.

Mobile-first indexing raises the stakes on mobile performance specifically

Google's indexing is mobile-first, meaning the mobile version of a page is what Google primarily crawls and indexes for ranking (Google Search Central — Understanding Core Web Vitals and Google Search results). A site that performs well on desktop but poorly on a mid-range mobile device is being judged, for Core Web Vitals purposes, primarily on the version that performs worse.

What that means for a commerce roadmap

Test and monitor performance on the actual device tiers your traffic uses, not a flagship phone on office WiFi.
Treat mobile CrUX data as the primary signal for prioritization, since it's what mobile-first indexing actually evaluates.
Don't assume a desktop fix, a CDN change, a caching layer, closes a mobile-specific gap caused by unoptimized images or excess JavaScript shipped to every device equally.

Getting your own field data instead of guessing

CrUX is exposed through four access methods of increasing complexity and control, all documented by the Chrome team (Chrome for Developers — Overview of CrUX).

Method	Best for
PageSpeed Insights	Quick, single-URL check combining CrUX field data with a Lighthouse lab run
CrUX Dashboard	Ongoing, visual tracking of a property's historical field performance
CrUX API	Pulling current field data into your own tooling or CI checks programmatically
BigQuery dataset	Custom, granular analysis across URL patterns, countries, or device types

Starting with PageSpeed Insights or the CrUX Dashboard is enough to answer the first real question: which templates, on which device class, are actually failing the thresholds today. That answer is what should drive the prioritization, not an assumption based on how the site feels on a developer's own laptop. The BigQuery route is worth the extra setup once the org needs to slice performance by country or connection type rather than by single URL.

The reach argument: not every customer has a fast connection

A page built and tested on a fast office connection with a current-generation phone tells you nothing about the experience for a customer on a mid-tier Android device or a constrained mobile network. CrUX field data exists specifically because lab conditions systematically understate real-world variance in device and network quality.

This is a reach argument as much as a performance one: every kilobyte and every millisecond of main-thread blocking work disproportionately affects the segment of your traffic already on the weakest connections, which lab testing on a developer machine will never surface.

Building the internal case without inventing numbers

The most durable version of this argument for stakeholders doesn't lean on a universal conversion-per-second claim, because that number doesn't generalize across businesses. It leans on three things that do hold up under scrutiny.

Google's own statement that Core Web Vitals function as a tie-break signal in ranking, not a dominant one, which is a real, sourced, if modest, SEO argument.
Your own CrUX field data, pulled via PageSpeed Insights or the CrUX API, showing exactly which templates and device classes are failing today, which is specific to your business.
A controlled A/B test on your own highest-traffic template, run the way Rakuten 24 ran theirs, which produces a number you can actually defend in front of finance.

The strongest page-speed business case isn't a borrowed statistic from someone else's case study. It's your own CrUX data plus a controlled experiment on your own highest-traffic page.

Speed as a standing discipline, not a launch checklist

The Rakuten 24 test and the CrUX thresholds both describe a snapshot. Neither describes what happens six months later when a marketing team adds a personalization script, a support team embeds a chat widget, and a merchandising team adds an above-the-fold promotional banner, each shipped independently, each individually defensible.

A performance budget enforced in CI, failing a build when LCP or CLS regresses past a set threshold on key templates, catches this before it reaches production (Chrome for Developers — Lighthouse overview). Without that gate, the business case made once at launch decays silently, and the next stakeholder conversation starts from a worse baseline than the one the original case was built on.

Who should own the ongoing number

Treat CrUX field performance the same way an organization treats uptime: a number with a named owner, a review cadence, and an agreed threshold that triggers investigation, not a report someone glances at during a quarterly audit. The teams that hold their numbers over multiple quarters are the ones checking after every release, not just before the one big launch that prompted the original investment.

FAQ

Is page speed a major Google ranking factor?

No. Google states there's no single dominant signal, and that relevant content is still surfaced even when page experience is weaker. Speed functions mainly as a tie-break between similarly relevant pages (Google Search Central — Understanding Google Page Experience).

What's the difference between lab data and field data for page speed?

Lab data, like a Lighthouse run, is one simulated test on one device profile. Field data, from CrUX, is aggregated real-user measurement across actual devices and networks over a rolling 28-day window, and it's what actually feeds Search Console and ranking systems (Chrome for Developers — Overview of CrUX).

Can I apply Rakuten 24's conversion lift numbers to my own site?

No. Those are one company's controlled A/B test result on one landing page. They're a real, sourced data point that justifies running your own test, not a formula that transfers to a different business (web.dev — Rakuten 24 case study).

Why does mobile performance matter more than desktop for SEO?

Google uses mobile-first indexing, meaning the mobile version of a page is the primary version evaluated for ranking, so a mobile performance gap is judged more heavily than an equivalent desktop one (Google Search Central — Understanding Core Web Vitals and Google Search results).

Is chasing a perfect Core Web Vitals score worth it for SEO alone?

Google explicitly cautions against this: passing Core Web Vitals doesn't guarantee top rankings, and optimizing purely for a perfect score "just for SEO reasons" may not be the best use of engineering time (Google Search Central — Understanding Google Page Experience).

What's the most defensible way to build a speed investment case internally?

Combine Google's own tie-break framing, your own CrUX field data showing where you're actually failing, and a controlled A/B test on your highest-traffic template, rather than borrowing a conversion percentage from an unrelated company's case study.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.