A collaborative research study with Google found that a 0.1-second improvement in load time can lead to an 8.4% increase in conversions for e-commerce sites. A tenth of a second. That’s the difference between winning and losing 8% of your customers.
Speed and performance compound. Every decision throughout the build process either adds to it or chips away at it, and most brands don’t notice until it shows up in their conversion data and bottom line.
I lead engineering at Pattern, where we build custom enterprise Shopify sites for brands like Marine Layer and Magnetic Me. We treat site speed and performance as first-class concern from the first commit to long after launch. Here’s how that works in practice.
The Compound Effect
Speed isn’t a single fix. There’s no plugin you install, no setting you toggle, no one-time optimization that makes a site fast and keeps it that way.
The brands that win on performance treat it as an ongoing discipline, baked into how vendors get evaluated, how content gets uploaded, how every feature decision gets made. The brands that lose are the ones who “fixed performance” once and watched it degrade over the next eighteen months.
The difference between a 2-second site and a 4-second site isn’t one bad decision. It’s fifty small ones: an app that loads JavaScript on every page even though it’s only used at checkout, hero images uploaded at 4000 pixels wide, a chat widget that initializes before the page is even interactive.
Each one costs you a fraction of a second. Stack enough of them up and you’re leaving real money on the table.
Strategic Decisions
App Auditing and Vendor Exploration
Shopify’s app ecosystem is a double-edged sword. Apps solve real problems, but every app is another JavaScript bundle, another potential render-blocking resource, another vendor who may or may not prioritize performance.
We audit apps for clients regularly not just for functionality, but for performance cost. Sometimes this means replacing a bloated app with a leaner alternative. Sometimes it means building lightweight custom functionality instead of reaching for an app. Sometimes the app is worth the performance cost, but we make that tradeoff consciously.
When evaluating new vendors, performance is an incredibly important part of the scorecard alongside features and price.
Lean Architecture for Integrations
Most Shopify apps are engineered to load everything immediately. Their development team isn’t thinking about the bigger picture for your brand, just how they can get their app to load the fastest.
So the default on your site should actually be the opposite. For example, if your reviews widget is the first thing that loads on your PDP, even though it’s only needed well after a scroll down the page, it could be costing you valuable performance loss that’s losing you valuable conversion dollars on the way to checkout.
When we integrate third-party tools, we architect for minimal footprint:
- Lazy-load scripts that aren’t needed for initial render
- Load third-party resources from your own domain where possible to reduce DNS lookups
- Defer non-critical integrations until after the page is interactive
On a recent build, we wrapped all analytics and tracking—Triple Whale, Klaviyo, Google Analytics—in deferred loading with staggered timeouts. None of it blocks the initial render. Your customer sees the page, the tracking catches up in the background.
Helping Clients Build a Practice Around Site Performance
Speed optimization doesn’t end when we hand over the keys, so an ongoing practice of speed optimization — especially around optimizing media and other assets — is a crucial part of the handoff process with clients.
What the Shopify CDN does: Shopify’s CDN is excellent at serving static assets quickly from edge locations worldwide. Images uploaded through the admin, theme assets, and static files all benefit automatically.
What the Shopify CDN doesn’t do: It doesn’t optimize your images for you. It doesn’t prevent you from uploading a 4MB PNG when a 200KB WebP would look identical. It doesn’t know that the lifestyle image you’re using as a background doesn’t need to be 4000 pixels wide.
We educate clients on:
- Image sizing and formats: What dimensions actually make sense for each context, and why WebP and AVIF exist
- Asset weight awareness: How to evaluate whether a new hero video or animation is worth its performance cost
- App installation hygiene: Why “just trying” an app and then disabling it often leaves leftover code and costly JavaScript behind, remnants that can affect your bottom line
- Content entry patterns: How the way you structure content in the CMS affects render performance
A well-built site can still be slowed down by a 15MB homepage video uploaded six months after launch. Most clients are also surprised to learn that .GIFs can have enormous site speed impacts on average and are not ADA compliant.
That’s why we give clients the knowledge needed to make informed tradeoffs instead of chasing optimization problems after they happen. The work doesn’t end when initial development ends, it’s just beginning.
Architecture Decisions
Progressive Loading and Code Splitting
Not every piece of JavaScript needs to load on page load, in fact most of it shouldn’t.
We use an islands architecture where interactive components are loaded when they come into view. On a recent enterprise build, this meant 80+ independent JavaScript islands, each loading only when needed.
A mega menu doesn’t load its JavaScript until a user interacts with the header. A product recommendations carousel initializes only when it enters the viewport. The checkout upsell modal doesn’t exist until someone clicks “Add to Cart.” Heavy components like tabbed carousels and fabric explorers auto-lazy load, while critical components like the hero and product customizer load immediately.
For third-party libraries, we follow the same principle:
- Reviews widgets load when the reviews section scrolls into view
- Loyalty/rewards widgets load when user scrolls to footer or clicks account icon
- Analytics and tracking defer until after the page is interactive
… and so on. The goal is a fast initial render with functionality that arrives just before the user needs it.
Interaction Feedback
Perceived performance matters as much as actual performance. A button that responds instantly feels fast even if the underlying operation takes time.
We build interaction feedback into every high-intent element:
- Immediate visual state changes on click—color shifts, loading spinners, subtle animations—before any network request completes
- Optimistic UI updates that assume success and roll back on failure
- Skeleton states for content that’s loading, so users see structure instead of blank space
- Disabled states with feedback so users know their click registered and the system is working
When someone taps “Add to Cart,” something should happen in under 100ms so the experience feels like it’s actually working, avoiding rage clicks and strengthening conversions.
Writing JavaScript for Slow Connections
Here’s something most speed optimization guides miss: your customer in rural Montana on a 3G connection experiences your site very differently than your brand team on office WiFi.
We write JavaScript that accounts for this reality, particularly for high-intent interactions like variant selection and add-to-cart flows. This means:
- Optimistic UI updates that don’t wait for server responses
- Skeleton states that communicate progress without blocking interaction
- Graceful degradation when network requests take longer than expected
- Debounced inputs that don’t fire requests on every keystroke
The Add to Cart button is the most important button on your site. It needs to feel instant even when it’s not.
Using the Platform
Modern browsers have built-in performance features that didn’t exist five years ago, and they’re free. So the work to make your site faster isn’t discovering some clever trick, it’s being disciplined enough to use these tools consistently across every template and component. We use them aggressively:
- Native lazy loading (
loading="lazy") for images and iframes below the fold—no JavaScript required - Responsive images with srcset so mobile users don’t download desktop-sized files
- Modern formats like WebP and AVIF with fallbacks via the
<picture>element - Proper
widthandheightattributes to prevent layout shift (CLS) fetchpriority="high"on hero images so the browser knows what to load first- Preconnect hints for critical third-party origins like your CDN and font provider
- Critical CSS inlined in the
<head>so layout-critical styles don’t wait for external stylesheets
We also implement template-specific image preloading so that the browser starts fetching what matters before it even knows it needs it.
When your current agency says “we’ve optimized images,” ask if they’re doing all of this. A 2MB hero image served to a phone because someone skipped srcset is money walking out the door.
Animation Architecture
Beautiful animations sell products. Slow animations lose customers. The difference is in how they’re built.
We approach animation with a specific architecture: GPU-accelerated properties only (transforms and opacity), timeline management that doesn’t block the main thread, and lazy initialization for below-the-fold animations. For scroll-triggered animations, we use native Intersection Observer instead of heavier libraries, and one-time animations automatically stop observing after they trigger. When we do need to leverage libraries like GSAP for more intricate animations, we carefully weave in speed optimization to each iteration.
This requires planning animation as part of the technical architecture and integrating dev teams with design teams during the design phase, not treating it as a polish layer added at the end. When animation is an afterthought, it’s usually the first thing to cause performance problems—and the last thing anyone thinks to audit.
The Development Process
The strategic decisions above only matter if they’re enforced consistently. Here’s how we build performance accountability into the development workflow so issues get caught early (when they’re cheap to fix) instead of after launch when they’re expensive.
Automated Checks at the Commit Level
We have special checks on my framework that catch performance issues before code ever reaches a pull request including checks for unoptimized code, missing image dimensions, render-blocking patterns, and more.
This isn’t about catching every issue—it’s about building muscle memory. When developers get immediate feedback that a particular approach has performance implications, they start writing faster code by default. The result: fewer performance bugs make it into the codebase in the first place.
Pull Request Reviews with Unlighthouse
Every pull request gets a performance review alongside the code review. We run tests against each code change to catch regressions before they merge.
This matters because performance problems are cheap to fix in a PR and expensive to fix in production. A developer looking at their own diff can immediately see what caused a score drop.
Three weeks later, buried under new features, that same issue becomes an archaeology project, and you’re paying for the excavation.
Regular Site-Wide Audits
During active development, we run regular, comprehensive site audits for performance, ADA and more. Post-launch, we shift to monthly cadence or trigger audits after significant content changes.
These audits catch the issues that slip through page-level checks: cumulative bloat from multiple features, interactions between components that seemed fine in isolation, and the slow creep of third-party scripts added “just for this one campaign.”
Performance degrades gradually. Without regular audits, you don’t notice until a customer complains—or worse, until you see it in your conversion data and have to work backwards to figure out what changed.
That’s where the craft in enterprise software engineering at scale comes into play for e-commerce sites and is part of what we love to do everyday for our clients.
I lead engineering at Pattern, where we build Shopify Plus stores with performance as a feature, not an afterthought. If you’re planning a rebuild or migration and want speed treated as a first-class concern, reach out and say hello.
