一篇文章搞定前端面試

本文旨在用最通俗的語(yǔ)言講述最枯燥的基本知識(shí)

面試過前端的老鐵都知道對(duì)于前端面試官喜歡一開始先問些HTML5新增元素啊特性啊或者是js閉包啊原型啊或者是css垂直水平居中怎么實(shí)現(xiàn)啊之類的基礎(chǔ)問題當(dāng)你能倒背如流的回答這些之后面試官臉上會(huì)劃過一絲詭異的笑容然后晴轉(zhuǎn)多云故作深沉的清一下嗓子問**從用戶輸入U(xiǎn)RL到瀏覽器呈現(xiàn)頁(yè)面經(jīng)過了哪些過程**如果你懂巴拉巴拉回答了一堆他又接著問**那網(wǎng)頁(yè)具體是如何渲染出來(lái)的呢**如果你還懂又巴拉巴拉的回答了一堆他還會(huì)繼續(xù)問**那你有哪些網(wǎng)頁(yè)性能優(yōu)化的經(jīng)驗(yàn)?zāi)?*當(dāng)你還能巴拉巴拉的回答了一堆之后面試官這下心里就有逼數(shù)了轉(zhuǎn)而去問你一些和技術(shù)無(wú)關(guān)的七大姑八大姨之類的事情這時(shí)候你就可以歡呼你的offer基本已經(jīng)到手了。

那么各位問題來(lái)了真正輪到你去面試的時(shí)候 你能否很好的回到這些問題呢

用戶輸入U(xiǎn)RL回車之后瀏覽器到底做了啥

頁(yè)面渲染的完整流程是怎樣的

前端性能優(yōu)化有哪些經(jīng)驗(yàn)

如果不能那我們往下走?有人會(huì)疑惑說(shuō)不是講前端嗎為毛要講TCP、DNS這些與前端無(wú)關(guān)的知識(shí)?別慌咯跟著文章走吧多學(xué)無(wú)害

文章提綱 1. TCP 2. UDP 3. 套接字socket 4. HTTP協(xié)議 5. DNS解析 6. HTTP請(qǐng)求發(fā)起和響應(yīng) 7. 頁(yè)面渲染的過程 8. 頁(yè)面的性能優(yōu)化

TCP連接

TCPTransmission Control Protocol 傳輸控制協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。 說(shuō)的這么專業(yè)有啥用呢 先來(lái)舉個(gè)栗子吧 還記得小時(shí)候我們做的紙杯電話么兩個(gè)紙杯用一條繩子連到一起兩個(gè)各拿一個(gè)紙杯把線拉直一個(gè)對(duì)著紙杯講一個(gè)用耳朵對(duì)著紙杯聽。

這其實(shí)就是一種最簡(jiǎn)單的連接通信兩人通過一根線連接起來(lái)聲音從這邊的紙杯發(fā)出通過線傳輸?shù)搅硪粋€(gè)紙杯接收擴(kuò)展到現(xiàn)在家家戶戶都有的固定電話也是如此它的通信也是建立在雙方可接受并且信任的基礎(chǔ)上進(jìn)行如

A拿起電話撥通0775-6532122開始呼叫B

B聽到電話聲響起拿起電話此時(shí)A收到B已經(jīng)拿起電話的聲音

雙方開始講話。

回到我們的tcp協(xié)議其實(shí)它和上面所說(shuō)的電話協(xié)議差不多只不過電話的協(xié)議是服務(wù)于電話通信而tcp是服務(wù)于網(wǎng)絡(luò)通訊的一種協(xié)議類似的通訊雙方建立一次tcp連接也需要經(jīng)過三個(gè)步驟握手。

客戶端發(fā)送syn包(syn=j)到服務(wù)器并進(jìn)入SYN_SEND狀態(tài)等待服務(wù)器確認(rèn)。

服務(wù)器收到syn包必須確認(rèn)客戶的SYNack=j+1同時(shí)自己也發(fā)送一個(gè)SYN包syn=k即SYN+ACK包此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)。

客戶端收到服務(wù)器的SYNACK包向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)此包發(fā)送完畢客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)完成三次握手。

上面幾個(gè)唧唧歪歪的英文看的有點(diǎn)懵逼翻譯一下吧?(大家最好記一下這些狀態(tài)碼在服務(wù)器連接數(shù)的性能優(yōu)化中會(huì)經(jīng)常用到)

