摘要：前端性能優(yōu)化的涉及點(diǎn)從服務(wù)器到協(xié)議再到宿主環(huán)境本身都要有比較深刻的認(rèn)識(shí)，業(yè)界目前主要還是以雅虎總結(jié)出來?xiàng)l前端性能優(yōu)化的黃金軍規(guī)為參考。

歡迎大家前往騰訊云技術(shù)社區(qū)，獲取更多騰訊海量技術(shù)實(shí)踐干貨哦~

導(dǎo)語 : 從事前端有6年+的時(shí)間了，從最開始的美工到重構(gòu)再到偏向js邏輯開發(fā)的前端開發(fā)，一直在前端這個(gè)行業(yè)里面摸索和學(xué)習(xí)，我現(xiàn)在將自己這些年的一個(gè)心得體會(huì)來個(gè)系統(tǒng)性的梳理寫成一篇關(guān)于性能優(yōu)化的主題文章，希望對(duì)大家有點(diǎn)幫助，也歡迎大家提出各種意見和建議。

作者：劉勇剛

前端工程師是一個(gè)最近這5-6年才開始慢慢被互聯(lián)網(wǎng)公司重視起來的一個(gè)職業(yè)，可以說是一個(gè)新興行業(yè)，我用一張簡(jiǎn)單的思維導(dǎo)圖帶大家回顧一下前端技術(shù)發(fā)展的歷程以及未來一個(gè)展望：

1.0時(shí)代沒什么說的，html、css打天下的時(shí)代，那個(gè)時(shí)候你會(huì)用js開發(fā)個(gè)計(jì)算器就牛逼到不行。2.0時(shí)代是最好的時(shí)代，新技術(shù)、新思想蓬勃發(fā)展，堪稱前端的工業(yè)革命，前端人員的地位得到了充分認(rèn)可，門檻也有一定的提升。前端性能優(yōu)化的涉及點(diǎn)從服務(wù)器到協(xié)議再到宿主環(huán)境本身都要有比較深刻的認(rèn)識(shí)，業(yè)界目前主要還是以雅虎總結(jié)出來35條前端性能優(yōu)化的黃金軍規(guī)（http://www.cnblogs.com/siqi/p...） 為參考。今天我想將這些年對(duì)前端的性能優(yōu)化的經(jīng)驗(yàn)思考整體來個(gè)串燒，帶大家鳥瞰一下前端性能優(yōu)化目前的一些通行做法以及這么做的出發(fā)點(diǎn)。文章初衷主要是對(duì)一些性能優(yōu)化基礎(chǔ)知識(shí)回顧和體系梳理，不對(duì)具體技術(shù)點(diǎn)做深入分析，點(diǎn)到為止，個(gè)人理解不對(duì)的地方歡迎各位大神拍磚，拋磚引玉。

引入話題前我還是先從一個(gè)老生常談的話題開始：

“從用戶輸入U(xiǎn)Rl到頁(yè)面展示給用戶瀏覽器客戶端的過程中發(fā)生了什么？”

這里用個(gè)圖表簡(jiǎn)單描述一下幾個(gè)步驟：

web優(yōu)化的目標(biāo)就是如何讓用戶更快、更簡(jiǎn)單易用、更流暢的使用我們的服務(wù)，對(duì)于前端開發(fā)而言就是如何讓我們的資源體量更小、數(shù)量更精簡(jiǎn)、內(nèi)容更早呈現(xiàn)、交互更加人性化。

web性能優(yōu)化有個(gè)大家比較公認(rèn)的二八原則，就是資源從服務(wù)器處理完下發(fā)到客戶端的瀏覽器上（上圖第6步）所占的時(shí)間比例大概是整個(gè)過程的20%，也就是說服務(wù)器端可以優(yōu)化的空間的效率提升并不會(huì)很明顯，前端性能優(yōu)化成為web性能優(yōu)化重點(diǎn)考慮的領(lǐng)域，我下面將會(huì)從以下幾個(gè)維度去做了自己的一個(gè)思考（跟35條軍規(guī)有一定重疊）和總結(jié)：

