Focusing solely on global browser usage statistics to justify feature implementation is misleading. What truly matters is the browser usage on your specific website, which can vary significantly. This principle extends beyond simply avoiding features incompatible with older browsers; it's about prioritizing metrics directly relevant to your site's success.

This concept of site-specific performance tracking has been on my mind lately. It's not just about avoiding CSS Grid due to legacy browser support; it's about measuring the metrics that genuinely impact your users.

Performance testing often relies on synthetic testing, where automated browsers load your site and record metrics like asset size, load times, and request counts. While useful, this data doesn't reflect the actual user experience. We obsess over JavaScript bundle size, Largest Contentful Paint (LCP), and Lighthouse scores, but these are proxies, not direct measures of user perception.

Consider typical website analytics like Google Analytics. While providing data on page popularity, session duration, and traffic sources, this information remains quite general.

For truly insightful analytics, you need a more targeted approach. Ask yourself: What specific aspects of your site's performance are crucial? How frequently is Feature X used? How many files are uploaded weekly? How many messages are sent? How often is the star button clicked? These questions highlight the need for custom JavaScript to capture and report this data. Generic analytics tools won't suffice; proactive development is necessary.

This principle applies to performance tooling as well. Instead of relying solely on generic synthetic tests, adopt Real User Monitoring (RUM). Track real users on their actual devices, gaining invaluable insights. This approach aligns perfectly with the logic of focused analytics and unlocks crucial data.

For instance, First Input Delay (FID), a key Google Web Core Vital impacting SEO, requires JavaScript-based data collection. Similarly, LCP, while a clever attempt at a more meaningful metric, still involves estimation. Google must make assumptions for broad applicability, but you can pinpoint the crucial elements on your site and track their rendering times directly. Using SpeedCurve's hero rendering time, for example:

<main elementtiming="article"></main>

This directly measures what matters to your site, not just generic numbers.

Furthermore, while FID is valuable, consider using User Timing (a W3C standard) to trigger JavaScript events marking important site actions. For example, on a platform like CodePen, this could track editor readiness:

Editors.init();
performance.mark("Editors are initialized.");

This proactive, albeit slightly more involved, approach to analytics surpasses standard methods. While a performance budget limiting JavaScript size to 200KB is helpful, a budget ensuring a core feature loads within 1.1 seconds (instead of a slower 1.4 seconds) is far more impactful.

1 This is because creating a SpeedCurve chart of the three Web Core Vitals requires LUX, their RUM solution, to include FID data. Apologies for the acronym overload!

The above is the detailed content of The Analytics That Matter. For more information, please follow other related articles on the PHP Chinese website!