Planning Performance Work in a New Year

Each year brings another round of browser updates, new device launches, and revised tooling — which means the performance checklist you leaned on last year is already due for a refresh. This guide covers the essentials for creating fast experiences in 2021, from the metrics that matter to the features you should be auditing in your front-end stack.

Choosing the Right Metrics

Performance work only succeeds when it is tied to metrics that reflect real user experience. In 2021, the focus has shifted away from aggregate load times and toward field data that captures what users actually encounter. Core Web Vitals are now central to this conversation, but they are not the only signals worth tracking in production. You should pair laboratory testing in a controlled environment with real-user monitoring (RUM) to see how your site behaves on varied connections and devices.

When you plan a performance budget, define it around a set of user-centric metrics rather than a single number. Keep an eye on the largest contentful paint for loading, first input delay for interactivity, and cumulative layout shift for visual stability. These three tell you more about perceived experience than a single “load” event ever will.

Auditing Your Current State

Before you set new targets, you need a baseline. Run a fresh audit of your most important pages to see where you stand today. If you do not have field data yet, start there. Real-user monitoring tools collect key metrics including DOM complete, time to first byte, first input delay, and client CPU and memory usage. With that data, you can prioritize fixes that actually move the needle for your audience.

Your initial audit should also cover the basics: JavaScript bundle size, image payloads, font loading behavior, and the health of your caching strategy. Broken or inefficient third-party scripts are a frequent culprit behind regressions, so a quick review of what you load from external domains is often a high-yield first step.

Setting Up a Monitoring Workflow

Performance is not a one-time fix; it is a habit. A stable routine helps you catch regressions before they reach the majority of your audience. Align your monitoring setup with the product lifecycle — from development to staging to production.

At each stage you want a clearly defined responsibility for performance. Test early, often and in the same conditions your users experience. If your team works in sprints, use CI checks to prevent performance budgets from breaking unnoticed. In production, keep a RUM tool active to track metric trends over time and to alert you when a change in traffic patterns or a new release moves a key metric in the wrong direction.

Focusing on Resilient Front-End Architecture

Beyond the numbers, start the year by reviewing the architectural assumptions baked into your front-end. Reliance on a single huge framework bundle is one of the most common causes of jank and slow startup. If you have a scalable workflow, a smaller code footprint and responsible loading patterns built in from the start, you spend less time patching up problems later.

Use the insights from your monitoring to guide gradual improvements. For teams with heavy JavaScript, a shift toward server-side rendering or static generation can yield quick wins when done incrementally. For sites bloated by media, delivery pipeline changes — like compressing versions of images and using modern formats — are often the single most effective optimization you can make without touching application logic.

Keeping the Process Simple

Remember that a performance culture is built on consistent practice, not heroic effort. Get monthly reminders to review field data, align code-review criteria with performance budgets and keep the documentation on what and why you monitor up to date, so new team members can onboard into the workflow quickly.

Planning and Measurement

Micro-optimizations help keep performance on track, but lasting results require clearly defined, measurable targets that influence decisions across an organization. Before any optimization work begins, a few foundational priorities need to be established.

Building a performance culture

Front-end developers often know exactly what causes performance problems and how to fix them. The issue is rarely technical knowledge; it is organizational alignment. Without buy-in from business stakeholders, every optimization effort turns into a cross-departmental battle. To secure that support, build a case: show how speed — particularly Core Web Vitals — affects the KPIs the business cares about.

Make performance tangible with data relevant to specific stakeholder groups. Correlate conversion rates with application load and rendering performance, or examine how search bot crawling rates relate to page speed. Study complaints from customer service and sales teams, and analyze analytics for high bounce rates and conversion drops, then explore how performance improvements could relieve those issues. Run experiments and measure outcomes on both mobile and desktop, using tools like Google Analytics, to build a company-tailored case study with real data. Public case studies and experiments shared on WPO Stats can also help educate the business about performance's impact on user experience and business metrics.