1、突破單線程解析渲染阻塞限制

瀏覽器是一個(gè)單線程解析模式去解析渲染從服務(wù)器端拿到的html文本，css加載的過程中會(huì)對(duì)后續(xù)的腳本資源加載造成阻塞，腳本的加載也會(huì)阻塞后續(xù)DOM結(jié)構(gòu)的解析造成頁(yè)面的留白時(shí)間增長(zhǎng)，雅虎的35條軍規(guī)中有一條就是樣式文件放在頭部，腳本文件放在DOM節(jié)點(diǎn)最末尾，減少阻塞。這里還有幾個(gè)針對(duì)腳本文件的優(yōu)化：

針對(duì)不需要DOM操作（主要考慮是需要操作DOM的腳本往往需要獲取一些樣式信息）的Js腳本可以采用動(dòng)態(tài)創(chuàng)建script的方式載入，動(dòng)態(tài)載入的腳本不阻塞后續(xù)資源的加載。
腳本文件加載可以加上defer或者async屬性標(biāo)識(shí)防止阻塞（關(guān)于兩者區(qū)別可以參考）

2、利用事件冒泡特性

瀏覽器的事件模型的冒泡的特性（瀏覽器事件模型不清楚的自行搜索了解）我覺得是最牛逼的設(shè)計(jì)之一，解決了瀏覽器因?yàn)榻馕鯠OM模型不同步導(dǎo)致開發(fā)者往DOM對(duì)象注冊(cè)事件回調(diào)找不到對(duì)象的問題。

瀏覽器事件注冊(cè)有3個(gè)級(jí)別定義，DOM 0級(jí)事件注冊(cè)（利用DOM元素行內(nèi)事件屬性onclick注冊(cè)事件回調(diào)），DOM 1級(jí)事件注冊(cè)（利用DOM元素對(duì)象的onclick API 在外部注冊(cè)事件回調(diào)），DOM 2級(jí)事件注冊(cè)（利用利用DOM元素對(duì)象的addEventListner/attachEvent API 在外部注冊(cè)事件回調(diào)）。這里性能優(yōu)化的建議就是利用DOM2級(jí)在目標(biāo)DOM的父標(biāo)簽（大部分框架是在body標(biāo)簽統(tǒng)一注冊(cè)事件監(jiān)聽）注冊(cè)回調(diào)，收攏事件監(jiān)聽入口同時(shí)節(jié)約了DOM節(jié)點(diǎn)引用開銷。

3、避開Cookie性能bug

Cookie是前端作為前后臺(tái)登錄態(tài)校驗(yàn)最通常用的緩存方案，但鑒于瀏覽器在每次都會(huì)往同域的任何資源的http請(qǐng)求中自動(dòng)帶上cookie信息的情況，這里有必要進(jìn)行優(yōu)化一下，因?yàn)橄馽ss、js、image這些資源請(qǐng)求是不需要cookie信息的，會(huì)無端造成請(qǐng)求帶寬的浪費(fèi)（想象一下我們的cookie大小假設(shè)為10K，100個(gè)請(qǐng)求就是近1M的大小，高并發(fā)下以我們現(xiàn)行網(wǎng)絡(luò)帶寬也是蠻大的一筆負(fù)擔(dān)了）。Cookie free性能優(yōu)化方案的處理方式是CDN異域靜態(tài)資源服務(wù)器部署我們的前端css、js、image資源。

以自己目前負(fù)責(zé)的香港跨境匯款為例

頁(yè)面路徑下的資源的請(qǐng)求：

CDN資源加載的請(qǐng)求：

通過對(duì)比CDN分開部署的資源請(qǐng)求并沒有帶上cookie信息。

4、突破瀏覽器并發(fā)連接限制

