CSS和JS在網(wǎng)頁中的放置順序是怎樣的？
- css放到head標(biāo)簽內(nèi)
- js一般放到body尾部，因?yàn)閖s會(huì)涉及dom的操作，所以會(huì)等dom都加載完成后，再去加載js。
解釋白屏和FOUC
白屏現(xiàn)象：
- 器需要加載html文件和所有css文件后，構(gòu)造了渲染樹后，再把樹節(jié)點(diǎn)渲染在屏幕上。如果暫時(shí)加載不到css文件，則會(huì)阻塞渲染過程，造成白屏現(xiàn)象。
- 如果把樣式放在底部,對(duì)于IE瀏覽器,在某些場景下(新窗口打開,刷新等)頁面會(huì)出現(xiàn)白屏,而不是內(nèi)容逐步展現(xiàn)。
- 如果使用 @import 標(biāo)簽（使用@import標(biāo)簽引入樣式文件的情況下，會(huì)等待html文件加載完成后才加載css文件）,即使 CSS 放入 link, 并且放在頭部,也可能出現(xiàn)白屏。
FOUC(Flash of Unstyled Content) 無樣式內(nèi)容閃爍：
如果把樣式放在底部,對(duì)于IE瀏覽器,在某些場景下(點(diǎn)擊鏈接,輸入U(xiǎn)RL,使用書簽進(jìn)入等),會(huì)出現(xiàn) FOUC 現(xiàn)象(逐步加載無樣式的內(nèi)容,等CSS加載后頁面突然展現(xiàn)樣式).對(duì)于 Firefox 會(huì)一直表現(xiàn)出 FOUC .
async和defer的作用是什么？有什么區(qū)別
<script src="script.js"></script>
沒有 defer 或 async，瀏覽器會(huì)立即加載并執(zhí)行指定的腳本，“立即”指的是在渲染該 script 標(biāo)簽之下的文檔元素之前，也就是說不等待后續(xù)載入的文檔元素，讀到就加載并執(zhí)行。
<script async src="script.js"></script>
有 async，加載和渲染后續(xù)文檔元素的過程將和 script.js 的加載與執(zhí)行并行進(jìn)行（異步）。
<script defer src="script.js"></script>
有 defer，加載后續(xù)文檔元素的過程將和 script.js 的加載并行進(jìn)行（異步），但 script.js 的執(zhí)行要在所有元素解析完成之后，DOMContentLoaded 事件觸發(fā)之前完成。
在有 async 的情況下，JavaScript 腳本一旦下載好了就會(huì)執(zhí)行，所以很有可能不是按照原本的順序來執(zhí)行的。如果 JavaScript 腳本前后有依賴性，使用 async 就很有可能出現(xiàn)錯(cuò)誤。
簡述網(wǎng)頁的渲染機(jī)制
- 解析html構(gòu)建DOM樹
- 解析CSS構(gòu)建CSSOM樹
- 把DOM和CSSOM組合成渲染樹（Render Tree）
- 在渲染樹的基礎(chǔ)上進(jìn)行布局，計(jì)算每個(gè)節(jié)點(diǎn)的幾何結(jié)構(gòu)（Layout Tree）
- 把每個(gè)節(jié)點(diǎn)繪制到屏幕上（Painting）
為了構(gòu)建render tree，瀏覽器大致會(huì)做以下幾個(gè)方面：
- 從DOM樹的根部開始，經(jīng)過每一個(gè)可見的節(jié)點(diǎn)。
- 有一些節(jié)點(diǎn)像script tags，meta tags等是不可見的，有一些會(huì)被忽略掉，因?yàn)樗麄儾粫?huì)被反映到渲染的結(jié)果上。
- 有一些節(jié)點(diǎn)通過css隱藏起來，也會(huì)被忽略掉（display：none）。
- 對(duì)于一些可見的節(jié)點(diǎn)，在CSSOM上找到相對(duì)應(yīng)的設(shè)置。
- 結(jié)合內(nèi)容和樣式發(fā)出可見的節(jié)點(diǎn)。
最終輸出在屏幕上的是內(nèi)容和樣式結(jié)合的渲染。當(dāng)渲染樹完成時(shí)，我們下一步將進(jìn)入布局layout階段。
到目前為止，我們已經(jīng)計(jì)算了了那些可見的節(jié)點(diǎn)和他們的樣式，但我們還沒有計(jì)算他們?cè)谄聊簧洗_切的位置和大小，這就是布局階段，也被稱為“reflow”。
要計(jì)算出每一個(gè)對(duì)象確切的位置和大小，瀏覽器從render tree的根部開始，經(jīng)過節(jié)點(diǎn)。讓我們考慮一下這個(gè)簡單的例子：
<html>
<head>
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Critial Path: Hello world!</title>
</head>
<body>
<div style="width: 50%">
<div style="width: 50%">Hello world!</div>
</div>
</body>
</html>
在上面的網(wǎng)頁中，body包含兩個(gè)嵌套的div：第一個(gè)div將節(jié)點(diǎn)的寬度設(shè)置為整個(gè)界面的50%，第二個(gè)節(jié)點(diǎn)，將節(jié)點(diǎn)寬度設(shè)成其父節(jié)點(diǎn)的50%，也就是整個(gè)界面的25%。
布局過程的輸出結(jié)果是一個(gè)盒模型，能夠精準(zhǔn)的在界面中體現(xiàn)每一個(gè)元素確切的位置和大小，所有相對(duì)的度量方式都會(huì)被轉(zhuǎn)換成像素表示。
最后，現(xiàn)在我們知道哪一個(gè)節(jié)點(diǎn)是可見的，還有他們的樣式以及幾何構(gòu)成，我們可以將這些信息傳給最后的階段，這個(gè)階段將會(huì)把這些把render tree 上的節(jié)點(diǎn)轉(zhuǎn)化成真正的圖像。這一階段經(jīng)常被稱為“painting”或“rasterizing”。
瀏覽器會(huì)花一些時(shí)間去做這些工作。然而，chrome 開發(fā)工具會(huì)提供一些關(guān)于上面三個(gè)階段的原理。讓我們看一下例子“hello world”的layout布局階段：
- 在時(shí)間線上，我們可以看到layout事件捕獲了render tree的結(jié)構(gòu)，位置和大小在時(shí)間線上。
- 當(dāng)layout完成時(shí)，瀏覽器開始了“paint setup”和“paint”事件，將渲染樹render tree轉(zhuǎn)化成圖像。
執(zhí)行渲染樹的結(jié)構(gòu)，布局和paint所花的時(shí)間會(huì)由于文件大小，所設(shè)置樣式的不同而不同，越大的文件和越復(fù)雜的樣式，所花的時(shí)間越多（如：一個(gè)純色是很好畫的，而一個(gè)陰影需要更多的時(shí)間）。
最終網(wǎng)頁出項(xiàng)在屏幕上：
我們?cè)俸唵位貞浺幌聻g覽器的步驟：
- 處理html，構(gòu)建DOM樹。
- 處理css，構(gòu)建CSSOM樹。
- 結(jié)合DOM和CSSOM構(gòu)成渲染樹render tree。
- 開始布局，計(jì)算每個(gè)節(jié)點(diǎn)的幾何結(jié)構(gòu)。
- paint，畫出每個(gè)節(jié)點(diǎn)。
我們的演示網(wǎng)頁看起來很簡單，但它也需要一些工作。無論DOM或CSSOM被改變，我們都必須重復(fù)以上過程，去計(jì)算出哪些圖像需要重新渲染。
**Optimizing the critical rendering path is the process of minimizing the total amount of time spent performing steps 1 through 5 in the above sequence. **Doing so renders content to the screen as quickly as possible and also reduces the amount of time between screen updates after the initial render; that is, achieve higher refresh rates for interactive content.
