Mobile Checkout 2026: How 7-Field Forms Lift DACH ConversionA typical German mobile checkout asks fo…
Mobile-First Storefront Without JavaScript Bloat Lighthouse 95+
Mobile-First Storefront Without JavaScript Bloat Lighthouse 95+ for Composable Frontends
Composable sounds like "more APIs, more bundle size, worse performance." A widespread assumption — and it's wrong. When the frontend layer is orchestrated right, you ship less JavaScript over the wire than a Luma Magento theme or an average Shopify theme with 30 installed apps. Lighthouse 95+ becomes a platform property, not a sprint goal.
Where the JavaScript in Classic Shops Comes From
Before we talk composable an honest inventory of typical bundle sizes (mobile, gzipped):
- Magento Luma: RequireJS + Knockout.js + Luma theme stack = ~280–420 KB
- Shopify Vanilla + 30 apps: Liquid layer + 5–30 KB per app = ~350–550 KB
- Magento Hyvä (Best Case): Alpine + Tailwind + custom JS = ~120–180 KB
- WooCommerce with active plugins: jQuery + plugin JS = ~300–500 KB
These are realistic median values from market Lighthouse reports not worst cases. Every third-party script (tag manager, personalization, live chat, reviews) adds another 30–100 KB. Mobile LCP over 4 seconds is the result.
The Three Composable Killer Mechanics
A well-orchestrated composable frontend has structural advantages that classic themes can't match:
1. Tree-Shaking + Pure-ESM Component Library
A composable component library shipped as ESM lets the bundler tooling remove unused code. On a product page, only the components actually rendered get loaded — not the entire library.
Example: a storefront with 60 components in the library typically loads 8–12 components on a PDP (gallery, add-to-cart, variant selector, reviews, etc.) the other 48 never make it into the user's bundle. In a classic theme setup, all 60 are in a shared theme bundle on every page load.
2. Island Architecture and Selective Hydration
Not every area of a storefront is interactive. Static content (product description, SEO text, footer) doesn't need client JavaScript it renders as HTML and stays HTML. Interactive components (add-to-cart, variant selector, search) get isolated as islands and hydrated.
Concretely: on a typical PDP, 70% of the markup is static. That 70% needs no JS bundle. Selective hydration typically saves 40–60 KB of JS on a 100 KB page.
3. Hydrate-on-Interaction
Components only needed after user interaction load only when they're needed. A search modal loads its JS on the first click of the search icon, not on page load. The reviews widget loads when it scrolls into view.
This moves JavaScript loading out of the critical LCP path. LCP measures when the largest visible element is rendered JS that isn't needed for the critical element has no business in the LCP path.
What Lighthouse 95+ Concretely Requires
Lighthouse 95+ on mobile is reachable when these values hold:
| Core Web Vital | Lighthouse 95+ Target |
|---|---|
| **LCP (Largest Contentful Paint)** | < 2.5s |
| **INP (Interaction to Next Paint)** | < 200ms |
| **CLS (Cumulative Layout Shift)** | < 0.1 |
| **TBT (Total Blocking Time)** | < 200ms |
| **TTFB (Time to First Byte)** | < 600ms |Source: web.dev Core Web Vitals — Google standard.
With the three mechanics above, these values are reachable without ripping out marketing features (personalization, A/B tests, tag manager). They just load after the critical render path.
Mobile-First Specifics
Mobile has quirks that change the performance strategy:
- Bundle splitting by viewport: components rendered only on desktop (mega menu with complex hover logic) don't belong in the mobile bundle
- Critical CSS path: above-the-fold CSS inline, the rest async via `<link rel="preload">`. Saves 100–300ms LCP on mobile
- Image formats AVIF/WebP: AVIF saves 50–70% bandwidth vs. JPEG. Mobile on 4G benefits directly
- Network-aware hydration: detect 2G/3G via Network Information API — delay hydration for non-critical components
Proof Data Typical Before/After
Plausible median values from real migration projects (measured Lighthouse mobile, 4G throttling):
| Metric | Magento Luma Before | Composable FMP After |
|---|---|---|
| **JS over the wire (gzipped)** | 320 KB | 95 KB |
| **LCP** | 4.8s | 1.9s |
| **INP** | 380ms | 140ms |
| **CLS** | 0.18 | 0.04 |
| **Lighthouse Score (Performance)** | 42 | 96 |Disclaimer: Values are typical magnitudes from migration projects, not exact customer guarantees. Actual performance depends on third-party stack (tag manager, reviews, etc.).
More on Core Web Vitals in headless architectures.
What Composable Setups Often Get Wrong
Composable isn't automatically fast. Anti-patterns that ruin performance:
- Too many small API calls instead of a batched GraphQL request. 8 sequential REST calls on a PDP = 800ms network wait
- Missing pre-fetching: when a user navigates from home to category, the category data should already be loading in the background — on hover over the category link
- Render-blocking third-parties: tag manager and personalization scripts in the head without `async`/`defer` = instant LCP killer
- Images without `width`/`height`: layout shift on every image load = CLS climbs
- Excessive client routing: SPA routing without SSR/SSG for the most important pages = TTFB suffers under server load
The performance platform properties of Laioutr are designed to avoid these anti-patterns out of the box.
FAQ
Is composable really faster than Hyvä? In most setups: yes. Hyvä optimizes theme rendering and typically delivers 120–180 KB of JS — already significantly better than Luma. A well-orchestrated composable frontend with selective hydration typically comes in at 80–120 KB. The decisive lever isn't the theme engine — it's component granularity and hydration model.
Does Lighthouse 95+ work with tag manager and personalization? Yes, if these tools are orchestrated correctly. Tag manager loads after LCP, personalization as an edge worker instead of client JS, reviews as hydrate-on-scroll. Lighthouse 95+ is reachable with an active marketing stack.
What does performance optimization cost in a composable setup? If a composable frontend is orchestrated correctly from the start: nothing on top — performance is a platform property. If you have to retrofit an existing composable setup, typically 4–8 weeks of performance sprint, depending on anti-pattern density.
How do we realistically measure Lighthouse 95+ in the field, not just the lab? Real User Monitoring (RUM) instead of Lighthouse lab. Tools like Vercel Speed Insights or New Relic Browser return field data. Important: look at the 75th percentile, not the median — that corresponds to worse user connections.
What image formats are standard in 2026? AVIF as primary format, WebP as fallback, JPEG as emergency fallback. Picture element with source set for all three. Browser support for AVIF has been universal since Q4 2024 (except old IE forks irrelevant in B2C anyway).
Next Steps
If your storefront currently has Lighthouse < 80 mobile and you want to know what an FMP setup concretely delivers — we run performance audits. Lighthouse baseline, bundle analysis, bottleneck identification, migration estimate.