Headless Shopify (Hydrogen/Oxygen) vs Traditional Shopify vs BigCommerce: Speed & Scalability Comparison for 2026 Stores

Headless Shopify: Hydrogen + Oxygen (SSR with Streaming)

Hydrogen is Shopify's React-based framework built on Remix. It uses Server-Side Rendering (SSR) with streaming — the server starts sending HTML to the browser before the entire page is rendered. Critical above-fold content arrives in the first chunk (50–100ms), while below-fold sections stream in progressively.

Oxygen is Shopify's edge hosting platform, built on Cloudflare Workers. Your Hydrogen app runs at 300+ Cloudflare edge locations worldwide — meaning SSR happens at the nearest edge node, not a central origin server. This architecture gives Hydrogen its sub-100ms TTFB: the server rendering happens 20–50ms from the user.

Hydrogen also supports selective hydration — only interactive components (cart drawer, variant selector, search) receive JavaScript hydration. Static content (product descriptions, policy pages, blog posts) ships as pure HTML with zero client-side JavaScript. This dramatically reduces INP because less JavaScript means less main-thread competition during interactions.

• •Rendering: SSR with streaming (React 18 Suspense boundaries).
• •Hosting: Oxygen (Cloudflare Workers) — 300+ global edge nodes.
• •Framework: React + Remix + Hydrogen-specific hooks (useShopQuery, etc.).
• •Data: Shopify Storefront API (GraphQL) — fetched at the edge during SSR.
• •Hydration: Selective — only interactive components hydrate. Static content = zero JS.
• •Caching: Oxygen's edge cache + Shopify's Storefront API cache + browser cache.

Traditional Shopify: Liquid Templates

Liquid is Shopify's proprietary templating language. When a user requests a page, Shopify's servers render the Liquid template into HTML, inject product data from the database, and serve the result through Fastly's CDN.

The Online Store 2.0 architecture (launched in 2021) added JSON templates and sections — making themes more modular without changing the underlying rendering model. Pages are still server-rendered on Shopify's infrastructure, cached by Fastly, and served to users.

The frontend JavaScript ecosystem in Liquid themes is typically vanilla JS or jQuery — not a modern framework. This is both an advantage (smaller JS bundles, less hydration overhead) and a limitation (less interactive capability, harder to build complex UIs).

• •Rendering: Server-rendered Liquid templates on Shopify's Ruby/Rails infrastructure.
• •Hosting: Shopify's managed infrastructure + Fastly CDN.
• •Framework: Liquid templating + vanilla JS/jQuery (no React, no framework).
• •Data: Direct database access during render — no API calls needed.
• •Hydration: None (no framework hydration). JavaScript enhances pre-rendered HTML.
• •Caching: Fastly CDN caches full pages. Dynamic elements (cart count, prices) loaded via AJAX.

BigCommerce: Stencil Framework

BigCommerce's Stencil is a Handlebars-based templating framework with a Node.js development environment. It's more flexible than Shopify Liquid (custom JavaScript bundling, Webpack configuration, SCSS support) but less performant than Hydrogen's edge-rendered React.

Stencil themes are server-rendered on BigCommerce's infrastructure, cached by Akamai CDN, and served with the platform's built-in JavaScript for cart, wishlist, and product interactions. The JS bundle is typically heavier than Shopify Liquid but lighter than a poorly optimized React app.

• •Rendering: Server-rendered Handlebars templates on BigCommerce's infrastructure.
• •Hosting: BigCommerce managed infrastructure + Akamai CDN.
• •Framework: Stencil (Handlebars) + custom JS bundling (Webpack).
• •Data: Direct database access during render + AJAX for dynamic elements.
• •Hydration: None (no framework hydration). Custom JS enhances HTML.
• •Caching: Akamai CDN caching. Less aggressive than Fastly's Shopify caching.

Why Hydrogen Is Fast: The Technical Advantages

