web：從輸入URL到瀏覽器顯示頁面發生了什麼？如何優化？

時間 2019-11-16

標籤 web 輸入 url 瀏覽器顯示頁面發生了什麼如何優化欄目 HTML 简体版

原文原文鏈接

這個是個經典的前端/web工程師面試問題。css

總體流程

輸入 URL-》預處理（本地）-》查詢 DNS-》創建鏈接-》發送請求-》等待響應-》接收數據（網絡）-》讀取 Cache-》處理渲染（本地渲染）。html

優化思路

監控--》優化--》分析（閉環）前端

白屏時間：</header>結束
首屏時間：首屏圖片加載結束
用戶可操做時間：DOMReady / 核心JS加載完畢
加載完成：onload / 異步渲染完畢

網絡方向：減小請求次數 -減少請求體積 - 加快請求速度本地：減小DOM數量量web

優化方法

預處理 Expire/cache-control面試
查詢 DNS 減小DNS查詢次數、chrome
創建鏈接減小HTTP鏈接、避免跳轉、緩存 Ajax、延遲加載、預加載、使⽤CDN、配置ETags、使⽤Ajax GET、避免空 src 三、發送請求域名拆分、減小iframe數量、避免40四、減小Cookie大小、靜態域名不要帶 cookiesegmentfault
等待響應 gzip傳輸、儘早 flush、數組
接收數據（網絡）瀏覽器
讀取 Cache緩存
處理渲染（本地渲染）前端35條優化減小DOM數量和操做、置頂CSS、⽤<link>代替 @import、避免CSS表達式、避免使用 filters、、 js 置底、壓縮JS和CSS、使⽤用事件代理理。。。

APP

Hybrid -預取、預渲染 -模板本地化 -圖片緩存 -長鏈接、網絡探測 - 首屏時間可減小60%+
React Native -用Native View完成渲染 - 體驗大幅優化

流程處理

第一步：輸入 URL。

涉及概念： URL是統必定位資源符，URL有四種傳輸協議： 1.http—— 超文本傳輸協議 2.ftp—— 文件傳輸協議 3.file—— 主要用於訪問本地計算機中的文件 4.https——數據通過加密的超文本傳輸協議

第二步：查詢DNS。

DNS查詢是⽐比較耗時的⼀一個操做，爲何？？ TTL是 Time To Live的縮寫，該字段指定IP包被路由器丟棄以前容許經過的最大網段數量。

nslookup或者dig命令查看域名解析過程

nslookup www.baidu.com
Server:         172.22.~.~     --->返回的是本身的服務器
Address:        172.22.~.~#53      --->返回的是本身的IP

www.baidu.com   canonical name = www.a.shifen.com.    ----->域名別名記錄:別名(CName,Canonical Name)記錄
Name:   www.a.shifen.com    --->目標域名
Address: 220.181.112.244         --->目標返回的Ip
Name:   www.a.shifen.com    
Address: 220.181.111.188

dig www.baidu.com     

; <<>> DiG 9.8.3-P1 <<>> www.baidu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9163
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 5

;; QUESTION SECTION:
;www.baidu.com.                 IN      A

;; ANSWER SECTION:
www.baidu.com.          1200    IN      CNAME   www.a.shifen.com.
www.a.shifen.com.       92      IN      A       220.181.112.244
www.a.shifen.com.       92      IN      A       220.181.111.188

;; AUTHORITY SECTION:
a.shifen.com.           392     IN      NS      ns3.a.shifen.com.
a.shifen.com.           392     IN      NS      ns1.a.shifen.com.
a.shifen.com.           392     IN      NS      ns5.a.shifen.com.
a.shifen.com.           392     IN      NS      ns4.a.shifen.com.
a.shifen.com.           392     IN      NS      ns2.a.shifen.com.

;; ADDITIONAL SECTION:
ns1.a.shifen.com.       346     IN      A       61.135.165.224
ns2.a.shifen.com.       346     IN      A       180.149.133.241
ns3.a.shifen.com.       346     IN      A       61.135.162.215
ns4.a.shifen.com.       346     IN      A       115.239.210.176
ns5.a.shifen.com.       347     IN      A       119.75.222.17

;; Query time: 7 msec
;; SERVER: 172.22.1.253#53(172.22.1.253)
;; WHEN: Fri Nov 24 14:36:52 2017
;; MSG SIZE  rcvd: 260

衆所周知，DNS查詢過程當中的交互是採用UDP的。若是你但願採用TCP方式，需 dig +tcp www.baidu.com
dig很是著名的一個查詢選項就是+trace，當使用這個查詢選項後，dig會從根域查詢一直跟蹤直到查詢到最終結果，並將整個過程信息輸出出來。 dig +trace www.baidu.com