瀏覽器針對(duì)domain,而非頁(yè)面page做并發(fā)連接限制的特性，domain hash的技術(shù)優(yōu)化方案的處理方式是將資源劃分域分開部署，但因?yàn)檫^多的域劃分會(huì)增加多余的DNS開銷，這里通行的數(shù)量是3個(gè)以內(nèi)。目前我們的港菲匯款業(yè)務(wù)只有兩個(gè)域名分開部署，一個(gè)主站，一個(gè)CDN，我個(gè)人建議可以將CDN中的圖片資源再多帶帶再分一個(gè)域名部署會(huì)更好些，為什么多帶帶把圖片抽出來，后面會(huì)講到。

5、利用GPU硬件加速瀏覽器渲染

針對(duì)一些界面渲染過程比較耗時(shí)的情況下，可以利用CSS3屬性開啟GPU來加速渲染我們的DOM，開啟很簡(jiǎn)單一般我是用-webkit-transform:translateZ(0)假3D屬性來喚起系統(tǒng)GPU加速渲染功能，關(guān)于為什么會(huì)這樣，我這里做個(gè)簡(jiǎn)單的解釋：

對(duì)于我們的瀏覽器而言，拿到我們的html文本串開始按順序解析成DOM樹，并與同步解析出來的CSS匹配生成渲染樹（跟DOM樹的節(jié)點(diǎn)不是一一對(duì)應(yīng)，比如display:none的節(jié)點(diǎn)就不會(huì)插入渲染樹）

圖片來源：https://segmentfault.com/a/11...

瀏覽器將渲染樹的節(jié)點(diǎn)用一個(gè)圖層表示，這樣層層疊加在一起生成layout，有點(diǎn)像ps的圖層疊加的概念（可以通過火狐瀏覽器開發(fā)者工具3維展示更直觀），一般情況下對(duì)節(jié)點(diǎn)的任何涉及尺寸的改變都會(huì)引起layout的重排重繪（重排和重繪是造成瀏覽器渲染的最大性能損耗的因素），但有種開小灶的情況Composite Layers（復(fù)合圖層）直接交給我們GPU中多帶帶的合成器進(jìn)程處理，自身變化不會(huì)引起其他層的位置變化，不會(huì)引起重排重繪。tranform 3d屬性是可以悄悄的告訴我們的瀏覽器把元素解析作為復(fù)合圖層交給多帶帶進(jìn)程去處理的。

注：這里有個(gè)原則，不能濫用我們的加速，因?yàn)檫^多開啟硬件加速會(huì)消耗更多的用戶內(nèi)存空間，也會(huì)比較耗電，一般針對(duì)css3動(dòng)畫建議開啟

1、減少http請(qǐng)求數(shù)量

a、通行解決方案

css、script合并：gulp、webpack都能夠很簡(jiǎn)單的通過任務(wù)腳本的方式去自動(dòng)化解決，目前我們團(tuán)隊(duì)是用我們自研的前端構(gòu)建工具配合我們的Dust庫(kù)做的發(fā)布前的資源打包任務(wù)，核心就是用的gulp。

css sprites雪碧圖：將網(wǎng)站常用的一些小圖片整合到一張大圖上來，樣式里面通過background-position二維坐標(biāo)定位找到自己的圖片。這里有個(gè)原則，一般是將網(wǎng)站復(fù)用率較高的，不太容易變動(dòng)的圖標(biāo)和圖片，比如按鈕、平鋪背景小圖片等。

font-icon字體圖標(biāo)：字體圖標(biāo)庫(kù)的使用，是一個(gè)非常有創(chuàng)新的方式，因?yàn)槭鞘噶康?，解決位圖像素放大變虛的問題，體驗(yàn)很好，相比同樣矢量的SVG來說使用更簡(jiǎn)單，一個(gè)css的font-family就可以像平時(shí)設(shè)置字體一樣使用，淘寶是國(guó)內(nèi)這方面的先行者，有自己的一套很開放的矢量圖標(biāo)庫(kù)平臺(tái)。淘寶自身的許多小圖標(biāo)都是用的字體圖標(biāo)來展示的。

