
Full-stack commerce case study
We rebuilt the rendering strategy and governed it with a 50–60 component design system across 2M+ monthly product pages, taking Largest Contentful Paint from 4.1s to 1.8s and doubling checkout conversion from 2% to 4%.
4.1s → 1.8s
Largest Contentful Paint (LCP) across 2M+ monthly product pages
2% → 4%
Checkout conversion rate, doubled
50–60
Component design system built and maintained across product squads
2M+
Monthly product pages served by the platform
The problem
A 2M+ monthly page e-commerce platform was losing checkout conversion to slow Largest Contentful Paint: 4.1 seconds on product pages, well past the point where users start abandoning before the page is even usable.
Multiple product squads were shipping UI independently, which meant performance regressions kept re-appearing even after fixes landed, and the platform's heavy martech stack (Tealium, Adobe Analytics, Adobe Target, Contentsquare, GTM, OneTrust) was a recurring source of render-blocking cost.
Our approach
01
We profiled Core Web Vitals against real production traffic rather than lab conditions alone. The biggest LCP cost wasn't where the team first assumed. Render-blocking third-party scripts and unoptimized hero imagery across product pages were the real problem, not JavaScript bundle size.
02
We restructured the rendering approach for product pages: moving critical content earlier in the render path, deferring non-critical scripts, and optimizing image delivery (sizing, formats, lazy loading below the fold) without changing the visual design.
03
Performance gains erode if every squad rebuilds components inconsistently. We built and maintained a 50–60 component design system on design tokens, used across multiple product squads, so performance budgets and accessibility standards were enforced by default, not by review.
04
The platform ran Tealium CDP, Adobe Analytics, Adobe Target, Contentsquare, GTM, and OneTrust, all of which can quietly bring back the performance cost we'd just removed. We sequenced and lazy-loaded these integrations so analytics and consent management didn't undo the LCP work.
05
LCP improvement is a means, not an end. We tracked checkout conversion alongside Core Web Vitals throughout, which is how a 4.1s → 1.8s LCP improvement showed up as checkout conversion moving from 2% to 4%.
Tech stack
Frontend
React, Next.js, TypeScript
Design system
Design tokens, atomic design, 50–60 components across multiple product squads
Martech
Tealium CDP, Adobe Analytics, Adobe Target, Contentsquare, GTM, OneTrust
Performance
Core Web Vitals tuning (LCP focus), rendering strategy, asset optimization
Frequently asked
Render-blocking third-party scripts and unoptimized hero imagery across 2M+ monthly product pages were the real cause, not JavaScript bundle size, which is where most teams look first.
By restructuring the rendering path to prioritize critical content, deferring non-critical scripts, optimizing image delivery, and sequencing martech integrations (Tealium, Adobe Analytics, Adobe Target, Contentsquare, GTM, OneTrust) so they didn't reintroduce the performance cost.
No. A governed 50–60 component design system on design tokens let multiple product squads ship consistent, performant UI without each squad re-solving accessibility and performance from scratch.
Checkout conversion doubled from 2% to 4% over the engagement, tracked alongside Core Web Vitals throughout, since on a commerce platform, page speed and willingness to complete checkout are directly linked.
Our team specializes in exactly this kind of performance work. See our full services.