SYN:synchronous 建立聯(lián)機(jī) ACK:acknowledgement 確認(rèn) SYN_SENT:請(qǐng)求連接

SYN_RECV:服務(wù)端被動(dòng)打開后,接收到了客戶端的SYN并且發(fā)送了ACK時(shí)的狀態(tài)。再進(jìn)一步接收到客戶端的ACK就進(jìn)入ESTABLISHED狀態(tài)。

值得注意的是tcp在握手過程中并不攜帶數(shù)據(jù)(就像你打電話給酒店訂房時(shí)在確認(rèn)對(duì)方是酒店客服人員之前你也不會(huì)馬上把身份證號(hào)***給他吧)而是在三次握手完成之后才會(huì)進(jìn)行數(shù)據(jù)傳送。

至于它的應(yīng)用場(chǎng)景其實(shí)是根據(jù)它本身的特點(diǎn)而定的比如對(duì)網(wǎng)絡(luò)通訊質(zhì)量有要求需要保證數(shù)據(jù)準(zhǔn)確性時(shí)就需要用到TCP協(xié)議了如HTTP、ftp等文件傳輸協(xié)議、或一些郵件傳輸協(xié)議SMTP、pop等

UDP協(xié)議

(UDP協(xié)議并非本文需要重點(diǎn)著筆的內(nèi)容但是講到TCP了作為他的互補(bǔ)兄弟在此掠過一筆)

UDP?User Datagram Protocol 用戶數(shù)據(jù)報(bào)協(xié)議 相比于TCP的面向連接需要反復(fù)確認(rèn)的繁瑣步驟UDP是一中性格特立獨(dú)行并且主觀性超強(qiáng)的非面向連接的協(xié)議使用udp協(xié)議經(jīng)常通信并不需要建立連接它只是負(fù)責(zé)把數(shù)據(jù)盡可能快的發(fā)送出去簡(jiǎn)單粗暴并且不可靠而在接收端UDP把每個(gè)消息斷放入隊(duì)列中接收端程序從隊(duì)列中讀取數(shù)據(jù)。

有人會(huì)說(shuō)UDP協(xié)議這么不可靠為啥還會(huì)造出來(lái)呢 話說(shuō)回來(lái)天底下沒有無(wú)用之人只有你不懂用的人而已雖然UDP不可靠但是它的傳輸速度快效率高在一些對(duì)數(shù)據(jù)準(zhǔn)確性要求不高的場(chǎng)景UDP就變得很有用了比如qq語(yǔ)音、qq視頻。

套接字socket

為什么要說(shuō)嵌套字 那是因?yàn)榫拖袂懊嬲f(shuō)的TCP或UDP都是一種協(xié)議也就是計(jì)算機(jī)網(wǎng)絡(luò)通信中在傳輸層的一種協(xié)議簡(jiǎn)單地說(shuō)就是一種約定就像合作雙方的合同一樣然后合同是死的只有履行合同才是實(shí)質(zhì)性的行動(dòng)因此無(wú)論是TCP還是UDP要產(chǎn)生作用都需要有實(shí)際的行為去執(zhí)行才能體現(xiàn)協(xié)議的作用 那么有什么辦法讓這些協(xié)議作用呢 這就要說(shuō)到socket了。

socket也叫嵌套字 是一組實(shí)現(xiàn)TCP/UDP通信的接口API也就是說(shuō)無(wú)論TCP還是UDP通過對(duì)scoket的編程都可以實(shí)現(xiàn)TCP/UCP通信作為一個(gè)通信鏈的句柄它包含網(wǎng)絡(luò)通信必備的5種信息

連接使用的協(xié)議

本地主機(jī)的IP地址

本地進(jìn)程的協(xié)議端口

遠(yuǎn)地主機(jī)的IP地址

遠(yuǎn)地進(jìn)程的協(xié)議端口

可見socket包含了通信本方和對(duì)方的ip和端口以及連接使用的協(xié)議TCP/UDP。通信雙方中的一方暫稱客戶端通過scoket嵌套字對(duì)另一方暫稱服務(wù)端發(fā)起連接請(qǐng)求服務(wù)端在網(wǎng)絡(luò)上監(jiān)聽請(qǐng)求當(dāng)收到客戶端發(fā)來(lái)的請(qǐng)求之后根據(jù)socket里攜帶的信息定位到客戶端就相應(yīng)請(qǐng)求把socket描述發(fā)給客戶端雙方確認(rèn)之后連接就建立了。 因此套接字之間的連接過程有三個(gè)步驟

