Our benchmark found that 6 of 37 SaaS homepages passed all three Core Web Vitals on mobile, compared with 26 of 37 on desktop. Those were the pages with complete, matched field records for both devices.
Twenty passed on desktop alone. That is enough to make me ask which device a performance report describes before discussing a fix.
I work in growth. When a finding becomes an engineering task, I want to understand the visitor experience behind it and what evidence would justify changing the page.
We examined 60 public B2B SaaS marketing homepages for the Merge Rocks October 2026 benchmark. The results give me a practical sequence for reviewing my own page: establish the field coverage, reproduce the lab behavior, inspect the work behind it, then check accessibility separately.
Open both device views on the exact URL
Start with the page you intend to investigate. Record the requested URL and the final URL after redirects, including any language or product path. Add the build or release identifier where you have one.
In PageSpeed Insights, inspect mobile and desktop separately. Check whether the field panel describes that URL or falls back to the whole origin. Record the actual trailing 28-day collection window. Origin data provides broader context, but it cannot fill a missing measurement for one particular page. Google’s PSI documentation explains those distinctions.
Our paired comparison required complete URL-level records for both devices over the same window within each site. Windows varied between sites.
Source: Merge Rocks, October 2026. Each homepage appears in one category. The other 23 homepages lacked at least one required measurement and were excluded from this comparison, rather than counted as failures.
For your URL, keep the three p75 values visible beside each device:
| Metric | “Good” threshold |
|---|---|
| Largest Contentful Paint | ≤2.5 seconds |
| Interaction to Next Paint | ≤200 milliseconds |
| Cumulative Layout Shift | ≤0.1 |
These are the Core Web Vitals thresholds. The 75th percentile describes a value that roughly 75% of recorded experiences meet or better.
An out-of-threshold mobile metric gives me a specific investigation to discuss with engineering. A desktop pass alone leaves that mobile question unanswered.
Read missing metrics before interpreting a pass
There is a detail in PSI’s assessment rules worth checking: an assessment can pass when INP has insufficient data, provided LCP and CLS are good.
Our benchmark’s pass definition required good values for all three metrics. To enter the paired comparison, a page needed all three measurements on both devices. Our pass rate therefore should not be described as the share of pages displaying a PSI pass badge.
Seven partial URL/device records in our dataset were missing INP alone. That means seven records, not seven sites. We did not observe or infer PSI badges for them.
For your page, write down which metric is absent. Missing INP means responsiveness remains unknown in that field record. It is neither zero nor an automatic failure. CrUX’s coverage requirements also explain why a page may lack field data.
I would keep that gap attached to the investigation even if the displayed assessment looks reassuring. A lab test can help investigate the page while field coverage is incomplete, but TBT cannot replace missing field INP.
Someone reading the release note should be able to tell what the assessment actually covered.
Use repeated lab runs to test the current build
Once the page and field coverage are clear, use lab testing to investigate the current build.
Open the URL in Chrome DevTools, find the Lighthouse panel and run a mobile audit. The Lighthouse overview documents this workflow.
For a useful comparison, I would run five comparable cold loads and keep every report. Cold means starting each run without reused cache, cookies or service-worker state, using the same reset procedure throughout. Five is a practical starting point consistent with our benchmark method; it does not eliminate measurement variability.
Keep these conditions consistent:
- The URL, build and browser/Lighthouse versions.
- The mobile configuration, viewport and throttling settings.
- The cache-reset method and consent state.
- The page state, including any open overlays or other setup.
Record warnings and unexpected behavior alongside the results. If one run loads a consent overlay and another does not, investigate that difference before treating the numbers as comparable.
For each metric, calculate the median and retain the spread, such as the minimum and maximum. Do this separately for LCP and TBT rather than choosing the report with the most attractive overall score.
If the spread is wide, check the page state and collection warnings. Keep the unusual run visible while you work out what happened.
These instructions establish a repeatable test for your page. A current DevTools mobile preset does not automatically reproduce our benchmark’s pinned browser, hardware assumptions and configuration.
For a proposed change, repeat the same procedure before and after it.
Use TBT to choose what to trace
TBT measures the accumulated blocking portions of long tasks during the measured load. For a task lasting more than 50 milliseconds, only the excess counts. The total can accumulate across separate tasks; it is not one continuous wait. It is also a lab diagnostic, whereas INP measures interaction responsiveness. Google’s TBT explanation covers that boundary.
If TBT is high or inconsistent, I would ask for a performance trace from the same page state.
The useful question is what work occupied the main thread during that load. Inspect the long tasks and connect them to the specific work visible in the trace before proposing a change. JavaScript transfer size alone cannot identify the cause or tell you what removing an integration would save.
A ticket can then name the observed task, relevant trace interval and proposed change. Keep the trace with the Lighthouse reports so the next person can assess the diagnosis.
After a release, remember that a rolling field window can still contain visits from before the change. It does not instantly become a clean after-test. A comparable lab result and the later field record answer different questions.
Scan both views, then try the tasks
Performance and accessibility need separate checks.
Across our 60 homepages, Axe flagged at least one critical or serious finding on 56 sites, combining two initial viewport states per site. Serious contrast findings appeared on 48 sites, and serious link-name findings on 30.
Source: Merge Rocks, October 2026. Sites count once per category across the initial desktop and mobile views. Categories overlap; these are affected-site counts, not counts of distinct defects. Excluding two pages with browser-method exceptions left 54 of 58 with findings.
On your page, use an automated checker such as axe DevTools at desktop and mobile viewport sizes. Record the tool version and tested state. Inspect each flagged element, retaining the rule and element evidence with the issue. Review items marked as needing further inspection rather than treating them as cleared.
For a contrast finding, inspect the foreground/background combination in the flagged state. For a link-name finding, inspect the link’s accessible name and whether it communicates its purpose.
Then extend the check into actual tasks on your own page or test environment. Our benchmark did not open menus, complete forms or interact with consent controls. The following are additional checks I would request:
- Move through the page with Tab and Shift+Tab. Check that focus remains visible and follows an understandable order.
- Open and close the navigation using the keyboard. Check where focus goes and whether you can continue.
- Reach the main form, understand its labels and submit it with required fields empty. Inspect the error feedback and focus behavior.
- Try the relevant consent controls and any overlay that affects access to the page.
The W3C’s preliminary accessibility checks provide a starting point for keyboard, focus and form review.
Keep the task outcome beside the automated finding. A changed issue count is less useful than knowing whether someone can now operate the affected control.
These checks remain an initial review. They do not establish accessibility conformance, and a clean automated scan leaves manual coverage unresolved.
Leave a record that supports a decision
I would keep one compact record with the release or ticket:
Page: requested/final URL, language/path, build
Field: URL/origin scope, device, window, LCP/INP/CLS, missing values
Lab: five reports, metric medians + ranges, versions/config/state
Accessibility: tool/version, viewports/state, rules/elements, manual task outcomes
Decision: change or accepted uncertainty, reason, owner, next check
For me, a useful report is one I can hand to an engineer without asking them to reconstruct what happened. It identifies a reproducible problem, a question requiring another check or an uncertainty the release owner has consciously accepted.
Our 60-page sample was deliberately selected, and it assessed marketing homepages rather than authenticated SaaS products. I use it to choose checks worth making. The ticket should still name what failed on your page, under which conditions, and what the next person needs to investigate.
Top comments (0)