• Performance Metrics for Front-end Applications
  • By Mahdhi Rezvi
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: niayyy
  • Proofreader: PlusMultiply0, HurryOwen

Performance indicators of front-end applications

The Internet has become an indispensable part of our daily life. According to CreditLoan, users spend an average of 7.6 hours a day online, with 20% of that time spent surfing the Web. You can just imagine how many hours of Internet time there should be in 2020, a year filled with disasters, when everyone stays at home.

These numbers show how much the Internet has affected us. To make the most of this big opportunity, the site should have very high standards. It’s easy to build a good looking website, but it’s very difficult to achieve great performance. This is because there are many bottlenecks in Web development, such as expensive JavaScript overhead, slow loading of Web fonts, slow downloading of large images, etc.

You can have the best looking, most attractive website in the world, but if the performance of the site is very poor on the user’s browser, people won’t use it.

User-centric performance and its importance

Now we know why you should start improving your site’s performance.

With Vitaly, generally speaking, your goal should be to be at least 20% faster than your fastest competitor.

But when we talk about performance, what are we really aiming for?

As Philip says, “Performance is relative.” In some cases, your site can load very quickly on a user’s phone and very slowly on other devices. Two sites may take the same amount of time to load, but one site seems to be able to display content faster through progressive loading. This creates the illusion that the page is ready, when in fact it is still loading.

On the other hand, a Web page loads quickly, but there are multiple blocking processes running in the background, so it can take a long time for the page to respond.

Therefore, it is most important to measure performance accurately against objective criteria that can be quantitatively measured.

Why is it important?

Traditionally, page events such as LOAD have been used to measure performance. But in reality, that’s not necessarily what users care about.

For example, a site might load a minimal page right away, but then delay retrieving content and take a few seconds to display useful content on the page. This can happen after the page load event. Although technically the “load time” is shorter, the load time is irrelevant to the actual user experience, as useful content takes a few more seconds to display.

Types of performance Indicators

Performance metrics can be divided into the following categories.

  • Quantity-based indicators
  • Milestone indicator
  • Render target
  • User-defined Indicators

Quantity-based indicators

Measuring the number of HTTP requests depends on the size of resources such as images, styles, JavaScript, HTML, and so on.

The place of useful

  • Alerts – They tell you about the health of your site by letting you know if your Web application has exceeded its performance budget, and they also help monitor if your Web application has timed out, which is considered the simplest performance indicator.

The place of useless

  • Understand the user experience — they can’t elaborate on the information the user perceives because these metrics are mostly about direct attributes.

Rule-based metrics

These metrics are generated by Web applications and browser extensions according to predefined rules. You’ll get a single output value/score or a series of site ratings. Applications such as Google’s Pagespeed Insights and Lighthouse provide rules-based metrics.

The place of useful

  • Scores are a form of presentation that makes it easier to communicate, measure and track performance. In other words, scores are easy to interpret because higher scores directly indicate better performance.
  • Provide “activity items” or tips on how to improve each score or rating.

The place of useless

  • Know the user experience — Similar to quantity-based metrics, these metrics cannot detail information about user perception because they are based on known rules that change over time. But there are some applications and extensions that do provide user-centric feedback.

Milestone indicator

These metrics are usually time-based and can be easily viewed from the web TAB of the browser developer tools. Metrics like “page load” and “DOMContentLoaded” are part of the milestone metrics. The “time to fetch the first byte” metric is also part of this, helping to understand the response speed of the back-end server.

Another metric is “interactive time.” This metric tells you when the page is ready for user interaction. In other words, when the page is ready for users to interact with. This is important because loaded pages that are not ready for user interaction are not loaded pages.

The place of useful

  • Describe the user experience of the client as a milestone and describe the perception of the user.
  • Time-based metrics are easy to track.
  • Visualization is simple and easy to understand.

The place of useless

  • You can’t show the whole picture — these metrics don’t capture what the user sees between milestones.

Render target

Rendering metrics help fill in the gaps in milestone metrics by revealing the user’s visual experience of what they see on the screen. This can be useful in conjunction with milestone metrics.

The place of useful

  • Describe the user experience because they can handle the visual experience from the user’s point of view
  • Identifying rendering performance

The place of useless

  • Pixel priority – they don’t know which pixels are important. In other words, it doesn’t know to ignore visual content that has no real value to the user, such as ads and pop-ups.
  • Inability to recognize interactivity — not knowing when a user can interact with visual content.