圖片base64編碼傳輸：圖片base64編碼后，可以讓瀏覽器減少自身的一次http請(qǐng)求，但因?yàn)樽陨淼囊恍┤毕?，不能濫用（即使一個(gè)很小的圖片編碼后都會(huì)有一大串字符，增加了我們CSS體積，性能不降反升），我的建議是針對(duì)那些全站通用或者體積很小不好整合到雪碧圖里面的圖標(biāo)進(jìn)行編碼，當(dāng)然還有很多不同的場(chǎng)景大家自己權(quán)衡。

圖片延時(shí)加載：主要是為了減少首屏一次性圖片的加載量。具體做法是給圖片或者標(biāo)簽設(shè)置一個(gè)私有行內(nèi)屬性data-image(當(dāng)然可以自己隨便定義)存放目標(biāo)圖片地址信息，監(jiān)聽瀏覽器的滾動(dòng)事件，標(biāo)簽到了瀏覽器可視區(qū)域就將圖片地址放入圖片的src屬性中或者作為標(biāo)簽的樣式的背景圖片中展示。淘寶首頁(yè)的做法是用一個(gè)div來做延時(shí)圖片加載，通過背景圖片來展示最后的圖片。

圖片展示前：

圖片展示后：

b、緩存機(jī)制

協(xié)議緩存方案：利用http緩存協(xié)議頭cache-control做304緩存，或者更精確的ETAG設(shè)置依據(jù)資源的修改時(shí)間來設(shè)置緩存方案。但目前更有效或者極端的做法是利用max-expire-time，設(shè)置資源的最大緩存時(shí)間假設(shè)為1年的長(zhǎng)緩存，更新采用非覆蓋式更新的方式是目前大公司通行的做法。這樣每次資源請(qǐng)求的時(shí)候都是只從客戶端緩存讀?。╯tatus:200，size:from
cache），而不是還要跑一次http請(qǐng)求到服務(wù)器端拿到304狀態(tài)。還是以一張?zhí)詫毷醉?yè)圖片長(zhǎng)緩存的截圖為例：

appCache應(yīng)用緩存方案：離線應(yīng)用緩存是h5提供一個(gè)比較有效的離線應(yīng)用方案，利用navigator.online
、window.applicationCache對(duì)象、服務(wù)器.appcache(以前是.manifest)配置文件保證在脫機(jī)下的移動(dòng)web應(yīng)用照常能用，如果要做數(shù)據(jù)的離線還要加上window.localStorage做離線數(shù)據(jù)的保存。這里簡(jiǎn)單說一下接入離線應(yīng)用需要的幾個(gè)步驟：

1、給需要做離線緩存的頁(yè)面html標(biāo)簽設(shè)定manifest屬性，指定緩存的配置文件 cache.appcahe（可以設(shè)定任何擴(kuò)展名，只要在服務(wù)器端配置mime-type為text/cache-manifest就行）。

2、創(chuàng)建上一步指定的cache.appcache配置文件，按以下截圖說明來配置資源

3、在服務(wù)器端配置配置文件的擴(kuò)展名映射的mime-type為text/cache-manifest

appcache離線方案詬病太多，目前接入的不多，有種慢慢變棄兒的趨勢(shì)，這里提出來讓大家權(quán)衡

**PWA(Progressive Web
Apps)方案**：谷歌提出的一套全新的離線web方案，利用manifest.json配置文件、window.serviceWorker對(duì)象來實(shí)現(xiàn)類原生app體驗(yàn)的離線應(yīng)用方案，可以說是瀏覽器應(yīng)用緩存的一個(gè)脫胎升級(jí)方案（鑒于文章篇幅，這里不做介紹了）。

2、減輕http數(shù)據(jù)請(qǐng)求大小

a、通行解決方案

css、script、圖片壓縮：這些可以gulp或者webpack自動(dòng)化腳本里面定義腳本任務(wù)來完成。

服務(wù)器開啟gzip壓縮：一般現(xiàn)在服務(wù)器都有開啟Gzip壓縮，壓縮率通常都是30%以上，效果還是不錯(cuò)的。

原圖：

Gzip壓縮后：

圖片服務(wù)器動(dòng)態(tài)響應(yīng)方案：這個(gè)方案對(duì)應(yīng)上面宿主環(huán)境維度domain hash多帶帶出來一個(gè)獨(dú)立域名部署圖片資源的方案介紹。圖片資源是網(wǎng)站請(qǐng)求資源中一個(gè)非常大頭的開銷，以前大家可以在靜態(tài)資源服務(wù)器中建個(gè)image目錄存放就完事，隨著網(wǎng)站服務(wù)發(fā)展，圖片不僅面臨多樣化、高并發(fā)帶來的壓力，在移動(dòng)端wap站點(diǎn)中更是要針對(duì)不同的分辨率屏幕下圖片尺寸動(dòng)態(tài)適配的場(chǎng)景以為了節(jié)省帶寬的需求。圖片服務(wù)器的多帶帶架構(gòu)有一定的復(fù)雜度（如果考慮到高并發(fā)下的容災(zāi)、緩存機(jī)制的話不亞于一個(gè)大型web網(wǎng)站集群的搭建，這里有篇文章推薦大家閱讀），這里只討論一下其中負(fù)責(zé)切圖服務(wù)部分的服務(wù)器（簡(jiǎn)稱切圖服務(wù)器）功能，切圖服務(wù)器對(duì)外提供一個(gè)restful的url調(diào)用，比如http://www.xxx.com/xxx圖片路...“xxx圖片路徑”下的xxx圖片等比壓縮成130*120的圖片尺寸并返回，這塊服務(wù)可以使用我們前端比較熟悉的node創(chuàng)建，當(dāng)然也可以用PHP來提供。

b、頁(yè)面切片預(yù)加載方案

性能優(yōu)化靜態(tài)資源維度最后一塊內(nèi)容就是針對(duì)頁(yè)面，如何盡早輸出頁(yè)面模塊，減少留白時(shí)間是一個(gè)思考點(diǎn)。facebook應(yīng)用的BigPipe方案是個(gè)很不錯(cuò)的借鑒思想，還有淘寶也有首頁(yè)做了相應(yīng)的切片方案，對(duì)頁(yè)面合理的分塊，在服務(wù)器和客戶端建立某種對(duì)應(yīng)機(jī)制，讓各個(gè)頁(yè)面塊并行的在服務(wù)器端拼接完成并吐出來，目前我對(duì)這塊沒有太深的了解，這里只是提出bigPipe的方案供大家參考。

TCP連接中的3次握手、慢啟動(dòng)的一些特性注定了連接通道的利用效率成為制約性能的一個(gè)很大的因素。因?yàn)閔ttp是基于TCP的應(yīng)用協(xié)議，TCP層維度考慮還得從http幾個(gè)版本的發(fā)展歷史來看：

http1.0時(shí)期：tcp連接是基于一種單通道順序等待請(qǐng)求響應(yīng)方式(客戶端每發(fā)一個(gè)請(qǐng)求都要重新建立連接)，特定歷史背景下產(chǎn)生的，低效率很難跟上時(shí)代發(fā)展，99年在1.0基礎(chǔ)上修訂出1.1版本，并沿用至今。

http1.1時(shí)期：在請(qǐng)求頭信息加入keep Alive保持連接的一定活性(當(dāng)然也加入了100
Status節(jié)約帶寬、cache特性等)，允許在一個(gè)連接通道生命期內(nèi)重復(fù)發(fā)送不同的應(yīng)用請(qǐng)求，一定程度上減輕了連接資源利用效率問題，但當(dāng)用戶瀏覽網(wǎng)頁(yè)時(shí)間大于連接活性周期再次請(qǐng)求的時(shí)候仍然要重新建立這些請(qǐng)求，在大型科技公司對(duì)高并發(fā)高可用性下資源高效利用的背景下，1.1版本還是難滿足大公司對(duì)高性能條件下網(wǎng)絡(luò)資源的高效率利用的要求。

