摘要:性能最好具有可量化可監(jiān)測(cè)以及可改動(dòng)的特性。下文是一份年的前端性能優(yōu)化清單,闡述了作為前端開發(fā)人員,為了確保反饋速度以及瀏覽器兼容性我們需要考慮的問題。地圖設(shè)計(jì)的決定違背了性能理念,所以他在這份清單內(nèi)的順序有待考慮。
2017前端性能優(yōu)化清單
你開始使用漸進(jìn)啟動(dòng)了么?是不是已經(jīng)使用過React和Angular中tree-shaking和code-splitting兩個(gè)工具?有沒有用過Brotli、Zofli和HPACK這幾種壓縮技術(shù),或者OCSP協(xié)議(在線證書狀態(tài)協(xié)議)?知不知道資源提醒,客戶端提醒和CSS containment一類的技術(shù)?了解IPv6,HTTP/2和Service Worker這些協(xié)議嗎?
回想那些年,大家往往在完成了產(chǎn)品之后才會(huì)去考慮性能。常常把與性能相關(guān)的事情拖到項(xiàng)目的最后來(lái)做,所做的也不過是對(duì)服務(wù)器上的config文件進(jìn)行一些微調(diào)、串聯(lián)、優(yōu)化以及部分特別小的調(diào)整。而現(xiàn)在,技術(shù)已經(jīng)有了翻天覆地的變化。
一個(gè)項(xiàng)目的性能是非常重要的,除了要在技術(shù)層面上注意,更要在項(xiàng)目的設(shè)計(jì)之初就開始考慮,這樣才可以使性能的各種隱形需求完美的整合到項(xiàng)目中,隨著項(xiàng)目一起推進(jìn)。性能最好具有可量化、可監(jiān)測(cè)以及可改動(dòng)的特性。網(wǎng)絡(luò)越來(lái)越復(fù)雜,對(duì)網(wǎng)絡(luò)的監(jiān)控也變得越來(lái)越難,因?yàn)楸O(jiān)測(cè)的過程會(huì)受到包括設(shè)備、瀏覽器、協(xié)議、網(wǎng)絡(luò)類型以及其他技術(shù)(CDN,ISP,緩存,代理服務(wù)器,防火墻,負(fù)載均衡器和服務(wù)器對(duì)性能的影響都很大)的很大影響。
下文是一份2017年的前端性能優(yōu)化清單,闡述了作為前端開發(fā)人員,為了確保反饋速度以及瀏覽器兼容性我們需要考慮的問題。
(你也可以下載checklist PDF或者check in Apple Pages。優(yōu)化萬(wàn)歲!)
正文微優(yōu)化是保持性能最好的辦法,但是又不能有太過明確的優(yōu)化目標(biāo),因?yàn)檫^于明確的目標(biāo)會(huì)影響在項(xiàng)目中做的每一個(gè)決定。以下是一些不同的模型,請(qǐng)按照自己舒服的順序閱讀。
請(qǐng)準(zhǔn)備好然后定下目標(biāo)! 1. 比你最強(qiáng)的競(jìng)爭(zhēng)對(duì)手快20%根據(jù)一個(gè)心理學(xué)研究,你的網(wǎng)站最少在速度上比別人快20%,才能讓用戶感覺到你的網(wǎng)站比別人的更快。這個(gè)速度說(shuō)的不是整個(gè)頁(yè)面的加載時(shí)間,而是開始加載渲染的時(shí)間,首次有效渲染時(shí)間(例如頁(yè)面需要加載主要內(nèi)容的時(shí)間),或者交互時(shí)間(指的是頁(yè)面或者應(yīng)用中主要的頁(yè)面加載完成,并主備好與用戶進(jìn)行交互的時(shí)間)。
在Moto G(一個(gè)中端三星設(shè)備)和Nexus 4(比較主流的設(shè)備)上衡量開始渲染時(shí)間(用WebPagetest)以及首頁(yè)有效渲染時(shí)間(用Lighthouse),最好是在一個(gè)開放的實(shí)驗(yàn)室中,使用規(guī)范的3G,4G和Wi-Fi鏈接。
Lighthouse,一個(gè)Google開發(fā)的新的性能審查工具
你可以通過你的分析報(bào)告看看你的用戶處在哪個(gè)階段,選取其中前90%的用戶體驗(yàn)來(lái)做測(cè)試。接著收集數(shù)據(jù),建一個(gè)表格,篩去20%的數(shù)據(jù)并預(yù)設(shè)一個(gè)目標(biāo)(如:性能預(yù)算)。現(xiàn)在你可以將上述兩個(gè)值進(jìn)行對(duì)比檢測(cè)。如果你始終維持著你的目標(biāo)并且通過一點(diǎn)一點(diǎn)改變腳本去加快交互時(shí)間,那么上述方法就是合理可行的。
由Brad Frost創(chuàng)建的性能分析
和你的同事分享這份清單。首先要確保團(tuán)隊(duì)中的每個(gè)人都熟悉這份清單。項(xiàng)目中每一個(gè)決定都會(huì)影響性能,如果前端工程師們都在積極的參與項(xiàng)目概念,UX以及視覺設(shè)計(jì)的決定,這將會(huì)給整個(gè)項(xiàng)目帶來(lái)巨大收益。地圖設(shè)計(jì)的決定違背了性能理念,所以他在這份清單內(nèi)的順序有待考慮。
2. 反應(yīng)時(shí)間為100毫秒,幀數(shù)是每秒60幀RAIL性能模型會(huì)為你提供一個(gè)優(yōu)秀的目標(biāo),既盡最大的努力在用戶初始操作后的100毫秒內(nèi)提供反饋。為了達(dá)到這個(gè)目標(biāo),頁(yè)面需要放棄權(quán)限,并將權(quán)限在50毫秒內(nèi)交回給主線程。對(duì)于像動(dòng)畫一樣的高壓點(diǎn),最好的方法就是什么都不做,因?yàn)槟阌肋h(yuǎn)無(wú)法達(dá)到最小絕對(duì)值。
同理,動(dòng)畫的每一幀都需要在16毫秒內(nèi)完成,這樣才能保證每秒60幀(一秒/60=16.6毫秒),如果可以的話最好能在10毫秒內(nèi)完成。因?yàn)闉g覽器需要一定的時(shí)間去在屏幕上渲染新的幀,而且你的代碼需要在16.6毫秒內(nèi)完成執(zhí)行。要注意,上述目標(biāo)應(yīng)用于衡量項(xiàng)目的運(yùn)行性能,而非加載性能。
縱使這個(gè)目標(biāo)實(shí)現(xiàn)起來(lái)非常困難,你的最終目標(biāo)也應(yīng)該是讓開始渲染時(shí)間低于1秒且速度指數(shù)低于1000(在網(wǎng)速快的地方)。對(duì)于首次有效渲染時(shí)間,上限最好是1250毫秒。對(duì)于移動(dòng)端,3G下移動(dòng)設(shè)備首次渲染時(shí)間低于3秒都是可以接受的。稍微高一點(diǎn)也沒關(guān)系,但千萬(wàn)別高太多。
定義你所需要的環(huán)境 4. 選擇和安裝你的開發(fā)環(huán)境不要過多的關(guān)注當(dāng)下最流行的工具,堅(jiān)持選擇適合自己開發(fā)環(huán)境的工具,例如Grunt、Gulp、Webpack、PostCSS,或者組合起來(lái)的工具。只要這個(gè)工具運(yùn)行的速度夠快,而且沒有給你的維護(hù)帶來(lái)太大問題,這就夠了。
5. 漸進(jìn)增強(qiáng)(progressive enhancement)在構(gòu)建前端結(jié)構(gòu)的時(shí)候,應(yīng)始終將漸進(jìn)增強(qiáng)作為你的指導(dǎo)原則。首先設(shè)計(jì)并且構(gòu)建核心體驗(yàn),隨后再完善那些為高性能瀏覽器設(shè)計(jì)的高級(jí)特性的相關(guān)體驗(yàn),創(chuàng)建彈性體驗(yàn)。如果你的網(wǎng)頁(yè)可以在使用低速網(wǎng)絡(luò)、老舊顯示器的很慢的電腦上運(yùn)行飛快,那么在光纖高配電腦上它只會(huì)運(yùn)行的更快。
6. Angular,React,Ember等最好使用那些支持服務(wù)器端渲染的框架。在使用某個(gè)框架錢,先記錄服務(wù)器和客戶端的引導(dǎo)時(shí)間,記得要在移動(dòng)設(shè)備上測(cè)試,最終才能使用某個(gè)框架(因?yàn)槊鎸?duì)的是性能問題,如果在使用某個(gè)框架后,再做修改是非常困難的)。如果你使用JavaScript框架,要保證你的選擇是被廣泛使用并且經(jīng)過考驗(yàn)的。不同框架對(duì)性能有著不同程度的影響,同時(shí)對(duì)應(yīng)著不同的優(yōu)化策略,所以最好可以清楚的了解你要用的框架的每個(gè)方面。在寫網(wǎng)頁(yè)應(yīng)用時(shí)可以先看看PRPL pattern和application shell architecture。
本圖描述了PRPL pattern
上圖是application shell,是一個(gè)小型的、由HTML,CSS和JavaScript構(gòu)成的用戶界面
根據(jù)你整體組織結(jié)構(gòu)的優(yōu)先順序和策略,你可以考慮使用Google的AMP或Facebook的Instant Articles。要知道沒有這些你也可以達(dá)到不錯(cuò)的性能,但是AMP可以提供一個(gè)性能不錯(cuò)的免費(fèi)的內(nèi)容分發(fā)網(wǎng)絡(luò)框架(CDN),Instant Articles可以在Facebook上促進(jìn)你的性能。你也可以建立progressive web AMP。
8. 選擇適合你的CDN根據(jù)你的動(dòng)態(tài)數(shù)據(jù)量,可以將一部分內(nèi)容外包給靜態(tài)網(wǎng)站生成工具,將它置于CDN上,從中生成一個(gè)靜態(tài)版本,從而避免那些數(shù)據(jù)庫(kù)的請(qǐng)求。也可以選擇基于CDN的靜態(tài)主機(jī)平臺(tái),通過交互組件豐富你的頁(yè)面(JAMStack)。
注意CDN是否可以很好的處理(或分流)動(dòng)態(tài)內(nèi)容。沒必要單純的將你的CDN限制為靜態(tài)。反復(fù)檢查CDN是否執(zhí)行了內(nèi)容的壓縮和轉(zhuǎn)化,檢查智能HTTP/2傳輸和緩存服務(wù)器(ESI),注意哪些靜態(tài)或動(dòng)態(tài)的部分處在CDN的邊緣(最接近用戶的服務(wù)器)。
開始優(yōu)化 9. 直接確定優(yōu)化順序首先應(yīng)該弄清楚你想解決的問題是什么。檢查一遍你所有的文件(JavaScript,圖片,字體,第三方script文件以及頁(yè)面中重要的模塊,例如輪播,復(fù)雜信息圖標(biāo)和多媒體內(nèi)容),并將他們分類。
列一個(gè)表格。明確瀏覽器上應(yīng)該有的基礎(chǔ)核心內(nèi)容,哪些部分屬于為高性能瀏覽器設(shè)計(jì)的升級(jí)體驗(yàn),哪些是附加內(nèi)容(那些不必要或者可以被延時(shí)加載的部分,例如字體,不必要的樣式,輪播組件,播放器,社交網(wǎng)站入口,很大的圖片)。更詳細(xì)的細(xì)節(jié)請(qǐng)參考文章”Improving Smashing Magazine’s Performance‘’。
使用符合標(biāo)準(zhǔn)的技術(shù)向過時(shí)的瀏覽器提供核心體驗(yàn),向老式瀏覽器提供增強(qiáng)體驗(yàn), 同時(shí)對(duì)所加載的內(nèi)容要有嚴(yán)格的把控。即首要加載核心體驗(yàn)部分,將增強(qiáng)部分放在DomContentLoaded,把額外內(nèi)容發(fā)在load事件中。
以前我們可以通過瀏覽器的版本推斷出設(shè)備的性能,但現(xiàn)在我們已經(jīng)無(wú)法推測(cè)了。因?yàn)楝F(xiàn)在市場(chǎng)上很多廉價(jià)的安卓手機(jī)都不考慮內(nèi)存限制和CPU性能,直接使用高版本的Chrome瀏覽器。一定要注意,在我們沒有其他選擇的時(shí)候,我們選擇的技術(shù)同時(shí)可能成為我們的限制。
11. 考慮微優(yōu)化和漸進(jìn)啟動(dòng)在一些應(yīng)用中,可以在渲染頁(yè)面前先初始化應(yīng)用。最好先顯示框架,而不是一個(gè)進(jìn)度條或指示器。使用可以加速初始渲染時(shí)間的模塊或技術(shù)(例如tree-shaking和code-splitting),因?yàn)榇蟛糠中阅軉栴}來(lái)自于應(yīng)用引導(dǎo)程序的初始分析時(shí)間。還可以在服務(wù)器上提前編譯,從而減輕部分客戶端的渲染過程,從而快速輸出結(jié)果。最后,考慮使用Optimize.js來(lái)加快初始加載速度,它的原理是包裝優(yōu)先級(jí)高的調(diào)用函數(shù)(雖然現(xiàn)在已經(jīng)沒什么必要了)。
漸進(jìn)啟動(dòng)指的是使用服務(wù)器端渲染,從而快速得到首次有效渲染,這個(gè)渲染過程也包括小部分的JavaScript文件,目的是使交互時(shí)間盡可能的接近首次有效渲染時(shí)間。
到底采用客戶端渲染還是服務(wù)器端渲染?不論哪種做法,我們的目標(biāo)都是建立漸進(jìn)啟動(dòng):使用服務(wù)器端渲染可以得到很短的首次有效渲染時(shí)間,這個(gè)渲染過程也包括小部分的JavaScript文件,目的是使交互時(shí)間盡可能的接近首次有效渲染時(shí)間。接下來(lái),盡可能的增加一些應(yīng)用的非必要功能。不幸的是,正如Paul Lewis所說(shuō),框架基本上對(duì)開發(fā)者是沒有優(yōu)先級(jí)的概念的,因此漸進(jìn)啟動(dòng)在很多庫(kù)和框架上是很難實(shí)施的。如果你有時(shí)間的話,還是考慮使用策略去優(yōu)化你的性能吧。
12. HTTP的緩存頭使用的合理嗎?仔細(xì)檢查一下例如expires,cache-control,max-age以及其他HTTP緩存頭是否被正確的使用。一般來(lái)說(shuō),資源不論在短時(shí)間(如果它會(huì)被頻繁改動(dòng))還是不確定的時(shí)間內(nèi)(如果它是靜態(tài)的)都是可緩存的——你大可在需要的時(shí)候在URL中成改版本。
如果可能,使用為指紋靜態(tài)資源設(shè)計(jì)的Cache-control:immutable,從而避免二次驗(yàn)證(2016年12月,只有FireFox在https://處理中支持)。你可以使用,Heroku的primer on HTTP caching headers,Jake Archibald的 ”Caching Best Practices”,還有IIya Grigorik的HTTP caching primer作為指導(dǎo)。
13. 減少使用第三方庫(kù),加載JavaScript異步操作當(dāng)用戶請(qǐng)求頁(yè)面時(shí),瀏覽器會(huì)抓取HTML同時(shí)生成DOM,然后抓取CSS并建立CSS對(duì)象模型,最后通過匹配DOM和CSS對(duì)象生成渲染樹。在需要處理的JavaScript文件被解決之前,瀏覽器不會(huì)開始對(duì)頁(yè)面進(jìn)行渲染。作為開發(fā)者,我們要明確的告訴瀏覽器不要等待,直接開始渲染。具體方法是使用HTML中的defer和async兩個(gè)屬性。
事實(shí)上,defer更好一些(因?yàn)閷?duì)于IE9及以下用戶對(duì)于IE9及以下用戶,很有可能會(huì)中斷腳本)。同時(shí),減少第三方庫(kù)和腳本的使用,尤其是社交網(wǎng)站的分享按鍵和嵌入(比如地圖)。你可以使用靜態(tài)的社交網(wǎng)站分享按鍵(例如SSBG的)和指向交互地圖的靜態(tài)鏈接去代替他們。
14. 圖片是否被正確優(yōu)化?盡可能的使用帶有srcset,sizes還有元素的響應(yīng)式圖片。你也可以利用元素的WebP格式,用JPEG格式作為替補(bǔ)(參見Andreas Bovens的code snippet)或是使用內(nèi)容協(xié)商(使用接受頭)。Sketch原本就支持WebP,WebP圖片可以直接被Photoshop的WebP plugin導(dǎo)出。當(dāng)然也有很多其他方法。
響應(yīng)圖片斷點(diǎn)生成器可自動(dòng)處理圖片
你也可以使用客戶端提示,現(xiàn)在瀏覽器也可以做到。在用來(lái)生成響應(yīng)圖片的源文件過少時(shí),使用響應(yīng)圖片斷點(diǎn)生成器或類似Cloudinary的服務(wù)自動(dòng)的優(yōu)化圖片。在很多案例中,多帶帶使用sreset和sizes都帶來(lái)了很大的收益。在本網(wǎng)站上,我們給文件添加-opt后綴——例如brotli-compression-opt.png;這樣團(tuán)隊(duì)的每一個(gè)人就知道這些帶著后最的圖片是被優(yōu)化過的。
15. 圖片的進(jìn)一步優(yōu)化當(dāng)你在編寫登陸界面的時(shí)候,發(fā)現(xiàn)頁(yè)面上的圖片加載的特別快,這時(shí)你需要確認(rèn)一下JPEG格式文件是否已經(jīng)通過mozJPEG(它可以操作掃描等級(jí)從而提高渲染時(shí)間)優(yōu)化和壓縮,PNG格式對(duì)應(yīng)Pingo,GIF需要用到Lossy GIF,SVG要使用SVGOMG。對(duì)圖片不重要的部分進(jìn)行模糊處理(使用高斯模糊過濾器處理他們),從而減少文件大小,最后你可能還要去彩色化使圖片變成黑白,從而減少更多的容量。對(duì)于背景圖片,使用Photoshop保持0到10%的質(zhì)量輸出是絕對(duì)可以接受的。
如果你還覺得不夠,那你可以通過多重背景圖片技術(shù)來(lái)提高圖片的感知性能。
16. 網(wǎng)頁(yè)字體優(yōu)化了嗎?你用來(lái)修飾網(wǎng)頁(yè)字體的服務(wù)很有可能毫無(wú)用處,包括字形和額外的特性。如果你在使用開源的字體,嘗試用字體庫(kù)中某一個(gè)小的子集或是自己歸類一個(gè)小的子集從而壓縮文件大小(例如通過一些特殊的注音符號(hào)引用Latin)。WOFF2 support是個(gè)非常不錯(cuò)的選擇,如果瀏覽器不支持,那你可以將WOFF和OTF作為備用。你也可以從Zach Leatherman的“Comprehensive Guide to Font-Loading Strategies”一文中選擇一個(gè)合適的策略,然后使用服務(wù)器來(lái)緩存字體。如果想要快速入門,Pixel Ambacht的教程與案例會(huì)讓你的字體變得盡然有序。
Zach Leatherman的“Comprehensive Guide to Font-Loading Strategies”提供了一打可以讓字體傳輸變得更好的選項(xiàng)
如果你用的是第三方服務(wù)器主機(jī),沒辦法自己在服務(wù)器上對(duì)字體進(jìn)行操作,一定看看Web Font Loader。FOUT is better than FOIT中提到,在備選情況下立即渲染文本,并且異步加載字體——你也可以使用loadCSS實(shí)現(xiàn)這個(gè)。你可能也會(huì)避免本地OS上安裝字體。
17. 快速執(zhí)行關(guān)鍵部分的CSS為了確保瀏覽器盡可能快的渲染你的頁(yè)面,先收集頁(yè)面首次可見部分的CSS文件(也叫決定性CSS或上半版CSS)進(jìn)行渲染,然后將它加入頁(yè)面的
部分,從而避免重復(fù)操作。因?yàn)槁龁?dòng)階段對(duì)交換包大小的限制,你關(guān)鍵CSS文件的大小也被限制在14KB左右。如果高于這個(gè)值,瀏覽器需要重復(fù)一些步驟來(lái)獲取更多的樣式。關(guān)鍵CSS是允許你這樣做的。可能對(duì)每個(gè)模板都需要這個(gè)操作。如果可能,考慮一下用Fiament Group用的條件內(nèi)斂方法。通過HTTP/2,關(guān)鍵CSS可以多帶帶存為CSS文件,通過服務(wù)器傳輸,而且可以避免HTML膨脹。服務(wù)器傳輸缺乏連續(xù)支持,并且存在一些超高速緩存的問題(Hooman Beheshti演示的前144頁(yè))。事實(shí)上,這樣會(huì)導(dǎo)致網(wǎng)絡(luò)緩沖區(qū)膨脹。因?yàn)門CP的慢啟動(dòng),服務(wù)器傳輸在穩(wěn)定的連接下會(huì)更有效率。所以你可能需要建立帶有緩存的HTTP/2服務(wù)器傳輸機(jī)制。但請(qǐng)記住,新的cache-digest規(guī)則會(huì)否定手動(dòng)建立的需要緩存的服務(wù)器的請(qǐng)求。
18. 通過tree-shaking和code-splitting減少凈負(fù)載Tree-shaking是通過保留那些在項(xiàng)目過程中真正需要的代碼從而清理你的構(gòu)建過程的一種方式。你可以用Webpack 2來(lái)提出那些沒用的住配置文件,用UnCSS或Helium從CSS中取出不需要的樣式。同理,也可以考慮學(xué)習(xí)一下如何編寫高效的CSS選擇器,以及如何避免膨脹和高費(fèi)的樣式。
Code-splitting是另一個(gè)Webpack特性,它可以根據(jù)按需加載的塊將你的代碼分開。只要你在代碼中定義了分離點(diǎn),Webpack便會(huì)處理好相關(guān)的輸出文件。它基本上能保證你初始下載的內(nèi)容很小,而且在需求被添加時(shí)按需請(qǐng)求代碼。
Rollup所展示的結(jié)果要比Browserify配置文件所顯示的好得多。所以當(dāng)我們想使用類似工具的時(shí)候,或許應(yīng)該看看Rollupify,它將ECMAScript2015模塊變成了一個(gè)更大的CommonJS模塊——因?yàn)樾∧K沒準(zhǔn)有出乎意料的高性能成本,這源自于你對(duì)打包工具模塊系統(tǒng)的選擇。
19. 提升渲染性能使用類似CSS containment的方法對(duì)高消耗組建進(jìn)行隔離,從而限制瀏覽器樣式的范圍,可以作用在為無(wú)canvas的瀏覽工作的布局和裝飾工作中,或是用在第三方工具上。要確保頁(yè)面滾動(dòng)和出現(xiàn)動(dòng)畫效果時(shí)沒有延遲,別忘了之前提到過的每秒60幀的原則。如果沒辦法做到,那就盡可能保證每秒幀數(shù)的大致范圍在15到60幀。使用CSS中的will-change通知瀏覽器哪些元素和屬性發(fā)生了變化。
也記得要衡量渲染執(zhí)行中的性能(可以用DevTools)。可以參照Udacity上Paul Lewis的免費(fèi)課程——瀏覽器渲染優(yōu)化,作為入門。還有一篇Sergey Chikuyonok的文章講了如何正確的用GPU動(dòng)畫。
20. 預(yù)熱網(wǎng)絡(luò)連接,加快傳輸速度使用頁(yè)面框架,對(duì)高消耗組建延遲加載(字體,JS文件,循環(huán)播放,視頻和內(nèi)嵌框架)。使用資源提示來(lái)節(jié)省在dns-prefetch(指的是在后臺(tái)執(zhí)行DNS檢索),preconnect(指要求瀏覽器在后臺(tái)進(jìn)行握手鏈接(DNS,TCP,TLS)),prerender(指要求瀏覽器在后臺(tái)對(duì)特定頁(yè)面進(jìn)行渲染),preload(指的是提前取出暫不執(zhí)行的源文件)。根據(jù)你瀏覽器的支持情況,盡量使用preconnect來(lái)代替dns-prefetch,而且在使用prefetch和prerender要特別小心——后者(prerender)只有在你非常確信用戶下一步操作的情況下再去使用(比如購(gòu)買流程中)。
HTTP/2 21. 準(zhǔn)備好使用HTTP/2Google開始向著更安全網(wǎng)頁(yè)的方向努力,并且將所有Chrome上的HTTP網(wǎng)頁(yè)定義為“不安全”時(shí),你或許應(yīng)該考慮是繼續(xù)使用HTTP/1.1,還是將目光轉(zhuǎn)向HTTP/2環(huán)境。雖然初期投入比較大,但是使用HTTP/是大趨勢(shì),而且在熟練掌握之后,你可以使用service worker和服務(wù)器推送技術(shù)讓行性能再提升一大截。
現(xiàn)在,Google計(jì)劃把所有HTTP頁(yè)面標(biāo)記為不安全,并且將HTTP安全指示器設(shè)置為與Chrome用來(lái)攔截HTTPS的紅色三角相同的圖標(biāo)。
使用HTTP/2的環(huán)境的缺點(diǎn)在于你要轉(zhuǎn)移到HTTPS上,并且根據(jù)你HTTP/1.1用戶的數(shù)量(主要指使用過時(shí)操作系統(tǒng)和過時(shí)瀏覽器的用戶),你需要適應(yīng)不同的建構(gòu)過程,才能發(fā)送不同的建構(gòu)。注意:不論是遷移還是新的構(gòu)建過程都可能非常棘手而且耗時(shí)很多。
22. 適當(dāng)部署HTTP/2重申,使用HTTP/2協(xié)議之前,你需要徹底排查目前為止你所使用協(xié)議的情況。你需要在打包組建和同時(shí)加載很多小組間之間找到平衡。
一方面,你可能想要避免將很多資源鏈?zhǔn)芥溄樱c其將你全部的界面分割成許多小模塊,不如將他們壓縮使之成為建構(gòu)過程的一部分,之后給它們賦予可檢索的信息并加載它們。這樣的話,對(duì)一個(gè)文件將不再需要重新下載整個(gè)樣式清單或JavaScript文件。
另一方面,封裝是很有必要的,因?yàn)橐淮蜗驗(yàn)g覽器發(fā)送太多JavaScript文件會(huì)出問題。首先,壓縮會(huì)造成損壞。得益于dictionary reuse,壓縮大文件不會(huì)對(duì)文件造成損害,壓縮小文件則不然。確實(shí)有方法可以解決這個(gè)問題,但這不是本文討論的范疇。其次,瀏覽器還沒有優(yōu)化到可以對(duì)類似工作流進(jìn)行優(yōu)化。例如,Chrome會(huì)引發(fā)進(jìn)程間通信(IPCs),這些通信的數(shù)量與資源的數(shù)量成正比,而這成百上千個(gè)資源將會(huì)消耗大量的瀏覽器的執(zhí)行時(shí)間。
Chrome的Jake Archibald建議,為了用HTTP/2達(dá)到最好的效果,考慮一下逐步加載CSS文件
當(dāng)然你可以考慮逐步加載CSS文件。很顯然,你這樣做對(duì)HTTP/1.1的用戶非常不利,所以你可能需要根據(jù)不同的瀏覽器建立多個(gè)版本來(lái)應(yīng)對(duì)你的調(diào)度過程,這樣就會(huì)使過程略微復(fù)雜。你也可以避免HTTP/2連接的合并,同時(shí)受益于HTTP/2來(lái)使用域名碎片,但是實(shí)現(xiàn)起來(lái)有些困難。
我們到底應(yīng)該做什么呢?如果你粗略的用過HTTP/2,似乎成功的發(fā)送過10個(gè)左右的包(在老是瀏覽器上運(yùn)行的也不錯(cuò))。那你就能著手開始試驗(yàn)并且為你的網(wǎng)站找到平衡點(diǎn)。
23. 確保服務(wù)器安全可靠所有的瀏覽器都支持HTTP/2并且使用TLS,這是有你可能想要避免安全警告,并刪除頁(yè)面上沒用的元素。好好檢查你的安全頭部是否設(shè)置正確,排除已知的缺陷并檢查證書。
如果還沒有遷移到HTTP, 你那可以先看看HTTPS準(zhǔn)則(The HTTPS-Only Standard)。確保所有外部插件和監(jiān)視腳本都能被HTTPS正確加載,確保沒有跨站腳本出現(xiàn),HTTP腳本傳輸?shù)陌踩^和內(nèi)容安全頭也都設(shè)置正確。
24. 你的服務(wù)器和CDN支持HTTP/2嗎?不同服務(wù)器和CDN對(duì)HTTP/2的兼容性不同,你可以使用TLS夠快嗎?一文來(lái)查看你有什么選擇。
Is TLS Fast Yet?讓你能看看你的服務(wù)器和CDN在使用HTTP/2的時(shí)候你能使用的工具
2015年,Google介紹了Brotli,一個(gè)新的開源無(wú)損數(shù)據(jù)格式,它已經(jīng)被Chrome,F(xiàn)irefox和Opera很好的兼容了。具體使用時(shí),Brotli所顯示出的效率要遠(yuǎn)高于Gzip和Deflate。它根據(jù)不同的配置可能壓縮的時(shí)候會(huì)比較慢,但是壓縮速度慢最后會(huì)讓壓縮效率提高。而且解壓起來(lái)非常快。因?yàn)檫@個(gè)算法來(lái)自Google,所以瀏覽器只在用戶通過HTTPS訪問網(wǎng)頁(yè)的時(shí)候使用它,這個(gè)事情就不奇怪了。Brotli的隱患是它沒辦法在目前大部分服務(wù)器上預(yù)設(shè),而且如果沒有NGINX或者Ubuntu,部署起來(lái)還是有難度的。但其實(shí)你是可以在不支持它的CDN上使用Brotli(通過service worker)。
你可以看看Zopfli壓縮算法作為備選,它將數(shù)據(jù)編碼為Deflate,Gzip和Zlib格式。任何規(guī)范的Gzip壓縮資源都受益于Zopfli改進(jìn)了Deflate編碼,因?yàn)槲募?huì)比Zlib壓縮的最大文件小3%-8%。問題在于文件會(huì)消耗大概80倍的時(shí)間去壓縮。這就是為什么在不怎么會(huì)變得資源上使用Zopfli是不錯(cuò)的選擇,這樣的文件一般都?jí)嚎s一次,下載多次。
26. OCSP裝訂是否可以使用?讓服務(wù)器使用OCSP裝訂,可以提升你TLS握手的速度。線證書狀態(tài)協(xié)議(OCSP)是作為證書廢置列表協(xié)議的代替品被創(chuàng)造出來(lái)的。兩個(gè)協(xié)議都可以用來(lái)檢測(cè)SSL證書是否被取消。然而,OCSP不需要瀏覽器花時(shí)間下載和掃描證書信息的列表,所以它可以減少握手時(shí)間。
27. 你是否開始使用IPv6?因?yàn)槲覀円呀?jīng)沒什么IPv4的地址可用了,而且移動(dòng)網(wǎng)絡(luò)大都開始使用IPv6(美國(guó)已經(jīng)有50%的入口采用IPv6),將你的DNS升級(jí)到IPv6為以后作打算是個(gè)不錯(cuò)的選擇。要確保通網(wǎng)絡(luò)可以支持雙棧協(xié)議——它需要允許IPv6和IPv4同時(shí)運(yùn)行。畢竟IPv6不只是做為后備計(jì)劃的。而且研究顯示,伴隨鄰居發(fā)現(xiàn)(NDP)和路由優(yōu)化,使用IPv6的網(wǎng)站要比普通網(wǎng)站快10%到15%。
28. 是否使用HPACK?如果你在使用HTTP/2,看看你的服務(wù)器有沒有執(zhí)行HPACK對(duì)HTTP的響應(yīng)頭進(jìn)行壓縮,來(lái)減少不必要的消耗。因?yàn)镠TTP/2服務(wù)器相對(duì)較新,所以有些像HPACK這樣的規(guī)格目前還沒有被支持。我們可以用H2spec來(lái)檢查HPACK是否在工作。
H2spec的截圖
沒有經(jīng)過優(yōu)化的網(wǎng)絡(luò)可以比用戶機(jī)器的本地緩存跑得更快。如果你的網(wǎng)站在HTTPS上運(yùn)行,你可以參考“實(shí)用主義者的service workers手冊(cè)”,然后把靜態(tài)資源存在service worker的緩存中,把離線預(yù)設(shè)(甚至離線頁(yè)面)存在用戶機(jī)器方便檢索,這樣比多次進(jìn)行網(wǎng)絡(luò)連接更有效。你還可以參考Jake的離線使用手冊(cè)和免費(fèi)的Udactiy課程“離線網(wǎng)絡(luò)應(yīng)用”。如果瀏覽器支持,那就再好不過了,預(yù)設(shè)就能在任何地方代替網(wǎng)絡(luò)了。
測(cè)試與監(jiān)聽 30. 監(jiān)聽混合內(nèi)容中的警告如果你近期完成了HTTP到HTTPS的遷移,你可以利用類似Report-URI.io一類的對(duì)主動(dòng)和被動(dòng)的混合內(nèi)容警告都進(jìn)行監(jiān)聽。也可以利用混合內(nèi)容掃描器來(lái)對(duì)你使用HTTPS的網(wǎng)頁(yè)進(jìn)行掃描。
31. 你的開發(fā)流程是否使用Devtools進(jìn)行了優(yōu)化?選一個(gè)調(diào)試工具來(lái)對(duì)每一個(gè)按鈕進(jìn)行檢查。確保自己明白如何分析渲染性能和控制臺(tái)輸出、明白如何調(diào)試JavaScript以及編輯CSS樣式。Umar Hansa最近有一個(gè)關(guān)于使用DevTools調(diào)試和測(cè)試的分享,主要包括一些不常用的技巧和技術(shù)。
32. 是否使用代理瀏覽器和過時(shí)瀏覽器測(cè)試過?僅僅使用Chrome和Firefox測(cè)試是不夠的。還應(yīng)該看看你的網(wǎng)頁(yè)在代理瀏覽器和過時(shí)瀏覽器上運(yùn)行的怎么樣。比如UC瀏覽器和Opera Min, 它們?cè)趤喼奘袌?chǎng)的份額很高(高達(dá)35%)。在推廣時(shí),利用目標(biāo)客戶所在國(guó)家的平均網(wǎng)速來(lái)進(jìn)行測(cè)試,避免日后出現(xiàn)大的誤差。同樣的,不僅要在節(jié)流網(wǎng)絡(luò)以及模擬的高數(shù)據(jù)處理設(shè)備上進(jìn)行測(cè)試,還要在真實(shí)設(shè)備上測(cè)試。
33. 有無(wú)建立持續(xù)監(jiān)聽?在進(jìn)行快速、無(wú)限制的測(cè)試時(shí),最好使用一個(gè)個(gè)人的WebPageTest實(shí)例。建立一個(gè)能自動(dòng)預(yù)警的性能預(yù)算監(jiān)聽。建立自己的用戶時(shí)間標(biāo)記從而測(cè)量并監(jiān)測(cè)具體商用的數(shù)據(jù)。使用SpeedCurve對(duì)性能的變化進(jìn)行監(jiān)控,同時(shí)利用New Relic獲取WebPageTest沒法提供的數(shù)據(jù)。SpeedTracker,Lighthouse和Calibre都是不錯(cuò)的選擇。
快速入門這份清單綜合性很強(qiáng),幾乎介紹了所有的可用的優(yōu)化方式。那么,如果你只有一個(gè)小時(shí)進(jìn)行優(yōu)化,你應(yīng)該干什么呢?讓我們從中總結(jié)10個(gè)最有用的來(lái)。別忘了在你開始優(yōu)化前和結(jié)束優(yōu)化后,記錄你的結(jié)果,包括開始渲染時(shí)間以及在3G,有限連接下的速度。
結(jié)語(yǔ)有線連接下,你的目標(biāo)是將開始渲染時(shí)間降低至1s一下,而3G的目標(biāo)是保持在3s一下,SpeedIndex值保持在1000一下。為開始渲染時(shí)間和交互時(shí)間做優(yōu)化。
為你主要的模板準(zhǔn)備關(guān)鍵CSS文件,將它們放在頁(yè)面的中(你可以使用14KB)。
對(duì)于你自己和第三方的腳本文件,盡可能的延遲加載它們——尤其是社交網(wǎng)站按鈕,播放器和高消耗的JavaScript文件。
使用更快的dns-lookup,preconnect,prefetch,preload和prerender添加資源提示,從而加快傳輸速度。
將字體一類屬性作為子集,異步加載(或者使用系統(tǒng)字體代替)。
優(yōu)化圖片,并考慮在關(guān)鍵頁(yè)中使用WebP(例如登陸頁(yè)面)。
確保HTTP的緩存頭和安全頭都被正確的設(shè)置。
在服務(wù)器上使用Brotli或Zopfli壓縮算法。(如果不支持這兩個(gè),嘗試一下Gzip)
如果HTTP/2可用,使用HPACK壓縮算法,并監(jiān)聽混合內(nèi)容的警告。如果你在使用LTS,就可以使用OCSP裝訂。
如果可能,將類似字體,JavaScript文件以及圖片緩存在service worker緩存中——事實(shí)上越多越好!
文中提到的一些優(yōu)化可能超出了你工作的范圍,有的可能超出了你的預(yù)算,有的甚至對(duì)你正在使用的有些過時(shí)的代碼判了死刑。但沒關(guān)系,本文只是一個(gè)普通大綱(希望能做到綜合性強(qiáng)),你應(yīng)該根據(jù)自己的工作環(huán)境列一份適合自己的清單。最重要的,在開始優(yōu)化之前,先對(duì)項(xiàng)目中存在的問題有一個(gè)明確的了解。最后,祝大家2017年優(yōu)化順利!
----------------------------------我們需要的小伙伴------------------------------------
工作職責(zé):
-Web前端的功能設(shè)計(jì)、開發(fā)和優(yōu)化,開發(fā)可重用模塊
-實(shí)現(xiàn)與視覺稿、交互稿一致的跨平臺(tái)、瀏覽器、客戶端,兼容性好的移動(dòng)端頁(yè)面和PC頁(yè)面
-前沿技術(shù)研究和新技術(shù)調(diào)研,
職位要求:
-精通JavaScript/HTML5/CSS3等相關(guān)前端開發(fā)技術(shù),熟悉頁(yè)面架構(gòu)和布局,有良好的程序設(shè)計(jì)和架構(gòu)能力;
-精通vue或react; 熟悉并熟練使用es6語(yǔ)法,熟悉node.js;
-掌握前端調(diào)試、性能優(yōu)化、工程化等開發(fā)等相關(guān)技術(shù);
-具有至少一年以上移動(dòng)端網(wǎng)頁(yè)開發(fā)經(jīng)驗(yàn);
-對(duì)web技術(shù)鉆研有強(qiáng)烈興趣,有良好的學(xué)習(xí)能力和強(qiáng)烈的進(jìn)取心,能主動(dòng)跟進(jìn)新技術(shù)發(fā)展動(dòng)態(tài)優(yōu)先 ;
-學(xué)習(xí)能力強(qiáng),強(qiáng)烈的責(zé)任心,具有較強(qiáng)的溝通能力及團(tuán)隊(duì)合作精神 ;
-有較強(qiáng)的產(chǎn)品理解,能從技術(shù)角度推動(dòng)產(chǎn)品優(yōu)化;
-思維縝密、思路清晰,較好的邏輯分析能力;
-了解一門后臺(tái)語(yǔ)言(php或java)者優(yōu)先;
有意向的同學(xué),請(qǐng)發(fā)送簡(jiǎn)歷到 xuheng@baidu .com :)
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/81225.html
摘要:感謝王下邀月熊分享的前端每周清單,為方便大家閱讀,特整理一份索引。王下邀月熊大大也于年月日整理了自己的前端每周清單系列,并以年月為單位進(jìn)行分類,具體內(nèi)容看這里前端每周清單年度總結(jié)與盤點(diǎn)。 感謝 王下邀月熊_Chevalier 分享的前端每周清單,為方便大家閱讀,特整理一份索引。 王下邀月熊大大也于 2018 年 3 月 31 日整理了自己的前端每周清單系列,并以年/月為單位進(jìn)行分類,具...
摘要:前端每周清單年度總結(jié)與盤點(diǎn)在過去的八個(gè)月中,我?guī)缀踔蛔隽藘杉拢ぷ髋c整理前端每周清單。本文末尾我會(huì)附上清單線索來(lái)源與目前共期清單的地址,感謝每一位閱讀鼓勵(lì)過的朋友,希望你們能夠繼續(xù)支持未來(lái)的每周清單。 showImg(https://segmentfault.com/img/remote/1460000010890043); 前端每周清單年度總結(jié)與盤點(diǎn) 在過去的八個(gè)月中,我?guī)缀踔蛔隽?..
摘要:楊冀龍是安全焦點(diǎn)民間白帽黑客組織核心成員,被浪潮之巔評(píng)為中國(guó)新一代黑客領(lǐng)軍人物之一他在本文中依次分享了對(duì)于黑客的定義如何從黑客成為一名安全創(chuàng)業(yè)者技術(shù)創(chuàng)業(yè)踩過的坑給技術(shù)創(chuàng)業(yè)者建議等內(nèi)容。 showImg(https://segmentfault.com/img/remote/1460000012377230?w=1240&h=796); 前端每周清單專注前端領(lǐng)域內(nèi)容,以對(duì)外文資料的搜集為...
摘要:性能最好具有可量化可監(jiān)測(cè)以及可改動(dòng)的特性。下文是一份年的前端性能優(yōu)化清單,闡述了作為前端開發(fā)人員,為了確保反饋速度以及瀏覽器兼容性我們需要考慮的問題。地圖設(shè)計(jì)的決定違背了性能理念,所以他在這份清單內(nèi)的順序有待考慮。 2017前端性能優(yōu)化清單 你開始使用漸進(jìn)啟動(dòng)了么?是不是已經(jīng)使用過React和Angular中tree-shaking和code-splitting兩個(gè)工具?有沒有用過Br...
閱讀 2380·2021-10-09 09:41
閱讀 3172·2021-09-26 09:46
閱讀 835·2021-09-03 10:34
閱讀 3150·2021-08-11 11:22
閱讀 3364·2019-08-30 14:12
閱讀 710·2019-08-26 11:34
閱讀 3343·2019-08-26 11:00
閱讀 1749·2019-08-26 10:26