Front-end Performance Optimization Guide [7]–Web Performance Metrics

This is part 7 of a series on Web performance standards. Part 2: Web loading for page rendering

Measuring the performance of a Web page has always been a challenge for Web developers.

Initially, we used metrics such as Time to First Byte, DomContentLoaded, and Load to measure document loading progress, but they didn’t directly reflect the user’s visual experience.

In order to measure the user’s visual experience, the Web standard defines performance metrics that are standardized across major browsers, such as First Paint and First Contentful Paint. Other performance metrics proposed by the Web Incubator Community Group (WICG) include Largest Contentful Paint, Time to Interactive, First Input Delay, and First CPU Idle. There are also Meaningful Paint and Speed Index from Google and First Screen Paint from Baidu. These metrics are not unrelated, but have evolved in user-centric goals that are no longer recommended, implemented by various testing tools, and used as a common standard with apis provided by major browsers for measurement in production environments. I divided these metrics into three categories: document loading related, content rendering related, and interactive responsiveness related, and based on these metrics, EXTRACTED the core metrics that were most relevant to the user. The sources, definitions, and measurement methods of these indicators are described below.

🐹 Document loading related

The timeline of document loading process is shown in the figure, where three indicators are mainly introduced: TTFB, DCL and Load time.

Load (L)

The time when the onLoad event is triggered. The onLoad event is triggered when all the resources on the page have been loaded (e.g. images, CSS).

First Paint (FP)

Proposed by the Web Performance Working Group in the W3C Standard Paint Timing. Defines the time from the start of the load to the first time the browser draws a pixel onto the screen, the time the page first visually changes on the screen. However, this change may be a simple background color update or unobserved content, it does not indicate page content integrity and may report a time when no visible content is drawn.

Note: First Paint does not include default background painting, but does include non-default background painting.

This is the first critical moment when developers care about page loading — when the browser starts rendering the page. ** Measurement method

function getFirstPaint() {
  let firstPaints = {};
  if (typeof performance.getEntriesByType === 'function') {
    let performanceEntries = performance.getEntriesByType('paint') | | []; performanceEntries.forEach((entry) = > {
      if (entry.name === 'first-paint') {
        firstPaints.firstPaint = entry.startTime;
      } else if (entry.name === 'first-contentful-paint') { firstPaints.firstContentfulPaint = entry.startTime; }}); }else {
    if (chrome && chrome.loadTimes) {
      let loadTimes = window.chrome.loadTimes();
      let {firstPaintTime, startLoadTime} = loadTimes;
      firstPaints.firstPaint = (firstPaintTime - startLoadTime) * 1000;
    } else if (performance.timing && typeof performance.timing.msFirstPaint === 'number') {
      let{msFirstPaint, navigationStart} = performance.timing; firstPaints.firstPaint = msFirstPaint - navigationStart; }}return firstPaints;
}
Copy the code

