The case below is composited from several Magento performance and conversion engagements Bemeir has led with mid-market merchants in the 20 to 80 million dollar GMV range. Specific numbers have been generalized into ranges that reflect typical outcomes rather than any single client. The architectural decisions and the sequencing are real. The point is not to claim any specific number, but to walk through how a customization-and-performance program actually compounds when run with discipline.
The Starting Point
The merchant in this composite was running Adobe Commerce 2.4 on a Luma-derived theme with roughly six years of accumulated customization debt. Catalog size was around 18,000 SKUs across 12 brands, with heavy use of configurable products and a 30-attribute filterable layered navigation. Traffic mix was roughly 65 percent mobile, 30 percent desktop, 5 percent tablet, and a meaningful share of paid social driving expensive new-customer acquisition.
The baseline metrics looked like this. Largest Contentful Paint on mobile PDPs was sitting in the 4.2 to 4.8 second range, well above the 2.5 second Core Web Vitals threshold. Interaction to Next Paint was averaging 380 milliseconds, also outside the good range. Cumulative Layout Shift was acceptable at 0.06. Mobile conversion rate was sitting in the low 1 percent range, while desktop conversion was roughly 3.2 percent. Bounce rate on PDPs from paid social was above 60 percent. Average order value was healthy at around 145 dollars, which made the conversion gap especially expensive.
The team knew they had performance and conversion problems. What they did not have was a clear hypothesis about which customizations would move the metrics, and a discipline for not breaking what was already working.
The Hypothesis
The diagnostic phase produced four working hypotheses, ordered by expected impact. First, the PDP image strategy was costing several seconds of LCP because the hero image was loading from the legacy Magento media path with no responsive variants and aggressive client-side resizing. Second, the layered navigation was rendering all 30 facets on every category page, creating both performance cost and decision paralysis on mobile. Third, the checkout was running on a heavily customized version of the legacy Magento checkout with layout XML overrides four levels deep, contributing meaningful INP and abandonment. Fourth, the legacy frontend stack itself, with KnockoutJS and RequireJS, was a structural ceiling on what any spot optimization could achieve.
Bemeir’s recommendation, drawn from the Magento performance practice the team has refined across dozens of mid-market engagements, was to address the four hypotheses in sequence, with explicit A/B testing on the customizations that touched the customer experience and pure performance work on the structural pieces.
The Sequence: Image Strategy First
PDP image strategy was the first lever because it had the largest expected LCP impact and the lowest customer-facing risk. The work involved three customizations. A custom Magento module was built to generate responsive image variants on upload, integrated with a CDN-based image transformation service. The PDP template was modified to use the picture element with explicit width and height attributes, eliminating layout shift and giving the browser the information needed to allocate space correctly. Lazy loading was applied below the first viewport, with the hero image preloaded via a link rel preload directive.
The measured outcome was an LCP improvement of 1.5 to 2.0 seconds on mobile PDPs. Conversion rate on the affected pages moved up by 6 to 9 percent in A/B testing across three weeks. No regressions in any other metric. This is the part of the engagement where the team built confidence that the customization program could move metrics without breaking things.
Layered Navigation: Where Customization Earned Its Cost
The layered navigation work was the most intensive customization in the engagement. The default Magento behavior renders all configured filters on category pages, with attribute counts updated client-side as filters are applied. On mobile with 30 facets, this meant a heavy initial render and noticeable filter interaction lag.
The custom module Bemeir built changed three things. The default visible filter set was reduced to seven, with the rest collapsed under a “more filters” expansion that loaded on demand. Filter counts moved from real-time client-side recalculation to a debounced server-side query that returned counts only after the user stopped interacting for 200 milliseconds. The mobile filter UI itself was rewritten as a bottom sheet rather than a sidebar, which reflected mobile interaction patterns better.
This work shipped behind a feature flag, A/B tested for four weeks against the legacy navigation. The variant won across every metric: category page bounce dropped by 12 to 18 percent, time-to-add-to-cart shortened by roughly 25 percent, and conversion rate on category-entry sessions improved by 11 to 14 percent. INP on category pages dropped from 380 milliseconds into the 180 to 220 millisecond range.
Checkout: When Customization Means Removing Customization
The checkout work was the inverse of the layered navigation work. Instead of adding customization, the engagement removed it. The legacy checkout had accumulated 14 layout XML overrides, three plugin interceptors on Magento_Checkout core classes, and four custom UI components patched into the KnockoutJS bundle. Most of these had been added over years to address specific requests that nobody on the current team could fully explain.
The customization audit identified seven of the 14 overrides as no longer necessary, two as replaceable with native Magento configuration, and five as legitimately needed. The five legitimate overrides were rebuilt cleanly, properly scoped, and documented. The plugin interceptors were collapsed into a single module with a clear purpose. The KnockoutJS components were rewritten to load only on the steps where they were actually used.
The performance impact was substantial: checkout INP dropped from 420 milliseconds to roughly 160 milliseconds, and the JavaScript bundle on the checkout pages shrank by approximately 40 percent. Cart-to-checkout completion improved by 8 to 11 percent in A/B testing. The team also reported that the checkout codebase became materially easier to maintain, which compounded the value over time.
Hyva: The Structural Reset
The fourth hypothesis was that the legacy frontend stack was a structural ceiling. After the first three workstreams shipped, the data confirmed it. Performance gains from per-component optimizations were real but plateauing. The KnockoutJS and RequireJS bundle weight remained substantial even after aggressive trimming.
The team committed to a Hyva theme migration as the next major workstream. The migration was scoped at roughly five months from kickoff to launch, with the customizations from the previous workstreams reimplemented as clean Hyva components rather than ported as legacy template hacks. The audit-and-rebuild approach added discipline to the migration: about 30 percent of the legacy theme’s customizations turned out to be unnecessary on Hyva because the platform handled the underlying need natively.
The post-migration measurements showed LCP on mobile PDPs landing in the 1.4 to 1.8 second range, a structural reset from the 4.2 to 4.8 starting point. INP across the site landed under 150 milliseconds. The JavaScript payload on a typical page dropped by approximately 80 percent compared to the legacy theme. The Hyva docs describe the architectural reasons this happens, primarily the elimination of the heavy default JavaScript stack in favor of Tailwind plus Alpine.js.
A/B Test Discipline Throughout
The single non-negotiable across the entire engagement was that every customer-facing customization shipped behind a feature flag and ran a real A/B test before promotion. This is the discipline that separates conversion optimization programs that compound from programs that thrash.
The test cadence was three to four customer-facing experiments running simultaneously, each targeting a specific hypothesis with clear success metrics defined before launch. Tests ran for a minimum of two complete business weeks or until they reached the predefined sample size, whichever was longer. Tests with flat or negative results were rolled back without negotiation, even when stakeholders had emotional investment in the variant. According to research from the Baymard Institute, the merchants who sustain conversion gains over years are the ones who run this discipline consistently, not the ones who occasionally A/B test their biggest ideas.
Before and After Metrics
The composite outcomes across this engagement tracked roughly as follows.
| Metric | Baseline | Post-Engagement | Change |
|---|---|---|---|
| Mobile LCP (PDP) | 4.2 to 4.8 sec | 1.4 to 1.8 sec | Approximately 60% improvement |
| Mobile INP (site-wide) | 380 ms average | Under 150 ms | Approximately 60% improvement |
| Mobile CLS | 0.06 | 0.02 | Within “good” threshold |
| Mobile conversion rate | Low 1% range | High 1% to low 2% range | Approximately 38% relative lift |
| Desktop conversion rate | Approximately 3.2% | Approximately 4.0% to 4.2% | Approximately 25% relative lift |
| PDP bounce rate (paid social) | Above 60% | High 40s to low 50s | Approximately 18% improvement |
| Average order value | Approximately $145 | Approximately $148 to $152 | Slight positive, not statistically significant |
| Checkout completion rate | Mid-range | 8 to 11% relative lift | Statistically significant |
| Total page weight (mobile) | Approximately 4.2 MB | Approximately 1.6 MB | Approximately 60% reduction |
The 38 percent conversion lift in the headline is the mobile number, weighted by the channel mix. The desktop number is healthier in absolute terms but had less room to grow. The point of presenting both is that the impact distribution across devices and channels is not uniform, and the merchants who tune to a single number tend to underinvest in the segments where the marginal dollar matters most.
What Made the Program Work
Three things separated this engagement from the conversion programs that stall. The first was treating performance and customization as the same conversation. Every customization had a performance budget, every performance optimization had a conversion hypothesis, and the team did not ship work that scored badly on either dimension. The second was sequencing. The image work came before the navigation work because it was lower risk and built the team’s confidence. The Hyva migration came after the spot optimizations because it captured the structural ceiling that no spot optimization could break. The third was A/B test discipline applied without exception, including on the changes that “obviously” had to work.
For merchants in the mid-market range looking at similar starting conditions, the lesson is not that 38 percent is achievable. The lesson is that compounding gains across performance, customization, and conversion are achievable when the program is run as a single discipline rather than three separate workstreams. The merchants who run it that way usually
