Where do BigCommerce stores actually lose speed?

Not where most audits look. The platform layer — hosting, CDN, TLS, HTML delivery — is BigCommerce's job and it's done well. The losses come from what gets added on top, in a predictable order of damage: third-party app scripts, oversized above-the-fold imagery, JavaScript-heavy theme features (carousels, mega-menu animations, quick-view modals), and web-font loading. A stock Cornerstone theme scores well; a "finished" store often ships 30–60 points lower. The delta is decisions, not platform.

The app-script tax

Every app you install rents space in your customer's browser. Reviews, chat, heat-mapping, pop-ups, loyalty widgets, analytics duplicates — each one is a script, and most load synchronously on every page whether they're used there or not. This is the single biggest INP and main-thread killer we see on BigCommerce audits.

  • Audit Script Manager quarterly. BigCommerce's Script Manager shows what's injected; the surprise is always what's still there from apps uninstalled a year ago.
  • Load scripts where they're used. A checkout-survey script doesn't belong on category pages. Scope by page type, defer what can't be removed.
  • Prefer platform features and custom code over apps for one-job tasks. A 20-line Stencil customization routinely replaces an app carrying 400KB of JavaScript. This is when custom development is the cheap option — the math is in our apps vs. custom guide.

Images: the LCP fight

Your Largest Contentful Paint element is almost always the hero image or the first product grid. BigCommerce serves images through its CDN with on-the-fly sizing via Stencil's image API — the tooling is there; themes just have to use it.

  • Serve responsive sizes with getImageSrcset so a phone doesn't download the 2400px desktop hero.
  • Don't lazy-load the LCP image. Lazy-load below-the-fold media, but the hero needs to start downloading immediately — loading="eager" plus fetchpriority="high".
  • Kill the homepage carousel, or cap it at one pre-rendered slide. Nobody defends carousels with data. Slide two costs you LCP on every visit and earns a fraction of a percent of clicks.

Fonts and CSS

  • Self-host fonts as woff2 with font-display: swap and preload the one or two files above-the-fold text needs. Third-party font CDNs add connection round-trips to your critical path. (This site does exactly this — view source.)
  • One or two families, variable weights. Six font files is a design decision with a Core Web Vitals invoice.
  • Trim theme CSS on customized themes. Long-lived Stencil themes accrete stylesheets for sections that no longer exist; unused CSS is parse time and blocks render.

What counts as "fast" in 2026

Two scoreboards, and they're different: Lighthouse (lab) and Core Web Vitals field data (what Google actually uses — LCP, CLS, and INP, which replaced FID in 2024). A store can score 95 in the lab and fail INP in the field because lab tests don't click your janky mega-menu. Targets we build to: LCP under 2.0s, CLS under 0.05, INP under 150ms in field data, Lighthouse 95+ as the lab proxy. Past that, spend the effort on conversion, not another two points.

The order of operations

  1. Pull field data (CrUX / Search Console CWV report) — fix what real users feel, not what the lab guesses.
  2. Script inventory: remove, scope, defer. Biggest win, least glamour.
  3. LCP element: right-sized, eager, high-priority.
  4. Carousel and animation audit: remove or simplify.
  5. Fonts: self-host, subset, swap.
  6. Re-measure, then stop. Speed is a threshold, not a religion.

Performance is baked into every theme we ship — it's a line item in design & redesign and development, and the field-data side lives in technical SEO. If your store's CWV report is red and nobody can say why, that's literally what the free audit is for.