Performance isn't a feature. It's the feature. Every 100 milliseconds of load time improvement translates to roughly a 1% increase in conversion rate, according to research from Deloitte and Google. For an Adobe Commerce store doing $20M annually, that math turns performance optimization into a million-dollar conversation faster than most executives expect.
This is the story of how a mid-market B2B and DTC operation on Adobe Commerce went from failing Core Web Vitals on 73% of its pages to passing on 96% — and what that did to their business in the six months that followed.
The Starting Point: A Performance Crisis
The client — a consumer products manufacturer with a hybrid B2B/DTC operation processing approximately 1,800 orders per day — came to Bemeir with a problem that felt familiar: their Adobe Commerce store was slow, getting slower, and they'd watched their organic traffic decline 22% over nine months as Google's page experience signals increasingly influenced rankings.
The Core Web Vitals numbers told the story:
| Metric | Starting Value | Google "Good" Threshold | Status |
|---|---|---|---|
| Largest Contentful Paint (LCP) | 4.8 seconds | < 2.5 seconds | Poor |
| First Input Delay (FID) | 340 ms | < 100 ms | Poor |
| Cumulative Layout Shift (CLS) | 0.31 | < 0.1 | Poor |
| Interaction to Next Paint (INP) | 420 ms | < 200 ms | Poor |
Every single metric was in the red. Google Search Console flagged 73% of the site's URLs as having "poor" page experience. Mobile performance was even worse — LCP exceeded six seconds on 4G connections, which is where a significant portion of their DTC customers browsed.
The root causes were a textbook Adobe Commerce performance case: an unoptimized Luma theme with 47 JavaScript modules loading on every page, a third-party extension stack that had grown to 38 extensions over four years of incremental additions, server-side rendering times averaging 2.1 seconds before the browser even received HTML, and an image pipeline that served uncompressed 2MB product photos to mobile devices.
Phase 1: The Foundation — Server-Side Performance
Performance optimization on Adobe Commerce works in layers, and you always start at the bottom. No amount of frontend work matters if the server takes two seconds to generate a response.
The first intervention was infrastructure. The site ran on a shared Adobe Commerce Cloud instance that was undersized for their traffic profile. Bemeir migrated the application to a properly architected AWS deployment: dedicated EC2 instances for the application layer, ElastiCache for Redis session and cache storage, CloudFront CDN for static asset delivery, and an Elasticsearch cluster sized for their 45,000-SKU catalog.
Server-side rendering time dropped from 2.1 seconds to 380 milliseconds. Full-page cache hit rates went from 62% to 94% after reconfiguring Varnish with proper cache tags and implementing hole-punching for personalized content blocks rather than bypassing cache entirely.
The extension audit was surgical. Of 38 installed extensions, 11 were completely unused — leftover from features that had been abandoned but never uninstalled. Seven more had overlapping functionality with either core Adobe Commerce features or other installed extensions. Removing the unused extensions and consolidating the redundant ones reduced the module count to 24 and cut average server response time by another 140 milliseconds.
According to Adobe Commerce performance best practices documentation, extension count is one of the top three factors affecting server-side performance. Every extension adds to the dependency injection compilation, event observer processing, and plugin interception chain. Fewer extensions means faster responses — there's no shortcut around this reality.
Phase 2: The Frontend Transformation — Hyvä Theme
This is where the project turned from incremental improvement to transformational leap. The decision to move from Luma to Hyvä was the single highest-impact change in the entire optimization project.
Luma, Adobe Commerce's default frontend, was built in an era when jQuery was king and RequireJS was considered modern. It loads a massive JavaScript bundle on every page — typically 300-400KB of JavaScript before any page-specific functionality runs. That JavaScript has to be downloaded, parsed, compiled, and executed before the page becomes interactive. On mobile devices with constrained CPU, this process alone can take two to three seconds.
Hyvä replaces all of that with Alpine.js and Tailwind CSS. The total JavaScript payload dropped from 387KB to 42KB. CSS went from 280KB (loaded as a monolithic bundle regardless of page type) to 28KB of page-specific, purged CSS.
The impact on Core Web Vitals was immediate and dramatic:
| Metric | Post-Infrastructure | Post-Hyvä | Improvement |
|---|---|---|---|
| LCP | 3.2 seconds | 1.4 seconds | 56% faster |
| FID | 180 ms | 28 ms | 84% reduction |
| CLS | 0.22 | 0.04 | 82% reduction |
| INP | 290 ms | 85 ms | 71% reduction |
The LCP improvement came from two factors: dramatically faster JavaScript parsing meant the browser could start rendering meaningful content sooner, and Hyvä's simplified DOM structure meant the critical rendering path had fewer blocking resources. The FID and INP improvements were almost entirely attributable to the reduced JavaScript payload — less JavaScript means faster interactivity, full stop.
CLS improvement was a Hyvä design benefit. Luma's asynchronous JavaScript loading frequently caused layout shifts as modules initialized and injected content into the page. Hyvä's server-rendered approach with Alpine.js progressive enhancement eliminated the most common shift triggers: late-loading navigation elements, price rendering delays, and asynchronous review widget injection.
Bemeir's Hyvä implementation for this client took nine weeks — faster than a typical Luma redesign because Hyvä's component architecture is simpler to work with. The reduced complexity also meant fewer QA cycles. The Hyvä theme had 60% fewer template files than the Luma theme it replaced, which translates directly to less surface area for bugs.
Phase 3: Image Optimization and Asset Delivery
With server and frontend performance addressed, images became the remaining bottleneck. Product photography is non-negotiable for eCommerce — you can't sell a $200 product with a 50KB thumbnail. But serving a 2.4MB JPEG to a mobile device on a 4G connection is also non-negotiable in the other direction.
The image pipeline overhaul had three components. First, all product images were reprocessed through automated optimization: WebP conversion with AVIF fallback for supported browsers, responsive srcset attributes serving appropriate sizes per viewport, and aggressive quality optimization (82% quality for WebP produces visually indistinguishable results while reducing file size by 60-70% versus the source JPEG).
Second, lazy loading was implemented for all below-fold images. The hero image and first row of product images on category pages loaded eagerly to preserve LCP, while everything else loaded on scroll. This reduced initial page weight on category pages from 4.2MB to 680KB.
Third, CloudFront's image optimization was configured to serve format-appropriate images automatically based on the Accept header. Browsers supporting AVIF get AVIF. Chrome and Firefox get WebP. Legacy browsers get optimized JPEG. Zero client-side decision logic required.
The combined effect: median page weight dropped from 5.1MB to 1.1MB across the site. On mobile connections, this translated to roughly three seconds of reduced download time for first-visit users.
Phase 4: Third-Party Script Management
The final optimization layer addressed third-party scripts — the performance tax that every eCommerce site pays and most never audit. The client's site loaded 14 third-party scripts: Google Analytics (GA4), Google Tag Manager, Facebook Pixel, Pinterest Tag, Criteo retargeting, Hotjar session recording, Zendesk chat widget, a loyalty program widget, two A/B testing tools (one of which nobody on the team could identify), and four payment-related scripts.
Total third-party JavaScript: 1.2MB. On every page. Before any interaction.
The intervention was pragmatic, not purist. We didn't advocate removing analytics or marketing tools — they serve real business purposes. Instead, we implemented a tiered loading strategy. Critical scripts (GA4, consent management) loaded immediately. Marketing scripts (Meta Pixel, Pinterest, Criteo) loaded after the page became interactive — a 3-second delay that had zero measurable impact on attribution accuracy. Experience tools (Hotjar, chat) loaded on user interaction — scroll, click, or 10-second idle. The unidentified A/B testing tool was removed entirely.
Third-party script impact on INP dropped by 62%. The chat widget alone had been adding 180ms to interaction latency on every page, even when no user ever opened it.
The Business Results
Performance optimization projects live or die on business outcomes. Technical metrics impress engineers; revenue metrics fund the next project. Here's what happened in the six months following full optimization:
Organic traffic recovered and grew. The 22% decline reversed within three months as Google's page experience signals improved. By month six, organic traffic was 31% above the pre-decline baseline — not just recovery, but growth. Google Search Console showed 96% of URLs passing Core Web Vitals assessments, up from 27%.
Conversion rate increased 18%. On mobile specifically — where the performance improvements were most dramatic — conversion rate improved 24%. Desktop conversion improved 11%. The combined lift translated to approximately $3.6M in additional annual revenue at existing traffic levels.
Bounce rate dropped 15%. Faster pages keep visitors. Category pages saw the largest improvement: bounce rate dropped from 52% to 38%. Product pages improved from 34% to 28%.
Server costs decreased 22%. This surprises people, but faster code requires fewer server resources. The optimized application served the same traffic volume on smaller infrastructure. The AWS bill dropped from $8,400/month to $6,500/month.
According to Google's own research published through web.dev, businesses that achieve "good" Core Web Vitals scores see 24% fewer page abandonments on average. This client's results tracked closely with that benchmark.
The Compounding Effect
Six months of data confirmed what Bemeir has seen across dozens of Adobe Commerce performance engagements: performance improvements compound. Better Core Web Vitals improve organic rankings. Better rankings drive more traffic. Faster pages convert that traffic at higher rates. Higher conversion rates generate more revenue. More revenue funds further optimization.
The client reinvested a portion of the performance-driven revenue gains into a second phase — personalization and advanced search — which the now-optimized infrastructure could support without performance degradation. On the pre-optimization Luma theme, adding personalization features would have pushed LCP back above four seconds. On the Hyvä-powered, properly architected platform, personalization added less than 200ms to page load.
What This Means for Your Adobe Commerce Store
If your Adobe Commerce store is failing Core Web Vitals — and according to the Chrome User Experience Report, roughly 58% of Adobe Commerce sites still don't pass all three thresholds — the optimization path is well-established. Infrastructure first, frontend second (Hyvä is the most impactful single change available), images and asset delivery third, third-party scripts fourth.
The timeline for meaningful improvement is typically three to four months for a comprehensive optimization. The ROI, in our experience, is consistently the highest of any eCommerce investment category. Faster sites make more money. The data is unambiguous.
Bemeir has delivered Core Web Vitals optimization for Adobe Commerce merchants ranging from $5M to $200M in annual digital revenue. The technical approach scales across that spectrum — the same architectural principles apply whether you're running 500 SKUs or 500,000. What changes is the complexity of implementation, not the strategy.
If your pages take more than three seconds to load, you're leaving money on the table every single day. The question isn't whether to invest in performance — it's how much revenue you're willing to lose while you wait.
