As a front-end development engineer, you must pay attention to three performance indicators:-JS Tutorial-php.cn

As a front-end development engineer, you must pay attention to three performance indicators:

php中世界最好的语言

Release： 2017-11-18 14:06:25

Original

1400 people have browsed it

As a qualified front-end development engineer, do you know several performance indicators that you need to pay attention to? Today I will give you a good introduction to the three indicators that you must pay attention to as a front-end engineer

1. Regarding the page response time, there is a famous "2-5-8 principle". When a user visits a page:

When the response is received within 2 seconds, the system response will be felt quickly;

When the response is received between 2-5 seconds, the system response speed will be felt It's OK;

When the response is received within 5-8 seconds, the system's response speed will feel very slow, but it is acceptable;

When the user still cannot get the response after more than 8 seconds, the user You will feel that the system is terrible and choose to leave the site or initiate a second request.

If a website hopes to capture users, the speed and stability of the website are the first priority.

You can get many performance indicators of the page from various front-end monitoring platforms. This article will introduce several key indicators and give corresponding optimization ideas.

2. Start rendering time

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

This time point can be represented by the formula Time To Start Render = TTFB (Time To First Byte) + TTDD (Time To Document Download) + TTHE (Time To Head End). Among them, TTFB represents the time from the browser initiating the request to the server returning the first byte, TTDD represents the time to load the HTML document from the server, and TTHE represents the time required to complete the parsing of the document header. There is a corresponding attribute in advanced browsers to obtain this time point. Chrome can be obtained through chrome.loadTimes().firstPaintTime, and IE9+ can be obtained through performance.timing.msFirstPaint. In unsupported browsers, the approximate value can be simulated by obtaining the moment when the header resource is loaded according to the above formula. The faster the start rendering time, the faster users can see the page.

Optimizations at this point in time include:

1) Optimize server response time, server output as early as possible

2) Reduce html file size

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

DOM Ready

This point in time indicates that the DOM parsing has been completed and the resources have not been loaded. At this time, the user and the page Interaction is already available. It can be expressed by the formula TimeTo Dom Ready = TTSR(Time To Start Render) + TTDC(Time To Dom Created) + TTST(Time To Script). TTSR has been introduced above, and TTDC represents the time it takes to create the DOM tree. TTST represents the loading and execution time of all static scripts in BODY. There is a corresponding DOMContentLoaded event in advanced browsers. The document describing the DOMContentLoaded event on 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).

For detailed specifications, please view the W3C's HTML5 specification. It can be seen from the MDN document that this event mainly refers to the completion of loading and parsing of the DOM document. It seems very simple, but the triggering of the DOMContentLoaded event is closely related to css and js. Now there is a special term Critical Rendering Path (critical rendering path) to describe it. The impact of the critical rendering path on DOMContentLoaded is introduced in detail in the article [Critical Rendering Path].

In browsers that do not support the DOMContentLoaded event, you can obtain approximate values through simulation. The main simulation methods are:

1) Low-version webkit kernel browsers can poll the document. readyState to achieve

2) In IE, the doScroll method of documentElement can be continuously called through setTimeout until it can be used to implement

The specific implementation method can refer to the implementation of mainstream frameworks (jquery, etc.). The DOM Ready time point means that the user can interact with the page, so the earlier the better. Optimizations for this time point include:

1) Reduce the complexity of the DOM structure, with as few nodes as possible, and nesting Don’t go too deep

2) Optimize the key presentation path

3. First screen time

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

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

2) Generally, the main factor that affects the first screen is the loading of picture. After the page is loaded, determine whether the picture is in the first screen and find out whether it is loaded. The slowest one can be regarded as the first screen time. Of course, other details need to be considered. For details, please refer to [Building a front-end performance monitoring system in 7 days]

The optimizations for this time point are:

1) Try not to rely on the display of the first screen of the page. js code, js should be executed or loaded after domReady as much as possible

2) Delayed loading of images outside the first screen

3) Keep the structure of the first screen as simple as possible, and css outside the first screen can be delayed loaded

onload

at this time It is the time when the window.onload event is triggered, which means that the original document and all referenced content have been loaded. The most obvious feeling for the user is that the loading state on the browser tab has ended.

The optimization methods at this point in time are:

1) Reduce the number of resource requests and file size

2) Place the non-initialization script after onLoad and execute it

3) Asynchronous loading of scripts without synchronization

In order to optimize the performance of the entire site, you can consider doing some preloading when onloading the page, and preloading the resources that other pages need to use.

I hope that reading the above article will be helpful to you on the road to front-end development.