dig +trace www.moa.gov.cn

; <<>> DiG 9.8.3-P1 <<>> +trace www.moa.gov.cn
;; global options: +cmd
.                       165815  IN      NS      f.root-servers.net.     ---》'.'表明最高等級DNS服務器稱爲root
.                       165815  IN      NS      e.root-servers.net.
.                       165815  IN      NS      i.root-servers.net.
.                       165815  IN      NS      d.root-servers.net.
.                       165815  IN      NS      h.root-servers.net.
.                       165815  IN      NS      l.root-servers.net.
.                       165815  IN      NS      g.root-servers.net.
.                       165815  IN      NS      j.root-servers.net.
.                       165815  IN      NS      c.root-servers.net.
.                       165815  IN      NS      k.root-servers.net.
.                       165815  IN      NS      b.root-servers.net.
.                       165815  IN      NS      m.root-servers.net.
.                       165815  IN      NS      a.root-servers.net.
;; Received 492 bytes from 172.22.1.253#53(172.22.1.253) in 55 ms

cn.                     172800  IN      NS      a.dns.cn.    --------》遞歸查詢你去找cn.的DNS吧，它的IP是XXX.XXX.XXX.XXX，他負責管這部分的域名。
cn.                     172800  IN      NS      d.dns.cn.
cn.                     172800  IN      NS      e.dns.cn.
cn.                     172800  IN      NS      ns.cernet.net.
cn.                     172800  IN      NS      b.dns.cn.
cn.                     172800  IN      NS      c.dns.cn.
;; Received 295 bytes from 192.5.5.241#53(192.5.5.241) in 28 ms

moa.gov.cn.             86400   IN      NS      ns.agri.gov.cn.
moa.gov.cn.             86400   IN      NS      mdns.agri.gov.cn.
;; Received 105 bytes from 202.112.0.44#53(202.112.0.44) in 52 ms

www.moa.gov.cn.         3600    IN      CNAME   www.f5.moa.gov.cn.
www.f5.moa.gov.cn.      5       IN      A       202.127.45.114
;; Received 69 bytes from 202.127.45.1#53(202.127.45.1) in 18 ms

最後返回IP 202.127.45.114 ,

DNS 優化 DNS存在着多級緩存，從離瀏覽器的距離排序的話瀏覽器緩存，系統緩存，路由器緩存，IPS服務器緩存，根域名服務器緩存，頂級域名服務器緩存，主域名服務器緩存。

瀏覽器緩存：chrome://dns/
系統緩存主要存在/etc/hosts(Linux系統)中:

DNS負載均衡 DNS能夠返回一個合適的機器的IP給用戶，例如能夠根據每臺機器的負載量，該機器離用戶地理位置的距離等等，這種過程就是DNS負載均衡，又叫作DNS重定向。你們耳熟能詳的CDN(Content Delivery Network)就是利用DNS的重定向技術，DNS服務器會返回一個跟用戶最接近的點的IP地址給用戶，CDN節點的服務器負責響應用戶的請求，提供所需的內容。
DNS Prefetching X-DNS-Prefetch-Control 頭控制着瀏覽器的 DNS 預讀取功能。 DNS 預讀取是一項使瀏覽器主動去執行域名解析的功能，其範圍包括文檔的全部連接，不管是圖片的，CSS 的，仍是 JavaScript 等其餘用戶可以點擊的 URL。 http://www.jianshu.com/p/c3a14a853c79 https://developer.mozilla.org/zh-CN/docs/Controlling_DNS_prefetching

第三步：創建鏈接

TCP 握手 SYN，SYN ACK, ACK 慢啓動和流量控制

優化減小HTTP鏈接避免跳轉緩存 Ajax 延遲加載預加載

第四步：發送請求

http/https HTTPS在傳輸數據以前須要客戶端與服務器進行一個握手(TLS/SSL握手)，在握手過程當中將確立雙方加密傳輸數據的密碼信息。TLS/SSL使用了非對稱加密，對稱加密以及hash等。具體過程請參考經典的阮一峯先生的博客TLS/SSL握手過程。 HTTPS相比於HTTP，雖然提供了安全保證，可是勢必會帶來一些時間上的損耗，如握手和加密等過程，是否使用HTTPS須要根據具體狀況在安全和性能方面作出權衡。
http 請求發送HTTP請求的過程就是構建HTTP請求報文並經過TCP協議中發送到服務器指定端口(HTTP協議80/8080, HTTPS協議443)。HTTP請求報文是由三部分組成: 請求行, 請求報頭和請求正文。常見的請求報頭有: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization, Cookie, User-Agent等。

第五步：等待響應

http狀態碼是由3位數組成，第一個數字定義了響應的類別，且有五種可能取值:

1xx：指示信息–表示請求已接收，繼續處理。 2xx：成功–表示請求已被成功接收、理解、接受。 3xx：重定向–要完成請求必須進行更進一步的操做。 4xx：客戶端錯誤–請求有語法錯誤或請求沒法實現。 5xx：服務器端錯誤–服務器未能實現合法的請求。平時遇到比較常見的狀態碼有:200, 204, 301, 302, 304, 400, 401, 403, 404, 422, 500(分別表示什麼請自行查找)。

第六步：

第七步：處理渲染

現代瀏覽器渲染頁面

的過程是這樣的：解析HTML以構建DOM樹 –> 構建渲染樹 –> 佈局渲染樹 –> 繪製渲染樹。步驟詳細解釋：第一步：渲染引擎開始解析html，根據標籤構建DOM樹， DOM樹是由HTML文件中的標籤排列組成。第二步：根據css樣式構建渲染樹，包括元素的大小、顏色，隱藏的元素不會被構建到該樹中。渲染樹是在DOM樹中加入CSS或HTML中的style樣式而造成。渲染樹只包含須要顯示在頁面中的DOM元素，像<head>元素或display屬性值爲none的元素都不在渲染樹中。第三步：根據css樣式構建佈局樹，主要是肯定元素要顯示的位置。第四步：根據前面的信息，繪製渲染樹。

在瀏覽器還沒接收到完整的HTML文件時，它就開始渲染頁面了，在遇到外部鏈入的腳本標籤或樣式標籤或圖片時，會再次發送HTTP請求重複上述的步驟。在收到CSS文件後會對已經渲染的頁面從新渲染，加入它們應有的樣式，圖片文件加載完馬上顯示在相應位置。在這一過程當中可能會觸發頁面的重繪或重排。

涉及到兩個概念: reflow(迴流)和repain(重繪)。DOM節點中的各個元素都是以盒模型的形式存在，這些都須要瀏覽器去計算其位置和大小等，這個過程稱爲relow;當盒模型的位置,大小以及其餘屬性，如顏色,字體,等肯定下來以後，瀏覽器便開始繪製內容，這個過程稱爲repain。頁面在首次加載時必然會經歷reflow和repain。reflow和repain過程是很是消耗性能的，尤爲是在移動設備上，它會破壞用戶體驗，有時會形成頁面卡頓。因此咱們應該儘量少的減小reflow和repain。

不一樣的瀏覽器有不一樣的渲染引擎，對於渲染引擎的使用總結以下： Trident(MSHTML)內核：IE,MaxThon,TT,The World,360,搜狗瀏覽器等 Gecko內核：Netscape6及以上版本，FF,MozillaSuite/SeaMonkey等 Presto內核：Opera7及以上 Webkit內核：Safari,Chrome等

爲何要前端優化時，建議把 JS 文件放在最後？？

JS的解析是由瀏覽器中的JS解析引擎完成的。JS是單線程運行，也就是說，在同一個時間內只能作一件事，全部的任務都須要排隊，前一個任務結束，後一個任務才能開始。可是又存在某些任務比較耗時，如IO讀寫等，因此須要一種機制能夠先執行排在後面的任務，這就是：同步任務(synchronous)和異步任務(asynchronous)。JS的執行機制就能夠看作是一個主線程加上一個任務隊列(task queue)。同步任務就是放在主線程上執行的任務，異步任務是放在任務隊列中的任務。全部的同步任務在主線程上執行，造成一個執行棧;異步任務有了運行結果就會在任務隊列中放置一個事件；腳本運行時先依次運行執行棧，而後會從任務隊列裏提取事件，運行任務隊列中的任務，這個過程是不斷重複的，因此又叫作事件循環(Event loop)。

當文檔加載過程當中遇到JS文件，HTML文檔會掛起渲染過程，不只要等到文檔中JS文件加載完畢還要等待解析執行完畢，纔會繼續HTML的渲染過程。緣由是由於JS有可能修改DOM結構，這就意味着JS執行完成前，後續全部資源的下載是沒有必要的，這就是JS阻塞後續資源下載的根本緣由。CSS文件的加載不影響JS文件的加載，可是卻影響JS文件的執行。JS代碼執行前瀏覽器必須保證CSS文件已經下載並加載完畢。

http://www.javashuo.com/article/p-kppakjuk-x.html

減小 dom事件緣由

利用 js 事件冒泡原理：在一個對象上觸發某類事件（好比單擊onclick事件），若是此對象定義了此事件的處理程序，那麼此事件就會調用這個處理程序，若是沒有定義此事件處理程序或者事件返回true，那麼這個事件會向這個對象的父級對象傳播，從裏到外，直至它被處理（父級對象全部同類事件都將被激活），或者它到達了對象層次的最頂層，即document對象（有些瀏覽器是window）。