Building a Performance Strategy Around Data

Performance work often raises a familiar set of questions: How do you make a business case for investment? How do you prove improvements once they're shipped? And how do you understand the real impact of changes across different user scenarios? The common thread in answering all of these is data.

Start in the Lab

The first step is establishing a baseline in your development environment. At Spotify, web teams use lighthouse-ci integrated through Backstage. This setup provides a feedback loop directly in the pull request workflow, posting comparative reports against the latest master results. The reports cover key metrics like Web Vitals and performance budgets, surfaced as comments on each PR.

The Lighthouse CI server adds a historical dimension, letting teams visualize audit data across runs and understand how metrics diverge between commits. This makes it possible to spot trends and regressions over time.

Configuration through lighthouserc.json allows the profiling to be tuned to represent your actual user base. By adjusting parameters based on analytics data, lab results better reflect real-world conditions rather than an idealized environment.

Lab data functions as a smoke test — it catches issues before they reach production. But it has limitations. It cannot fully represent the variety of devices, network conditions, and usage patterns your real users experience. That is where field data becomes essential.

Choosing the Right Metrics

Not all metrics carry equal weight. The Web Vitals project provides a framework for identifying which user-centric metrics matter most. Understanding what each one measures helps clarify its impact on user experience.

Core Web Vitals

  • LCP (Largest Contentful Paint) — Marks when the main content of a page has likely loaded, measuring perceived load speed.
  • FID (First Input Delay) — Quantifies the delay users experience when trying to interact with a page that has not yet become responsive.
  • CLS (Cumulative Layout Shift) — Measures visual stability by tracking unexpected layout shifts that can disrupt the user.

Other Supported Metrics

  • FCP (First Contentful Paint) — Marks the first point where the user sees anything on screen, indicating that the page is loading.
  • TTFB (Time to First Byte) — Measures connection setup and server responsiveness; for navigation requests it precedes all other loading metrics.

Experimental Metrics

  • INP (Interaction to Next Paint) — Assesses responsiveness by observing latency across all user interactions and reporting a single value that nearly all interactions fell below.

Monitoring in the Wild

Capturing real-user metrics requires an analytics pipeline. Google Analytics export to BigQuery can be combined with dashboard tools to build real-time performance monitoring. Spotify has integrated these components and uses a live dashboard to track performance against actual user sessions.

Consider a case study from January 2022: the mobile web player on the Show page had room for improvement in LCP. The team theorized that Server Side Rendering (SSR) would bring meaningful gains. Without historical field data, it would have been difficult to assess how severe the problem was or whether the SSR work had the intended effect. With the monitoring dashboard in place, the impact was measurable — the data showed the before-and-after state clearly.

This approach unlocks a number of capabilities. Real-user data points to the specific journeys and areas where users struggle most. It allows you to prioritize work based on evidence rather than intuition. After deploying changes, the same data validates whether those changes delivered the expected results.

Investigating and Acting on Findings

Once field data identifies problem areas, deeper profiling can begin. Chrome's built-in Lighthouse integration and the DevTools performance tab are both effective tools for drilling into the specifics of a slowdown. The profiling output reveals which components or processes need attention, guiding targeted fixes rather than speculative rewrites.

Each performance issue presents its own context, and there is rarely a universal solution. But data-driven investigation narrows the search space considerably. Instead of guessing at potential bottlenecks and applying broad fixes, you can focus on the precise areas where measurements show users are being affected.

Making Performance a Continuous Practice

A performance story begins and ends with data. Understanding the current state of your application, measuring it consistently, and monitoring it over time creates the foundation for shipping work that genuinely matters to users. The visibility into how code changes translate into user-visible results also deepens your understanding of the product itself.

With the right tooling, you can identify key user journeys, instrument them properly, and prioritize improvements with confidence. General-purpose optimizations often miss the mark because every application and every user path has its own characteristics. A solid data pipeline makes performance work a repeatable, measurable practice instead of a series of educated guesses.