Three Companies Fixed Their Core Web Vitals. Here's What Happened to Revenue.
There are two kinds of evidence in the website-speed conversation.
The first kind is population-level data: 500 million visits, 16 million websites, broad associations between faster pages and higher conversion rates. That evidence is useful for establishing that the relationship exists, but it cannot tell you what happened to a specific company’s revenue when it fixed a specific problem.
The second kind is harder to find and more persuasive: a named company, a documented technical change, a before-and-after measurement. Not a survey. Not an extrapolation. A company, a fix, a number.
This article covers three of the strongest examples available, plus a fourth regression anchor. The goal is to give you the kind of evidence that settles the “but does it actually work?” objection, and then to translate what these companies found into numbers a Tampa Bay business owner can recognize.
A Note on Methodology Labels
Before the case studies: a word on what different types of evidence can and cannot prove.
A controlled A/B test, two identical pages, one variable changed, randomly assigned users, is the gold standard for proving cause and effect. Very few speed studies meet this standard.
A before/after RUM study (RUM = Real User Monitoring) measures real user behavior on the same page before and after a technical change. It cannot rule out other factors that changed in the same window, but it is substantially more informative than a correlation.
A before/after cohort study follows the same group of sites or users across time. Similar strengths and limits as RUM, depending on what else changed.
A regression analysis finds mathematical relationships across a large dataset. Strong for spotting patterns at scale; cannot prove causation.
All four studies below are labeled accordingly.
Case Study 1: Nuvemshop: 8.9% Mobile Conversion Lift
Methodology: Before/after cohort study. Same stores, measured year-over-year.
Nuvemshop is a Latin American ecommerce platform serving hundreds of thousands of merchant stores, primarily in Brazil. In a 2026 case study published by Google’s web development team, and highlighted by Google Search Advocate John Mueller: Nuvemshop documented what happened when they systematically improved LCP across their merchant base.
LCP stands for Largest Contentful Paint. In plain terms: how long it takes for the main visible element on a page, usually a hero image or primary heading, to fully render. Google’s current threshold for “good” LCP is under 2.5 seconds at the 75th percentile of real users.
Nuvemshop’s improvement: the share of their merchant stores with good LCP went from 57% to 96%, a 39-percentage-point shift in the proportion of stores passing the threshold. The team measured the same cohort of stores before and after, year-over-year.
The outcome: mobile conversion rate increased 8.9%. Cart engagement increased 8.4%.
This was not a controlled A/B experiment, multiple improvements happened alongside the LCP work, and the study does not isolate LCP as the sole driver. But the methodology (same cohort, year-over-year, large sample) is more rigorous than most before/after claims in this space, and the result was published by Google with named attribution.
For a Tampa Bay ecommerce store doing $30,000 a month in web-influenced revenue: 8.9% is $2,670 per month.
Case Study 2: Vodafone: 8% Higher Sales From a Single A/B Test
Methodology: A/B-style controlled test. Two visually identical pages, one variable changed.
The Vodafone case study is the closest thing to a controlled experiment in the published speed-revenue literature. In a test documented circa 2024 and cited in a 2025 analysis by Harunstudio, Vodafone compared two versions of a page that were visually identical in every way, same design, same content, same layout, but loaded at different speeds. One page’s LCP was 31% faster than the other.
Users were split between the two pages. The faster page drove 8% higher sales.
Because the only meaningful variable between the two pages was load speed, this result is more cleanly attributable to performance than most speed-revenue studies allow. An A/B test with identical creative and one changed variable is the design you would want if you were trying to isolate the effect.
One important transparency note: this case study was cited in a secondary source (Harunstudio, 2025). The Vodafone finding is widely attributed to a Google/Vodafone web performance case study; readers who want the primary source should search Google’s web.dev case studies library for the Vodafone entry. The secondary citation is noted here in the interest of source accuracy.
The finding is consistent with the broader pattern: a single LCP improvement, isolated from other variables, produced a measurable and substantial revenue outcome.
Case Study 3: redBus: 7% Sales Increase From One INP Fix
Methodology: Before/after RUM study. Specific code change documented; real user monitoring before and after.
INP stands for Interaction to Next Paint, how quickly a page visually responds after someone taps or clicks. Google replaced its previous interactivity metric (FID) with INP in March 2024. INP is stricter: it measures every interaction across a session, not just the first.
redBus is one of India’s largest online bus-booking platforms. In 2023, their engineering team identified that the search results page, the most critical conversion step in their funnel, had a slow INP score driven by the way JavaScript handled user interactions. They made a specific, documented change to how the page processed those interactions.
The result: INP improved by 72%. Following that improvement, redBus recorded a 7% increase in overall sales.
The case study is published on Google’s web.dev platform in 2023, with the code change documented in enough technical detail that other engineering teams can reproduce the approach. This is not a modeled estimate. It is a named company, a specific fix, a real user monitoring measurement, and a revenue outcome.
For a Tampa Bay service business, say, a home-services company with a “Get a Quote” form on a slow-responding page, the redBus case study is the most directly applicable evidence available. The booking flow is the same type of interaction. The INP problem is the same type of problem.
A Fourth Anchor: Renault’s Regression Study
In 2021, Groupe Renault published an analysis on Google’s web.dev platform covering 10 million visits across 33 countries over 4 months. Using linear regression across their landing page performance data, they found that a 1-second improvement in LCP correlated with a 14 percentage-point decrease in bounce rate and a 13% increase in conversions.
This is a regression study, not a controlled experiment. The 13% figure describes a correlation across Renault’s specific pages and traffic, it does not imply that any 1-second LCP improvement will produce 13% more conversions for any site. But it is a large, named dataset with a documented methodology, and the direction is consistent with every other piece of evidence in this article.
The Renault study is labeled here as a 2021 data point, a “recent” reference, not a current benchmark, because the optimization work predates current Core Web Vitals standards.
The SMB Translation: What a Conservative Improvement Would Mean
None of the three case companies above is a small business in Tampa Bay. They are a Latin American ecommerce platform, a European telecommunications company, and an Indian travel-booking service.
The objection “those are big companies, my situation is different” is worth addressing directly.
The mechanism that causes slow pages to lose conversions is not scale-dependent. The experience of tapping a booking button and waiting, whether on the Vodafone website or a Tampa Bay HVAC company’s quote form, is identical. The user’s reaction is identical. The revenue consequence is the same type of consequence, scaled to the volume of traffic.
Take a hypothetical Tampa Bay home-services company with $80,000 a month in revenue that originates from or is influenced by their website. That might be a combination of inbound calls from organic search, quote form submissions, and booking-page completions.
A conservatively modeled 7% improvement in the conversion rate, in line with the lower end of what these case studies found, equals $5,600 a month. Over a year, that is $67,200.
That estimate is explicitly illustrative, the actual outcome depends on what is failing on your site, how severe the problem is, and what changes are made. But $5,600 a month is what a conservative application of this evidence produces.
What These Case Studies Have in Common
Each of the three primary case studies above shares a structural pattern:
- A specific metric was identified as failing.
- A specific technical change was made.
- Real-user monitoring measured the result before and after.
- A revenue outcome, sales, conversion rate, cart engagement, was recorded.
None required a site redesign or months of work. The Vodafone test ran on existing page content. The redBus fix was a scoped JavaScript change. The Nuvemshop improvement was a systematic LCP optimization across their merchant platform.
For a business owner asking “is this real?”, these three cases answer with named organizations and documented numbers.
The Free Assessment
The first question a Tampa Bay business owner should answer is not “what is my site’s Lighthouse score?” It is: what is my current LCP, INP, and CLS in real user field data, and what would a 7% improvement in my conversion rate mean in dollars?
iServU’s free assessment answers both questions using your actual CrUX field data and your actual revenue numbers. No account manager, no handoffs, one conversation with Gabriel Lopez-Seco, who runs the assessment directly.
Book a free assessment at iServU →
Sources
- Google web.dev / Nuvemshop (2026). Core Web Vitals Case Study: Nuvemshop. https://www.techwyse.com/news/reports-data/google-lcp-core-web-vitals-nuvemshop-case-study
- Harunstudio citing Vodafone / Google (2025, secondary cite of 2024 Vodafone data). Core Web Vitals Revenue Impact. https://harunstudio.com/en/blog/core-web-vitals-revenue-impact/
- Google web.dev / redBus (2023). redBus INP Case Study. https://web.dev/case-studies/redbus-inp
- Google web.dev / Groupe Renault (2021). Renault Core Web Vitals Case Study. https://web.dev/case-studies/renault
