When we think about evaluating the performance of an application, we tend to move to a back-end environment. We describe metrics such as resource utilization, disk I/O operations, memory leak detection, response time, and so on. However, given the complexity of today’s web interactions, it’s not so crazy to think that we also need to understand how to focus performance evaluation efforts on the UI.

But what should we do? The browser is not really performing I/O operations on the client disk. Can we measure memory utilization in some way? What else can we analyze?

Indeed, if you were very specific, you would come up with a list of custom metrics, one specific to your context. Here, I’ve listed the top five metrics to consider when measuring UI performance in general.

Interaction time (TTI)

This metric gives you an idea of how long it takes a user to interact with the application. One thing is to present it, and the other thing is to make it interactive. This indicator depends on the following:

  • Stable layout. All visible content is loaded.
  • The CPI main thread is free. If you are still loading scripts or working on something, your application will not be interactive. User clicks and other actions are ignored (or queued) until the thread is released.

Because it directly affects the user experience (UX) of an application, it has become a very relevant metric. It’s not just about cold numbers, it’s about the way the user experiences the UI. Although this may sound subjective, by using metrics such as TTI, we can start to get closer to it.

Measure the TTI

The fastest and easiest way to calculate your site’s TTI is to use Lighthouse on Google DevTools. As part of the reports generated by Lighthouse, you have the TTI number:

Optimize your TTI

One key way to improve TTI is to reduce the load time of scripts. Script processing and load times will be the main reasons for high TTI, so consider the following:

  • Remove unused scripts, all the scripts that the browser needs to interpret and doesn’t use, and that just steals a few seconds from load time.
  • Divide your script into smaller files. This also helps browsers optimize how these scripts are loaded and interpreted.
  • Dynamically loaded scripts, especially those from external sources, can’t really be split or changed at all.

Note, however, that the main thread is only considered “reliable interaction” if there are no tasks lasting more than 50 milliseconds (at least) for 5 seconds. This sets a lower limit for TTI’s “good enough” value, which should be good enough if it is 5 seconds or less, while less is considered very good.

First input delay (FID)

Related to TTI, this metric measures the time it takes for your application to respond from the moment the user performs the first input operation. As scary as it sounds like TTI, the difference between these two metrics is huge:

  • TTI measures how long it takes for your application to be ready to start responding to interactions. You don’t need users to measure this; it’s all about making sure the main thread is free and everything is loaded. But in the end, it measures the potential time your application spends interacting.
  • FID, on the other hand, requires the user to measure it because IT tracks the time it takes to actually respond after performing an interaction.

Ideally, you want a low FID because it shows that your application is responsive from the start.

How do you measure FID?

Because measuring FID correctly requires real user interaction, you can’t simply browse the site and get that value. However, you can add code to your application to get this information. Once you have it, you can do as you please. Google has a open source script, directly within the page, you can use the script to measure the index: https://github.com/GoogleChromeLabs/first-input-delay

Improve your FID time

Improving first-input latency is not an easy task because it is tied to the structure and logic of your code. However, Philip Walton from Google came up with a technique called “Idle to Urgent,” which tries to maximize the processing time of the main thread without actually locking it. Essentially, it depends on deciding when to load the required resource: when the browser is idle and has available processing power, or when the resource is actually needed. It tries to bridge the gap between desire and lazy resource loading. Philip’s article covers a very detailed implementation approach to how to implement this concept if you need to reduce the “first input delay” time.

Total Lockdown Time (TBT)

“Total block time” is the amount of time a page is unresponsive while loading resources, interpreting JavaScript files, and who knows what other tasks are in the background. Essentially, the main thread is too busy processing everything you throw at it to respond to user input. It covers the period from the first rich paint (FCP) to TTI.

While TBT may sound like just another way to describe TTI, in reality they are not that different. Consider making the main thread have the following four consecutive tasks:

  1. Task 1:300 ms
  2. Task 2:55 milliseconds
  3. Task 3:45 ms
  4. Task 4:50 ms

As I said above, the first two tasks are considered “long tasks” because they are more than 50 milliseconds long. In fact, the “blocking time” would be all the time in the first 50ms, which would result in a total of 255ms of “total blocking time” for a total 450ms task. With this in mind, how is TBT different from TTI? Considering that 3 51ms tasks are spread over 10 seconds, it is impossible for the main thread to have no “blocking time” for more than 5 seconds:

The image above shows the given scenario. The total blocking time here is 3 milliseconds, while the actual TTI is 15 seconds. Now, consider what would happen if instead of a three-microtask, you had a task that took 10 seconds. This new case has a TBT of 9950 ms (total time for the first 50 ms), but the TTI will remain the same. However, UX is not the same, which is why TBT is minimized even if TTI remains the same.

Measuring TBT

The total blocking time can be measured using Lighthouse on a Google Chrome browser such as TTI. In fact, if you generate a report, you can see it under TTI.

Improve technical barriers to trade

