User Timings

Why It Matters

• Generic metrics do not tell the whole story. Largest Contentful Paint might be fast, but if the feature your users came for takes five more seconds to become functional, the generic metric misses the real problem. User Timings capture what standard metrics cannot.
• They make performance actionable. Knowing that "the product carousel loaded in 1.2 seconds" is far more useful than knowing "some content painted at 0.8 seconds." Custom timings tied to specific features give developers clear targets to optimize.
• They work in real-world monitoring. User Timings show up in browser developer tools and can be sent to analytics and monitoring services. This lets you track custom performance metrics from real users over time, not just in lab tests.
• They bridge business and engineering goals. Business teams care about how fast the checkout flow works or when a search returns results. User Timings let you measure exactly those moments and report on them in terms everyone understands.

How to Use Them

1. Identify moments that matter. Determine which user-facing milestones are most important for your application. When does the search bar become functional? How long does a form submission take? When do the main product images appear? These are your candidates for custom timings.
2. Set performance marks. Use performance.mark() to create named timestamps at significant moments in your code. Place marks at the start and end of operations you want to measure.
3. Create measurements between marks. Use performance.measure() to calculate the duration between two marks. This gives you a named measurement with a precise duration that shows up in developer tools.
4. Send timings to your monitoring service. Use the Performance Observer API to collect your custom timings and send them to your analytics or monitoring system. This lets you track trends over time and catch regressions from real user data.
5. Review and act on the data. Custom timings are only valuable if you use them to drive decisions. Set performance budgets around your custom measurements and investigate when timings regress beyond acceptable thresholds.

Common Mistakes

• Creating too many timings. Measuring everything dilutes the signal. Focus on the five to ten moments that genuinely matter to your users and business. Too many custom timings create noise that makes it harder to find actionable insights.
• Using vague mark names. Names like "start" and "end" become meaningless when you have multiple measurements. Use descriptive names like "search-results-rendered" or "hero-image-visible" that clearly identify what is being measured.
• Collecting data without acting on it. Custom timings that get sent to analytics but never reviewed are wasted effort. Assign ownership, set thresholds, and create alerts so regressions are caught and investigated.
• Only measuring in development. Lab testing catches some issues, but real user timings reveal how your application performs across the full range of devices, networks, and usage patterns. Collect custom timings from production traffic.