Just as UX is a spectrum, web performance is a distribution, and treating any single number as an aspirational target is flawed. Performance goals need to be granular, trackable, and tangible.

Setting a competitive target: 20% faster than the fastest competitor

Psychological research shows users perceive a site as faster than a competitor's only when it is at least 20% faster. Study your main competitors, collect their mobile and desktop performance data, then set thresholds designed to outpace them.

The Chrome UX Report (CrUX) provides a pragmatic starting point: it is a ready-made RUM data set with new releases on the second Tuesday of each month. Data is Chrome-specific, but it covers performance distribution and Core Web Vitals scores across a broad visitor base. For page-level detail, Page Speed Insights (and its API, which is not deprecated) surfaces CrUX data for specific URLs, which is more useful for setting targets for individual pages like the landing page or product listing. Page Speed Insights' synthetic results should match the CrUX environment if CrUX informed your target.

Alternatives and complements to CrUX include the Chrome UX Report Compare Tool, Google's Speed Scorecard (with a revenue impact estimator), Real User Experience Test Comparison, and SiteSpeed CI for synthetic testing. For a deeper analysis of where slowdowns and inefficiencies lie, Harry Roberts' Site-Speed Topography Spreadsheet breaks down performance by key page types, and running a Lighthouse audit on every page of a competitor's site (via Lighthouse Parade, with CSV output) identifies which pages warrant attention.

To influence priorities with this data, use tools that illustrate the stakes. The UX Speed Calculator, an open-source project, simulates data to show how conversion rates decay or bounce rates rise with slower performance, helping sell a RUM solution or performance budget internally.

With competitor data collected, set performance budgets: shave 20% off their metrics and commit to those thresholds as goals. Useful resources for budgeting include Addy Osmani's guide on starting performance budgeting, Lara Hogan's budget approach for designers, Harry Roberts' Google Sheet for visualizing third-party script impact via Request Map, and tools like Performance Budget Calculator, perf-budget-calculator, and Browser Calories. Budgets need not be aspirational; a pragmatic budget can simply stop regression by setting a threshold at your worst data point from the past two weeks. Harry Roberts' "Performance Budgets, Pragmatically" outlines this strategy.

Budgets must be visible and enforced. Integrate them into a CI workflow with Webpack Performance Hints, Bundlesize, Lighthouse CI, or Sitespeed CI, so pull requests show a score history. Dashboard tools like SiteSpeed.io and SpeedCurve report on build sizes regularly. Budgets alone do not create awareness, though. Consider custom ESLint rules that flag imports known to be dependency-heavy, or maintain a list of "safe" packages for the team. Pinterest used this approach after its PWA retrospective.

Choosing the right metrics

Not all metrics are equal. The right ones depend on your application: how quickly the most important pixels render and how quickly those rendered pixels respond to input. Load events and server response times matter less than the perceived snappiness of the interface. Traditional metrics fall into groups, and a full picture generally requires drawing from several.

  • Quantity-based metrics count requests, weight, and performance scores. They raise alarms and track change over time, but say little about user experience.
  • Milestone metrics mark states in the loading process, such as Time To First Byte and Time To Interactive. They describe user experience, but not what happens between milestones.
  • Rendering metrics estimate visual progress, like Start Render time and Speed Index. They measure rendering performance but not when important content appears or becomes interactive.
  • Custom metrics measure a specific user-facing event, like Twitter's Time To First Tweet or Pinterest's PinnerWaitTime. They describe experience precisely but are difficult to compare externally.

Commonly relevant metrics include TTI, when layout has stabilized and the main thread can handle input; FID, the delay between a user's first interaction and the browser's response; LCP, when the largest visible content has loaded; TBT, the time between first paint and TTI when the main thread was blocked by long tasks; CLS, which quantifies unexpected layout shifts; and Speed Index. CPU time spent shows how often and how long the main thread is busy, a clear proxy for janky experiences. Component-level CPU costs, proposed by Stoyan Stefanov, isolate the impact of individual JavaScript components via Puppeteer and Chrome.