@font-face {
  font-family: 'Pacifico';
  font-style: normal;
  font-weight: 400;
  src: local('Pacifico Regular'), local('Pacifico-Regular'), url(https://fonts.gstatic.com/s/pacifico/v12/FwZY7-Qmy14u9lezJ-6H6MmBp0u-.woff2) format('woff2');
  font-display: swap;
}
Copy the code

First Meaningful Paint (FMP)

Introduced by Google in Time to First Meaningful Paint: A Layout-based Approach.

Defining how long the main content of a page is drawn to the screen is a better measure of the user’s perceived loading experience, but still not ideal. The definition of main content varies from page to page. For example, for a blog post, the main content is the title and summary, for a search page, the main content is the search results, and for an e-commerce page, the main content is the image.

So use the time when the number of layouts is maximum and the Web font is loaded as the approximate time to draw the main content. With the loading and parsing of web pages, Layout objects are gradually added to the Layout Tree. For the point at which the main content is drawn to the screen, it is estimated by counting the number of layout objects. The algorithm takes the maximum moment (number of layout objects added to the layout tree/Max (1, page height/screen height)) as the FMP point of time. If the font is being loaded at layout time, The layout changes are delayed until the font is displayed to guess when the main content of the page is drawn to the screen.

This calculation is too sensitive to small differences in page loading and can lead to inconsistent results. In addition, the definition of a measure depends on browser-specific implementation details, meaning that it cannot be standardized or implemented across all Web browsers. Largest Contentful Paint is recommended instead of FMP in Lighthouse 6.0.

try {
  const po = new PerformanceObserver((entryList) = > {
    const entries = entryList.getEntries();
    const lastEntry = entries[entries.length - 1];

    // renderTime takes precedence, if not loadTime
    let lcp = lastEntry.renderTime || lastEntry.loadTime;
    window.perfData.push({
      'LCP', lcp
    });
  });
  po.observe({type: 'largest-contentful-paint'});
} catch (e) {
  // Do nothing 
}
Copy the code

Speed Index (SI)

Created by Google in webpagetest.org. Definition This is a measure of the filling speed of content in the visible area of the page, measured by calculating the average time that content in the visible area of the page is displayed. Measuring way

First capture the video of the page loading in the browser, and then calculate the percentage of page filling for every 100 millisecond screen shot to get a curve (the vertical axis is the degree of content filling in the visible area of the page, and the horizontal axis is the time).

Example 1 and Example 2 in the figure were both filled in at 10s, but Example 1 was 80% filled in at 2s, and Example 2 was 80% filled in at 8s.

The area of the shaded part of the figure (above the time-content fill percentage curve) indicates the filling speed of the page content within the visible area. The smaller the area, the faster the filling speed.

In terms of time, you can calculate it this way to represent the average time for content to be displayed in the visible area of the page.

Example 1: Speed Index = (80% * 2) + (20% * 10) =3.6
Example 2: Speed Index = (80% * 8) + (20% * 10) =8.4
Copy the code

This average time can be used to compare the performance experience of the full display of the first screen content, but it does not calculate the time when the full display of the first screen content is not considered as a time metric.

🐷 Interactive responsiveness correlation

Time to Interactive (TTI)

Developed by the Web Incubator Community Group (WICG) in Time To Interactive, is a non-standardized performance metric.

define

Represents the point in time when a web page is first fully interactive and the browser can consistently respond to user input. The point at which the interactible state is fully reached is when the last Long Task is completed, and the network and main thread are idle for the next 5 seconds.

By definition, the Chinese term sustainable interaction time or fluid interaction time is more appropriate.

Long tasks are tasks that take more than 50 milliseconds to complete

TTI calculations, which rely on observing whether Long tasks and main threads are idle, are not currently included in the Web performance standard specification, but are implemented in some performance monitoring tools. In addition, Google provides an API for TTI collection: TTI-Polyfill

const ttiPolyfill = require('tti-polyfill');
ttiPolyfill.getFirstConsistentlyInteractive().then((tti) = > {
  window.perfData.push({
    'tti': tti
  });
});
Copy the code

First Input Delay (FID)

This metric was developed by the Web Incubator Community Group (WICG) and has been used in various tools.

define

From the time the user first interacts with the page (such as clicking a link, clicking a button, etc.) to the time the browser is actually able to respond to that interaction.

Input is delayed because the main thread of the browser is busy doing other things and cannot respond to the user. A common reason for this is that the browser is busy parsing and executing large JavaScript files loaded by the application.

The first input delay usually occurs between the first content rendering (FCP) and the sustainable interaction time (TTI), because the page has rendered some content but is not yet able to reliably interact.

If the user is interacting with the page when the main thread is at its busiest, the latency is longer, and if the user is interacting with the page when the main thread is idle, the browser may respond immediately. Therefore, for the index FID, we need to pay attention to the overall FID value distribution, rather than a single value. In the Event Timing specification (not Web standard) developed by WICG group, the API for FID acquisition is given. Whether it can be used in production depends on whether the major browsers implement it. In addition, Google provides a JS library github.com/GoogleChrom… Used for measuring FID.

// Code examples from: Wireless Performance Tuning: FPS Testing
var lastTime = performance.now();
var frame = 0;
var lastFameTime = performance.now();

var loop = function(time) {
    var now =  performance.now();
    var fs = (now - lastFameTime);
    lastFameTime = now;
    var fps = Math.round(1000/fs);
    frame++;
    if (now > 1000 + lastTime){
        var fps = Math.round( ( frame * 1000 ) / ( now - lastTime ) );
        frame = 0;    
        lastTime = now;    
    };           
    window.requestAnimationFrame(loop);   
}
Copy the code

🎯 Core Indicators

When opening a page, the user may see a process like this: white screen → base image → partial content appears → full first screen content appears but images are still loading → full first screen content appears and images have been loaded.

Generally, the user starts to interact with the page when most of the content is displayed on the first screen, such as clicking and swiping down. These changes can take a long time before the first screen is full and the user experience will be poor. We need to optimize these processes so that the first screen is displayed as quickly as possible, and of course the user experience is best when the first screen is displayed immediately without these processes. We can measure these key points of change with several core metrics that can be approximated by some of the performance metrics we described earlier.

As for Interactive Time and fluid Interactive Time, I think Time To First Interactive (TTFI) and Time To Preferably Interactive (TTCI) are more appropriate. FCI and TTI are defined as first interaction time and sustainable interaction time, but the English names are not easy to understand.

But as noted at the beginning of this article by Google’s First Interactive and First Preferably Interactive: 👉 Updated [25 July 2018] : We have renamed these metrics to simplify messaging with external developers. First Interactive is now First CPU Idle, Time to Preferably Interactive called Time to Interactive (TTI). This article still uses the old name.

FSP and FCI currently do not have a unified measurement and collection method in the online production environment, but we can measure it in the offline laboratory environment. The general practice is to visit a page, click or slide in the page when the page is opened, and record the video of this process, cut the video into N pictures per second (e.g., 10 pictures, 1 frame every 100 ms), and then calculate the change of the page content with the algorithm, for example:

• 1. The Optical Character Recognition (OCR) algorithm is used to calculate the change of the number of bytes of the text in the image. When the number of bytes is very small, it can be defined as the white screen state; when the number of bytes is stable, it means that the content of the first screen is stable. Slide back and forth until the number of bytes changes. Changes in the number of bytes indicate that the page is slidable and interactive. When the number of bytes changes after three swipes back and forth, the page interacts smoothly.

• 2. Look at each pixel of the image, compare it to the final image, and calculate the percentage of pixels that each frame matches.
• 3. Get a histogram of the colors in the image (one red, one green, and one blue), and then view the overall distribution of colors on the page. We calculate the difference between the start histogram (for the first video frame) and the end histogram (for the last video frame) and use that difference as a baseline. The difference between the histogram of each frame in the video and the first histogram is compared to the baseline to determine the “integrity” of the video frame.

Each of the three approaches has its advantages and disadvantages:

• The first way is not to monitor the change of the picture without text on the screen.
• The second method is not suitable for cases where the page flows during loading.
• The third way, which is very sensitive to the final state, is to calculate the progress according to the final image, which is not suitable for the situation of the page with video playback and rotation graph.

For these key time points to measure user experience, Google also provides four indicators to reflect user experience. For detailed description, you can see the user-centered performance indicators.

💫 thinking

In 2014, Baidu submitted a proposal to the Web Performance Working Group on the optimization of first-screen rendering, a specification designed to speed up the actual perception of first-screen content by mobile users. The main content of the specification is as follows: After the Web page code is parsed, it also needs to go through the layout and paint stages before it is displayed to the user on the screen. Mobile screens are small, often filled with very short code, and this is the area of content that users actually perceive first. When A page code consists of A and B, code A can represent all the contents of the first screen. After A completes Web content parsing, it cannot complete layout and paint immediately. There are several trigger conditions for the kernel to transition from the parse state to the layout state, including the number of tokens parsed, the parsing time, and the delay time. There are also several conditions necessary for the kernel to transition from Layout state to paint state. These conditions prevent the kernel from exiting the Layout process early and entering the actual screen painting phase. All of these constraints don’t take into account the size of the first screen and the importance of the actual user perception of content. This limitation has an even greater impact on browsing speed in complex mobile networks. By defining the first screen rendering optimization specification, Web developers can specify the browser to draw appropriate first screen content in advance (the kernel can determine the first screen location or the developer can specify the first screen location), thus speeding up the first screen display speed and significantly shortening the time for users to see non-white screen pages for the first time.

<! -- Instructs the browser to determine the first-screen judgment mechanism and optimize the first-screen content drawing in advance. -->
<meta name="render-optimize-policy" content="first-screen-advance [;enable]">
Copy the code

Specific programs can be consulted:

• W3C Chinese Interest Group Topic: proposal for a first screen rendering optimization specification
• W3C Member Submission： First Screen Paint