There are many factors that could affect TBT, so a good rule of thumb is to note the recommendations Lighthouse makes at the bottom of its report. Some of these will help you keep your numbers down. TBT of 300 milliseconds or less is generally considered good enough, so if you’re sitting there, don’t worry for a while. However, if your numbers are bad, as in the screenshot above, you may want to consider following this guide, where you can learn how to determine what is causing long tasks to block the main thread. Remember, first you need to determine which tasks last more than 50 milliseconds, and then start working on the slower tasks. There is no universal, definitive solution to slow TBT. It takes time and patience, but it can be done.

Cumulative Layout Shift (CLS)

In other words, how much your layout moves when everything is loaded. If your layout is not structured correctly, slow-loading images or fonts (to name just two) can cause elements to move (or move) before the user has even had a chance to interact with them. Even worse, when it interacts with the element loading the image, the cancel button is suddenly invisible, and the Buy now button is exactly where another button is. A high CLS is inherently bad UX, so you want to try to reduce that number as much as possible.

Measure your site’s CLS

The default report of Lighthouse has given you a good idea of what a CLS index is.

You can find it under the TBT value. On the other hand, if you want to incorporate this value into a custom report or want more control over how it evaluates, you can take advantage of the Layout Instability API, which gives you everything you need to measure how elements move around your element. A web page. This choice gives you complete control over the calculation and how it is handled, but note that this is not a simple formula and requires a lot of consideration (for example, iFrame and what happens to the background page). So, instead, if you’re looking for a custom alternative, check out Google’s WebVitals API, which provides a very handy getCLS method.

Improve your CLS

CLS occurs due to unexpected changes in the layout, so consider the following guidelines when writing HTML and CSS:

  • Do not insert elements on other elements that will cause layout deviation. This usually happens when a sudden notification or alert box is inserted. Try alternative methods that do not affect the position of other elements on the page.
  • Always add size attributes to your image and video elements. This way, the browser knows how to reserve a proper place for it before loading.
  • Avoid layout changes caused by animations. Some transitions are so good that they don’t require any movement, so consider using transitions instead of moving elements or changing the size that affects the layout, even if it’s just a few frames.

Evaluating front-end performance

Monitoring the performance of Web applications in production can be challenging and time consuming. Asayer is a front-end monitoring tool that replays everything the user does and shows you what your application is doing on each issue. It’s like opening a browser inspector while looking over the user’s shoulder.

With Asayer, you can reproduce problems, summarize JS errors, and monitor application performance. Asayer provides plug-ins for capturing Redux or VueX storage state and for checking Fetch requests and GraphQL queries.

Asayer Redux

Debugging is enjoyable and suitable for modern front-end teams – free to start monitoring your Web applications.

First Qualified coating (FCP)

The “first rich drawing” is the time it takes to draw the first non-white element on a page. This is an important metric, because the longer it takes to render the content, the longer the user will see it on a blank page, and if it happens long enough, they may even think your site isn’t working properly. This, in turn, will cause users to leave looking for alternatives. Note, however, that this metric refers to the first part of the rendering, it does not refer to the time it takes to render the entire page, but it is still relevant enough that you should pay close attention to this metric. After all, we’re measuring how quickly your users perceive your site visually.

Measurement of FCP

It’s no surprise that Lighthouse on Google’s Browser now gives you a way to capture this metric. You can see it in the following screen capture:

As in other cases, if you need more control over calculations and data, you can use the Paint Timing API. A good FCP is considered between 1 and 3 seconds. If it’s more than three seconds, then you really need to worry about improving it.

Improve your FCP

After all, your First Contentful Paint doesn’t just depend on your front-end code, it’s the First thing that happens when you receive a response from your server. So when you want to improve FCP, consider the following:

  • Reduce server response time. This causes the browser to start processing and interpreting the response more quickly. This could be improving server-side code or improving how static resources are served, such as moving images to a high-quality CDN.
  • Consider using defer to load non-critical resources (i.e., scripts and CSS stylesheets) :
Copy the code

Or load the stylesheet asynchronously using the following small fragment:

<! -- Fallback for when JavaScript is disabled, But in this case CSS can't be loaded. --> <noscript><link rel="stylesheet" href="style.css"></noscript>Copy the code

The code snippet media loads the stylesheet as “print,” which causes the browser to load it asynchronously, but once the page is loaded, it changes its media type to “all” (note the onload attribute). This flag exists if NOScript disables JS, because onLoad does not fire the event in that case.

  • Delete unnecessary resources. If you don’t use stylesheets or JS scripts, remove them, they actually block FCP time to a large extent.
  • Inline key styles. This is a problematic problem, but if you’re anxious to improve FCP as much as possible, inlining some CSS will reduce the time it takes to parse external resources, and your browser will parse it faster.

There are many other ways to improve FCP, but consider the above recommendations before diving into other types of optimizations.

conclusion

Measuring UI performance is not a joke, nor is it an easy task. While a tool like Lighthouse gives you most of the metrics you need to know if you have a good UI or a bad ONE, there are other ways to measure them. In fact, if you’re trying to track these numbers and create custom reports around them, you can capture them yourself using a variety of apis.

Remember: There is only one way to know if you need to optimize your UI performance and evaluate it. Start with these five key metrics around UI performance, and continue to add others when you decide you’ve done everything you can.