GitHub

Performance Culture & Planning

Establishing a Performance Culture

Performance optimization that sticks requires organizational commitment, not just technical effort. Without business buy-in, speed improvements erode within months as new features, third-party scripts, and design changes quietly undo the work. The most effective teams treat performance as a product feature — something measured, budgeted, and defended — rather than a periodic cleanup task. Study the complaints flowing into customer service, correlate them with slow page loads, and build a company-specific case study using your own Real User Monitoring (RUM) data paired with business KPIs like conversion rate, bounce rate, and revenue per session.

Case studies remain the most effective tool for converting skeptics, but choose them carefully. A 2025 Web Performance Calendar article cautions that many public case studies conflate speed improvements with simultaneous redesigns, making it impossible to isolate the impact of performance alone. Where possible, run isolated A/B tests (fast vs. slow on the same design) and present absolute numbers alongside percentages. Compelling data points from well-documented studies include: Rakuten 24’s A/B test showing improved Core Web Vitals led to a 53% increase in revenue per visitor and 33% increase in conversion rate; Relive achieving 50% faster LCP and seeing a 3% conversion increase with 6% less bounce; and T-Mobile’s data-driven initiative producing a 20% reduction in site issues and 60% improvement in visit-to-order rate after systematically improving LCP with field data dashboards.

Resources:

The “Fast by Default” Mindset

Most organizations fall into what one 2025 PerfPlanet author calls the “Performance Decay Cycle” — ship, complain, panic, patch, repeat. The alternative is embedding performance into every stage of development so speed is the default outcome rather than a late rescue mission. This means performance-aware architecture decisions (rendering strategy, data-fetching patterns, component boundaries) made early, before they become ceilings you can’t break through without a rebuild. Practically, this involves making performance part of the design process, integrating performance gates into CI/CD, and distributing ownership across the team rather than designating a single “performance person.” Create a performance checklist for every project and ensure all engineers rotate through performance-related tasks so institutional knowledge spreads.

For companies too small to dedicate a full-time performance team, a middle ground works well: set up RUM to notify on deviations, use Lighthouse CI to catch regressions in pull requests, and bring in a specialist for periodic reviews or major architecture decisions. The key is proactive prevention — catching regressions before they reach production — rather than reactive firefighting.

Resources:

Be 20% Faster Than Your Fastest Competitor

Competitive benchmarking remains the single most persuasive argument for performance investment. Gather CrUX (Chrome User Experience Report) data for your domain and your top 5–10 competitors, then aim to be at least 20% faster on the metrics that matter — LCP, INP, and CLS. Tools like DebugBear, SpeedCurve, and Catchpoint allow you to monitor competitor sites with the same fidelity as your own, including historical trending and side-by-side filmstrip comparisons. The 2025 Catchpoint Retail Benchmark Report evaluated the NRF Top 50 retailers using 3,000+ global vantage points and ranked them by a composite “Digital Experience Score” — a useful model for structuring your own benchmarks.

When testing, use CrUX field data as your primary signal (it reflects real users across 28 days) and supplement with synthetic lab tests for debugging and competitive comparison. Don’t over-index on Lighthouse scores — they are lab-based proxies. A DebugBear review of 100 sites in 2025 found that teams frequently chased Lighthouse Total Blocking Time improvements even when their field INP was already healthy, wasting effort on the wrong metric.

Resources:

Choose Representative Test Devices

The Moto G4 that served as the Chrome team’s baseline device for years is now over nine years old and locked to Android 7.0. For 2025–2026, Harry Roberts at CSS Wizardry recommends the Samsung Galaxy A15 5G (~$199, low-tier) and Samsung Galaxy A54 5G (~$450, mid-tier) as broadly representative Android hardware. Both are mass-market devices sold worldwide with multi-year update support, and their hardware profiles map well to Chrome DevTools’ built-in “Low-tier” and “Mid-tier” CPU throttling presets. Samsung’s A-series leads global shipments, meaning you’re testing on what people actually use.

Alex Russell’s “Performance Inequality Gap, 2026” report provides the network baselines to pair with device testing: the P75 connection delivers roughly 9 Mbps down, 3 Mbps up, with 100ms RTT. This represents a modest improvement over prior years, but the hard reality is that the slowest quartile of connections has barely improved. The gap between the fastest and slowest users continues to widen. Russell notes that computers with spinning-disk HDDs, ≤4 GB RAM, and ≤2 cores still represent millions of active devices. Building to the limits of “feels fine on my MacBook Pro” is, as he puts it, active malpractice.

For emulation when physical devices aren’t available, WebPageTest offers proxy device profiles (Moto G Power and Samsung Galaxy S10e approximate the A15 and A54 respectively). Chrome DevTools’ CPU throttling (4× for mid-tier, 6× for low-tier) combined with network presets (Slow 4G: 150ms RTT, 1.5 Mbps down) provides reasonable approximation for quick checks.

Resources:

Share the Checklist With Your Team

A performance checklist is only as effective as its distribution. Make sure every member of the team — designers, developers, product managers, QA — understands that every decision has performance implications. Map design decisions against the performance budget. Distribute ownership broadly: don’t let performance become one person’s responsibility, or you end up with the “consultant scenario” where the rest of the team never learns the fundamentals. Post performance dashboards prominently (T-Mobile uses Looker Studio dashboards accessible to all staff), celebrate wins publicly when metrics improve, and consider running periodic “performance sprints” where the team focuses exclusively on speed improvements — the quick wins from these sprints often generate the buy-in needed for sustained investment.

Resources: