建站
咨詢
售后
建站咨詢
新聞中心
此文主要講的事情是如何讓用戶快點(diǎn)看到首屏頁面，其主要影響因素是延遲和解析渲染耗時(shí)。有關(guān)安全部分其實(shí)也是優(yōu)化的一部分。我們著重說下網(wǎng)絡(luò)部分。
我們提供的服務(wù)有：網(wǎng)站設(shè)計(jì)制作、網(wǎng)站設(shè)計(jì)、微信公眾號(hào)開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、汾西ssl等。為成百上千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的汾西網(wǎng)站制作公司
大致過程：DNS域名解析、建立TCP連接、下載資源、解析頁面。文章描述的優(yōu)化會(huì)盡量限制在當(dāng)時(shí)的分析的過程下。
參考
- 《計(jì)算機(jī)網(wǎng)絡(luò)自頂向下方法》
- 《Web性能權(quán)威指南》
- 老生常談-從輸入url到頁面展示到底發(fā)生了什么
- what happens when you type in a URL in browser
- 從瀏覽器多進(jìn)程到JS單線程，JS運(yùn)行機(jī)制最全面的一次梳理
- DNS解析的過程是什么，求詳細(xì)的？
- 前端性能優(yōu)化***實(shí)踐
- 前端性能優(yōu)化-justjavac
- 瀏覽器的渲染：過程與原理
- 瀏覽器渲染過程與性能優(yōu)化
1.DNS域名解析
一般來講，我們輸入的url是域名，而為了識(shí)別一個(gè)實(shí)體，TCP/IP使用IP地址來唯一確定一臺(tái)主機(jī)到因特網(wǎng)的連接，DNS會(huì)幫助我們完成域名到IP地址映射的工作。以 www.aaa.com為例，解析過程大致如下：
過程
瀏覽器
瀏覽器查詢?yōu)g覽器緩存，沒有。
本機(jī)層
瀏覽器客戶端向系統(tǒng)詢問服務(wù)器IP地址，調(diào)用本機(jī)內(nèi)的DNS解析程序，檢查自己本地的hosts文件是否有這個(gè)域名映射關(guān)系，沒有。
查找本機(jī)的DNS解析器緩存，沒有。
路由器緩存
可能還存在路由器緩存這一層
本地DNS服務(wù)器
本機(jī)的DNS解析程序向本地的DNS服務(wù)器發(fā)起請(qǐng)求，一般為TCP/IP參數(shù)中設(shè)置的***DNS服務(wù)器，是知道IP地址的，一般會(huì)UDP協(xié)議。
本地DNS服務(wù)器查詢是否在本地區(qū)域文件中，沒有。
本地DNS服務(wù)器查詢DNS緩存中是否存在，沒有。
本地DNS服務(wù)器會(huì)根據(jù)是否設(shè)置轉(zhuǎn)發(fā)器判斷是向上一級(jí)DNS服務(wù)器（其解析規(guī)則同理）還是直接向根DNS服務(wù)器（知道根DNS服務(wù)器的IP地址）發(fā)送請(qǐng)求。
與DNS服務(wù)器
收到請(qǐng)求后，根DNS服務(wù)器并不直接解析地址，但是知道每個(gè)***域中的一臺(tái)服務(wù)器的地址（如 com域名服務(wù)器）。如果為迭代查詢方式，此***域DNS服務(wù)器的ip被返回給本地DNS服務(wù)器。
本地DNS服務(wù)器提取到***域DNS服務(wù)器信息后，會(huì)再向其發(fā)出請(qǐng)求。***域DNS服務(wù)器收到請(qǐng)求后，會(huì)先查詢自己的緩存，沒有，則將負(fù)責(zé)的二級(jí)域名服務(wù)器（如 aaa.com域名服務(wù)器）返回給本地DNS服務(wù)器，以此類推直到查到目標(biāo)域名的映射信息或查詢失敗。
查到映射信息后返回到本機(jī)，中間各層會(huì)進(jìn)行緩存。
查詢方式
- 遞歸方式：一路查下去中間不返回，得到最終結(jié)果才返回信息。
- 迭代方式：就是上面的本地DNS服務(wù)器與其他域名服務(wù)器直接的查詢方式，查到一個(gè)可能知道的服務(wù)器地址，將此地址返回，重新發(fā)送解析請(qǐng)求。
一般默認(rèn)的方式從本機(jī)到本地DNS服務(wù)器是遞歸，DNS服務(wù)器之間是迭代查詢。
優(yōu)化
當(dāng)然針對(duì)DNS的優(yōu)化就是減少DNS解析的時(shí)間，由于瀏覽器緩存機(jī)制的存在，我們只需要對(duì)***訪問進(jìn)行優(yōu)化（雖然我們現(xiàn)在只是請(qǐng)求了一個(gè)html文件，但是html文件里還會(huì)有我們后續(xù)要請(qǐng)求的css/js/img等），即適當(dāng)減少要解析的域名個(gè)數(shù)，考慮到其他優(yōu)化機(jī)制可以將頁面及頁面內(nèi)資源發(fā)布到2-4個(gè)域名上。
2.建立連接
TCP連接
好了，瀏覽器終于拿到服務(wù)器IP了，客戶端想要與服務(wù)器間通信并傳遞消息需要開啟TCP（一種傳輸層協(xié)議）連接。
過程：
- 客戶端創(chuàng)建socket，向服務(wù)器目標(biāo)端口發(fā)送連接建立請(qǐng)求，數(shù)據(jù)段包含位碼SYN（建立聯(lián)機(jī)標(biāo)志位） = 1，隨機(jī)數(shù)seq（順序號(hào)碼）= x，和其他TCP標(biāo)志和選項(xiàng)。
- 服務(wù)器有一個(gè)專門處理連接請(qǐng)求的welcome socket，接收到連接建立請(qǐng)求，置位碼SYN和ACK（確認(rèn)標(biāo)志位）為1，ack（確認(rèn)號(hào)碼）= x + 1，隨機(jī)數(shù)seq = y，并返回。
- 客戶端檢查ack是否等于x + 1，等于時(shí)，將ACK置為1，SYN置為0，將ack置為y + 1發(fā)送至服務(wù)器端。
- welcome socket檢查ack等于y + 1和ACK等于1后，創(chuàng)建新的socket，此socket由源IP/源端口、目標(biāo)IP/目標(biāo)端口標(biāo)識(shí)，之后客戶端發(fā)送的數(shù)據(jù)都被引導(dǎo)向此新的socket，至此，TCP連接建立。
簡(jiǎn)單來講：
- // client:
- send ({ SYN : 1 , seq : x , ... others })
- |
- ↓
- //server: send ({ SYN : 1 , ACK : 1 , ack : x + 1 , seq : y , ... others })
- |
- ↓
- //client: ack === x + 1 ? send ({ ACK : 1 , SYN : 0 , ack : y + 1 , ... others }) : 'hehe'
- |
- ↓
- //server: ack === y + 1 && ACK === 1 ? new Socket () : ''
SSL/TLS
如果啟用了HTTPS進(jìn)行加密，在使用TLS前還需要協(xié)商建立加密信道。
過程：
客戶端
TCP連接建立之后，再以純文本形式發(fā)送一些規(guī)格說明，隨機(jī)數(shù) Random1，TLS協(xié)議版本，支持的加密套件列表，支持或希望使用的其他TLS選項(xiàng)。
服務(wù)器
- 取得TLS協(xié)議版本以備將來通信使用，從客戶端提供的加密套件列表中選擇一個(gè)，生成隨機(jī)數(shù) Random2發(fā)送給客戶端；
- 附上自己的證書，將響應(yīng)發(fā)送給客戶端；
- 同時(shí)，也可發(fā)送一個(gè)請(qǐng)求，要求客戶端提供證書以及其他TLS擴(kuò)展參數(shù)。
客戶端
- 同上，可能會(huì)向服務(wù)器發(fā)送自己的證書。
- 客戶端收到服務(wù)器的證書后，通過證書鏈關(guān)系從根CA（證書的簽發(fā)機(jī)構(gòu)）驗(yàn)證證書的合法性，驗(yàn)證通過后取出證書中的服務(wù)器公鑰，生成隨機(jī)數(shù)Random3，再用服務(wù)器公鑰加密 Random3（pre master key），發(fā)送給服務(wù)器；
- 告訴服務(wù)器可以開始加密透明信了；
- 客戶端用 三個(gè)隨機(jī)數(shù)和 約定的加密方法生成 對(duì)話密鑰。將前面的握手信息生成完成摘要，使用 對(duì)話密鑰加密，發(fā)送告訴服務(wù)器我已完成握手。
除了服務(wù)器公鑰加密的新對(duì)稱密鑰外，所有的數(shù)據(jù)都是明文形式發(fā)送。
服務(wù)器
用私鑰解密出客戶端發(fā)來的隨機(jī)數(shù)，通過驗(yàn)證消息的MAC檢測(cè)消息完整性，用相同的方式生成 對(duì)話密鑰。
解密客戶端發(fā)送的完成報(bào)文，驗(yàn)證 對(duì)話密鑰是否正確。
- 告訴客戶端，要開始加密了；
- 同樣再返回給客戶端一個(gè)加密的完成消息。
客戶端用它之前生成的 對(duì)話密鑰解密這條消息，確定 對(duì)話密鑰是否正確，正確則建立信道并且開始發(fā)送應(yīng)用數(shù)據(jù)。
其中：
- 對(duì)話密鑰又可稱為 協(xié)商密鑰。
- 對(duì)話密鑰是對(duì)稱密鑰，對(duì)稱加解密速度很快。
- 服務(wù)器公鑰和私鑰是非對(duì)稱密鑰，非對(duì)稱加解密速度很慢。
- 使用非對(duì)稱加密生成可靠的對(duì)稱密鑰，使用對(duì)稱密鑰進(jìn)行后續(xù)數(shù)據(jù)的加密。
- 上述帶序號(hào)報(bào)文可能一次發(fā)送，也可能分次連續(xù)發(fā)送。
- SSL和TLS可以當(dāng)作一個(gè)東西。
- 服務(wù)器也可以不使用CA頒發(fā)的證書，而使用自己的證書。
優(yōu)化
我們要對(duì)TCP和SSL/TLS握手耗時(shí)進(jìn)行優(yōu)化。有以下幾個(gè)因素：
- 數(shù)據(jù)往返延遲：主要受地理位置影響，使用較近的服務(wù)器進(jìn)行數(shù)據(jù)傳輸會(huì)減少數(shù)據(jù)往返的時(shí)間，我們可以通過在不同的地區(qū)部署服務(wù)器（如：CDN，其也會(huì)用到DNS解析，可能在DNS解析階段就完成了對(duì)客戶端訪問域名到距離最近的服務(wù)器的映射），將數(shù)據(jù)放到接近客戶端的地方，可以減少網(wǎng)絡(luò)往返時(shí)間。
- 證書鏈：其實(shí)數(shù)據(jù)往返延遲優(yōu)化不只是針對(duì)TCP握手階段的，后續(xù)基于TCP的數(shù)據(jù)傳輸都會(huì)收益，如SSL/TLS握手和后續(xù)的請(qǐng)求響應(yīng)。那么證書鏈?zhǔn)怯绊慡SL/TLS握手的一個(gè)重要因素，證書鏈?zhǔn)欠?wù)器向客戶端發(fā)送的證書內(nèi)的信息，由站點(diǎn)證書、中間證書頒發(fā)機(jī)構(gòu)的證書、~~根證書~~組成（比較類似DNS域名解析服務(wù)器之間的關(guān)系）。
原因：
- TCP慢啟動(dòng)：由于TCP慢啟動(dòng)（為避免擁塞，TCP連接初始只能發(fā)送較少的分組，然后等待客戶端確認(rèn)，然后翻倍，經(jīng)過幾次往返直至到達(dá)閾值）和TLS/SSL握手?jǐn)?shù)據(jù)發(fā)送一般位于TCP連接慢啟動(dòng)階段的關(guān)系，證書數(shù)據(jù)過多會(huì)超過TCP連接的初始值，會(huì)造成數(shù)據(jù)往返次數(shù)的成倍增加。
- 證書鏈驗(yàn)證過長(zhǎng)：由于客戶端瀏覽器在驗(yàn)證證書可靠性時(shí)，會(huì)遞歸驗(yàn)證鏈條中的每個(gè)節(jié)點(diǎn)至根證書，也會(huì)增加握手時(shí)間。
方法：
- 減少中間證書頒發(fā)機(jī)構(gòu)的數(shù)量，優(yōu)化至只有站點(diǎn)證書和一個(gè)中間證書頒發(fā)機(jī)構(gòu)。
- 不要添加根證書信息，瀏覽器內(nèi)置信任名單中有根證書。
握手次數(shù)：前兩點(diǎn)優(yōu)化都是針對(duì)的握手時(shí)間的優(yōu)化，握手次數(shù)也是影響延遲的重要因素。我們?cè)诤竺嬲劦酱罅空?qǐng)求的時(shí)候再說這一點(diǎn)。
初始擁塞窗口：適當(dāng)增大初始擁塞窗口大小，即增大TCP連接初始可發(fā)送的分組大小。
3.獲得頁面響應(yīng)
重定向響應(yīng)
如果服務(wù)器返回了跳轉(zhuǎn)重定向（非緩存重定向），那么瀏覽器端就會(huì)向新的URL地址重新走一遍DNS解析和建立連接。
所以應(yīng)該避免不必要的重定向。
頁面資源響應(yīng)
在獲得了html響應(yīng)之后，瀏覽器開始解析頁面，進(jìn)入準(zhǔn)備渲染的階段。下載優(yōu)化同樣放在后面談到大量請(qǐng)求的時(shí)候再說這一點(diǎn)。
4.解析渲染頁面
我們需要將這個(gè)過程先分為兩個(gè)部分來看，頁面資源加載和渲染。
頁面資源加載
瀏覽器在解析頁面的過程中會(huì)去請(qǐng)求頁面中諸如js、css、img等外聯(lián)資源。
建立連接
同樣這些資源的加載也是需要建立TCP連接的，直接使用也需要進(jìn)行DNS解析和握手。
優(yōu)化
此處的請(qǐng)求次數(shù)與頻率相對(duì)于***次請(qǐng)求頁面資源時(shí)要高很多，所以這里著重闡述下成批量的請(qǐng)求的優(yōu)化。
瀏覽器目前使用的HTTP協(xié)議版本大多是1.1和2，二者有些不同，但是底層都是使用TCP進(jìn)行數(shù)據(jù)傳輸。由于TCP握手耗時(shí)，和SSL/TLS更加耗時(shí)，我們需要減少整個(gè)加載過程中需要建立的連接的次數(shù)和耗時(shí)。
復(fù)用：針對(duì)HTTP1.1的***方法是啟用長(zhǎng)連接：HTTP 1.1提供了默認(rèn)開啟長(zhǎng)連接功能，相對(duì)于短連接（每請(qǐng)求一個(gè)資源建立然后斷開一次TCP連接），同一客戶端socket（瀏覽器可能會(huì)開多個(gè)端口并行請(qǐng)求）針對(duì)同一socket(域名+端口)后續(xù)請(qǐng)求都會(huì)復(fù)用一個(gè)TCP連接進(jìn)行傳輸，直到關(guān)閉這個(gè)TCP連接。
加速：針對(duì)SSL/TLS握手有會(huì)話恢復(fù)機(jī)制，驗(yàn)證通過后，可以直接使用之前的對(duì)話密鑰，減少握手往返。
加載之前
在服務(wù)器返回響應(yīng)時(shí)，又存在幾種情況，如：服務(wù)器負(fù)載大，服務(wù)器宕機(jī)，無法及時(shí)或較快響應(yīng)請(qǐng)求，服務(wù)器地理位置過遠(yuǎn)或跨運(yùn)營商導(dǎo)致延遲很高。
優(yōu)化
這里跟建立連接部分的優(yōu)化其實(shí)是公用的，但是單純的正常建立連接消耗資源較少，所以我們?cè)谶@個(gè)再較完成的闡述一下。
- 增加帶寬：但是大部分情況下服務(wù)器帶寬并不是影響延遲的主要因素。
- 智能DNS解析：根據(jù)客戶端的IP地址，將域名解析為最近的或不跨運(yùn)營商的服務(wù)器的IP地址，解決地理位置和跨運(yùn)營商的延遲問題。
- CDN：使用某種分析方式根據(jù)節(jié)點(diǎn)服務(wù)器的地理位置、負(fù)載情況、資源匹配情況從遍布各地的節(jié)點(diǎn)服務(wù)器中找出最合適的靜態(tài)資源服務(wù)器。
- 負(fù)載均衡：使用DNS負(fù)載均衡、IP負(fù)載均衡、反向代理負(fù)載均衡等方式從一堆服務(wù)器（集群相同職責(zé)）或一組服務(wù)器（分布式職責(zé)區(qū)分）中選擇最合適的服務(wù)器處理請(qǐng)求。
- 這幾種技術(shù)可能是相互結(jié)合的，比如CDN會(huì)用到DNS智能解析和負(fù)載均衡等。
- 其中使用了跳轉(zhuǎn)重定向方式的會(huì)重新進(jìn)行DNS解析和握手，其中一部分優(yōu)化實(shí)際是在域名的DNS解析部分完成的。
開始加載
好了，服務(wù)器終于可以愉快的返回?cái)?shù)據(jù)了。
HTTP 1.1
過程：
- 雖然HTTP 1.1有長(zhǎng)連接，一個(gè)TCP連接可以用來請(qǐng)求多個(gè)資源，但是這些資源的下載是串行的，比如使用這個(gè)TCP通道請(qǐng)求1.css、2.css、1.js，只有在前者傳輸成功完整完成后才會(huì)進(jìn)行下一個(gè)的傳輸。
- 雖然瀏覽器一般會(huì)請(qǐng)求建立多個(gè)TCP連接（多個(gè)端口向服務(wù)器一個(gè)端口請(qǐng)求資源，新的TCP連接的建立會(huì)進(jìn)行新的握手），去并行的請(qǐng)求頁面資源加快整體的下載速度，然而對(duì)每個(gè)域名的并行連接是有數(shù)量限制的（保護(hù)服務(wù)器負(fù)載，并受主機(jī)端口限制），所以我們還是要進(jìn)行一些優(yōu)化。
優(yōu)化：
- 減少
- 減少頁面中需要發(fā)起的請(qǐng)求總數(shù)，如我們常規(guī)使用的代碼合并，雪碧圖（精靈圖/Sprite合并小圖標(biāo)），將圖片轉(zhuǎn)為base64寫入其他文件，避免空的img src屬性等。
- 切割拆分?jǐn)?shù)據(jù)，讓首屏數(shù)據(jù)優(yōu)先加載等。
- 增加：增加資源的分布域名，部署在不同域名下，“突破”瀏覽器并行連接限制（結(jié)合DNS部分，不易過于分散，且過多連接會(huì)共享帶寬，且移動(dòng)端的解析更加緩慢）。
HTTP 2
由于HTTP 2提供了多路復(fù)用的功能，基于二進(jìn)制數(shù)據(jù)幀和流的傳輸，使通過一個(gè)TCP連接進(jìn)行數(shù)據(jù)分散、亂序、并行傳輸成為現(xiàn)實(shí)，即我們所有的資源都可以通過一個(gè)TCP連接不阻塞的并行傳輸。
所以我們針對(duì)HTTP 1.1的減少請(qǐng)求數(shù)量所做的合并優(yōu)化、增加資源分布域名都成為了無效優(yōu)化，可以丟掉。同時(shí)由于文件不用合并，進(jìn)行文件更新時(shí)我們也不用再修改單個(gè)開發(fā)模塊更新所有（合并文件）模塊了。
加載中
總的來說是很簡(jiǎn)單的過程，客戶端接收服務(wù)器傳輸返回的響應(yīng)。
優(yōu)化
傳輸?shù)臄?shù)據(jù)大小越小，那么傳輸就越快，延遲就越小。
更?。?/p>
- Gzip：?jiǎn)⒂肎zip可對(duì)響應(yīng)體進(jìn)行壓縮，可減少70%大小的數(shù)據(jù)體積。
- 減少cookie：去除不必要的cookie，設(shè)置合適過期時(shí)間。
- 舍棄cookie：對(duì)于靜態(tài)文件請(qǐng)求我們可以不要cookie，即HTTP1.1中提到的，分布在其他域名下，子域名設(shè)置合理的domian（cookie作用域）。
- 首部壓縮：HTTP2還提供了首部壓縮功能，即通過雙方共有的一些字典，將首部信息（狀態(tài)行、請(qǐng)求/響應(yīng)頭）“映射”為更簡(jiǎn)短的數(shù)據(jù)。
- 圖片：使用合適的圖片大小和圖片格式，可以節(jié)省大小。
緩存：小到最小的情況當(dāng)然是不接受數(shù)據(jù)傳輸，使用本地緩存。一般使用服務(wù)器前一次返回的響應(yīng)頭部字段進(jìn)行控制。
強(qiáng)緩存：強(qiáng)緩存不會(huì)向服務(wù)器發(fā)送請(qǐng)求。
- Expires：http1.0字段，使用服務(wù)器時(shí)間做標(biāo)識(shí)。
- Cache-Control：max-age= seconds，使用相對(duì)于請(qǐng)求的時(shí)間，不超過這個(gè)時(shí)長(zhǎng)，直接使用緩存。還有其他的值。
協(xié)商緩存：
- Last-Modified/If-Modified-Since：資源***修改時(shí)間，秒。瀏覽器客戶端發(fā)送If-Modified-Since字段，服務(wù)器響應(yīng)Last-Modified字段。
- ETag/If-None-Match：資源的標(biāo)識(shí)符，客戶端發(fā)送If-None-Match字段，服務(wù)器響應(yīng)ETag字段，并比較兩者，決定返回緩存重定向還是其他，這個(gè)標(biāo)識(shí)只比較內(nèi)容，不關(guān)心資源時(shí)間。
- 合理拆分頁面資源，比如外聯(lián)js和css就可以獨(dú)立于html進(jìn)行緩存。
關(guān)閉TCP
在資源下載完畢之后，需要關(guān)閉TCP連接。這段沒有什么可以優(yōu)化的。
過程：
- TCP客戶端發(fā)送一個(gè)FIN = 1（結(jié)束標(biāo)志位）和隨機(jī)數(shù)seq = a，用來關(guān)閉客戶到服務(wù)器的數(shù)據(jù)傳送。
- 服務(wù)器收到這個(gè)關(guān)閉請(qǐng)求，返回ACK = 1 ，ack = a + 1，此時(shí)服務(wù)器之前的數(shù)據(jù)可能還沒有傳輸完成。
- 數(shù)據(jù)傳輸完成后，服務(wù)器發(fā)送一個(gè)FIN = 1和隨機(jī)數(shù)seq = b給客戶端。
- 客戶端返回ACK = 1，ack = b + 1，并等待一段時(shí)間，確保服務(wù)器沒有返回沒收到確認(rèn)報(bào)文的重傳申請(qǐng)，后關(guān)閉連接。
- 服務(wù)器收到確認(rèn)報(bào)文后，驗(yàn)證關(guān)閉連接。
總結(jié)
HTTP2 真好用。合理使用緩存。
頁面解析渲染
上述的資源加載是發(fā)生在頁面解析過程中的。那么瀏覽器的頁面解析渲染是怎么樣的一個(gè)過程呢？
過程
簡(jiǎn)要來講就是：
- 處理HTML標(biāo)記，構(gòu)建DOM樹。
- 處理CSS標(biāo)記，構(gòu)建CSSOM樹。
- 將DOM樹和CSSOM樹融合成渲染樹（會(huì)忽略不需要渲染的dom）。
- 根據(jù)渲染樹來布局，計(jì)算每個(gè)節(jié)點(diǎn)的幾何信息。
- 在屏幕上繪制各個(gè)節(jié)點(diǎn)。
- 中間遇到各種資源時(shí)，會(huì)進(jìn)行資源的下載。
問題
資源下載：
- css下載時(shí)會(huì)阻塞渲染（帶有media屬性除外）。
- 遇到 script 標(biāo)簽時(shí)，DOM構(gòu)建停止，此時(shí)控制權(quán)移交至js，直到腳本（下載）執(zhí)行完畢，此時(shí)瀏覽器有優(yōu)化一般會(huì)下載其他資源，但是不會(huì)解析。如果js中有對(duì)CSSOM的操作，還會(huì)先確保CSSOM已經(jīng)被下載并構(gòu)建。
- 圖片資源下載不會(huì)產(chǎn)生阻塞。
重繪重排導(dǎo)致重新進(jìn)行渲染樹的生成：
- 重排（回流）：會(huì)重新計(jì)算布局，通常由元素的結(jié)構(gòu)、增刪、位置、尺寸變化引起，如：img下載成功后，替換填充頁面img元素，引起尺寸變化；也會(huì)由js的屬性值讀取引起，如讀取offset、scroll、cilent、getComputedStyle等信息。
- 重繪：簡(jiǎn)單外觀的改變會(huì)引起重繪，如顏色變化等。
- 重排一定重繪。
優(yōu)化
dom
- 簡(jiǎn)化dom結(jié)構(gòu)，減少DOM樹和渲染樹構(gòu)建成本，減少頁面元素個(gè)數(shù)，如使用列表表格數(shù)據(jù)分頁，簡(jiǎn)單表格不要使用復(fù)雜第三方組件等方式。
js
- 將js腳本標(biāo)簽放在頁面body底部，減少對(duì)其他過程的阻塞。
- 延遲執(zhí)行：對(duì)不修改頁面的外鏈script使用defer屬性，使腳本并行下載不阻塞，下載后不立刻執(zhí)行，而在所有元素解析之后執(zhí)行。
- 減少和合并不必要的dom相關(guān)操作，如使用DocumentFragment、修改classname而不是各項(xiàng)style等，減少對(duì)重繪和重排的觸發(fā)。
css
- 將css放入head中，提前加載，并防止html渲染后重新結(jié)合css引起頁面閃爍。
- 減少css層級(jí)和css選擇器復(fù)雜度，提高解析速度，雖然瀏覽器有優(yōu)化。
- 使用更高性能的css樣式，如flex代替float。
- 開啟復(fù)合層，如使用3d變換、opacity等，使該元素及其子元素不導(dǎo)致外部的重排，但是也有坑。
- 合理使用脫離文檔流的樣式，減少對(duì)外部重排的影響，如absolute。
文件數(shù)量
- 減少***下載的文件數(shù)量大小，使用圖片懶加載，js的按需加載等方式，也可以節(jié)省用戶流量，甚至使用storage存儲(chǔ)進(jìn)行js、css文件的緩存。
- 拆分頁面資源，首屏數(shù)據(jù)優(yōu)先加載等。
5.其他優(yōu)化措施
我們還可以采取一些和延遲、渲染無關(guān)的優(yōu)化措施：
- 使用PWA，讓用戶在沒有得到數(shù)據(jù)時(shí)也能看到頁面。
- 對(duì)頁面某些ajax請(qǐng)求數(shù)據(jù)進(jìn)行storage存儲(chǔ)。
- 加載進(jìn)度、骨架圖、占位圖等類似讓用戶感覺好一點(diǎn)的措施。
- 及時(shí)更新升級(jí)服務(wù)器，優(yōu)化措施依賴于服務(wù)器支持。
文章名稱：從輸入url開始能做哪些優(yōu)化
標(biāo)題路徑：http://www.fisionsoft.com.cn/article/cdjgccp.html