User-defined Indicators

Custom indicators are triggered when the user experience changes. Use apis such as User Timing to get metrics from the browser and pass them to the server.

The place of useful

  • Describes the user experience when metrics focus on real data about the user.

The place of useless

  • Compared to competitors because your site’s metrics are unique. For example, Twitter’s “first release time” metric cannot be compared to Facebook’s custom metric because they do not mean the same thing.

Key metrics — Focus

Now that we know some of the metrics, let’s take a look at some of the key ones.

Interactive time (TTI)

This is the point where everything is stable enough to handle user interaction. In other words, when the layout is stable, the key Web fonts are displayed and the main thread has enough free time to process user input. This metric is critical to understanding how long users have to wait to interact with the site without or after delay.

First input delay (FID)

This is also called input responsiveness. The time between the user interacting with the site and the site being able to respond to that interaction. TTI is enhanced because FID fills in the gaps that occur when a user interacts with a web site. This is a real User metric (RUM) that can be measured with the help of some JavaScript libraries in the browser.

Maximum Content Rendering (LCP)

Represents a point in the page’s life cycle where important content of the page might have been loaded. This assumes, though, that the most important element of a page is the largest element visible in the user’s viewport. If the content has been rendered above and below the visible area (folded), only the content above — the part visible to the user — is considered.

Total blocking time (TBT)

TBT is a metric that helps quantify how long it takes for a web page to interact. TBT measures the time between the first drawing and the interactivity time (TTI). Lower TBT indicates better performance.

Cumulative Layout Offset (CLS)

CLS checks for instability in site elements. It highlights how often users experience unexpected layout offsets (backflow) and its impact on the overall user experience.

Let’s take a look at how unexpected layout offsets can negatively impact the user experience.

Speed index

The Speed index measures how quickly page content fills visually. The score is based on visual progress, but it’s just a calculation. Since this metric is considered from a visual point of view, viewport size directly affects the speed metric. Therefore, the viewport size needs to be defined to match the target audience for a more meaningful score.

CPU time spent

This indicator shows how long the main thread is blocked. It shows how often and how long CPU/ main thread execution is blocked, such as drawing, rendering, scripting, and loading. If your Web application has high CPU time, it will create an unpleasant latency experience for users. You can do this with WebPageTest.

Component-level CPU costs

Like CPU time spent, this metric focuses on the cost of JavaScript. The general idea is to use the CPU instruction count for each component to understand its impact on the overall experience.

This can be implemented through Puppeteer.

The setback index

When users get frustrated, they will leave your site. All of the metrics discussed above are for a single event. But Tim Vereecke’s frustration index focuses on gaps between indicators rather than looking at them individually. This metric looks at key milestones in the page and counts the user’s frustration during page loading as a score.

This is a key performance indicator of the user experience because it is completely focused on the user.

Influence of advertising weight

If you’re generating revenue from advertising on your site, it’s important to know that it’s an additional burden on users because it can degrade page performance. A script created by Paddy Ganti can help you figure out how to weight your ad-related code.

Deviation index

We talked about a lot of different indicators. But the problem with all of these metrics is consistency. The difference in results indicates the reliability of your site across the entire network. It also shows how much attention you have to pay to the system and infrastructure to provide simplified services. Because some external scripts are very unreliable, the difference for a particular page can be even greater. As Vitaly said, it’s also a good idea to keep track of supported browser versions for a better understanding of performance.

Why consider metrics for your site?

Every website has its own target audience. Depending on what your site does and who it serves, you should focus more on specific metrics.

For example, if you are a streaming media provider, you should pay more attention to the key points of input responsiveness, memory usage, and TTI because they are critical to your application. However, if the content on your site is more focused on readability, such as Wikipedia and Medium, focus more on cosmetic changes and CPU metrics. If you integrate advertising into your own blog, you should also pay attention to the impact of advertising weight. Furthermore, the frustration index can be applied to all of the above examples, as the primary goal of any website is to avoid user frustration, as it may negatively impact the user experience.

You only get one chance to make a first impression. Take advantage of this opportunity!

That’s all for this article. I strongly encourage you to read the following resources, as they are very educational in the broad area of Web performance.

resources

  • Front-End Performance Checklist 2020 by Vitaly Friedman
  • Presentation by Marcos Iglesias
  • Article by Steve Souders
  • Article by Philip Walton
  • Article by Mat Ball

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.