谷歌（叒是谷歌，牛逼）率先在09年基于TCP開發(fā)出全新SPDY應(yīng)用協(xié)議，解決了多路復(fù)用請(qǐng)求優(yōu)化、服務(wù)器推送的痛點(diǎn)問題，也為后面http2.0的推出奠定了基礎(chǔ)。
我們可以做的優(yōu)化：減少一些不必要的請(qǐng)求(掃除404死連接、304請(qǐng)求用我們的長(zhǎng)緩存機(jī)制)去優(yōu)化，盡量減少一些不必要的連接請(qǐng)求數(shù)。

鑒于js語言本身的靈活性，以及每個(gè)人的開發(fā)習(xí)慣，很難有很好的一個(gè)方式去驗(yàn)證開發(fā)者的代碼實(shí)現(xiàn)的效率（目前更多的是用打點(diǎn)測(cè)速的方式去監(jiān)控代碼的執(zhí)行時(shí)間），更多的是一種建議，大家有更好的建議可以提出來分享。

單線程限制：利用異步回調(diào)&多線程API突破js語言單線程帶來的內(nèi)存開銷利用不充分的問題，現(xiàn)有可以利用的一些異步方式的回調(diào)都可以嘗試?yán)帽热鐂ettimeout,setinterval,requestAnimationframe（推薦用它）,多線程的API方式有WebWork。這里推薦日本的一個(gè)開發(fā)者開發(fā)的一個(gè)多線程前端庫(kù)Concurrent.Thread.js（它是作者用setTimeout和setInterval來模擬的多線程，可以自行網(wǎng)上搜索了解）。

重點(diǎn)優(yōu)化代碼中的循環(huán)結(jié)構(gòu)體：就代碼本身而言影響執(zhí)行效率的大部分是循環(huán)體結(jié)構(gòu)和算法設(shè)計(jì)不合理導(dǎo)致的時(shí)間復(fù)雜度和空間復(fù)雜度的增加。這里放兩段實(shí)際項(xiàng)目中的代碼截圖來對(duì)比：

實(shí)例功能需要：實(shí)現(xiàn)輸入框每4個(gè)字符一個(gè)空格隔開的效果

低效實(shí)現(xiàn)方式，用for循環(huán):

改進(jìn)后的方式:

合理使用設(shè)計(jì)模式優(yōu)化代碼結(jié)構(gòu)：設(shè)計(jì)模式的合理利用(不能濫用)可以起到內(nèi)存優(yōu)化提高執(zhí)行效率效果，比如單例和簡(jiǎn)單工廠在創(chuàng)建xhr請(qǐng)求對(duì)象中的利用：創(chuàng)建一個(gè)簡(jiǎn)單工廠向外面提供xhr對(duì)象，工廠內(nèi)部用閉包開辟一個(gè)數(shù)組隊(duì)列單例用來存放xhr對(duì)象，當(dāng)調(diào)用者需要xhr對(duì)象時(shí)工廠就從隊(duì)列里取出readyState狀態(tài)為空閑（0/4）的xhr對(duì)象否則重新創(chuàng)建并放入隊(duì)列中。在有大量ajax對(duì)象請(qǐng)求的應(yīng)用下可以最大限度節(jié)約創(chuàng)建xhr消耗的內(nèi)存開銷，這里用個(gè)簡(jiǎn)圖來描述一下思路：

其他一些優(yōu)化建議：比如減少js頻繁操作dom節(jié)點(diǎn)的次數(shù)（這個(gè)本來想放在宿主環(huán)境維度）減少瀏覽器的重排重繪；比如針對(duì)dom標(biāo)簽對(duì)象（主要是針對(duì)ie下dom對(duì)象的引用會(huì)被GC回收遺漏的問題）、閉包內(nèi)部的引用類型的變量用完過后記得要及時(shí)釋放，避免造成內(nèi)存泄漏。