服務(wù)器監(jiān)聽:服務(wù)器實(shí)時(shí)監(jiān)控網(wǎng)絡(luò)狀態(tài)等待客戶端發(fā)來(lái)的連接請(qǐng)求

客戶端請(qǐng)求:客戶端根據(jù)遠(yuǎn)程主機(jī)服務(wù)器的IP地址和協(xié)議端口向其發(fā)起連接請(qǐng)求

連接確認(rèn):服務(wù)端收到套接字的連接請(qǐng)求之后就響應(yīng)請(qǐng)求把服務(wù)端套接字描述發(fā)給客戶端客戶端收到后一旦確認(rèn)則雙方建立連接進(jìn)行數(shù)據(jù)交互。

通常情況下socket連接就是TCP連接因此socket連接一旦建立,通訊雙方開始互發(fā)數(shù)據(jù)進(jìn)行通信直到其中一方或雙方斷開連接為止。

socket在即時(shí)通訊qq等各種聊天軟件等應(yīng)用上應(yīng)用廣泛。

HTTP協(xié)議

HTTP協(xié)議Hypertext Transfer Protocol 也叫超文本傳送協(xié)議 它是一種基于TCP/IP協(xié)議棧、在表示層和應(yīng)用層上的協(xié)議TCP在傳輸層的協(xié)議通俗一點(diǎn)說(shuō)就是

TCP/IP是位于傳輸層上的一種協(xié)議用于在網(wǎng)絡(luò)中傳輸數(shù)據(jù)

HTTP協(xié)議是應(yīng)用層協(xié)議基于TCP協(xié)議用于包裝數(shù)據(jù)程序使用它進(jìn)行通信可以簡(jiǎn)單高效的處理通信中數(shù)據(jù)的傳輸和識(shí)別處理

而在現(xiàn)在應(yīng)用非常廣泛的HTTP連接則是建立在HTTP協(xié)議上的、處于應(yīng)用層中的一種具體應(yīng)用。 上面說(shuō)到socket連接一旦建立就保持連接狀態(tài)而HTTP連接則不一樣它基于tcp協(xié)議的短連接也就是客戶端發(fā)起請(qǐng)求服務(wù)器響應(yīng)請(qǐng)求之后連接就會(huì)自動(dòng)斷開不會(huì)一直保持。

URL

前面講了tcp、udp、http...等等都是為了講一個(gè)具體問題而做的知識(shí)點(diǎn)鋪墊那就是我們開發(fā)的web應(yīng)用中請(qǐng)求的發(fā)起和響應(yīng)是一個(gè)怎樣的底層原理。?我們都知道web應(yīng)用絕大部分都是通過HTTP來(lái)進(jìn)行請(qǐng)求的而URL則是HTTP用來(lái)做連接建立和傳輸數(shù)據(jù)的一種具體實(shí)現(xiàn)因此在此要簡(jiǎn)單講一下URL。

URLUniform Resource Locator 統(tǒng)一資源定位符。說(shuō)白了就是網(wǎng)絡(luò)上用來(lái)標(biāo)識(shí)具體資源的一個(gè)地址包含了用戶查找該資源的信息HTTP使用它來(lái)傳輸數(shù)據(jù)和建立連接 一個(gè)URL有以下組成部分

協(xié)議

服務(wù)器地址域名或IP+端口

路徑

文件名

比如https://www.baidu.com/index.html 其中

https://是一種協(xié)議 當(dāng)然HTTP也是 ftp也是...

www.baidu.com是服務(wù)器地址當(dāng)然你知道百度的IP也可以,例如我用ping命令得到百度的ip 14.215.177.39那么我可以用http://14.215.177.39打開百度

index.html包含了路徑和文件名當(dāng)然通常index.html是可以省略的所以你打開百度時(shí)并沒有看到這個(gè)。

DNS

