Shopify Plus CWV Project: LCP 4.7s → 1.9s, +17% CVR, $1.2M Revenue

A Shopify Plus fashion brand hired me in February 2026 to fix Core Web Vitals before Google’s mobile-first ranking re-weighting compounded the damage. Mobile LCP was 4.7s, INP 312ms, CLS 0.27. 71% of mobile sessions failed at least one metric. In 12 weeks I got LCP to 1.9s, INP to 124ms, CLS to 0.04, and mobile conversion lifted 17%. Annualized incremental revenue: est. $1.2M. Here is the full teardown, app by app, script by script.

The Baseline: A Theme That Worked, Drowning in Apps

The brand was est. $14M GMV on Shopify Plus, four years on the platform, mobile-heavy traffic mix (78% of sessions), AOV roughly $112. The CTO had moved on six months earlier and the marketing team had been adding apps to solve every problem, which is the normal Shopify Plus failure mode. By the time I audited, the store had 41 installed apps, 27 of which were injecting JavaScript on every page load.

Here is what the lab and field data said at day zero:

Search Console flagged 71% of mobile URLs as failing at least one metric. The brand had been blaming “Shopify hosting” because no one had run a proper attribution audit. Hosting was not the problem. App-injected JavaScript was the problem.

The PageSpeed Insights treatment was the classic deceptive signal: mobile lab Lighthouse scored 64, which is genuinely bad, but the field CrUX data told a worse story. Lighthouse runs on a simulated mid-tier device with a cold cache and synthetic throttling. CrUX measures what real users on real Androids on real LTE actually experience. The lab said “needs work.” The field said “you are losing money right now.”

The Intervention: 12 Weeks, Three Sprints

Engagement scope: $4,800 for the 12-week sprint plus $400 a month ongoing monitoring after launch. The premium against my standard $400 audit was justified by catalog size (1,400 SKUs to validate), QA volume across 11 collection templates, and the Shopify Plus checkout extensibility layer the team also wanted reviewed.

I ran the work in three sprints of four weeks each.

Sprint 1 (Weeks 1 to 4): Audit, App Cull, and Quick Wins

Week 1 was the audit. I used the web-vitals library plus a custom attribution script to measure which third-party scripts were contributing the most to INP delay on PDPs and collection pages. The output was a ranked list of every app by INP cost in milliseconds.

Top offenders, in order of damage:

1. An abandoned “personalized recommendations” app from a vendor the brand was no longer paying. The app’s JS was still injected on every page, blocking the main thread for 140ms on average. Removed.
2. A duplicate review widget. The brand had migrated reviews from Yotpo to Judge.me two years earlier and never removed Yotpo’s script tag. Yotpo was loading on every PDP and doing nothing. Removed.
3. Tidio chat widget loading on every page on document ready instead of on user interaction. Deferred to scroll/click trigger.
4. Klaviyo email-capture popup loading on document ready instead of on time-delay. Deferred to 5s after first paint.
5. An unused “bundle builder” app from a vendor with three apps installed, only one of which was being used. Two removed.
6. A “size finder” app loading on every page when it was only needed on PDPs. Conditionally loaded via Liquid template check.
7. Five legacy currency-converter scripts from a multi-currency app the brand had replaced 18 months earlier with Shopify Markets. All removed.

Total: 14 apps removed entirely, 8 apps deferred or conditionally loaded. Time invested: 18 hours including QA. Mobile INP after week 2: 198ms, down 114ms.

The lesson here is the one every Shopify Plus brand learns the hard way. Every app you install borrows your INP budget. Every app you forget to uninstall keeps borrowing.

Week 3 I focused on the hero image. The PDP hero image was a 940KB JPEG. Switched to WebP via Shopify’s image CDN parameters (format=webp,width=1200,crop=center), added explicit width and height attributes to kill the CLS contribution from layout shift, and preloaded the LCP image in the <head> with fetchpriority="high". Mobile LCP after week 3: 2.8s, down from 4.7s.

Week 4 was image optimization across the catalog. All 1,400 PDPs got the WebP + width/height + lazy-loading treatment via a Liquid template change. Below-the-fold gallery images got loading="lazy". Above-the-fold gallery images got fetchpriority="high". Mobile LCP held at 2.6s by end of sprint 1.

Sprint 2 (Weeks 5 to 8): INP Patterns and Optimistic UI

Sprint 2 went after the harder INP problem. Mobile INP was at 198ms, marginally passing, but the variance was high and the 95th percentile was still failing. The fixes:

Optimistic UI on cart and filter actions. The cart add and the collection filter were both waiting for the API response before updating the visible UI. I rebuilt both to paint the visible change in under 50ms, then settle the data asynchronously, with a rollback if the API disagreed. Pattern:

button.addEventListener('click', async (e) => {
  // 1. Paint the UI change IMMEDIATELY (within 50ms)
  button.classList.add('is-loading');
  cartCount.textContent = currentCount + 1;

  // 2. Yield so the browser can paint before heavy work
  await new Promise(r => requestAnimationFrame(r));

  // 3. THEN do the expensive work
  const result = await fetch('/cart/add.js', { method: 'POST', body });

  // 4. Reconcile if the API disagrees
  if (!result.ok) cartCount.textContent = currentCount;
});

