Everyone knows performance matters. Faster stores convert better. Google considers speed in rankings. Users expect pages to load in under three seconds. None of this is news.
But most performance advice is either too generic to be useful or too specific to apply to your situation. “Optimize your images” is true but not actionable. “Add this specific caching header” might not apply to BigCommerce at all.
After optimizing dozens of BigCommerce stores, we’ve identified the changes that consistently make the biggest difference—and the ones that sound important but rarely move the needle.
Start With Measurement
Before optimizing anything, you need to know where you actually stand. Not where you think you stand—where you actually stand, measured properly.
Use real user data, not just lab tests. Google’s Core Web Vitals in Search Console shows you what actual visitors experience. Lab tools like PageSpeed Insights show what’s possible under ideal conditions. Both matter, but real user data should drive your priorities.
Measure the pages that matter. Your homepage might be fast, but what about your product pages? Your collection pages with hundreds of items? Your checkout? The pages where conversions happen are the pages where speed matters most.
Establish a baseline. Document current performance before you change anything. Otherwise, you won’t know whether your optimizations actually worked, or by how much.
For BigCommerce stores, we typically focus on three Core Web Vitals metrics: LCP (Largest Contentful Paint) for load speed, CLS (Cumulative Layout Shift) for visual stability, and INP (Interaction to Next Paint) for responsiveness. All three affect both user experience and search rankings.
What Actually Matters
These are the optimizations that consistently produce measurable improvements in BigCommerce stores:
Image Optimization
This is the low-hanging fruit, but most stores still don’t do it well. Images typically account for 50-80% of page weight on product and collection pages.
Size images correctly. BigCommerce will resize images, but it works best when you upload appropriately sized source images. A 4000px product photo displayed at 800px wastes bandwidth and processing power.
Use modern formats. BigCommerce supports WebP delivery through Akamai Image Manager on higher-tier plans. If you have access, enable it. WebP files are typically 25-35% smaller than equivalent JPEGs.
Implement lazy loading. Images below the fold shouldn’t load until users scroll to them. BigCommerce’s Stencil framework supports lazy loading, but it needs to be implemented correctly in your theme.
Optimize hero images and sliders. These are often the largest assets on the page and directly impact LCP. Consider whether you need a slider at all—they’re frequently slow and rarely clicked.
Third-Party Script Management
Every chat widget, analytics tool, and marketing pixel adds load time. This is where we see the biggest performance gains in established stores.
Audit everything that loads. Open your browser’s Network tab and watch what loads on a typical page. You might be surprised. Tracking scripts from campaigns that ended years ago. Chat widgets nobody uses. Analytics tools that duplicate each other.
Remove what you don’t need. If you can’t identify why something is loading, or if nobody would miss it, remove it. Be aggressive here. You can always add things back.
Defer what you can. Not everything needs to load immediately. Chat widgets, social sharing buttons, and review widgets can wait until after the main content is visible. Many apps offer lazy loading options—use them.
Consolidate tracking. Instead of multiple analytics scripts, use Google Tag Manager to manage them through a single container. This gives you one script instead of many, plus better control over when things load.
The collective impact is substantial. We’ve seen stores drop 2-4 seconds off load times just by cleaning up third-party scripts.
Critical Rendering Path
What content appears first matters as much as total load time. Users perceive a page as fast when they see content quickly, even if other elements are still loading in the background.
Prioritize above-the-fold content. The hero image, product title, and price should load before anything else. Defer sidebar widgets, footer content, and related products.
Inline critical CSS. CSS blocks rendering until it’s fully loaded. Inlining the CSS needed for above-the-fold content means users see something faster, while the rest of the stylesheet loads in the background.
Avoid render-blocking JavaScript. Scripts in the document head block rendering until they execute. Move non-essential scripts to the footer, or load them with async or defer attributes.
For Stencil themes, check how your theme handles CSS and JavaScript loading. Some themes are optimized for this; others aren’t.
Checkout Performance
Checkout is where performance directly impacts revenue. A slow checkout costs you sales.
Minimize checkout scripts. Every app that injects code into checkout adds latency. Be extremely selective about what runs on checkout pages.
Avoid redirect chains. Each redirect adds a network round-trip. Review your checkout flow for unnecessary redirects, especially if you’re using external payment gateways.
Test with real payment methods. Payment processing time varies by provider and configuration. Test your actual checkout with actual payment methods to understand the complete user experience.
What Matters Less Than You Think
Some commonly recommended optimizations don’t apply to BigCommerce, or provide minimal benefit:
Caching headers. BigCommerce handles caching at the platform level through Akamai. You can’t configure caching headers directly, and you don’t need to. The platform has this covered.
Server-side optimization. You don’t control BigCommerce’s servers. Recommendations about server configuration, PHP tuning, or database optimization don’t apply.
Code minification. BigCommerce minifies JavaScript and CSS automatically. Spending time on additional minification won’t produce meaningful gains.
CDN configuration. BigCommerce includes Akamai CDN automatically. Switching to a different CDN or configuring CDN settings isn’t possible or necessary.
HTTP/2 and HTTP/3. Already enabled at the platform level. Nothing for you to configure.
Focus your effort where you have control: images, third-party scripts, theme code, and content structure.
Stencil-Specific Optimizations
If you’re running a Stencil theme, these optimizations can help:
Review your theme’s asset loading. Check how your theme bundles and loads CSS and JavaScript. Some themes load everything on every page; others are more selective. Efficient asset loading can significantly impact performance.
Use async/defer for non-critical scripts. Review your theme’s script tags. Move non-essential scripts to load asynchronously where possible.
Optimize handlebars templates. Complex handlebars logic that runs on every page load can add up. Look for opportunities to simplify templates or move logic to JavaScript that loads after initial render.
Limit AJAX requests. Some themes make multiple AJAX calls on page load for things like cart counts or customer-specific content. Each request adds latency. Combine requests where possible, or defer non-essential ones.
Headless Considerations
If you’re running a headless frontend (Next.js, Gatsby, or similar), performance optimization looks different:
Leverage static generation. Product and collection pages that don’t change frequently can be statically generated for near-instant load times.
Implement incremental static regeneration. For pages that need fresher content, ISR provides a balance between static speed and dynamic content.
Optimize API calls. BigCommerce API response times affect your frontend performance. Minimize the number of calls, cache responses appropriately, and consider using GraphQL for more efficient data fetching.
Monitor hosting costs. Faster hosting is available, but it costs more. Understand the performance/cost tradeoff and choose appropriately for your traffic levels.
Measuring Success
After implementing optimizations, validate that they worked:
Compare Core Web Vitals before and after. Give it a few weeks for Google to collect enough real user data to show changes.
Test on real devices. Lab tests are useful, but test on actual phones and tablets on actual networks to confirm real-world improvements.
Watch conversion rates. Performance improvements should correlate with conversion improvements. If they don’t, dig deeper to understand why.
Document what you changed. Future you will want to know what was done and what impact it had.
The Bigger Picture
Performance optimization isn’t a one-time project. It’s an ongoing practice. New features add code. New apps add scripts. New content adds assets. Without active maintenance, sites slowly get slower.
The stores that stay fast do it through discipline: performance budgets that limit new additions, regular audits that catch creep, and a culture that treats speed as a feature, not an afterthought.
Start with the big wins—images and third-party scripts—then work your way through more granular optimizations as needed. And measure everything. Gut feelings about performance are notoriously unreliable.