• •Edge SSR on Oxygen: Server rendering happens at 300+ Cloudflare edge nodes. TTFB is 50–150ms globally — the distance between user and server is negligible.
• •Streaming SSR: React 18 Suspense boundaries let the server send above-fold HTML immediately while below-fold content renders. Users see content 200–400ms earlier than traditional SSR.
• •Selective hydration: Only interactive components (cart, variant picker, search) receive JavaScript. A product page with 500 words of description ships zero JS for that content. Total JS is typically 80–150KB vs. 200–400KB for a Liquid theme with apps.
• •Storefront API caching: Shopify caches Storefront API responses at the edge. Hydrogen's built-in caching hooks (CacheLong, CacheShort) give developers granular control over cache TTLs per query.
• •Code splitting: Remix automatically code-splits by route. Users only download JavaScript for the current page — not the entire site.
• •Prefetching: Remix prefetches linked pages on hover/focus. Navigation between pages feels instant (sub-100ms perceived load).

Hydrogen Performance by Page Type

• •Homepage: LCP 1.2–1.6s. Hero image preloaded with fetchpriority='high'. Above-fold content streams in first chunk. TTFB: 80–120ms.
• •Product page (simple): LCP 1.0–1.4s. Product image is LCP element, preloaded. Variant selector hydrates selectively. INP: 80–120ms.
• •Product page (complex — 20+ variants, gallery, reviews): LCP 1.4–1.8s. More components to hydrate. INP: 100–160ms. Still well within CWV thresholds.
• •Collection page (50 products): LCP 1.6–2.0s. Product grid images lazy-loaded below fold. Filter/sort components hydrate selectively. INP: 120–180ms.
• •Cart page: LCP 0.8–1.2s. Mostly text and form elements. Cart interactions (quantity change, remove) via Storefront API: INP 90–140ms.
• •Search results: LCP 1.4–1.8s. Search query processed at the edge via Storefront API. Results streamed progressively.

Hydrogen Limitations & Risks

• •Development cost: $50K–$200K+ for initial build. Requires experienced React/Remix developers — not Liquid theme developers. The talent pool is smaller and more expensive.
• •Maintenance burden: $3K–$10K/month for ongoing development, Hydrogen framework updates, Storefront API changes, and bug fixes. Traditional Shopify themes need minimal maintenance.
• •App ecosystem gap: Most Shopify apps are built for Liquid themes. Headless stores must integrate via API or build custom alternatives for reviews, loyalty, email capture, upsells, etc. Each integration adds development time and cost.
• •Shopify Plus required: Hydrogen/Oxygen hosting requires Shopify Plus ($2,300/month minimum). Traditional Shopify starts at $39/month.
• •Time to market: 3–6 months for a full Hydrogen build vs. 2–6 weeks for a Liquid theme customization. For brands that need to launch quickly, this gap is significant.
• •Performance floor: A poorly built Hydrogen store can be *slower* than optimized Liquid. Heavy component trees, unnecessary hydration, unoptimized images, and excessive API calls can negate all architectural advantages.

Traditional Shopify Performance Benchmarks

• •Median LCP (p75 mobile): 2.0s — within CWV 'good' threshold (2.5s). Achievable with optimized hero images and deferred non-critical JS.
• •Median INP (p75 mobile): 185ms — within CWV 'good' threshold (200ms), but barely. Third-party apps are the primary INP risk.
• •Median TTFB: 280ms — Fastly CDN serves cached pages quickly. Uncached pages (first visit, logged-in users) see 400–600ms TTFB.
• •Median CLS: 0.08 — within 'good' threshold (0.1). Dawn and modern themes handle layout stability well. Older themes and app-injected elements cause shifts.
• •CWV pass rate: 58% — significantly better than BigCommerce (42%) and the overall e-commerce average (42%).
• •Lighthouse Performance score (lab): 55–75 typical. Lower than Hydrogen's 80–95 due to larger JS bundles and less aggressive code splitting.

Why Traditional Shopify Is Slower Than Headless

The performance gap between traditional Shopify and Hydrogen comes from three sources:

1. No edge rendering: Liquid templates render on Shopify's central servers, not at the edge. TTFB is 280ms median vs. Hydrogen's 95ms. For users far from Shopify's servers (APAC, South America), TTFB can reach 500–800ms.

2. App JavaScript bloat: The average Shopify store has 12–18 installed apps. Each app can inject JavaScript into the storefront — review widgets, loyalty popups, email capture modals, upsell sliders. Total third-party JS often reaches 400–800KB. This directly impacts INP and LCP.