DNS:Domain Name Server域名服務(wù)器。 是進(jìn)行域名(domain name)和與之相對(duì)應(yīng)的IP地址 (IP address)轉(zhuǎn)換的服務(wù)器。DNS中保存了一張域名(domain name)和與之相對(duì)應(yīng)的IP地址 (IP address)的表以解析消息的域名。 在平時(shí)我們進(jìn)行開發(fā)時(shí)后端提供的接口地址通常是有IP地址加上端口號(hào)8080什么鬼的組成的但是當(dāng)我們把網(wǎng)站發(fā)布出去時(shí)通常都需要把IP改成用域名。 為什么呢 你想想哦比如谷歌的地址是89.12.21.221:9090,百度的地址是132.21.33.221:8766。。。 這么一看你根本沒有欲望是記住這些亂七八糟的數(shù)字吧 但是域名就不一樣了比如谷歌的google.com百度的baidu.com 是不是一遍就記住了呢 所以為了處理這個(gè)問題就需要用域名去映射IP地址達(dá)到易記易用的目的。

因此當(dāng)用戶在瀏覽器輸入https://www.baidu.com回車時(shí)它經(jīng)歷了以下步驟

瀏覽器根據(jù)地址去本身緩存中查找dns解析記錄如果有則直接返回IP地址否則瀏覽器會(huì)查找操作系統(tǒng)中hosts文件是否有該域名的dns解析記錄如果有則返回。

如果瀏覽器緩存和操作系統(tǒng)hosts中均無(wú)該域名的dns解析記錄或者已經(jīng)過期此時(shí)就會(huì)向域名服務(wù)器發(fā)起請(qǐng)求來(lái)解析這個(gè)域名。

請(qǐng)求會(huì)先到LDNS本地域名服務(wù)器讓它來(lái)嘗試解析這個(gè)域名如果LDNS也解析不了則直接到根域名解析器請(qǐng)求解析

根域名服務(wù)器給LDNS返回一個(gè)所查詢余的主域名服務(wù)器gTLDServer地址。

此時(shí)LDNS再向上一步返回的gTLD服務(wù)器發(fā)起解析請(qǐng)求。

gTLD服務(wù)器接收到解析請(qǐng)求后查找并返回此域名對(duì)應(yīng)的Name Server域名服務(wù)器的地址這個(gè)Name Server通常就是你注冊(cè)的域名服務(wù)器比如阿里dns、騰訊dns等

Name Server域名服務(wù)器會(huì)查詢存儲(chǔ)的域名和IP的映射關(guān)系表正常情況下都根據(jù)域名得到目標(biāo)IP記錄連同一個(gè)TTL值返回給DNS Server域名服務(wù)器

返回該域名對(duì)應(yīng)的IP和TTL值Local DNS Server會(huì)緩存這個(gè)域名和IP的對(duì)應(yīng)關(guān)系緩存的時(shí)間有TTL值控制。

把解析的結(jié)果返回給用戶用戶根據(jù)TTL值緩存在本地系統(tǒng)緩存中域名解析過程結(jié)束。

HTTP請(qǐng)求發(fā)起和響應(yīng)

如果這篇文章的主題是網(wǎng)絡(luò)通信那到這里已經(jīng)可以告一段落了但今天我們要講的是web應(yīng)用中請(qǐng)求的發(fā)起和響應(yīng)以及頁(yè)面渲染的原理因此以上只是鋪墊。 在一個(gè)web程序開發(fā)中一般都有前端和后端之分前端負(fù)責(zé)向后端請(qǐng)求數(shù)據(jù)和展示頁(yè)面后端負(fù)責(zé)接收請(qǐng)求和做出響應(yīng)發(fā)回給前端他們之間的協(xié)作的橋梁是什么呢 是API API是什么不就是一個(gè)URL嗎 URL又是啥呢上面說(shuō)到就是HTTP連接的一種具體的載體 因此 無(wú)論對(duì)于前端或者是后端理解HTTP無(wú)論是對(duì)自身對(duì)編程的理解還是和同事協(xié)作都是好處大大的 下面根據(jù)上面各個(gè)知識(shí)點(diǎn)的理解我們來(lái)整理一下并解決一下上面提到的第一個(gè)問題?從用戶輸入U(xiǎn)RL到瀏覽器呈現(xiàn)給用戶頁(yè)面經(jīng)過了什么過程

用戶輸入U(xiǎn)RL瀏覽器獲取到URL

