Twenty of the 26 SaaS homepages that passed all three Core Web Vitals on desktop missed at least one threshold on mobile. That is 76.9% of the desktop-passing group. The reassuring desktop result left a different question open for people arriving on a phone.

The figures come from the published data behind Merge Rocks’ SaaS website benchmark. Its October 2026 study covered 60 selected public B2B SaaS marketing homepages. Thirty-seven had all the measurements needed to compare mobile with desktop, and 26 of those passed on desktop. The other 23 lacked at least one required measurement; they were not counted as failures.

These are Google’s records of real visits. Each homepage’s mobile and desktop records covered the same period, with different visitors. Periods varied between sites. The breakdown below comes from regrouping the published measurements, without another round of testing. The selected sample does not establish a failure rate for the SaaS market.

Most of the mobile misses involved loading or stability

Google’s Core Web Vitals cover loading through Largest Contentful Paint (LCP), responsiveness through Interaction to Next Paint (INP), and visual stability through Cumulative Layout Shift (CLS).

The good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1. Google assesses each metric at the 75th percentile, separately for mobile and desktop. Passing requires all three metrics to meet their thresholds.

The 20 pages that passed on desktop but missed on mobile fall into two groups:

Seven pages had a responsiveness-only problem. Their loading and stability results already met the good thresholds. For those pages, the unresolved question concerns what happens when someone interacts with the interface. Another favorable loading result would not answer it.

The larger group had a loading or stability problem. Six of those pages also missed INP, so responsiveness needed attention alongside another metric.

Across all 20 pages, INP missed on 13, LCP on 11 and CLS on four. Those counts overlap. INP was the most common individual miss, yet most pages had a loading or stability issue. A ranking of the three metrics hides that combination. It would be easy to commission a responsiveness-only investigation that covered just part of the problem.

Commenting on the findings, Ihor Ostin, Head of Growth at Merge Rocks, says:

I would not turn the most common issue in this group into a standard brief for our developers. I would start with our own page: which mobile metric misses, who arrives there and how the page supports acquisition. Then we can decide what work deserves the budget.

Ostin tested one landing page before deciding to extend the work

In the report’s conclusion, Ostin describes an earlier project where he and a founder debated whether performance optimization deserved development time. A test gave that discussion a defined scope: two versions of one landing page.

The versions looked and functioned the same. Developers changed the technical implementation, moving a widget’s rendering to the server, server-rendering critical HTML and improving image loading. Ostin handled the hypothesis, experiment setup and analysis. He did not write the code.

Keeping the appearance and functionality the same gave the comparison a clear technical focus. That distinction matters to the growth question: the team was testing whether technical work on an existing destination was worth pursuing.

The team decided to extend the work across the site, beginning with pages attracting the most traffic and pages already generating sales, then moving to the rest. That earlier project is separate from the benchmark. The practical lesson is the sequence: test a defined change on a page that matters before deciding how far to extend the work.

Put the visitor context into the development brief

A company reading the benchmark needs to begin with its actual acquisition destinations. If campaigns send prospects to dedicated landing pages, a homepage result does not automatically make the homepage the first place to spend engineering time. Map where people arrive and what those pages contribute to acquisition.

Then look at device mix. A popular page visited mainly on desktop presents a different mobile priority from a page receiving substantial mobile prospect traffic. Visit volume belongs beside page purpose: what do people come to understand or do, and why does improving that experience matter to the business?

Marketing can bring that context into a request with the landing URL, traffic by device and the page’s role in acquisition. Attach the performance values and observation dates. Engineers should receive enough information to understand both the measured problem and the reason this destination deserves attention.

The investigation then follows the metric. For LCP, identify the prominent content being measured and inspect what delays its appearance. For INP, inspect browser activity around interactions. For CLS, identify which elements move unexpectedly and under what conditions.

The front-end development work depends on what that inspection finds: how the relevant content renders, how the layout reserves space or how an interaction updates the page. Engineers need to connect the observed behavior to a proposed change before estimating its scope. The number of missed thresholds cannot supply that explanation or predict a financial return.

Agree on verification before implementation. Record the page version, the behavior to compare and the conditions under which it will be tested. Keep repeated results instead of choosing the most favorable attempt. That gives the next reviewer a way to check the change without relying on the person who made it.

Lab tests can help check a change immediately. Real-user records cover a rolling period, which may still contain visits from before the update. Keep the dates visible when checking whether the relevant mobile field metric has improved. A better lab result is useful evidence about that test; it does not establish what the later field record will show.

A team can fund a focused investigation while the cause remains uncertain. Once engineers have established the behavior and a justified change, the implementation can compete with other planned work on its actual scope. Acquisition spending can be considered alongside evidence from the page people will reach.

The benchmark’s value is to sharpen that conversation. It gives a growth team a reason to look beyond a reassuring desktop result, while the company’s own visitors determine where the next piece of work belongs.