前幾天剛剛學完css，這兩天開始進軍js部分，看了一些老師們的操作視頻，有理論的，有展示的現象得到的一些結論的東西，第一遍看起來，其實很沒有感的，因為滿腦子都在引入概念，跟著老師走，自己其實在被動接受，也不敢自己跟著操作，怕跟不上節奏了，都怪自己是計算機界的一種小白了。所以心里發誓，有必要把c和Java好好下來研究研究了。廢話不多說，我第二遍看視頻，一遍看，一遍看代碼，思考，才有了感的。
瀏覽器的渲染機制
其實這個就是理論上的東西，最具有邏輯性了，所有很容易明白，理解，就算是拿來主義，也不可恥，因為本來就是如此，除非是作為一個瀏覽器開發者才會以此為恥的吧。
記得學HTML時，也有一個機制攻略的，那個就是從URL輸入到瀏覽器展示頁面的一個總體的思路過程了，資料可回顧參考《初學從url到展示網頁的感官》，這個過程里的其中一部分就是現在要講的瀏覽器渲染機制了。當時只是總攬全局，并且在邏輯上明白了一個思路，現在學到這里，我們需要細細拿出這 其中一部分，好好地品味下內在的想法如何實現的。
具體思路：瀏覽器發出請求，服務器收到后，回復給html文件，瀏覽器接收并解析：解析到css文件，發請求要css文件；解析到js文件，發請求要js文件。
html文件在第一時間解析完成，在瀏覽器的邏輯下，生成DOM樹。
同時，接收到css文件后，解析，生成cssOM樹，也就是樣式樹。
然后兩棵樹互相聯系作用，一個是角色，一個是角色的各種屬性，搭配起來，形成了一顆渲染樹，這棵樹也是存在于瀏覽器機制的邏輯里的，只是為了讓人更明白，所有，我覺得把這個理念概念化語義化了哦。
然后瀏覽器通過渲染樹，對各個節點標簽進行布局計算，計算完了，就開始畫畫，畫好了就顯示成頁面了。
流程圖如下：
其實在這里，我就感到奇怪了，比如js文件呢？還有實際操作的話，這個理論的應用層面在瀏覽器上會有什么樣的現象和問題？這就是我下面想要說的，不過我才疏學淺，時間很緊，只能把一些現象說出來，具體的一些結論，我能查出根據的會覺得會好，模凌兩可的只能作為自己的猜想了。說真的，瀏覽器其實原理一樣，但是耐不住開發人員的牛脾氣，所以，原理僅僅是在開發人員眼里的一條讓普通人更容易明白的小路而已，實際上，各種開發權限讓瀏覽器很搞怪，有時候讓你覺得，跟所學的知識相悖，根本沒有什么大一統的結論啊，比如，說js文件一加載就立刻執行，然后出來了一個異步加載；谷歌瀏覽器是白屏的效果，可為啥火狐的是閃爍了？反正，明白一句話，實踐出真知，越認識到錯誤，越接近真實，好比小學里0是最小的，那是對的，到初中你再說就錯了。
css文檔流的分析
首先css文件，這個研究對象，起初啊，第一次跟著老師走的時候，是蒙的，沒有思路，只是跟著他走，模仿他的思路，分析方法，現象驗證，總結，這一套路吧，那時候憋屈啊，自己討厭自己沒思路，聽得云里霧里的，只是記錄了一些所謂的結論和感官，以及對研究對象的一種很深很厭惡的感官了。第二遍看視頻，對照著代碼，才能有自己的思路，而且有點成就感的是，對老師最后的幾個現象反而得不出大一統的結論想到了一些東西，心里還是比較滿足的。
我按我的猜想走吧。
這個研究對象啊，在html中css的位置有兩個，一個在head中，一個在body里。在這里，我先對css的添加樣式做個說明，不管是外部鏈接還是內部的，還是幾乎廢棄的在html標簽里寫的，首先直接說最優的就是內部的，不用在發請求像外部的要文件了，加載快，省事。拋去這個因素，再從位置入手。
先說一下，大一統的結論，從老師的代碼實驗中得到了，一個HTML文件，幾乎所有的css文件都是同時開始加載的，不論位置。當然，除去幾乎要費了的那種在html標簽里寫的css,不是說它不適合或適合，只是說它沒法證明。
在head里的css，最明了，簡單。這里的css文件是全部加載完成后才開始執行，而且伴隨著執行，html的內容開始出現，符合渲染樹的步驟。
其實，我比較喜歡放這里，覺得很區塊化，而且，確實效果上很好的。
在body里的css文件，加載時遵循順序，而無論上下方是何種html標簽，都會在它們之后執行，谷歌嘛。但是關于圖片的加載時機的影響，這是我看到代碼實驗的一種猜想，僅僅限于谷歌瀏覽器上，尤其是當css上面或者下面有圖片或其他加載數據大時，影響會很明顯，圖片會顯得不受css文件影響一樣，該加載就加載。這里有一個因素是js文檔在head部時產生的阻礙作用，圖片會在所有css文件執行后加載，而把阻礙的js移到body底部時，圖片就好像不受css文件影響一樣，該加載就加載，也不等css文件了。
反正，對于研究加載的話，顯得很蒼白，特立獨行的是js文件，最具主動性，它只會影響HTML和css，而自身不受它們影響。css加載幾乎是同時加載的，它影響html的一些元素如圖片的加載時機的。執行的話，就比較簡單了，js文件加載后立即執行，css文件一個一個地執行，這里非要針對影響的話，我又查了下資料，貌似跟請求有關——
css文件的下載和渲染是同步的嗎? 還是先下載完, 再渲染?
不確定下載過程中是否同步做詞法分析parseCss，但是可能性很大，畢竟是種無損失的優化方案，但是最終肯定需要下載完再layout生成渲染樹，進而渲染。
css文件的下載&執行 和 html文件的下載&執行同步嗎?
并行的。但是需要注意一些限制，比如一個域名下最大并發6個請求，再多就得串行。
圖形的加載 和 html文件的下載/執行同步嗎, 音視頻呢, 別的資源呢?
同上。
有沒有可能出現html文件/圖片/css文件/js文件同時下載的情況?
常態。
有沒有可能出現html/css文件/js文件同時執行的情況?
html parse和css parse是并行的，兩者完成后才會layout、paint，新的css掛載會延遲layout、paint。js parse會阻塞html parse ，所以后面的layout、paint一定不會同時執行。
作者：錢多多
鏈接：https://www.zhihu.com/question/59024365/answer/161615976
來源：知乎
然后，再說說無樣式加載，白屏，閃爍現象——這是瀏覽器加載與顯示頁面方式不同造成的。
谷歌呢是當發現<link rel ="stylesheet"> 后立即停止渲染，在所有css加載完成之前頁面上不會有任何內容，所有白屏了?；鸷赜幸馑剂?，:<head>標簽中的<link rel ="stylesheet">與Chrome和Safari中完全一致，這些link標簽全部加載完之前，頁面上不顯示任何內容，而<body>中的內容則不阻塞任何內容顯示，也就是說，放<body>內，先渲染沒有樣式的，再渲染有樣式的。
repaint和reflow
- 簡介
repaint主要是針對某一個DOM元素進行的重繪，reflow則是回流，針對整個頁面的重排。字面意思來說：repaint就是重繪，reflow就是回流。repaint和reflow的目的是：展示一個新的頁面樣貌。 - 觸發
reflow是只要涉及到頁面排版和布局變動的，元素本身布局變動，style變化，就會觸發，而且功耗很大。repaint是除了上述情況之外，還有就是標簽本身的屬性渲染發生變化，顯示效果不一樣時，也會觸發，比如顏色變化，不過功耗小得多。 - 避免功耗問題
能不改就不改，盡量避免reflow，這就是想法了。
比如說經常有些刷新的對象啊標簽啊，比如動畫效果，對象一變化，整個頁面就相當于刷新了，所以，變動影響最小的就是把對象搞成絕對定位，或其他，反正脫離文檔流就行，并且如動畫一類的可控變化，讓變化頻率變小。
多用class選擇器，減少計算的量，精簡css的邏輯量，然后從這個角度入手，就是想辦法把css樹結構變得小巧，所以DOM元素能不用css的就不用，所以減少外部鏈接引入css文件。
說了這么多，都是跟css有關的，心里有點意思的，莫名其妙哦，這可是在學js??！只能說明，學css時，自己太蠢，僅僅當成了靜態頁面，給它們化妝打扮了，自以為可以為所欲為，可是站在更廣闊的大局觀，看到的風景卻是很不一樣的。這里的css里的東西，我其實偷懶了，時間關系，根本沒有自己把實例一一展示，我僅僅是通過視頻里的代碼展示推出了一些猜想，并自覺地認為，這僅僅是一個谷歌瀏覽器啊，那IE，火狐等等其他的呢？難道都要一一驗證？我暫時沒有時間了，只能說這個是未完結版，待續，，，
js文件的分析
終于到了新鮮貨了哦。不過js文件其實算是比較有原則的吧，畢竟它是為了實現功能和效果的，相比前兩者來說，卻是有些特立獨行。相比于如今的寬帶，研究白屏或者內容閃爍，比較無聊在于，幾乎沒有這種顯示體驗了，研究的意義在于，哦，讓我明白瀏覽器的渲染邏輯的更清晰化更具有邏輯，出來了一種現象，哦，我可以解釋，我懂得！所有我覺得我是前端工程師！包括js文件在整個運行過程中的位置，我還是有必要說說滴。
js文件的研究，就不那么俗套了，直接說位置放在head和body中 的情況吧。
先說，一般情況下，大一統的結論就是，加載了js文件，立刻執行，所以會阻礙后面的文件的執行，也會阻礙后面的內容的展示的。所以，一般情況下，都會把這個家伙放到body的最后，反正它就是個功能效果，對頁面的顯示體驗影響不大，那就先讓頁面顯示出來，最后再加載頁面的功能效果。并且js文件有作用元素，如果元素還沒出來，js先執行了，就會報錯。
如果放head里，不用說了，按標簽順序來，到了它這里，開始加載，加載的話不會影響其他哥們的加載，但是加載 完了，就立刻執行，執行時，它下面的css不能執行，html內容不能展示的。
在body里的js文件嗯，一般來說，應該也是跟head里的差不多的，但是偏偏有特例，嗯，在谷歌里，body里的js文件，有一個很有意思的現象，所以不是結論，視頻里老師稱之為谷歌的自己的優化——body里的js文件的first child，嗯就是大兒子的意思，有特殊待遇，在比其他的js兄弟們更早地加載執行，如何更早？幾乎相當于html解析到它這里時，做了個停頓，判斷處理，一秒左右，就開始加載了，這不算特殊。從除了它之外，其他的兄弟們受到隊伍前面的css文件執行的阻礙，前面的執行完了，它們才開始加載，所以大兒子是個異類。
然后，說到底，研究js如果太鉆牛角尖到具體的加載時機上，其實太復雜了，這僅僅是一個谷歌，還是那句話，不是瀏覽器開發者，就不懂得制定規則，只能按規則來，但是一個開發者一個規則，亂七八糟的，對初學者甚至于僅僅是個前端層次的大局來說，很無力，尤其是現在網速如此發達了，我們應該更關注于一些最基本的運行原理，比如js的阻礙效果，如何優化？做到看到現象，能夠模擬，解析出來邏輯，就可以了，哪里有那么多大一統的總結？
異步加載
defer 和 async
避免js文件的加載和執行擋路，于是有兩個屬性。
defer 和 async 在網絡讀取（下載）這塊兒是一樣的，都是異步的（相較于 HTML 解析）。
它倆的差別在于腳本下載完之后何時執行，顯然 defer 是最接近我們對于應用腳本加載和執行的要求的。
關于 defer，它是按照加載順序執行腳本的，這一點要善加利用。
async 則是一個亂序執行的主，反正對它來說腳本的加載和執行是緊緊挨著的，所以不管你聲明的順序如何，只要它加載完了就會立刻執行。
仔細想想，async 對于應用腳本的用處不大，因為它完全不考慮依賴（哪怕是最低級的順序執行），不過它對于那些可以不依賴任何腳本或不被任何腳本依賴的腳本來說卻是非常合適的，最典型的例子：網頁的廣告。
此處拿來主義《defer和async的區別》。