scheduler.yield() on the collection filter. Filtering 240 products in a collection was a long task that blocked input for 180ms on mid-tier Android. I broke the filter loop into yieldable chunks using scheduler.yield() with a setTimeout(0) fallback for Safari and older Chrome. Filter perceived latency dropped to under 60ms.

Debounced search input. The predictive search input was firing on every keystroke without debounce, causing a long task on every letter typed. Added a 150ms debounce. INP on the search input dropped from 240ms to 92ms.

Web Worker for the size calculator. The size finder did a non-trivial calculation against a measurement table on every input change. Moved the math off the main thread into a Web Worker. INP on the size finder dropped from 180ms to 38ms.

Mobile INP at end of sprint 2: 142ms. Mobile LCP held at 2.4s. CLS now at 0.09.

Sprint 3 (Weeks 9 to 12): CLS, Theme Polish, and Monitoring

Sprint 3 was CLS cleanup, JavaScript animation replacements, and monitoring setup.

CLS was bleeding from three sources on mobile:

1. A “free shipping over $X” banner that loaded after the hero and pushed content down. Reserved space via fixed-height CSS, populated on render.
2. The Klaviyo popup, even when deferred, was triggering layout shift on dismiss. Replaced with a CSS transform-based modal that does not affect document flow.
3. Below-the-fold gallery thumbnails were rendering without dimensions, causing shifts as users scrolled. Added explicit dimensions to every image element via Liquid template change.

Mobile CLS after sprint 3: 0.04.

JavaScript animations got swept next. The PDP image gallery zoom was using a JS height/width animation that triggered layout on every frame. Replaced with transform: scale(), which is GPU-accelerated and does not block the main thread. Mobile INP at end of sprint 3: 124ms.

Final monitoring setup: DebugBear RUM snippet installed for ongoing field data, Search Console CWV report bookmarked, weekly Slack alert wired to fire if any metric drops below “Good.” The $400 a month monitoring retainer covers daily checks, monthly reporting, and quarterly tune-ups.

If you want the same audit framework on your store, my 2026 Shopify Core Web Vitals playbook walks through the same patterns step by step. For the broader speed program, my website speed optimization service page has the tier pricing.

Final Numbers: The 12-Week Read

The +17% mobile CVR is the headline number, and it is the number that pays back the engagement. Annualized against the brand’s mobile traffic volume and AOV, that lift extrapolates to est. $1.2M in incremental annual revenue. I tag the $1.2M as est. because it is an annualized projection from 90 days of post-launch data, not 12 months of booked revenue.

The Outcome Decomposed

What each lever contributed:

App cull is the biggest single lever by a wide margin. This is true on every Shopify Plus engagement I have run. Apps are the silent INP killer, and the second-most-installed app in any given Shopify Plus store is the most-dangerous app, because it is the one nobody is actively defending.

Why the +17% CVR Number Held

Two reasons the conversion lift was bigger than the typical “page loaded faster” line.

First, the bounce-rate compounding. Mobile bounce rate dropped 22% across the same 90-day window. Every visitor who would have bounced on a 4.7s LCP page now stays. A stayed visitor has a chance to convert. That alone explains roughly 6 to 8 points of the CVR lift.

Second, the checkout-completion lift. The optimistic-UI cart fix changed how the add-to-cart felt. The cart no longer felt like it had hung. Users who would have rage-clicked or backed out now completed the add. Internal data showed +9% on the “session-with-add-to-cart” rate, which compounded into the +17% CVR.

Performance is a conversion lever long before it is an SEO lever. Most agencies pitch CWV as an SEO project. The SEO benefit landed at +11% organic clicks over 90 days, which is real money on a $14M GMV brand, but it is dwarfed by the +17% CVR landing on every paid and direct session too. CWV is a conversion project that throws off SEO benefits as a side effect.

Lessons: What I Would Do Differently

1. Run the app audit in week one, not week three. The biggest lift came from app removal. I delayed the heavy-lift step because I wanted to map the full attribution before pulling apps. The map turned out to be unnecessary. The top three offenders were obvious from a basic scroll through the apps list.

2. Lazy-load the product gallery scripts on PDPs sooner. CLS was worst on PDPs. The gallery script was loading on document ready and the gallery thumbnails were rendering before the script finished, causing layout shifts. Two extra days of work in sprint 1 would have moved CLS faster.

3. Set the 28-day CrUX expectation on day one. Two weeks in, the marketing team got nervous because the field data was still showing the old numbers. CrUX is a 28-day rolling window, so field data lags lab data by at least 14 days and often more. I now flag this in every kickoff: “lab numbers move in days, field numbers move in weeks, do not panic.”

What This Case Study Does Not Prove

This was a Shopify Plus engagement with executive sign-off to remove apps and rebuild theme code. A smaller Shopify store with a non-technical owner often cannot remove apps because the marketing team uses them daily. The fix list is the same. The pace is different.

Also: a Shopify store on a vintage theme (not Online Store 2.0) sometimes cannot hit these numbers without a theme migration. The Dawn-fork in this case study was already on Online Store 2.0, which let the optimization stack work. If you are on a vintage theme, the first call is “audit, then likely a theme migration.” For brands at the scale where headless makes sense, my headless Shopify migration service page covers when that is the right move.

FAQ