瀏覽器(應(yīng)用層)進(jìn)行DNS解析如果輸入的是IP地址此步驟省略

根據(jù)解析出的IP地址+端口瀏覽器應(yīng)用層發(fā)起HTTP請(qǐng)求請(qǐng)求中攜帶請(qǐng)求頭header也可細(xì)分為請(qǐng)求行和請(qǐng)求頭、請(qǐng)求體body

header包含?1. 請(qǐng)求的方法get、post、put.. 2. 協(xié)議http、https、ftp、sftp... 3. 目標(biāo)url具體的請(qǐng)求路徑已經(jīng)文件名 4. 一些必要信息緩存、cookie之類

body包含?1. 請(qǐng)求的內(nèi)容

請(qǐng)求到達(dá)傳輸層tcp協(xié)議為傳輸報(bào)文提供可靠的字節(jié)流傳輸服務(wù)它通過三次握手等手段來(lái)保證傳輸過程中的安全可靠。通過對(duì)大塊數(shù)據(jù)的分割成一個(gè)個(gè)報(bào)文段的方式提供給大量數(shù)據(jù)的便攜傳輸。

到網(wǎng)絡(luò)層 網(wǎng)絡(luò)層通過ARP尋址得到接收方的Mac地址IP協(xié)議把在傳輸層被分割成一個(gè)個(gè)數(shù)據(jù)包傳送接收方。

數(shù)據(jù)到達(dá)數(shù)據(jù)鏈路層請(qǐng)求階段完成

接收方在數(shù)據(jù)鏈路層收到數(shù)據(jù)包之后層層傳遞到應(yīng)用層接收方應(yīng)用程序就獲得到請(qǐng)求報(bào)文。

接收方收到發(fā)送方的HTTP請(qǐng)求之后進(jìn)行請(qǐng)求文件資源如HTML頁(yè)面的尋找并響應(yīng)報(bào)文

發(fā)送方收到響應(yīng)報(bào)文后如果報(bào)文中的狀態(tài)碼表示請(qǐng)求成功則接受返回的資源如HTML文件進(jìn)行頁(yè)面渲染。

頁(yè)面的渲染

當(dāng)一個(gè)請(qǐng)求的發(fā)起和響應(yīng)都完成之后瀏覽器就會(huì)收到響應(yīng)內(nèi)容但瀏覽器收到的是一串串的代碼或URL鏈接怎么把這些代碼轉(zhuǎn)化成用戶可以看得懂的界面呈現(xiàn)出來(lái)就是瀏覽器的工作了。 目前市場(chǎng)上的瀏覽器已經(jīng)不下百種各個(gè)瀏覽器根據(jù)內(nèi)核又可以分成幾大類每一類瀏覽器對(duì)頁(yè)面的渲染原理和過程有所差異。

但總的來(lái)說(shuō)各個(gè)瀏覽器渲染頁(yè)面都基本遵循如下圖的流程

圖中有幾處英文詞匯可能不好理解沒關(guān)系先做一下解釋

HTML parserHTML解析器其本質(zhì)是將HTML文本解釋成DOM tree。

CSS parserCSS解析器其本質(zhì)是講DOM中各元素對(duì)象加入樣式信息

JavaScript引擎專門處理JavaScript腳本的虛擬機(jī)其本質(zhì)是解析JS代碼并且把邏輯HTML和CSS的操作應(yīng)用到布局中從而按程序要的要求呈現(xiàn)相應(yīng)的結(jié)果

DOM tree:文檔對(duì)象模型樹也就是瀏覽器通過HTMLparser解析HTML頁(yè)面生成的HTML樹狀結(jié)構(gòu)以及相應(yīng)的接口。

render tree渲染樹也就是瀏覽器引擎通過DOM Tree和CSS Rule Tree構(gòu)建出來(lái)的一個(gè)樹狀結(jié)構(gòu)和dom tree不一樣的是它只有要最終呈現(xiàn)出來(lái)的內(nèi)容像或者帶有display:none的節(jié)點(diǎn)是不存在render tree中的。

layout也叫reflow 重排渲染中的一種行為。當(dāng)rendertree中任一節(jié)點(diǎn)的幾何尺寸發(fā)生改變了render tree都會(huì)重新布局。

