For testing, I deliberately made the big.css (3.8MB) and big.js (8.1MB) files larger. The console network selected Regular 4G, turned on Disable cache, and both js files and css files were in Introduced after the body tag.
The first situation: big.js is not introduced into the page, only big.css is introduced:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Document</title>
</head>
<body>
<p>我是呈现出来的文字</p>
</body>
<link rel="stylesheet" href="css/big.css">
</html>Result: At this time, the page took a total of 7.62s from being blank to showing the text on the page
Screenshot:
Second case: The page introduces big.css and big.js at the same time, and puts big.css after big.js:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Document</title>
</head>
<body>
<p>我是呈现出来的文字</p>
</body>
<script src="js/big.js"></script>
<link rel="stylesheet" href="css/big.css">
</html> Result: It takes almost no time to go from a blank page to the text on the page, which means that the text is presented immediately, even if the css and js are still loading at this time.
screenshot:
Question: Why does the loading of css in the first case block page rendering for so long, while in the second case there is almost no blocking?
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Because of the single thread, and the html is parsed in order
The first type is because your css is first, so you need to download and parse it first
The second type is because it is at the back, so you see the text first before downloading and parsing the js and css
This is why everyone says to put css in the head and js at the bottom. We hope that users will have a style when they see the interface, and we also don’t want the download and execution of js to block the time when users see the page