Study the first screen time? You need to know the details first.

Do mobile Web pages, by the mobile network speed and terminal performance impact, we often have to pay attention to the first screen content display time (hereinafter referred to as the first screen time) this indicator, it measures whether our page can be displayed in the user's patience before the end, to a large extent affecting the user's satisfaction with the use.

How to get the first screen time?

We often have to ask ourselves: how does the page load data?

A: After loading the static resources through the AJAX request to get the data backstage, the data back to render content

At each point to play a timestamp, the first screen time = point 8– point 1;

B: Using the background straight out, the returned HTML has been brought with the content

At this point the first screen time = Point 4– point 1.

Note: 1. Hit so many points, is because when we collect the first screen time, to analyze exactly which section is the performance bottleneck, which section has the optimization space, so we need to collect points 1, point 3– point 1 ... These times for analysis;

2. Dot 1 We usually make a timestamp at the beginning of the head tag of the HTML file;

3. There is generally no other loading process before the CSS file is loaded, so the dot 1 and dot 2 can generally be combined.

To this we collected the first screen related to various data, can do a variety of targeted optimization. wait! Before you make a drastic optimization, you need to know some details that will help you to do more accurate analysis and more detailed optimization.

Details 1:js The point behind the –js ≠js load time of the front point

jsendtime–jsstarttime = JS file load time, right?

Wrong! Obviously, this equation ignores the execution time of JS. JS code execution takes time, especially for complex calculations or frequent DOM operations, which can sometimes take up to hundreds of milliseconds.

So, jsendtime–jsstarttime = JS file load execution time?

Still wrong! Because the load execution of the CSS file has caused interference . It's weird, right, don't worry, let's do a test: We'll find a demo page, open it in Chrome, then launch the console, simulate the low speed, and keep the file loading time relatively long:

The jsendtime–jsstarttime time is collected under normal circumstances, and then a CSS request is blocked using Fiddler for a few seconds:

Then restore the request, get the jsendtime–jsstarttime results at this time, will find that the first time is hundreds of milliseconds will be nearly 1s, and the second time is less than 100ms or even close to 0 (my example, time depending on the reader specific JS file decision), the gap between the two is very obvious.

What is this principle? This is what we often call "load is parallel, execution is serial" results. When the HTML starts to load, the browser will load the CSS file and the JS file in parallel with the page, and if a file is not returned, the code behind it will not be executed. Just our demo, we blocked the CSS file for a few seconds, when the JS file because the parallel has been loaded back, but because the CSS file blocked, so the subsequent Jsstarttime assignment statement is not executed! when we let go of blocking, at this time will run to Jsstarttime assignment, JS file parsing, Jsendtime assignment, because the big head time loading has already completed, so jsendtime and jsstarttime difference is very small.

You know what this is for?

1. Do not put the results of jsendtime–jsstarttime into the JS file load execution time (unless you do not have an external CSS file), or you will be laughed at by the expert;
2. The blocking of the CSS file will affect the execution of the following JS code, which naturally includes the execution of the HTML code, that is, your page is blank at this point. So the CSS file as far as possible inline, you can let build tools to help you busy;
3. If you really want to know the JS file load time, the most correct posture is to use the Resource Timing API, but this API mobile can only be in Android4.4 and above the version of the data, but also in the business PV large scene only enough for our analysis

Of course, those two can still be used for analysis.

Details 2:html inside the external JS file, the previous file loading will block the execution of the next file, and if A.js is responsible for rendering and will dynamically pull JS, pull CGI and render, you will find that the JS file behind it and how to block it will not affect its processing

The conclusion of the first half is already proven in detail 1, since the execution of the browser is serial. This shows that we are responsible for rendering the content of the JS code to wait until it all the JS file load execution before execution, even if those code with rendering-independent code such as data escalation:

The second half of the conclusion is very good validation, we are responsible for the rendering of the JS file outside a JS file and block it, you will find that the rendering of the relevant JS regardless of the dynamic pull the new JS file, pull rendering related content are all normal, the content of the page is rendered smoothly, They do not need to wait for this file to be blocked.

You know what this is for?

1. unimportant "JS do not put in charge of the rendering of JS Front, where the" irrelevant "refers to the first screen rendering unrelated , such as data escalation components. We can choose to report the data temporarily saved up, the first to continue to perform the rendering of JS, and other responsible for the rendering of JS after the loading of the escalated component escalation. Even zepto such as the library we can also put the back, the rendering related code out and the native JS writing, put to the front;
2. As you can see, the execution of the dynamically loaded JS is not affected by the blocking of the HTML behind the external JS, that is to say, its execution and the subsequent JS execution order is indeterminate. So we have to be careful with the dependencies of the files. Of course, you can use the least error-prone approach: the file responsible for dynamically loading JS is the last file in the HTML.

(Note: Personally think this is the most important two points in the full text, because I am doing the first screen optimization ^-^)

Detail 3: If the return header of the HTML contains chunk, then it is parsed by the side return edge, otherwise it is a one-time return and parse. This is configured on the server

Dot 1 is generally written in the HTML head tag of the front, often friends take straight out when the point 4– point 1 time and non-straight out point 1 when the contrast, to explain how many milliseconds straight out optimization, I think not necessarily. To know the straight out of the case the HTML file contains the rendered content and DOM nodes, the file size is generally larger than the non-straight, and sometimes even a large dozens of k have, then I think it is necessary to explain how to optimize the HTML load time to take into account. Does the calculation above take into account the loading time of HTML?

That depends on whether the HTML file's return header contains chunk:

If the return header is included, the HTML file is parsed on the side of the return edge, at which point the calculation method is reasonable. If you do not include this header, then the HTML file is returned to the entire back to start parsing, at this time, the above calculation method is less than the HTML load time, it is not accurate. This return header is controlled by the background.

You know what this is for?

1. If we want to show the level of optimization that is straight out, it's best to look at your HTML return header first. If you do not include the chunk return header, consider taking HTML5 performance inside the Navigationstart as a dot 1 (This API is also Android4.4 and above to support), or to assess the size of the file changes to do some correction;
2. For HTML that does not have chunk enabled, it is recommended not to have too many JS in it that is not related to rendering the first screen content, which can affect rendering time

Detail 4: Loading and parsing of script nodes written in HTML will affect the trigger time of the domcontentloaded event

We sometimes use the domcontentloaded event instead of the OnLoad event to do some processing when the page is ready. You know, however, that the DOM inside the domcontentloaded contains more than the common DOM nodes that we often call, but also the script nodes.

Experiment, we will be the page in the outside of a JS file block for a period of time and then let go, we look at the Chrome console:

Obviously, the load time of the JS file can affect the event's triggering event. Will the parsing time of the JS code affect? We hit a point behind the last external JS file, and its time is:

So the JS file load execution will affect the timing of the domcontentloaded event execution.

You know what this is for?

1. If we intend to do some special processing in the domcontentloaded, OnLoad event and these processing is more important (such as related to rendering), then we'd better not in the HTML directly outside some of the rendering-independent JS files, you can consider using dynamic loading

Summarize

It's interesting to study the first screen time and the resource loading, so you can tap into the chrome console (especially the network tag inside) and fiddler to find out a lot of interesting little details. Do not think this is nothing to do, understand the best of these to do the first screen performance optimization, positioning because JS file execution sequence of errors and other scenarios are very good. So find something to remember to share with me ha ~

Study the first screen time? You need to know the details first.