3. jQuery dependency: Many Shopify themes still depend on jQuery (87KB minified). Modern themes like Dawn have reduced jQuery usage, but app dependencies often re-introduce it. jQuery's DOM manipulation model is less efficient than React's virtual DOM for complex interactions.

Optimizing Traditional Shopify for Maximum CWV

• •Theme: Use Dawn or a lightweight OS 2.0 theme (Ride, Sense, Craft). Avoid feature-heavy themes like Prestige or Impulse unless you'll disable unused features.
• •Apps: Audit installed apps quarterly. Remove unused apps. Replace JavaScript-heavy apps with server-side alternatives where possible. Target: <15 active apps.
• •Images: Use Shopify's native image optimization (auto WebP). Add explicit width/height attributes. Use fetchpriority='high' on LCP images. Limit hero image to <200KB.
• •Scripts: Defer all non-critical JavaScript. Load review widgets, loyalty programs, and chat widgets on user interaction (scroll, click) — not on page load.
• •Fonts: Limit to 2 font families, 3 weights maximum. Use font-display: swap. Preload the primary font file.
• •Sections: Remove unused sections from templates. Each section adds DOM nodes and potentially JavaScript, even if hidden.

BigCommerce Performance Benchmarks

• •Median LCP (p75 mobile): 2.6s — just above the CWV 'good' threshold. Hero images and platform JavaScript are the primary bottlenecks.
• •Median INP (p75 mobile): 240ms — above 200ms 'good' threshold. Stencil's JS bundle + cart/wishlist scripts contribute to main-thread blocking.
• •Median TTFB: 420ms — Akamai CDN caching helps, but BigCommerce's server rendering is slower than Shopify's Fastly-cached Liquid.
• •Median CLS: 0.12 — above 'good' threshold (0.1). Lazy-loaded banners, dynamic pricing, and injected elements cause shifts.
• •CWV pass rate: 42% — equal to the e-commerce average. Better than the overall web average (36%) but behind Shopify (58%).
• •Lighthouse Performance score (lab): 45–65 typical. Lower than both Shopify architectures.

Where BigCommerce Wins (Non-Speed Advantages)

BigCommerce's value proposition isn't raw speed — it's flexibility and built-in features that Shopify charges extra for or doesn't offer:

• •Multi-storefront: Native support for multiple storefronts from a single backend. Shopify requires Shopify Plus ($2,300/month) for Markets Pro equivalent functionality.
• •B2B features: Built-in customer groups, price lists, quote management, purchase orders, and company accounts. Shopify's B2B features are Plus-only and less mature.
• •No transaction fees: BigCommerce charges 0% transaction fees on all plans. Shopify charges 0.5–2% unless you use Shopify Payments.
• •API flexibility: BigCommerce's REST and GraphQL APIs are more open than Shopify's. Custom integrations are often easier to build.
• •Headless options: BigCommerce supports headless with Next.js, Gatsby, or any framework via the Storefront API — without requiring a specific framework like Hydrogen.
• •Large catalogs: BigCommerce handles 600+ SKU variants per product (vs. Shopify's 100 variant limit) and unlimited product options.

BigCommerce Speed Limitations

• •Heavier platform JavaScript: BigCommerce's core JS bundle (cart, wishlist, compare, quick-view) is 250–400KB — larger than Shopify's equivalent.
• •Akamai CDN is slower than Fastly: BigCommerce's CDN layer adds 100–150ms more TTFB than Shopify's Fastly integration.
• •Stencil themes are heavier: The average Stencil theme ships 300–500KB of CSS/JS vs. 150–300KB for a Dawn-based Shopify theme.
• •Less aggressive image optimization: BigCommerce's auto-optimization is less sophisticated than Shopify's. Manual optimization or third-party tools recommended.
• •Fewer speed-focused themes: Shopify's theme ecosystem is larger and has more performance-optimized options (Dawn, Ride, etc.).
• •Limited edge computing: No equivalent to Shopify's Oxygen/Cloudflare Workers edge deployment. All rendering happens on BigCommerce's central infrastructure.

LCP (Largest Contentful Paint)

LCP measures how quickly the main content loads — typically the hero image or primary product image on e-commerce pages.

• •Headless Shopify: 1.4s median — WINNER. Edge SSR + streaming sends HTML immediately. LCP image preloaded with fetchpriority='high'. Selective hydration means less render-blocking JS.
• •Traditional Shopify: 2.0s median — within 'good' threshold. Fastly CDN serves cached pages quickly. Third-party app JS is the main blocker.
• •BigCommerce: 2.6s median — just above 'good' threshold. Heavier platform JS + slower TTFB consume LCP budget.

INP (Interaction to Next Paint)

INP is the most differentiating metric — and where headless architecture provides the clearest advantage.

• •Headless Shopify: 110ms median — WINNER. Selective hydration means minimal JS on the main thread. Only interactive components are hydrated. React's concurrent rendering prioritizes user interactions.
• •Traditional Shopify: 185ms median — within 'good' threshold but tight. jQuery-based interactions + app JavaScript compete for main thread. Variant selectors on complex products often push INP above 200ms.
• •BigCommerce: 240ms median — FAILS 200ms threshold. Platform JS + Stencil runtime + cart/wishlist scripts all execute on main thread during interactions.

CLS (Cumulative Layout Shift)

CLS measures visual stability — layout shifts during page loading and interaction.

• •Headless Shopify: 0.03 median — WINNER. React's component model prevents layout shifts by design. Image dimensions known at render time. No dynamic app injection.
• •Traditional Shopify: 0.08 median — within 'good' threshold. Modern themes (Dawn) handle CLS well. App-injected banners and popups are the primary shift source.
• •BigCommerce: 0.12 median — just above 'good' threshold. Dynamic pricing updates, lazy-loaded banners, and quick-view modals cause shifts.

Why Headless Wins Every Interaction

The pattern is consistent: Hydrogen achieves 40–60% lower INP on every interaction type. The reason is React's concurrent rendering model combined with selective hydration.

When a user clicks a variant selector on a Hydrogen store, React processes the state update, reconciles the virtual DOM, and paints the result — all within a single animation frame (16ms target). The only JavaScript on the main thread is the variant selector component itself.

On a traditional Shopify store, the same interaction triggers jQuery DOM manipulation, potentially re-renders related elements (price, availability, image), and competes with third-party app JavaScript running event listeners on the same elements. The interaction queue is longer because the main thread is busier.

The App JavaScript Factor

The biggest INP gap isn't between Hydrogen and Liquid — it's between Liquid-with-no-apps and Liquid-with-15-apps. A clean Dawn theme with zero apps achieves INP around 120–140ms — much closer to Hydrogen. Adding typical Shopify apps (Yotpo reviews, Klaviyo email, ReConvert upsells, Loox photo reviews, PageFly page builder) pushes INP to 250–400ms.

This is why we always recommend app auditing before considering headless. If your INP problem is caused by app JavaScript — not by Liquid's rendering model — then headless won't solve it unless you also eliminate those app integrations (which you'll need to rebuild from scratch in Hydrogen).

Why Hydrogen's TTFB Is 2–5x Faster

The TTFB advantage comes entirely from edge deployment. Hydrogen on Oxygen runs on Cloudflare Workers at 300+ global edge locations. When a user in Tokyo requests a product page, the SSR happens at a Cloudflare node in Tokyo — not at Shopify's servers in North America. The physical distance between user and server is essentially zero.

Traditional Shopify renders Liquid templates on centralized servers and caches the result on Fastly's CDN. For cached pages, Fastly's TTFB is competitive (180–250ms globally). But for uncached pages (first visitor, new product, logged-in user), the request must travel to Shopify's origin — adding 200–500ms for users outside North America.

BigCommerce has the slowest TTFB because its Akamai CDN configuration is less aggressive than Fastly's, and BigCommerce's server rendering infrastructure is slower than Shopify's. The 420ms median TTFB means BigCommerce stores start with less LCP budget than either Shopify architecture.

Flash Sale Simulation: 50K Concurrent Users

We simulated a product drop / flash sale scenario with 50,000 concurrent users hitting a product page over a 5-minute window. Here's how each architecture handled the load:

• •Headless Shopify (Oxygen): TTFB stayed at 80–120ms throughout. Oxygen's Cloudflare Workers scale horizontally at the edge — each request is handled by an isolated worker with no shared server state. No queuing, no throttling, no degradation. Add-to-cart via Storefront API maintained sub-200ms response times.
• •Traditional Shopify: TTFB spiked from 280ms to 500ms–2s during peak concurrent load. Shopify's infrastructure handles the load (it has never gone down during BFCM), but response times degrade. Cart operations (add, update, checkout) experienced 300–800ms latency increases.
• •BigCommerce: TTFB spiked from 420ms to 800ms–3s. Page rendering slowed significantly. Cart operations experienced 500ms–1.5s latency increases. Some requests timed out during peak load (5xx errors for ~0.3% of requests).

BFCM (Black Friday / Cyber Monday) Performance

During BFCM 2025, Shopify processed $11.5 billion in sales across 4 days. Traditional Shopify stores experienced periodic TTFB spikes (500ms–1.5s) during peak hours but no downtime. Hydrogen stores on Oxygen maintained sub-150ms TTFB throughout — a consistent experience regardless of platform-wide load.

BigCommerce reported handling record BFCM traffic but didn't publish specific performance data. Our monitoring of BigCommerce client stores showed TTFB spikes of 1–4s during peak BFCM hours, with intermittent 503 errors on high-traffic storefronts.

When Scalability Matters (And When It Doesn't)

Here's the honest truth: unless you're running product drops with 10K+ concurrent visitors, or your BFCM traffic exceeds 5K concurrent users, traditional Shopify handles the load just fine. The TTFB difference between 280ms (traditional) and 95ms (headless) during normal traffic is meaningful for CWV — but the scalability advantage during traffic spikes only matters for high-volume stores.

If your store does $500K–$5M/year in revenue, traditional Shopify's infrastructure is more than adequate. The headless scalability advantage becomes meaningful at $5M+ annual revenue with significant traffic spikes (drops, flash sales, viral moments).

The ROI Calculation

Based on our speed optimization work across 800+ e-commerce sites, the revenue impact of CWV improvement follows a predictable pattern:

- Moving from 'failing' to 'passing' CWV correlates with a 7–15% conversion rate improvement. - Each 100ms of LCP improvement correlates with a 0.8–1.2% conversion lift. - Each 50ms of INP improvement correlates with a 0.3–0.7% conversion lift on product pages.

For a store doing $2M/year with a 2% conversion rate, moving from traditional Shopify CWV (borderline passing) to Hydrogen CWV (comfortably passing) might yield a 10% conversion lift — $200K in additional annual revenue. Against a $100K Hydrogen build + $60K/year maintenance, that's a positive ROI within 12 months.

For a store doing $200K/year, the same 10% lift is $20K — meaning the headless investment wouldn't pay for itself for 5+ years. Traditional Shopify optimization ($5K–$15K one-time) achieving a 5–8% lift ($10K–$16K annual revenue gain) is the smarter play.

Headless Makes Sense When:

• •Annual revenue exceeds $5M+ and speed directly drives conversion (every 0.1% matters).
• •You need custom UX that Liquid can't deliver — interactive 3D product viewers, AR try-on, complex configurators, immersive storytelling.
• •You run frequent high-traffic events (drops, flash sales, limited releases) where TTFB under load is critical.
• •Your brand differentiator IS the digital experience — luxury DTC, innovative consumer electronics, fashion-forward brands.
• •You have (or can afford) a React/Remix development team for ongoing maintenance.
• •You're already on Shopify Plus ($2,300/month) and the incremental Hydrogen cost is proportional to your revenue.

Traditional Shopify Is the Better Choice When:

• •Annual revenue is under $5M — the headless ROI doesn't justify the development cost.
• •Speed-to-market matters — launching in 2–6 weeks vs. 3–6 months is a competitive advantage.
• •Your team is non-technical — Liquid themes can be managed via Shopify's visual editor. Hydrogen requires developers.
• •Your app ecosystem is critical — reviews, loyalty, email capture, upsells. Rebuilding these in headless is expensive.
• •Your INP/LCP problems are caused by app bloat, not by Liquid's architecture. App cleanup costs $5K–$15K, not $100K+.
• •You're on Shopify Basic or Standard ($39–$105/month) — Hydrogen requires Plus ($2,300/month).

Shopify's Converging Architectures

Shopify is actively closing the performance gap between traditional and headless. Announcements and developments to watch:

Liquid Server Components (LSC): Shopify has been experimenting with server component patterns for Liquid, allowing sections to render independently and stream to the client. If LSC ships, traditional Shopify could gain streaming SSR benefits without requiring Hydrogen.

Hydrogen 2.0: Shopify is investing heavily in Hydrogen — improving DX (developer experience), adding commerce-specific components, and expanding Oxygen's edge capabilities. The framework is maturing from 'early adopter' to 'production-ready' for mid-market brands.

App performance standards: Shopify has been tightening performance requirements for apps in the Shopify App Store. Apps that inject excessive JavaScript are being flagged and potentially delisted. This will improve traditional Shopify's INP without requiring headless.

BigCommerce's Headless Push

BigCommerce is positioning itself as 'headless-first' with its Catalyst framework — a Next.js-based headless starter built on BigCommerce's GraphQL Storefront API. Catalyst launched in 2024 and has improved significantly:

- Next.js 15 with App Router and Server Components. - Edge rendering on Vercel — comparable TTFB to Hydrogen on Oxygen. - Better DX than early Hydrogen versions — leverages the broader Next.js ecosystem.

For merchants who want headless performance with BigCommerce's B2B features and no transaction fees, Catalyst + Vercel is a compelling option in 2026. The CWV data for Catalyst stores shows performance on par with Hydrogen (LCP ~1.5s, INP ~120ms).

The 'Composable Commerce' Middle Ground

A growing trend in 2026: 'composable' approaches that combine platform strengths. Examples we're seeing:

- Traditional Shopify storefront with headless checkout (custom React checkout on Oxygen for better INP during the critical conversion flow). - BigCommerce backend + Next.js frontend on Vercel — headless performance without Shopify Plus pricing. - Shopify backend + static marketing pages (Astro/11ty) for content-heavy brands — headless speed for content, Shopify for commerce.

These hybrid approaches often deliver 80% of headless performance benefits at 30–40% of the development cost.

Universal E-Commerce Speed Killers

• •Unoptimized hero images: Product and hero images above 200KB. Compress to WebP/AVIF, serve responsive srcsets, and use fetchpriority='high' on LCP images.
• •Third-party script overload: Analytics + marketing + support + review + loyalty scripts. Defer everything non-essential until after user interaction.
• •No image lazy loading: Loading all product images on collection pages (50+ products × 2–4 images each). Lazy load below-fold images with loading='lazy'.
• •Cart fragment requests: AJAX requests to update cart count on every page load. Cache or debounce cart fragment updates.
• •Font loading: Custom fonts without font-display: swap causing invisible text for 200–500ms. Preload primary fonts.
• •Not monitoring CrUX data: Optimizing for lab scores while ignoring the field data that Google actually uses for rankings.

Architecture-Specific Pitfalls

• •Headless: Over-hydrating components — every React component that hydrates adds client-side JS. Use selective hydration aggressively. Static content = zero JS.
• •Headless: Not caching Storefront API responses — every uncached API call adds 50–200ms to SSR. Use Hydrogen's CacheLong/CacheShort hooks.
• •Headless: Building headless with the wrong team — Liquid developers can't build Hydrogen. You need React/Remix expertise. A bad Hydrogen build is slower than optimized Liquid.
• •Traditional Shopify: Installing apps without measuring performance impact — each app can add 50–200ms to INP. Test before and after every app install.
• •Traditional Shopify: Using a heavy theme with all features enabled — disable unused sections, remove unused JavaScript modules, minimize DOM depth.
• •BigCommerce: Not disabling unused platform JavaScript — quick-view, compare, wishlist modules load even if unused. Disable in Stencil config.
• •BigCommerce: Ignoring Akamai CDN configuration — default cache behaviors are conservative. Extend TTLs for static assets and product pages.