Skip to main content

Build a sustainable performance practice

Performance is an ongoing practice, not a one-time project. Websites aren't static. As features, apps, and content accumulate, performance naturally degrades. Without a repeatable process and clear ownership, improvements from a one-time audit will regress within months. This guide covers why that happens and how to build a practice that keeps your store fast over time.

Anchor to WhyWhy

Anchor to The regression patternThe regression pattern

Most performance initiatives follow the same arc:

  1. A company runs a performance audit and implements technical fixes.
  2. Metrics improve and the project is considered successful.
  3. The team moves on to other priorities and performance is no longer actively managed.
  4. Within months, performance has regressed to its original state or worse.

This cycle repeats because it treats performance as a bug to fix rather than a practice to maintain. Every change to a storefront, whether it's a new feature, a design update, or a new app, has the potential to introduce regressions across all Core Web Vitals.

Anchor to What causes regressionWhat causes regression

  • New features: Adding functionality means more code, images, or scripts.
  • Design changes: Redesigns introduce larger images, complex animations, or more DOM nodes.
  • New apps: Each Shopify app can add third-party JavaScript that competes for the main thread.
  • Content updates: Marketing teams upload unoptimized images or add heavy tracking scripts.
  • Lack of ownership: Without a clear owner, no one monitors or is accountable for regressions.

The result is "death by a thousand cuts." No single change ruins performance, but the accumulation of many small additions does.

Anchor to HowHow

Anchor to Establish a measurement baselineEstablish a measurement baseline

Before you can improve performance, you need to know where you stand. Use Real User Monitoring (RUM) data to establish a baseline of actual user experience. RUM data reflects what real visitors experience across different devices, networks, and geographies.

With a baseline in place:

  • Identify the biggest performance gaps (TTFB to FCP to LCP) to narrow down root causes.
  • Prioritize issues by their impact on users, not by what's easiest to fix.
  • Segment data by page type, device, and geography to isolate specific problems.

Lab tools like WebPageTest and Lighthouse complement RUM, and you can use them to test changes in a controlled environment, but RUM data should drive your priorities.

Anchor to Build a repeatable improvement cycleBuild a repeatable improvement cycle

A sustainable practice depends on a cycle you repeat continuously, not a checklist you complete once. Each pass through the cycle addresses the next most impactful opportunity.

  1. Measure and identify: Use RUM data to find the biggest opportunities. Analyze performance gaps to narrow down causes. Prioritize by user impact. Segment by page type, device, and geography.

  2. Research and experiment: Research potential solutions. Formulate a hypothesis for each change. Create experimental implementations in a development environment.

  3. Test and validate: Use lab testing tools like WebPageTest to validate each experiment. Run before-and-after comparisons using the median of multiple runs. Confirm that the change produces the expected improvement before deploying.

  4. Implement: Deploy only changes that demonstrated a clear improvement in lab tests. Discard experiments that had no effect or made things worse. Document the changes and the expected outcome.

  5. Monitor and verify: After deployment, wait for sufficient RUM data to accumulate (days to weeks depending on traffic volume). Verify that real users are seeing the intended improvements. Check for unintended side effects on other metrics or business goals. Document the final results and share them with stakeholders.

Then repeat the cycle for the next opportunity or when a new regression is detected.

Anchor to Get organizational alignmentGet organizational alignment

Performance is a cross-functional problem. Development, Design, Marketing, and Product all make decisions that affect page speed. Without alignment between these groups, departments make isolated decisions that harm performance.

For agencies and theme developers, this means advocating for a performance-aware structure with your clients. Here's what that looks like in practice.

Anchor to Identify a championIdentify a champion

Someone needs to own performance as a responsibility, not a side project. This person tracks metrics, raises regressions, and coordinates across teams. They need decision-making authority and dedicated time. For smaller teams, this person might be a senior developer who adds performance monitoring to their regular workflow.

Anchor to Build a cross-functional teamBuild a cross-functional team

Performance decisions involve trade-offs between speed, features, and business goals. A small team with representation from Development, Design, and Marketing can evaluate these trade-offs together. This team doesn't need to meet constantly. Regular check-ins during active improvement work, plus as-needed communication after processes are established, are enough.

Anchor to Get leadership supportGet leadership support

When priorities conflict, and they will, a clear directive from leadership resolves the conflict. Without sponsorship, performance work gets deprioritized every time it competes with a feature launch or campaign deadline. Frame this for clients in terms they care about, such as conversion rates, bounce rates, and search ranking.

Anchor to ExamplesExamples

Anchor to Common regression patternsCommon regression patterns

Anchor to Marketing adds a tracking pixelMarketing adds a tracking pixel

A new analytics or advertising pixel gets added to every page. Each pixel is small on its own, but they accumulate. Six months later, the store loads 15 third-party scripts and LCP has regressed by 2 seconds.

Anchor to A merchant installs a new appA merchant installs a new app

The app injects JavaScript that runs on every page load, even pages where it's not needed. The app's script blocks rendering or competes for the main thread, pushing FCP and LCP later.

Anchor to A holiday campaign adds scripts that never get removedA holiday campaign adds scripts that never get removed

A seasonal promotion adds a countdown timer, a pop-up, and a chat widget. The campaign ends, but nobody removes the scripts. They sit there loading on every page visit for months.

Anchor to A redesign introduces unoptimized imagesA redesign introduces unoptimized images

New hero images are uploaded at full resolution without compression or responsive sizing. LCP jumps because the browser downloads a 3-MB image when a 200-KB version would look identical.

Anchor to The measurement-optimization loop in practiceThe measurement-optimization loop in practice

Here's a concrete walkthrough of one pass through the improvement cycle:

  1. Measure: RUM data shows that LCP on product pages regressed from 2.1s to 3.4s over the past two weeks. The regression correlates with a spike in Total Blocking Time.

  2. Identify: You segment the data and confirm that the regression affects mobile users on product pages specifically. A waterfall analysis in WebPageTest shows a new third-party script loading synchronously in the <head>, blocking rendering.

  3. Research: You trace the script to a recently installed app. You check whether the app offers async loading or whether its functionality is needed only on specific pages.

  4. Test: In a development environment, you defer the script and confirm in WebPageTest that LCP returns to the previous baseline. You run multiple test passes to confirm that the median improvement is consistent.

  5. Implement: You deploy the change, deferring the script or limiting it to pages where the app is used.

  6. Verify: Over the next week, RUM data confirms that LCP on product pages has returned to approximately 2.1s. There are no negative side effects on other metrics or on the app's functionality.

Anchor to TestingTesting

Anchor to Set up ongoing monitoringSet up ongoing monitoring

Use RUM data as your primary signal. Shopify's Web Performance Dashboard and Chrome UX Report (CrUX) provide field data that reflects real user experience. Set up regular reviews of this data, whether weekly or biweekly, to catch regressions before they compound.

Anchor to Detect regressions earlyDetect regressions early

Compare current metrics against your established baseline on a regular cadence. Look for:

  • Gradual upward trends in LCP, FCP, or TTFB.
  • Sudden jumps that correlate with deployments, new app installs, or content changes.
  • Degradation in specific segments, such as mobile users, specific page types, or specific geographies.

The earlier you catch a regression, the easier it is to identify the cause and the less impact it has on users.

Anchor to Validate fixes before and afterValidate fixes before and after

Use lab testing to validate changes before deployment. Run multiple test passes in WebPageTest and compare medians. After deployment, wait for RUM data to confirm the improvement in the field. Lab data tells you if your fix works. Field data tells you if it works for real users.

Anchor to ReferencesReferences

Was this page helpful?