 I often get questions like, is this piece of code better than that one? And my answer usually is, it really depends on the context, and you should probably just try them both and measure the impact. The user timing specification provides a standardized way of collecting timing data and either visualizing it in DevTools or even allowing you to send it to your analytics to gather real-life performance data. With performance.mark, you can save a named marker with a current timestamp. This allows you to track when a certain point in your code was executed. So for example, I could save a marker when my lazy loader is done loading all my non-critical styles. But arguably more important is performance.measure, which allows you to measure the time span between two of your markers. This allows you to track the duration of certain processes. So in my example, I could not only measure when my lazy loader was done, but instead how long it took to load all my non-critical styles. You can view all your markers and durations using performance.getEntries. They will contain name, type, as well as timestamps and durations. Alternatively, you can use DevTools Performance Timeline to inspect your markers. The easiest way to do that is to use the Entries panel to find what you're looking for. And that's it, a small tool to help you make performance-driven decisions when you're developing your app. See you next time. This was a supercharged micro-tip. But did you know we also do live streams? And you can watch the most recent one over there. But more importantly, you can subscribe to the channel and watch other series like AliCast or totally tooling tips and the best of them all, more supercharged.