repaint重繪渲染中的一種行為。render tree中任一元素樣式屬性幾何尺寸沒改變發(fā)生改變了render tree都會(huì)重新畫比如字體顏色、背景等變化。

所以根據(jù)關(guān)鍵詞匯的解釋以及順著流程圖的流程可以總結(jié)出瀏覽器解析渲染頁(yè)面主要包括以下過程

瀏覽器通過HTMLParser根據(jù)深度遍歷的原則把HTML解析成DOM Tree。

將CSS解析成CSS Rule TreeCSSOM Tree。

根據(jù)DOM樹和CSSOM樹來(lái)構(gòu)造render Tree。

layout根據(jù)得到的render tree來(lái)計(jì)算所有節(jié)點(diǎn)在屏幕的位置。

paint遍歷render樹并調(diào)用硬件圖形API來(lái)繪制每個(gè)節(jié)點(diǎn)。

前端性能優(yōu)化

對(duì)于頁(yè)面渲染基本上這樣就是一個(gè)的流程看完之后有沒有什么感覺在實(shí)際編碼中可以優(yōu)化的點(diǎn)呢沒有吧因?yàn)楹芏嗉?xì)節(jié)都沒有講述因此為了找到可優(yōu)化的點(diǎn)在此對(duì)頁(yè)面渲染過程的幾個(gè)關(guān)鍵步驟做一下陳述

上面講到HTML解析是瀏覽器的HTML解析器把HTML解析成dom tree而在解析過程瀏覽器根據(jù)HTML文件的結(jié)構(gòu)從上到下解析htmlHTML元素是以深度優(yōu)先的方式解析而script、link、style等標(biāo)簽會(huì)使解析過程產(chǎn)生阻塞阻塞的情況有

外部樣式會(huì)阻塞內(nèi)部腳本的執(zhí)行。

外部樣式與外部腳本并行加載但外部樣式會(huì)阻塞外部腳本執(zhí)行。

如果外部腳本帶有async屬性則外部腳本的加載與執(zhí)行不受外部樣式影響

如果link標(biāo)簽是動(dòng)態(tài)創(chuàng)建js生成不管有無(wú)async屬性都不會(huì)阻塞外部腳本的加載與執(zhí)行。

CSS Parser作用就是將很多個(gè)CSS文件中的樣式合并解析出具有樹形結(jié)構(gòu)Style Rules在對(duì)樣式解析的過程中默認(rèn)CSS選擇器是從右往左進(jìn)行解析的。至于為什么是從右到左而不是從左到右、也是不會(huì)從左到左... 下面舉個(gè)栗子來(lái)說(shuō)一下 假如現(xiàn)在有這樣的一個(gè)樣式:

#parent?.ch1?.dh1?{} .fh1?.ch1?.dh1{} .ah1?.ch1?.eh1?{} #parent?.fh1?{} .ch1?.dh1{}

我們來(lái)比較從左到右和從右到左兩種方式的結(jié)果從兩個(gè)圖的比較就可以看幾點(diǎn)

右邊的tree復(fù)雜度要比左邊的低

右邊的tree公用樣式重合度比左邊的低

右邊的tree從根開始的節(jié)點(diǎn)數(shù)要比左邊的少

可能光看這幾點(diǎn)沒看出什么問題但你要知道瀏覽器中的css解析器負(fù)責(zé)css的解析并為每個(gè)節(jié)點(diǎn)計(jì)算出樣式因此雖然css解析器要做的事情不多但要每個(gè)節(jié)點(diǎn)都要進(jìn)行遍歷查找計(jì)算計(jì)算量極大因此解析的方式是決定其性能的關(guān)鍵點(diǎn)。 就如

#parant?.a{} 和 .a{}

估計(jì)絕大多數(shù)人都會(huì)認(rèn)為前者要比后者性能更優(yōu)其實(shí)不然在解析過程中 #paran .a{}意味著css解析器要先找到#parent再找到他下面的.a所在節(jié)點(diǎn) 而后者可以直接定位到.a{}因此哪一種方式更優(yōu)顯而易見。

