TL;DR — Quick Summary
BigCommerce stores are slow because of Stencil theme over-fetching (front-matter YAML requesting unused data on every template), app JavaScript bloat (each app adds 100–500ms), unoptimized product images (60–80% of page weight), and suboptimal Akamai CDN configuration. Quick wins: 1) Audit front-matter — remove data declarations not used in each template (saves 100–300ms TTFB per page). 2) Profile apps individually — disable one at a time, measure, remove the worst offenders. 3) Convert images to WebP, use `getImageSrcset` for responsive sizing, and preload the LCP image. 4) Tune Akamai caching rules and enable Brotli compression. 5) Inline critical CSS and defer all non-essential JavaScript. 6) Preload payment SDKs on the cart page and strip marketing scripts from checkout. 7) Monitor CrUX field data — Google uses the 75th percentile of real-user data over 28 days for ranking, not lab scores. 8) Review Stencil Handlebars partials loaded globally vs. conditionally.
Key Takeaways
- ✓Stencil front-matter over-fetching is the #1 hidden BigCommerce performance issue — each unnecessary data declaration adds 50–150ms of server processing time.
- ✓Each installed BigCommerce app adds 100–500ms of JavaScript execution time — profiling apps individually reveals the worst offenders and can save 1–3 seconds.
- ✓Image optimization alone can reduce BigCommerce page weight by 60–80% without visible quality loss using WebP, responsive srcset, and lazy loading.
- ✓Akamai CDN configuration is often suboptimal by default — tuning cache rules, enabling Brotli, and optimizing edge caching can reduce TTFB by 30–50%.
- ✓BigCommerce's built-in features (faceted search, native reviews, advanced catalog management) reduce app dependency vs. Shopify — use them.
- ✓Checkout is the most revenue-critical page: preloading payment SDKs and removing marketing scripts can improve completion rates by 15–25%.
- ✓Core Web Vitals field data (CrUX) determines your Google ranking signal — lab scores are useful for debugging but don't directly affect rankings.
Why BigCommerce Stores Load Slowly
The average BigCommerce store takes over 4 seconds to load on mobile — well above Google's 2.5-second LCP threshold. Five compounding factors are responsible:
1. Stencil theme bloat: BigCommerce's Stencil framework uses Handlebars.js for server-side rendering with YAML front-matter at the top of each template to declare data requirements. Over time, themes accumulate unused Handlebars partials loading on every page, over-fetched front-matter data (requesting product reviews, related products, and blog posts on templates that don't display them), and CSS/JS bundles that include styles and scripts for features you've disabled. A product page that requests `blog.recent_posts`, `products.featured`, and `shop_by_brand` when it only displays the current product wastes 100–300ms of server processing time per request.
2. App JavaScript accumulation: Each BigCommerce app injects its own JavaScript, CSS, and potentially API calls into your storefront. The compound effect is devastating: 10 apps that each add 200ms of JavaScript execution = 2 seconds of main-thread blocking. Common high-impact apps include review widgets (200–500KB JS), live chat (300KB–1MB), upsell/cross-sell popups, loyalty programs, and analytics trackers.
3. Unoptimized product images: Product images typically account for 60–80% of total page weight. Full-resolution images (2000×2000px) served to mobile screens (375px wide), no WebP conversion, no responsive sizing, and no lazy loading for below-fold images. A product page with an 8-image gallery can easily exceed 8MB without optimization.
4. Suboptimal Akamai CDN configuration: BigCommerce uses Akamai's CDN for content delivery, but default cache rules aren't always optimal. Static assets may have short TTLs, certain page types may bypass the cache unnecessarily, and Brotli compression may not be enabled for all content types.
5. Checkout and payment complexity: Payment gateway scripts (Stripe, PayPal, Braintree, Square), address validation APIs, shipping rate calculators, tax computation services, and fraud detection tools all execute during checkout — the single most revenue-critical page.
Step 1: Audit and Optimize Your Stencil Theme
Stencil theme optimization is where most BigCommerce speed projects begin, because it addresses both server-side (TTFB) and client-side (render) performance simultaneously.
Front-matter data audit (highest priority): Open each template file and review its YAML front-matter section. For every data declaration, verify it's actually rendered in the template body. Common over-fetches we find on client stores:
- •`products.featured` on non-homepage templates
- •`blog.recent_posts` on product and category pages
- •`shop_by_brand` on pages without brand navigation
- •`products.new` loaded globally when only used on homepage
- •`products.top_sellers` on pages that don't display them
Remove any data requests that aren't rendered. Each removal reduces server processing time and TTFB, directly improving LCP.
Handlebars partial optimization: Stencil's `{{> partial}}` syntax includes a partial on every page where it's called. Audit for:
- •Global partials in base.html: Partials included in `base.html` render on every page. Move template-specific partials to their relevant templates only.
- •Missing conditionals: Use `{{#if}}` blocks to prevent rendering partials when their data is empty — an empty reviews partial still costs DOM and processing.
- •Nested partial chains: Deeply nested partials increase DOM complexity and rendering time. Flatten where possible.
- •Orphaned partials: Theme customizations often leave partials that render invisible content. Audit and remove them.
CSS delivery optimization: BigCommerce loads all theme CSS in a single file, which blocks rendering until fully downloaded.
- •Extract critical above-the-fold CSS (use tools like Critical) and inline it in the `
<head>` - •Load the full stylesheet asynchronously: `
<link rel="stylesheet" href="theme.css" media="print" onload="this.media='all'">` - •Remove unused CSS rules — Stencil themes often include styles for features you've disabled or never used
JavaScript optimization:
- •Audit `assets/js/` for scripts loaded globally but only needed on specific pages (e.g., product zoom JS loading on category pages)
- •Add `defer` to all non-critical script tags to prevent render-blocking
- •Split JavaScript by page type where the theme architecture allows it
- •Remove console.log statements and debugging code from production bundles
Step 2: Profile and Reduce App Impact
App JavaScript is the single largest variable in BigCommerce store performance. Two stores on identical Stencil themes can have a 3-second speed difference purely based on their installed apps.
How to profile each app's impact:
- 1Open Chrome DevTools → Network tab → filter by 'JS' to see all scripts loading
- 2Note the total JavaScript size and number of requests
- 3In BigCommerce admin, disable ONE app
- 4Hard refresh the storefront and measure the new totals
- 5Re-enable that app, disable the next one
- 6Create a spreadsheet: app name, JS size added, load time impact, business value
Common high-impact app categories:
- •Review widgets (Judge.me, Yotpo, Stamped): 200–500KB JS. If using multiple, consolidate to one. Consider BigCommerce's native reviews if your needs are simple.
- •Live chat (Tidio, LiveChat, Intercom): 300KB–1MB. Defer loading until after first interaction or page idle. Never load chat in the `
<head>`. - •Upsell/cross-sell popups (Bold, Rebuy): 100–300KB JS plus DOM injection. Consider whether the conversion lift justifies the speed cost — test with and without.
- •Loyalty programs (Smile.io, LoyaltyLion): 200–400KB JS. Defer to post-page-load. The loyalty widget doesn't need to render in the first paint.
- •Analytics beyond GA4 (Hotjar, Lucky Orange, Crazy Egg): Session recording scripts are heavy (200–500KB). Limit to specific pages or user segments rather than site-wide.
BigCommerce's built-in advantages: Unlike Shopify, BigCommerce includes several features natively that reduce app dependency:
- •Faceted search: Built-in, performant, no app needed
- •Product reviews: Native review system (basic but functional)
- •Multi-currency: Built-in support without apps
- •B2B features: Price lists, customer groups, quote management
- •Advanced catalog: Product rules, option sets, variant pricing
Use these native features instead of apps wherever possible — each app you eliminate saves 100–500ms of JavaScript execution.
Step 3: Build a High-Performance Image Pipeline
Product images typically account for 60–80% of total page weight on BigCommerce stores. A systematic image pipeline addresses format, sizing, compression, and loading strategy.
Format conversion: Convert all product images to WebP format (30–50% smaller than JPEG) or AVIF (50–70% smaller). BigCommerce supports WebP through its image CDN — the platform automatically serves WebP to supported browsers when images are requested through the built-in CDN URLs. Verify this is working by checking the `Content-Type` header in DevTools Network tab.
Responsive sizing with getImageSrcset: BigCommerce's Stencil framework provides the `getImageSrcset` Handlebars helper to serve appropriately-sized images for each viewport width. Implementation:
{{getImageSrcset image use_default_sizes=true}}
This generates `srcset` attributes with multiple image sizes, letting the browser download only the size it needs. A mobile device gets a 375px-wide image instead of the 2000px original — a 70–85% size reduction.
Lazy loading strategy:
- •Add `loading="lazy"` to all product grid images, gallery thumbnails, and below-fold content images
- •Critical exception: Never lazy-load the LCP element (hero banner on homepage, main product image on product pages)
- •The LCP image should use `loading="eager"` (or omit the attribute entirely) and `fetchpriority="high"`
Preload the LCP image: Identify what the LCP element is on each page type and preload it:
- •Homepage: Hero banner → `
<link rel="preload" as="image" href="hero.webp" fetchpriority="high">` - •Product page: Main product image → preload dynamically in the template
- •Category page: Category header image or first product thumbnail
Thumbnail optimization: Category page grids often load product thumbnails at the full original resolution. Resize thumbnails to their actual display dimensions (typically 300–400px wide for a 3-column grid). This alone can reduce category page weight by 60–80%.
Image compression settings:
- •JPEG/WebP quality: 80% (imperceptible difference, 40–60% size reduction vs. 100%)
- •Enable progressive JPEG rendering for perceived performance improvement
- •Strip EXIF metadata from product images (camera data, GPS coordinates — unnecessary weight)
Step 4: Optimize Akamai CDN Configuration
BigCommerce uses Akamai's global CDN for content delivery, which provides excellent infrastructure — but default configuration isn't always optimal for every store.
Cache rule optimization:
- •Verify static assets (CSS, JS, images, fonts) have long cache TTLs (ideally 1 year for versioned assets)
- •Check that HTML pages have appropriate cache headers for your content update frequency
- •Use BigCommerce's built-in CDN URL structure for all assets to ensure they're served from Akamai edge locations
Compression:
- •Verify Brotli compression is active for HTML, CSS, and JavaScript responses (30% smaller than gzip)
- •Check compression in DevTools: Network tab → Response Headers → look for `Content-Encoding: br`
- •If Brotli isn't active, gzip should be the fallback
DNS and connection optimization:
- •Add `
<link rel="preconnect" href="your-cdn-domain">` for third-party domains your store depends on - •Use `
<link rel="dns-prefetch">` for lower-priority external domains - •Minimize DNS lookups by consolidating third-party services where possible
HTTP/2 and HTTP/3: BigCommerce supports HTTP/2 by default, which enables multiplexing (multiple requests over a single connection). Verify HTTP/2 is active in DevTools Network tab — look for the 'Protocol' column showing 'h2'.
Edge caching for dynamic content: For stores with minimal personalization, consider implementing stale-while-revalidate cache strategies — serving cached content while revalidating in the background, providing instant loads while keeping content fresh.
Struggling with BigCommerce speed?
Our team optimizes BigCommerce sites for real-world results. Request an audit.
Step 5: Accelerate Checkout for Maximum Conversion
The checkout page is the most revenue-critical page on your BigCommerce store — and often the slowest. Payment gateway scripts, address validation APIs, shipping calculators, and fraud detection tools all execute simultaneously.
Preload payment SDKs on the cart page:
When a visitor adds an item to cart, they're likely heading to checkout. Begin loading payment gateway scripts (Stripe.js, PayPal SDK, Braintree) on the cart page using `<link rel="preload">` or `<link rel="modulepreload">`. This way the scripts are already cached when the visitor reaches checkout.
Remove marketing scripts from checkout: Marketing scripts that belong on product and category pages do NOT belong on checkout:
- •Remove chat widgets from checkout flow
- •Remove social proof popups ("X people viewing this")
- •Remove exit-intent popups (ironic on checkout)
- •Remove heatmap/session recording scripts
- •Keep ONLY: analytics (GA4), payment, shipping, and tax scripts
Minimize checkout DOM complexity:
- •Reduce the number of DOM elements on the checkout page
- •Avoid complex animations or transitions during form interactions
- •Ensure input fields respond within 100ms (target for good INP)
Optimize shipping rate lookups: If using real-time carrier rate lookups, implement:
- •Caching of rate responses for the same origin/destination/weight combinations
- •Debouncing address input to prevent API calls on every keystroke
- •Fallback flat rates while real-time rates load
Address validation optimization:
- •Defer address validation until the user finishes typing (not on every keystroke)
- •Use browser autofill APIs to reduce input time
- •Pre-populate country/state from IP geolocation for faster initial render
Impact measurement: Track checkout page load time and checkout completion rate (conversion rate) together. A 1-second improvement in checkout load time typically improves completion rates by 10–15%.
Step 6: Pass Core Web Vitals on BigCommerce
Google uses three Core Web Vitals as ranking signals for search. For BigCommerce stores, passing these thresholds directly impacts organic search visibility and Google Shopping tab rankings.
Fixing LCP (target: ≤ 2.5s): The LCP element on most BigCommerce pages is the hero banner (homepage), main product image (product pages), or category header image. To fix:
- 1Preload the LCP image: `
<link rel="preload" as="image" href="..." fetchpriority="high">` in the template head - 2Inline critical CSS: Extract above-fold styles and inline them to prevent render-blocking
- 3Optimize image format/size: Serve WebP at the exact display dimensions using `getImageSrcset`
- 4Reduce TTFB: Optimize front-matter data fetching, reduce app server-side processing
- 5Defer app JavaScript: Move non-critical app scripts below the fold or defer them entirely
Fixing INP (target: ≤ 200ms): INP measures how quickly your store responds to user interactions (clicks, taps, keyboard input). Common BigCommerce INP failures:
- •App JavaScript Long Tasks: Review/loyalty/chat apps running long scripts on the main thread
- •Product variant selectors: Heavy JS execution when switching sizes, colors, or options
- •Mega menu interactions: Complex navigation with many sub-categories and hover states
- •Filter/sort on category pages: Re-rendering product grids with JavaScript after filter changes
- •Add to cart handlers: Complex price calculations and DOM updates on add-to-cart
Fix by deferring non-essential app scripts, optimizing event handlers, breaking Long Tasks with `scheduler.yield()` or `setTimeout`, and using `requestIdleCallback` for non-urgent work.
Fixing CLS (target: ≤ 0.1): CLS layout shifts on BigCommerce stores typically come from:
- •Product images without explicit `width` and `height` attributes
- •Late-loading web fonts causing text reflow
- •Dynamically injected app content (review widgets, upsell popups, recommendation carousels)
- •Banner/hero images that load after the initial page render
- •Price updates after JavaScript calculates tax/currency
Fix by adding dimensions to all `<img>` tags, using `font-display: swap` with size-adjusted fallback fonts, reserving space (CSS `min-height`) for dynamically injected content, and preloading hero images.
Monitoring with CrUX: Google uses the Chrome UX Report (CrUX) for ranking — a 28-day rolling window of real user data at the 75th percentile. Lab scores (Lighthouse) are useful for debugging but don't directly affect rankings.
Monitor your CrUX data via PageSpeed Insights (field data section), Google Search Console (Core Web Vitals report), or the CrUX API. After making optimizations, allow 28 days for your CrUX data to fully reflect the improvements.
BigCommerce vs. Shopify: Speed Comparison
A common question: should you switch platforms for speed? The short answer: no — both platforms can achieve excellent performance with proper optimization.
Architecture comparison:
- •BigCommerce uses the Stencil framework with Handlebars.js templates and YAML front-matter for data declarations
- •Shopify uses the Liquid template language with a different data-fetching model
- •Both render server-side, meaning TTFB depends on server processing efficiency and data complexity
BigCommerce advantages:
- •More built-in features reduce app dependency (faceted search, native reviews, multi-currency, B2B features)
- •Fewer apps typically means less JavaScript overhead
- •No equivalent of Shopify's cart fragment overhead
- •Built-in B2B functionality without third-party apps
Shopify advantages:
- •Larger app ecosystem with more specialized options
- •Dawn theme is well-optimized out of the box
- •Hydrogen/Oxygen headless offering is mature
- •Shopify Functions for server-side customization without JavaScript overhead
Speed comparison based on our client data:
- •LCP: Both platforms can achieve sub-2s LCP with image optimization and critical CSS
- •INP: Both platforms can achieve sub-100ms INP with JavaScript optimization
- •CLS: Both platforms can achieve sub-0.05 CLS with proper image dimensions and font loading
Bottom line: The platform doesn't determine your CWV outcome — the implementation does. A well-optimized BigCommerce store will outperform a poorly-optimized Shopify store, and vice versa. Focus on the optimization fundamentals in this guide rather than considering a platform migration for speed reasons.
Headless BigCommerce: When and Why
BigCommerce has invested heavily in headless commerce capabilities, allowing stores to use a modern JavaScript frontend (Next.js, Nuxt, Gatsby) while using BigCommerce as the backend for product catalog, orders, and payments.
When headless makes sense for speed:
- •Your store needs heavily personalized, interactive experiences that Stencil's server-rendered Handlebars can't efficiently deliver
- •You have a development team capable of maintaining a custom frontend
- •You're serving global audiences and need edge-rendered pages (sub-100ms TTFB globally)
- •You want to use modern frontend performance techniques (React Server Components, Streaming SSR, Islands Architecture)
When headless is NOT worth it for speed:
- •Your Stencil theme can be optimized to pass CWV (most can)
- •You don't have frontend developers to maintain a custom build
- •Your catalog is small-to-medium (<10K products) — Stencil handles this efficiently
- •The migration cost doesn't justify the performance improvement
Headless performance considerations:
- •API latency: Every page request hits BigCommerce's API. Use edge caching (Vercel Edge, Cloudflare Workers) to cache API responses.
- •JavaScript bundle size: React/Next.js apps can be heavier than Stencil's server-rendered HTML if not carefully optimized.
- •Catalog API pagination: Large catalogs (10K+ products) require efficient API pagination and caching strategies.
- •Checkout: BigCommerce's embedded checkout or redirected checkout adds complexity in headless builds.
Recommended headless stack:
- •Frontend: Next.js 15+ with App Router and React Server Components
- •Hosting: Vercel (edge rendering, ISR for product pages)
- •API caching: SWR/React Query with stale-while-revalidate
- •Search: Algolia or Searchspring for sub-100ms search results
Ongoing Speed Monitoring and Maintenance
BigCommerce stores accumulate speed debt continuously as apps are added, products are uploaded with unoptimized images, and marketing scripts are injected.
Weekly (5 minutes):
- •Check Google Search Console Core Web Vitals report for new failures
- •Glance at PageSpeed Insights for your top 3 revenue pages (homepage, top product, top category)
Monthly (30 minutes):
- •Review installed apps — remove any not actively providing measurable value
- •Check for new scripts added via Script Manager or third-party injections
- •Verify CDN caching is working (check response headers)
- •Spot-check 5 product images for proper WebP serving and responsive sizing
- •Review conversion rate trends correlated with any speed changes
Quarterly (2–3 hours):
- •Full app performance audit (disable each, measure individually)
- •Theme front-matter audit across all templates
- •Complete image audit on high-traffic product and category pages
- •Third-party script inventory and cleanup
- •Competitive speed benchmarking against top 3 competitors
- •Review BigCommerce platform updates for new performance features
Performance budgets — set maximums and check monthly:
- •Total page weight: < 2MB (product pages), < 1.5MB (category pages)
- •Total JavaScript: < 300KB (compressed)
- •Installed apps: < 8 actively running scripts
- •TTFB: < 300ms
- •LCP: < 2.5s (field data)
- •INP: < 200ms
- •CLS: < 0.1
After every change: Whenever you install a new app, update your theme, or add a marketing script, re-test the affected pages immediately. Speed debt is easier to prevent than to fix retroactively.
Thresholds & Benchmarks
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| TTFB (Time to First Byte) | < 300ms | 300–800ms | > 800ms |
| Mobile Lighthouse Score | 75+ | 45–74 | Below 45 |
| LCP (Largest Contentful Paint) | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| INP (Interaction to Next Paint) | ≤ 200ms | 200–500ms | > 500ms |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | 0.1–0.25 | > 0.25 |
| Total Page Weight (product page) | < 2MB | 2–5MB | > 5MB |
| Total JavaScript | < 300KB | 300–600KB | > 600KB |
| Installed Apps | < 8 | 8–15 | > 15 |
Key Measurement Tools
Shows CrUX field data (what Google uses for ranking) alongside Lighthouse lab data. Test product pages, category pages, and checkout separately — they have very different performance profiles.
Core Web Vitals report groups pages by URL template (product, category, homepage). Monitor weekly for regressions after app installations or theme updates.
Performance tab for main-thread profiling (identify Long Tasks from apps), Network tab for waterfall analysis (find render-blocking scripts), Coverage tab for unused CSS/JS identification.
Multi-step transaction testing: homepage → category → product → cart → checkout. Detailed waterfall, filmstrip comparison, and Web Vitals attribution. The most thorough lab testing tool.
Visualize your origin-level CrUX data over time. Track the 28-day rolling window Google uses for ranking decisions. Available free via Google's official Looker Studio connector.
Built-in conversion funnel analysis. Correlate speed changes with conversion rate, cart abandonment, and revenue metrics to demonstrate ROI of optimization work.
Looking for speed help?
Step-by-Step Optimization Guide
Audit Stencil front-matter
Open every template file in your Stencil theme and review the YAML front-matter data declarations. Remove any data requests not actually rendered in the template body (e.g., blog_posts on product pages, featured_products on category pages). Each removal saves 50–150ms of server processing time.
Profile and reduce app JavaScript
Disable apps one at a time in BigCommerce admin. After each disable, hard-refresh the storefront and record JavaScript size and load time in a spreadsheet. Identify the top 3 heaviest apps. Remove, replace with lighter alternatives, or defer their scripts to after page load.
Optimize Handlebars partials
Audit base.html for partials loaded globally. Move page-specific partials (reviews, related products) to their relevant templates only. Add conditional {{#if}} blocks to prevent rendering empty partials. Remove orphaned partials from previous customizations.
Build image pipeline
Verify WebP is being served via BigCommerce's image CDN (check Content-Type headers). Implement getImageSrcset in Stencil templates for responsive images. Add loading='lazy' to all below-fold images. Preload the LCP image with fetchpriority='high'. Compress originals to 80% quality.
Inline critical CSS and defer JS
Extract above-the-fold critical CSS using a tool like Critical and inline it in the template <head>. Load the full stylesheet asynchronously with media='print' onload handler. Add defer attribute to all non-critical JavaScript. Move app scripts below the fold.
Optimize checkout speed
Preload payment gateway SDKs (Stripe.js, PayPal) on the cart page. Remove ALL marketing scripts from checkout (chat, popups, heatmaps, social proof). Implement address input debouncing. Cache shipping rate lookups for repeated origin/destination combinations.
Pass Core Web Vitals
Verify LCP < 2.5s by preloading hero/product images and inlining critical CSS. Fix INP < 200ms by deferring app JavaScript and breaking Long Tasks. Fix CLS < 0.1 by adding explicit dimensions to all images and reserving space for dynamic content.
Set up monitoring and budgets
Check Google Search Console CWV report weekly. Run PageSpeed Insights on top 5 revenue pages monthly. Set performance budgets: < 2MB page weight, < 300KB JS, < 300ms TTFB, < 8 apps. Re-test after every app installation or theme update.
Want us to handle these optimizations?
Request an audit for your BigCommerce site and see results in days, not months.
Real-World Case Studies
BigCommerce in 2026: Updates & Future Trends
BigCommerce Speed Optimization in 2026 and Beyond
BigCommerce is investing in several performance-impacting areas:
Stencil framework improvements: BigCommerce continues to optimize the Stencil rendering pipeline, reducing server-side processing time for template rendering. Recent updates include improved front-matter caching and more efficient Handlebars compilation.
Headless commerce maturity: BigCommerce's headless APIs (Catalog, Cart, Checkout) are becoming more performant with better caching, pagination, and response optimization. The Catalyst reference storefront (built on Next.js) provides a production-ready headless starting point.
GraphQL Storefront API: BigCommerce's GraphQL API allows querying only the data you need (vs. REST's fixed response shapes), reducing payload sizes and improving client-side performance.
Edge computing and personalization: Edge-rendered storefronts (via Vercel, Cloudflare Workers, or Netlify Edge) are becoming standard for high-performance headless builds, delivering sub-100ms TTFB globally.
AI-powered optimization: Emerging tools use machine learning to predict which images to preload, which scripts to defer, and which content to prefetch based on user behavior patterns.
Speculation Rules API: Browser-native prefetching and prerendering of linked pages, making navigation feel instant. BigCommerce headless builds can implement this today; Stencil support is expected in future updates.
AVIF image format: Broader browser support for AVIF means 50–70% smaller images vs. JPEG — nearly double the savings of WebP. BigCommerce's image CDN is expected to add AVIF support as browser adoption reaches critical mass.
Need help with BigCommerce speed?
Our team specializes in BigCommerce performance optimization. Request an audit and see exactly how much faster your site could be.