性能優(yōu)化一般都是從技術(shù)角度去入手，但我們的目標(biāo)之一“讓用戶簡(jiǎn)單易用”也是性能優(yōu)化的一環(huán)。當(dāng)技術(shù)性能缺陷難于避免的時(shí)候，作為前端交互實(shí)現(xiàn)的執(zhí)行者，更應(yīng)該配合產(chǎn)品和交互設(shè)計(jì)師提出一個(gè)我們認(rèn)為更好的交互邏輯體驗(yàn)方案去讓我們的數(shù)據(jù)加載不那么讓用戶有等待的感知，讓我們的提示更加的人性舒服。（交互設(shè)計(jì)師更加專業(yè)，我這里不敢班門弄斧）

Web3.0時(shí)代的前端展望：

文章最后對(duì)Web3.0時(shí)代做個(gè)自己的猜想，web3.0目前在業(yè)內(nèi)還沒有很明確定義，大家可以大膽猜想前端行業(yè)未來形態(tài)。我在這先YY一下，人工智能、大數(shù)據(jù)廣泛應(yīng)用應(yīng)該會(huì)成為推動(dòng)前端進(jìn)入3.0的時(shí)代的最好契機(jī)，以此引發(fā)的前端新的革命：

瀏覽器成為一個(gè)系統(tǒng)生態(tài)（至于哪個(gè)瀏覽器現(xiàn)在不好說，現(xiàn)在谷歌瀏覽器PWA方案提供給前端類app開發(fā)方案就有這個(gè)趨勢(shì)，以后都不需要裝系統(tǒng)了）。前端不再是數(shù)據(jù)的搬運(yùn)工，在web領(lǐng)域很有可能除了底層維護(hù)數(shù)據(jù)庫(kù)的工程師們繼續(xù)深耕外（主要切入云計(jì)算領(lǐng)域），其它的都可以轉(zhuǎn)到前端做瀏覽器系統(tǒng)生態(tài)（哎媽呀，有種翻身農(nóng)奴做主人的感覺O(∩_∩)O~~）。

傳統(tǒng)的html語義性的超文本標(biāo)記語言已經(jīng)很難承載更多的信息化數(shù)據(jù)，html5繼續(xù)深度發(fā)展，不再只是瀏覽器專用的標(biāo)記語言，可能會(huì)成為跨平臺(tái)標(biāo)準(zhǔn)的信息表示層，信息表示多樣化前所未有，可能到時(shí)候不叫html了。

http2.0成為一個(gè)廣泛試用的標(biāo)準(zhǔn)，并進(jìn)一步深化，安全校驗(yàn)層做到類似區(qū)塊鏈去中心化的思路，做到極致安全（https估計(jì)可以下崗了）。

js成為跨平臺(tái)公認(rèn)的標(biāo)準(zhǔn)實(shí)現(xiàn)語言（目前前端跨平臺(tái)基礎(chǔ)形態(tài)已經(jīng)有了），隨著Es6的廣泛推廣和深度改進(jìn)，可能就不會(huì)像現(xiàn)在這么靈活，更加像一個(gè)合格的標(biāo)準(zhǔn)“高級(jí)”腳本語言。

（以上猜想純屬個(gè)人理解，沒有權(quán)威認(rèn)證，大家可以暢所欲言）

結(jié)語：剛來鵝廠不久，作為前端攻城獅進(jìn)入到國(guó)內(nèi)頂尖互聯(lián)網(wǎng)公司感到驕傲，性能優(yōu)化是一個(gè)永恒的話題，每個(gè)階段都有聊不完的性能優(yōu)化的話題，我將我這些年的一些不成文的理解整理了一下，希望對(duì)大家有點(diǎn)幫助。第一次發(fā)文章，有錯(cuò)誤的地方請(qǐng)大家指點(diǎn)一二。

Web 前端性能優(yōu)化 : 如何有效提升靜態(tài)文件的加載速度
使用 Skeleton Screen 提升用戶感知體驗(yàn)
盒子端 CSS 動(dòng)畫性能提升研究

此文已由作者授權(quán)騰訊云技術(shù)社區(qū)發(fā)布，轉(zhuǎn)載請(qǐng)注明文章出處
原文鏈接：https://cloud.tencent.com/com...