瀏覽器解析HTML時(shí)當(dāng)遇到 script標(biāo)簽就會(huì)立即解析腳本同時(shí)阻塞解析文檔直到腳本執(zhí)行完畢你可能問為什么要這樣設(shè)計(jì)明顯啊腳本的執(zhí)行是改變css和dom會(huì)造成render tree不停的重繪和重排的而當(dāng)script是引入外部js文件時(shí)會(huì)阻塞到j(luò)s文件下載完成并且執(zhí)行完成為止除非加了defer或者async屬性。腳本在解析過程中將對(duì)dom或css的操作解析出來(lái)加入到DOM Tree和cssom中。

把這些度講完之后對(duì)于性能優(yōu)化的點(diǎn)相信大家心里都有點(diǎn)X數(shù)了吧下面簡(jiǎn)單總結(jié)一下日常開發(fā)過程中常用的性能優(yōu)化的地方

優(yōu)化選擇器路徑健全的css選擇器固然是能讓開發(fā)看起來(lái)更清晰然后對(duì)于css的解析來(lái)說(shuō)卻是個(gè)很大的性能問題因此相比于 .a .b .c{} 更傾向于大家寫.c{}。

壓縮文件盡可能的壓縮你的css文件大小減少資源下載的負(fù)擔(dān)。

選擇器合并把有共同的屬性內(nèi)容的一系列選擇器組合到一起能壓縮空間和資源開銷

精準(zhǔn)樣式盡可能減少不必要的屬性設(shè)置比如你只要設(shè)置{padding-left:10px}的值,那就避免{padding:0 0 0 10px}這樣的寫法

雪碧圖在合理的地方把一些小的圖標(biāo)合并到一張圖中這樣所有的圖片只需要一次請(qǐng)求然后通過定位的方式獲取相應(yīng)的圖標(biāo)這樣能避免一個(gè)圖標(biāo)一次請(qǐng)求的資源浪費(fèi)。

避免通配符.a .b *{} 像這樣的選擇器根據(jù)從右到左的解析順序在解析過程中遇到通配符*回去遍歷整個(gè)dom的這樣性能問題就大大的了。

少用Float:Float在渲染時(shí)計(jì)算量比較大盡量減少使用。

0值去單位對(duì)于為0的值盡量不要加單位增加兼容性

盡可能把script標(biāo)簽放到body之后避免頁(yè)面需要等待js執(zhí)行完成之后dom才能繼續(xù)執(zhí)行最大程度保證頁(yè)面盡快的展示出來(lái)。

盡可能合并script代碼

css能干的事情盡量不要用JavaScript來(lái)干。畢竟JavaScript的解析執(zhí)行過于直接和粗暴而css效率更高。

盡可能壓縮的js文件減少資源下載的負(fù)擔(dān)

盡可能避免在js中逐條操作dom樣式盡可能預(yù)定義好css樣式然后通過改變樣式名來(lái)修改dom樣式這樣集中式的操作能減少reflow或repaint的次數(shù)。

盡可能少的在js中創(chuàng)建dom而是預(yù)先埋到HTML中用display:none來(lái)隱藏在js中按需調(diào)用減少js對(duì)dom的暴力操作。

避免再HTML中直接寫css代碼。

使用Viewport加速頁(yè)面的渲染。

使用語(yǔ)義化標(biāo)簽減少css的代碼增加可讀性和SEO。

減少標(biāo)簽的使用dom解析是一個(gè)大量遍歷的過程減少無(wú)必要的標(biāo)簽?zāi)芙档捅闅v的次數(shù)。

避免src、href等的值為空。

減少dns查詢的次數(shù)。

以上就是文章的所有內(nèi)容總的來(lái)說(shuō)入門的文章是領(lǐng)人入門進(jìn)階的文章帶人進(jìn)階就像Java的書會(huì)有入門教程和進(jìn)階教程一樣這個(gè)文章里邊寫的大部分知識(shí)點(diǎn)都是為了讓讀者對(duì)頁(yè)面請(qǐng)求和呈現(xiàn)有一個(gè)鋪墊和整體的認(rèn)知由于涉及的知識(shí)點(diǎn)過多每個(gè)知識(shí)點(diǎn)拎出來(lái)都可以寫一本書所以大家把本文作為一個(gè)引路文需要對(duì)某個(gè)知識(shí)點(diǎn)進(jìn)行深入研究時(shí)再找相關(guān)書籍研究不喜勿噴。

本文轉(zhuǎn)載自異步社區(qū)

Web應(yīng)用防火墻 WAF

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。