One, the introduction

Recently, I read a book called “Web Efficient Programming and Optimization Practices”, which aroused my interest in Chrome Devtools. I happened to see the part about performance optimization and web rendering, and I remembered everyone’s understanding of browser rendering in various forums before, so I decided to take a look at this part of the knowledge point. Solve some problems.

The experiments in this article are based on Chrome, version 75.0.3770.100 (official version) (64-bit)

Second, pre-knowledge

Link first:

  • Google Web Developer Documentation: Critical path rendering
  • Html5 Developer Documentation: How browsers work
  • Google Web Developer Documentation: Browser Performance Tools

These several parts are more detailed and reliable articles seen in this process. Although the writing time of the article is not early, the principle will not change much. If you feel not satisfied after reading my article, you can have a look at these articles.

Here’s a quick summary of the browser rendering steps:

  1. The browser receives the HTML document
  2. Parsing HTML documents generates a DOM object model, which is a tree structure.
  3. Make requests for external resources in HTML, such as images, CSS files, JS files, etc.
  4. After obtaining the CSS file, the CSS object model is generated, which is also a tree structure.
  5. With the DOM object model tree and the CSS object model tree, the browser generates the render tree.
  6. With the render tree, the browser performs an operation called layout, which calculates the geometry of the various elements on the page.
  7. Eventually, the browser will paint the “laid out” page elements into the final page we see.

The above steps are relatively brief, and reflow and repaint are not included. The main purpose is to help you sort out the process for later reading.

Third, the body

Finally speaking of the topic of the article, presumably the title we have seen, is to study the link tag and script tag on the page rendering effect, since it is the impact, certainly is not ideal. As far as the impact on page rendering is concerned, the focus here is on the impact when the page is first drawn.

Let’s take stock of the unsatisfactory cases and try them out one by one:

  • The loading time of the link label in the normal position is too long
  • The loading time of the link label is too long
  • The loading time of the script label is too long. Procedure
  • Script labels take too long to load in abnormal positions

These are some of the situations tested in this paper. Of course, the normal position is that the link tag should be placed in the head and the script tag at the bottom of the body, and the loading time is too long to be processed by the server side delay of 5000 milliseconds.

This time in order to fast development, with some quick build tools, first recommended to you:

  • Parcel: A small front-end packaging tool that’s easy to use for a service. I’ve used it once before and found it useful.
  • Express: Because to simulate a bad network situation, although Google browser can also set the network speed, but I like their own control to intuitive, so I simply make a server more reliable, not more about Express.
  • Nodemon: This is used to monitor file changes on the server side. Actually, nothing is changed after writing, except the delay time for different files to return.

All right, that’s it. Without further ado, let’s get started.

Let’s take a look at the files we used:

HTML:


      
<html lang="zh-cmn-Hans">

<head>
    <meta charset="utf-8">
    <meta http-equiv="x-ua-compatible" content="IE=edge, chrome=1">
    <title>debounce</title>
    <style>
        img {
            width: 500px;
        }
        .block {
            width: 300px;
            height: 200px;
            border: 1px solid # 000;
        }
    </style>
    <link href="http://127.0.0.1:3000/public/css/common.css" rel="stylesheet">
</head>

<body>
    <div class="block">
        <h2 class="title">I'm a test writer with no relationship</h2>
    </div>
    <div class="pic">
        <img src="Https://ss3.bdstatic.com/70cFv8Sh_Q1YnxGkpoWK1HF6hhy/it/u=4215863670, & FM = 26 & gp = 0. 261223381 JPG">
    </div>
    <script src="http://127.0.0.1:3000/public/js/test.js"></script>
</body>
</html>
Copy the code

common.css:

.block {
	width: 500px;
	background-color: red;
	border: none;
}
Copy the code

test.js:

document.querySelector('.title').innerHTML = 'I've been modified.';
Copy the code

App. Js:

const express = require('express')
const app = express()
const fs = require('fs')
const path = require('path');

app.use(The '*'.function(req, res){
    if (req.params[0= = ='/public/css/common.css') {
        // setTimeout(() => {
            res.setHeader('content-type'.'text/css');
            res.send(fs.readFileSync(path.join(__dirname, req.params[0)));// }, 5000)
    } else if(req.params[0= = ='/public/js/test.js') {
        // setTimeout(() => {
            res.send(fs.readFileSync(path.join(__dirname, req.params[0)));// }, 5000)
    } else {
        res.send('success');
    }
})

app.listen(3000, () = >console.log('working'))
Copy the code

When the page opens, it looks like this:

Case 1: JS lazy loading at the top of the page

Let’s put the js tag at the bottom of the head, under the link tag, and add the server-side delay code to see what happens:

It can be seen that the page is blank for several seconds due to the delayed loading of THE JS script, which is definitely not what we want in normal development. Moreover, the DOM element of the operation cannot be found because the script position is too early.

Let’s see what happens to this page in the console:

Based on performance, we can see that the page is drawn for the first time after 5s, and it is easy to see that the previous page has been in the blank screen stage.

Case 2: JS is lazily loaded at the bottom of the page

Now let’s put the js in its original position, again with the delay, and see what happens:

This time we can see that the js file is lazily loaded, but the elements before the JS file are rendered quickly.

The page does not block rendering of previous elements due to js loading, and the JS file is drawn again after loading due to changes to the DOM element. Therefore, it is reasonable to put JS files at the bottom of the page, but it also needs to be discussed in different situations. For example, some pages are long and have many pictures, and the first screen may only show part of the DOM. In this case, if all JS files are placed at the bottom of the page, it may affect the real-time performance of THE DOM operation of JS scripts.

Case 3: THE CSS loads lazily at the top of the page

The link tag is not attached to the script tag. The link tag is not attached to the script tag. The link tag is attached to the server.

Sorry, there are no GIFs here…

The situation of the GIF can refer to the FIRST GIF, because it is the first time to write a serious article, so GIF is the first screen recording, and then cut video, and then upload video to do GIF. A little trouble, I don’t bother to make another one, small partners have good software or method welcome to comment section recommendation. As for the performance of the web page, it is basically the same as the first case, so let’s move on to the next case.

Case 4: The CSS loads lazily at the bottom of the page

This time we put the link tag at the bottom of the body. In fact, the first three cases are basically the same as WHAT I expected. I tried this one just to see the last case.

Well, it’s not exactly what I expected, so let’s take a look at the console to make sure:

We can see that the browser does not wait until the CSS is loaded to draw, as script delays do. Instead, the BROWSER draws the DOM very early, and draws it again after the CSS is loaded. I tried it a few more times, and if I put the CSS file in the middle of the DOM, I found that the CSS file delay also blocked the rendering of later elements, which I hadn’t expected.

Four, conclusion

In fact, if the network speed is fast enough, we do not need to consider optimization in the loading of resources, because the script itself can not be too large, so in the case of super fast network speed, of course, you can put wherever you want. Developers in 5 or 10 years’ time may look back on this article and not think much of what I’m thinking now, HHH.