FrustrationIndex, by Tim Vereecke, looks at the gaps between key perceived milestones — such as title visibility and visual readiness — rather than at each metric in isolation. Larger gaps indicate higher user frustration. Ad Weight Impact constructs two URLs — one with ads blocked — and reports the delta, useful for ad-dependent sites. Deviation metrics, as Wikipedia engineers note, show measurement variance, informing how reliable instruments are and whether a page is difficult to measure due to third-party scripts.

First Meaningful Paint does not appear here: it has been deprecated, as it proved inaccurate in about 20% of cases. LCP replaces it. Neither FID nor TTI accounts for scrolling, which happens off the main thread, so content-heavy sites may weight these less (thanks to Patrick Meenan).

Core Web Vitals: a focus

In May 2020, Google announced Core Web Vitals, user-focused metrics covering loading, responsiveness, and visual stability. Each should pass the "good" range on at least 75% of page views. They became Google Search ranking signals in May 2021, pushing them up many priority lists.

  • LCP < 2.5s: measures rendering of the largest image or text block visible in the viewport. LCP is delayed by slow server responses, blocking CSS, in-flight scripts, webfont loading, expensive rendering, and lazy-loaded images. Rendering the first visible portion quickly requires template-specific critical CSS management and ordering of the <head>. Images are the main culprit; on Fast 3G, the maximum theoretical image budget is about 144 KB, which makes responsive images and early preload of critical images essential.
  • FID < 100ms: measures UI responsiveness, or how long the browser was busy before responding to discrete input like clicks or taps. Staying within 50–100ms per interaction requires breaking long tasks (over 50 ms), code-splitting bundles, reducing JavaScript execution time, and deferring third-party scripts.
  • CLS < 0.1: measures visual stability, summing scores for unexpected layout shifts across page lifetime. Shifts come from webfont fallbacks, late-arriving adverts or embeds, images without reserved dimensions, and late CSS or JavaScript. The recommended score is below 0.1.

Core Web Vitals will evolve on a predictable annual cycle; expectations for the first update include a Core Web Vitals role for FCP, tightened FID thresholds, and better SPA support.

Useful tooling covers visualization of CLS (Layout Shift GIF Generator), comparison of scores (Web Vitals Leaderboard), and CLS in the SERP (Core SERP Vitals extension). The web-vitals library collects and sends metrics to analytics endpoints. For broader diagnostics, "What Forces Reflow" lists JavaScript calls that trigger synchronous layout computation, and CSS Triggers shows which properties trigger layout, paint, and composite.

Core Web Vitals are exposed across most RUM platforms: Cloudflare, Treo, SpeedCurve, Calibre, WebPageTest, New Relic, and Google's tools. They are not ultimate metrics, though. Katie Sylor-Miller points to a lack of cross-browser support, an incomplete lifecycle view, and difficulty correlating FID and CLS with business outcomes. Combining them with tailored metrics remains prudent.

Testing on representative devices

Accurate data collection starts with device choice. Many organizations profile based on analytics, but analytics misses users, especially those who abandon slow sites and never return. Research on typical devices in your target audience complements the analytics view. A globally representative device is an Android phone at least 24 months old, costing under $200, connected over slow 3G — 400ms RTT and 400kbps transfer. Check Amazon Best Sellers for your target market as a starting point (thanks to Tim Kadlec, Henri Helvetica, and Alex Russell for these pointers).

Practical options include a Moto G4/G5, mid-range Samsung (Galaxy A50, S8), Nexus 5X, Xiaomi Mi A3 or Redmi Note 7, or a slower Alcatel device or Cubot X19. Test across chipsets — a Snapdragon, an Apple, plus low-end Rockchip or MediaTek — rather than over-representing one family. Emulate mobile conditions on a desktop by throttling CPU and network: a 5× CPU slowdown with a throttled 3G profile (300ms RTT, 1.6 Mbps down) approximates tightly. Expect a 4×–5× slowdown on mobile hardware relative to desktop.

