一、真實DOM和其解析流程？
瀏覽器渲染引擎工作流程都差不多，大致分爲5步，創建DOM樹——創建StyleRules——創建Render樹——佈局Layout——繪製Painting
第一步，用HTML分析器，分析HTML元素，構建一顆DOM樹(標記化和樹構建)。
第二步，用CSS分析器，分析CSS文件和元素上的inline樣式，生成頁面的樣式表。
第三步，將DOM樹和樣式表，關聯起來，構建一顆Render樹(這一過程又稱爲Attachment)。每個DOM節點都有attach方法，接受樣式信息，返回一個render對象(又名renderer)。這些render對象最終會被構建成一顆Render樹。
第四步，有了Render樹，瀏覽器開始佈局，爲每個Render樹上的節點確定一個在顯示屏上出現的精確座標。
第五步，Render樹和節點顯示座標都有了，就調用每個節點paint方法，把它們繪製出來。
DOM樹的構建是文檔加載完成開始的？構建DOM數是一個漸進過程，爲達到更好用戶體驗，渲染引擎會盡快將內容顯示在屏幕上。它不必等到整個HTML文檔解析完畢之後纔開始構建render數和佈局。
Render樹是DOM樹和CSSOM樹構建完畢纔開始構建的嗎？這三個過程在實際進行的時候又不是完全獨立，而是會有交叉。會造成一邊加載，一遍解析，一遍渲染的工作現象。
CSS的解析是從右往左逆向解析的(從DOM樹的下－上解析比上－下解析效率高)，嵌套標籤越多，解析越慢。
webkit渲染引擎工作流程
二、JS操作真實DOM的代價！
用我們傳統的開發模式，原生JS或JQ操作DOM時，瀏覽器會從構建DOM樹開始從頭到尾執行一遍流程。在一次操作中，我需要更新10個DOM節點，瀏覽器收到第一個DOM請求後並不知道還有9次更新操作，因此會馬上執行流程，最終執行10次。例如，第一次計算完，緊接着下一個DOM更新請求，這個節點的座標值就變了，前一次計算爲無用功。計算DOM節點座標值等都是白白浪費的性能。即使計算機硬件一直在迭代更新，操作DOM的代價仍舊是昂貴的，頻繁操作還是會出現頁面卡頓，影響用戶體驗。