Several performance metrics that front-end development engineers must focus on

There is a well-known “2-5-8 rule” regarding page timing. When a user visits a page:

When the response is received within 2 seconds, it will feel that the system responds quickly;

In 2-5 seconds to get a response, will feel the response speed of the system is ok;

When the response is within 5-8 seconds, the response speed of the system will be perceived as slow, but acceptable;

When no response comes after more than eight seconds, the user feels bad and leaves the site or makes a second request.

If a website wants to capture users, the speed and stability of the site is the first to bear the brunt.

From a variety of front-end monitoring platforms, you can get a lot of performance metrics for your page. This paper will introduce several key indicators, and give the corresponding optimization ideas.

Start rendering time

This point in time indicates that the browser starts to draw the page. Before this point, the page is white, so it is also called white screen time.

Time To Start Render = TTFB(Time To First Byte) + TTDD(Time To Document Download) + TTHE(Time To Head End). Where TTFB represents the time from the browser to the server to return the first byte, TTDD represents the time to load the HTML document from the server, and TTHE represents the time required for the document header to be parsed. There are properties in advanced browsers to retrieve this point in time. Chrome by Chrome. LoadTimes (.) firstPaintTime, ie 9 + through performance. Timing. MsFirstPaint access, In unsupported browsers you can use the formula above to get an approximation by getting the simulation at the time when the header resource is finished loading. The faster the rendering time starts, the faster the user will see the page.

The optimization for this time point is as follows:

1) Optimize the server response time and output the server as soon as possible

2) Reduce HTML file size

3) Reduce header resources and put scripts in body as much as possible

DOM Ready

This point in time indicates that DOM parsing is complete, resources are not loaded, and user interaction with the page is available. TimeTo Dom Ready = TTSR(Time To Start Render) + TTDC(Time To Dom Created) + TTST(Time To Script) can be expressed by the formula. TTSR, described above, represents the time taken to create a DOM tree. TTST represents the time when all static scripts in the BODY load and execute. In advanced browsers, there is a corresponding DOMContentLoaded event. The documentation for the DOMContentLoaded event description in MDN is as follows:

The DOMContentLoaded event is fired when the document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading (the load event can be used to detect a fully-loaded page).

See the W3C’s HTML5 specification for details. MDN documents show that the DOMContentLoaded event is used when the DOM document has been loaded and parsed. It looks simple, but the event is related to CSS and JS, and now has the term Critical Rendering Path. In the article [Key Rendering Path], the influence of key rendering path on DOMContentLoaded is introduced in detail.

In browsers that do not support DOMContentLoaded events, approximations can be obtained by simulation. The main simulation methods are:

1) Lower versions of webKit kernel browsers can be implemented by polling document.readyState

2) The doScroll method of documentElement can be repeatedly called by setTimeout in IE until it is available for implementation

Specific implementation methods can refer to the mainstream framework (jquery, etc.) implementation. The DOM Ready time point means the user is Ready to interact with the page, so the earlier the better. Optimizations for this time point include:

1) Reduce the complexity of DOM structure, with as few nodes as possible and not too deep nesting

2) Optimize the key presentation path

The first screen time

This time point represents the time when the user sees the first screen page. This time point is very important but difficult to obtain. Generally, an approximate time can only be obtained through simulation. General simulation methods include:

1) Continuously obtain screen shots. When the screen shots no longer change, it can be regarded as the first screen time. Refer to the Speed Index algorithm of webPagetest;

2) Generally, the main factor affecting the first screen is the loading of pictures. After the page is loaded, determine whether the picture is in the first screen and find out the one with the slowest loading time as the first screen time. Of course, other details need to be considered. For details, please refer to [7 Days to build front-end performance Monitoring System].

The optimization for this time point is as follows:

1) The display of the first screen of the page should not rely on JS code, and JS should be executed or loaded after domReady

2) Lazy loading of images outside the first screen

3) Keep the structure of the first screen simple. The CSS outside the first screen can be loaded lazily

onload

This is the time when the window.onload event is triggered, indicating that the original document and all referenced contents have been loaded. The most obvious feeling of the user is that the loading state on the browser TAB ends.

The optimization methods at this time point are as follows:

1) Reduce resource requests and file sizes

2) Place the uninitialized script after onLoad

3) Scripts that do not need synchronization are loaded asynchronously

In order to optimize the performance of the whole site, the page onload can be considered to do some preloading, other pages need to use the resources pre-loaded in.

The author: Zhang Xian

Source: 51 cto