Profiles for testing and sharing goals

Passive monitoring commonly uses a "clean" profile: no extensions, anti-virus off, background tasks and network traffic suspended. But some users rely on browser extensions that have significant performance costs, such as those covered in the 2020 Chrome Extension Performance Report. If extensions are common among your customers, a clean profile paints an overly optimistic picture; test with a dedicated "customer profile" that includes those extensions.

Lastly, performance responsibilities belong to the team, not just engineering. Communicate goals so design, marketing, and everyone in between understand the performance implications of daily decisions. Map design decisions against the budget early, enabling smoother performance-focused conversations later.

From Metrics To Maintenance

A performance budget only pays off if you keep measuring against it. The real work starts after you ship the first optimization: you need a monitoring setup that catches regressions before your users do.

Lab Data vs. Field Data

Lab tests run in a controlled environment on a fixed device and network profile. They give you repeatable, comparable numbers for debugging, but they never reflect real conditions. Field data comes from actual users on their own devices and connections. You need both: lab data to isolate and fix issues, field data to confirm the impact of what you shipped.

  • Lab data: run these in CI or locally with tools like Lighthouse or WebPageTest to catch regressions on every commit.
  • Field data: collect from real sessions via CrUX (the Chrome User Experience Report), the Performance API in JavaScript, or your analytics platform.

For field metrics, remember that aggregates lie. The median hides the worst quarter of your users. Watch the p75 to p95 range, especially for Core Web Vitals, because that is where slow experiences actually hurt conversion and engagement.

Synthetic Monitoring

Run scheduled tests from multiple geographic locations against your production URLs. A tool like Calibre, SpeedCurve, or Lighthouse CI can catch layout shifts or third-party script changes that only appear under specific network conditions. Alert on trend shifts, not single outliers — flaky networks will otherwise produce noise.

Synthetic tests are also the place to check things that field data cannot answer: the number of requests per page, the total weight of JavaScript, whether images are served in the right format and dimensions, and whether your compression headers survived a CMS update.

Performance Budgets In CI

Treat performance as a build-time constraint, not a post-launch wish. Add budget checks to your pipeline that fail a pull request when:

  • the bundle size exceeds a threshold (track each chunk separately, not just the total);
  • the simulated LCP on a mid-range device goes over your target;
  • the number of render-blocking requests increases.

Keep the thresholds annoyingly tight. A budget that never fails is decoration. Review the failures as you would any other test failure: either fix the regression or consciously raise the limit with a note explaining why.

The Metrics That Matter Now

Core Web Vitals remain the baseline: LCP for loading, INP (replacing FID as the responsiveness metric) for interaction, and CLS for visual stability. But those three do not cover everything. Complement them with:

  • TTFB — if server response is slow, no client-side trick will fix it;
  • FCP — tells you when the user actually sees something painted;
  • TBT (Total Blocking Time) — the lab proxy for how long the main thread is blocked before the page becomes interactive.

Define your targets based on your own traffic. A p75 target on mobile is a sensible default for most sites, but if your audience is on low-end Android devices or congested networks, you might need to aim for p90 to protect the most fragile users.

Keeping The Budget Realistic

Budgets decay. As you add features, the weight creeps up. Review the budgets quarterly and adjust them when you add a major new capability, but never silently. Every change to the budget should be a deliberate decision with a measurable justification — a new critical feature, a change in audience, a new device segment you intend to support.

Finally, budget for maintenance. Documentation, alerting, and a periodic audit schedule are part of the system. Without a named owner for performance, the budgets will drift, the CI checks will get disabled, and the metrics will quietly regress until a marketing campaign surfaces the slowness.

Performance is not a project you finish. It is a property of your site that you maintain, measure, and defend.