2017前端性能優化清單

2017前端性能優化清單

你開始使用漸進啓動了麼？是否是已經使用過React和Angular中tree-shaking和code-splitting兩個工具？有沒有用過Brotli、Zofli和HPACK這幾種壓縮技術，或者OCSP協議（在線證書狀態協議）？知不知道資源提醒，客戶端提醒和CSS containment一類的技術？瞭解IPv6，HTTP/2和Service Worker這些協議嗎？

回想那些年，你們每每在完成了產品以後纔會去考慮性能。經常把與性能相關的事情拖到項目的最後來作，所作的也不過是對服務器上的config文件進行一些微調、串聯、優化以及部分特別小的調整。而如今，技術已經有了翻天覆地的變化。

一個項目的性能是很是重要的，除了要在技術層面上注意，更要在項目的設計之初就開始考慮，這樣纔可使性能的各類隱形需求完美的整合到項目中，隨着項目一塊兒推動。性能最好具備可量化、可監測以及可改動的特性。網絡愈來愈複雜，對網絡的監控也變得愈來愈難，由於監測的過程會受到包括設備、瀏覽器、協議、網絡類型以及其餘技術（CDN，ISP，緩存，代理服務器，防火牆，負載均衡器和服務器對性能的影響都很大）的很大影響。

下文是一份2017年的前端性能優化清單，闡述了做爲前端開發人員，爲了確保反饋速度以及瀏覽器兼容性咱們須要考慮的問題。

（你也能夠下載checklist PDF或者check in Apple Pages。優化萬歲！）

正文

微優化是保持性能最好的辦法，可是又不能有太過明確的優化目標，由於過於明確的目標會影響在項目中作的每個決定。如下是一些不一樣的模型，請按照本身舒服的順序閱讀。

請準備好而後定下目標！

1. 比你最強的競爭對手快20%

根據一個心理學研究，你的網站最少在速度上比別人快20%，才能讓用戶感受到你的網站比別人的更快。這個速度說的不是整個頁面的加載時間，而是開始加載渲染的時間，首次有效渲染時間（例如頁面須要加載主要內容的時間），或者交互時間（指的是頁面或者應用中主要的頁面加載完成，並主備好與用戶進行交互的時間）。

在Moto G（一箇中端三星設備）和Nexus 4（比較主流的設備）上衡量開始渲染時間（用WebPagetest）以及首頁有效渲染時間（用Lighthouse），最好是在一個開放的實驗室中，使用規範的3G，4G和Wi-Fi連接。

Lighthouse，一個Google開發的新的性能審查工具

你能夠經過你的分析報告看看你的用戶處在哪一個階段，選取其中前90%的用戶體驗來作測試。接着收集數據，建一個表格，篩去20%的數據並預設一個目標（如：性能預算）。如今你能夠將上述兩個值進行對比檢測。若是你始終維持着你的目標而且經過一點一點改變腳本去加快交互時間，那麼上述方法就是合理可行的。

由Brad Frost建立的性能分析

和你的同事分享這份清單。首先要確保團隊中的每一個人都熟悉這份清單。項目中每個決定都會影響性能，若是前端工程師們都在積極的參與項目概念，UX以及視覺設計的決定，這將會給整個項目帶來巨大收益。地圖設計的決定違背了性能理念，因此他在這份清單內的順序有待考慮。

2. 反應時間爲100毫秒，幀數是每秒60幀

RAIL性能模型會爲你提供一個優秀的目標，既盡最大的努力在用戶初始操做後的100毫秒內提供反饋。爲了達到這個目標，頁面須要放棄權限，並將權限在50毫秒內交回給主線程。對於像動畫同樣的高壓點，最好的方法就是什麼都不作，由於你永遠沒法達到最小絕對值。
同理，動畫的每一幀都須要在16毫秒內完成，這樣才能保證每秒60幀（一秒/60=16.6毫秒），若是能夠的話最好能在10毫秒內完成。由於瀏覽器須要必定的時間去在屏幕上渲染新的幀，並且你的代碼須要在16.6毫秒內完成執行。要注意，上述目標應用於衡量項目的運行性能，而非加載性能。

3. 首次有效渲染時間要低於1.25秒，速度指數要低於1000

縱使這個目標實現起來很是困難，你的最終目標也應該是讓開始渲染時間低於1秒且速度指數低於1000（在網速快的地方）。對於首次有效渲染時間，上限最好是1250毫秒。對於移動端，3G下移動設備首次渲染時間低於3秒都是能夠接受的。稍微高一點也不要緊，但千萬別高太多。

定義你所須要的環境

4. 選擇和安裝你的開發環境

不要過多的關注當下最流行的工具，堅持選擇適合本身開發環境的工具，例如Grunt、Gulp、Webpack、PostCSS，或者組合起來的工具。只要這個工具運行的速度夠快，並且沒有給你的維護帶來太大問題，這就夠了。

5. 漸進加強（progressive enhancement）

在構建前端結構的時候，應始終將漸進加強做爲你的指導原則。首先設計而且構建核心體驗，隨後再完善那些爲高性能瀏覽器設計的高級特性的相關體驗，建立彈性體驗。若是你的網頁能夠在使用低速網絡、老舊顯示器的很慢的電腦上運行飛快，那麼在光纖高配電腦上它只會運行的更快。

6. Angular，React，Ember等

最好使用那些支持服務器端渲染的框架。在使用某個框架錢，先記錄服務器和客戶端的引導時間，記得要在移動設備上測試，最終才能使用某個框架（由於面對的是性能問題，若是在使用某個框架後，再作修改是很是困難的）。若是你使用JavaScript框架，要保證你的選擇是被普遍使用而且通過考驗的。不一樣框架對性能有着不一樣程度的影響，同時對應着不一樣的優化策略，因此最好能夠清楚的瞭解你要用的框架的每一個方面。在寫網頁應用時能夠先看看PRPL pattern和application shell architecture。

本圖描述了PRPL pattern

上圖是application shell，是一個小型的、由HTML,CSS和JavaScript構成的用戶界面

7. AMP仍是Instant Articles？

根據你總體組織結構的優先順序和策略，你能夠考慮使用Google的AMP或Facebook的Instant Articles。要知道沒有這些你也能夠達到不錯的性能，可是AMP能夠提供一個性能不錯的免費的內容分發網絡框架（CDN），Instant Articles能夠在Facebook上促進你的性能。你也能夠創建progressive web AMP。

8. 選擇適合你的CDN

根據你的動態數據量，能夠將一部份內容外包給靜態網站生成工具，將它置於CDN上，從中生成一個靜態版本，從而避免那些數據庫的請求。也能夠選擇基於CDN的靜態主機平臺，經過交互組件豐富你的頁面（JAMStack）。

注意CDN是否能夠很好的處理（或分流）動態內容。不必單純的將你的CDN限制爲靜態。反覆檢查CDN是否執行了內容的壓縮和轉化，檢查智能HTTP/2傳輸和緩存服務器（ESI），注意哪些靜態或動態的部分處在CDN的邊緣（最接近用戶的服務器）。

開始優化

9. 直接肯定優化順序

首先應該弄清楚你想解決的問題是什麼。檢查一遍你全部的文件（JavaScript，圖片，字體，第三方script文件以及頁面中重要的模塊，例如輪播，複雜信息圖標和多媒體內容），並將他們分類。
列一個表格。明確瀏覽器上應該有的基礎核心內容，哪些部分屬於爲高性能瀏覽器設計的升級體驗，哪些是附加內容（那些沒必要要或者能夠被延時加載的部分，例如字體，沒必要要的樣式，輪播組件，播放器，社交網站入口，很大的圖片）。更詳細的細節請參考文章」Improving Smashing Magazine’s Performance‘’。

10. 使用符合標準的技術

使用符合標準的技術向過期的瀏覽器提供核心體驗，向老式瀏覽器提供加強體驗, 同時對所加載的內容要有嚴格的把控。即首要加載核心體驗部分，將加強部分放在DomContentLoaded，把額外內容發在load事件中。

之前咱們能夠經過瀏覽器的版本推斷出設備的性能，但如今咱們已經沒法推測了。由於如今市場上不少廉價的安卓手機都不考慮內存限制和CPU性能，直接使用高版本的Chrome瀏覽器。必定要注意，在咱們沒有其餘選擇的時候，咱們選擇的技術同時可能成爲咱們的限制。

11. 考慮微優化和漸進啓動

在一些應用中，能夠在渲染頁面前先初始化應用。最好先顯示框架，而不是一個進度條或指示器。使用能夠加速初始渲染時間的模塊或技術（例如tree-shaking和code-splitting），由於大部分性能問題來自於應用引導程序的初始分析時間。還能夠在服務器上提早編譯，從而減輕部分客戶端的渲染過程，從而快速輸出結果。最後，考慮使用Optimize.js來加快初始加載速度，它的原理是包裝優先級高的調用函數（雖然如今已經沒什麼必要了）。

漸進啓動指的是使用服務器端渲染，從而快速獲得首次有效渲染，這個渲染過程也包括小部分的JavaScript文件，目的是使交互時間儘量的接近首次有效渲染時間。

到底採用客戶端渲染仍是服務器端渲染？不論哪一種作法，咱們的目標都是創建漸進啓動：使用服務器端渲染能夠獲得很短的首次有效渲染時間，這個渲染過程也包括小部分的JavaScript文件，目的是使交互時間儘量的接近首次有效渲染時間。接下來，儘量的增長一些應用的非必要功能。不幸的是，正如Paul Lewis所說，框架基本上對開發者是沒有優先級的概念的，所以漸進啓動在不少庫和框架上是很難實施的。若是你有時間的話，仍是考慮使用策略去優化你的性能吧。

12. HTTP的緩存頭使用的合理嗎？

仔細檢查一下例如expires，cache-control，max-age以及其餘HTTP緩存頭是否被正確的使用。通常來講，資源不論在短期（若是它會被頻繁改動）仍是不肯定的時間內（若是它是靜態的）都是可緩存的——你大可在須要的時候在URL中成改版本。

若是可能，使用爲指紋靜態資源設計的Cache-control:immutable，從而避免二次驗證（2016年12月，只有FireFox在https://處理中支持）。你可使用，Heroku的primer on HTTP caching headers，Jake Archibald的 」Caching Best Practices」，還有IIya Grigorik的HTTP caching primer做爲指導。

13. 減小使用第三方庫，加載JavaScript異步操做

當用戶請求頁面時，瀏覽器會抓取HTML同時生成DOM，而後抓取CSS並創建CSS對象模型，最後經過匹配DOM和CSS對象生成渲染樹。在須要處理的JavaScript文件被解決以前，瀏覽器不會開始對頁面進行渲染。做爲開發者，咱們要明確的告訴瀏覽器不要等待，直接開始渲染。具體方法是使用HTML中的defer和async兩個屬性。

事實上，defer更好一些（由於對於IE9及如下用戶對於IE9及如下用戶，頗有可能會中斷腳本）。同時，減小第三方庫和腳本的使用，尤爲是社交網站的分享按鍵和<iframe>嵌入（好比地圖）。你可使用靜態的社交網站分享按鍵（例如SSBG的）和指向交互地圖的靜態連接去代替他們。

14. 圖片是否被正確優化？

儘量的使用帶有srcset，sizes還有<picture>元素的響應式圖片。你也能夠利用<picture>元素的WebP格式，用JPEG格式做爲替補（參見Andreas Bovens的code snippet）或是使用內容協商（使用接受頭）。Sketch本來就支持WebP，WebP圖片能夠直接被Photoshop的WebP plugin導出。固然也有不少其餘方法。

響應圖片段點生成器可自動處理圖片

你也可使用客戶端提示，如今瀏覽器也能夠作到。在用來生成響應圖片的源文件過少時，使用響應圖片段點生成器或相似Cloudinary的服務自動的優化圖片。在不少案例中，單獨使用sreset和sizes都帶來了很大的收益。在本網站上，咱們給文件添加-opt後綴——例如brotli-compression-opt.png；這樣團隊的每個人就知道這些帶着後最的圖片是被優化過的。

15. 圖片的進一步優化

當你在編寫登錄界面的時候，發現頁面上的圖片加載的特別快，這時你須要確認一下JPEG格式文件是否已經經過mozJPEG（它能夠操做掃描等級從而提升渲染時間）優化和壓縮，PNG格式對應Pingo，GIF須要用到Lossy GIF，SVG要使用SVGOMG。對圖片不重要的部分進行模糊處理（使用高斯模糊過濾器處理他們），從而減小文件大小，最後你可能還要去彩色化使圖片變成黑白，從而減小更多的容量。對於背景圖片，使用Photoshop保持0到10%的質量輸出是絕對能夠接受的。

若是你還以爲不夠，那你能夠經過多重背景圖片技術來提升圖片的感知性能。

16. 網頁字體優化了嗎？

你用來修飾網頁字體的服務頗有可能毫無用處，包括字形和額外的特性。若是你在使用開源的字體，嘗試用字體庫中某一個小的子集或是本身歸類一個小的子集從而壓縮文件大小（例如經過一些特殊的注音符號引用Latin）。WOFF2 support是個很是不錯的選擇，若是瀏覽器不支持，那你能夠將WOFF和OTF做爲備用。你也能夠從Zach Leatherman的「Comprehensive Guide to Font-Loading Strategies」一文中選擇一個合適的策略，而後使用服務器來緩存字體。若是想要快速入門，Pixel Ambacht的教程與案例會讓你的字體變得盡然有序。

Zach Leatherman的「Comprehensive Guide to Font-Loading Strategies」提供了一打可讓字體傳輸變得更好的選項

若是你用的是第三方服務器主機，沒辦法本身在服務器上對字體進行操做，必定看看Web Font Loader。FOUT is better than FOIT中提到，在備選狀況下當即渲染文本，而且異步加載字體——你也可使用loadCSS實現這個。你可能也會避免本地OS上安裝字體。

17. 快速執行關鍵部分的CSS

爲了確保瀏覽器儘量快的渲染你的頁面，先收集頁面首次可見部分的CSS文件（也叫決定性CSS或上半版CSS）進行渲染，而後將它加入頁面的<head>部分，從而避免重複操做。由於慢啓動階段對交換包大小的限制，你關鍵CSS文件的大小也被限制在14KB左右。若是高於這個值，瀏覽器須要重複一些步驟來獲取更多的樣式。關鍵CSS是容許你這樣作的。可能對每一個模板都須要這個操做。若是可能，考慮一下用Fiament Group用的條件內斂方法。

經過HTTP/2，關鍵CSS能夠單獨存爲CSS文件，經過服務器傳輸，並且能夠避免HTML膨脹。服務器傳輸缺少連續支持，而且存在一些超高速緩存的問題（Hooman Beheshti演示的前144頁）。事實上，這樣會致使網絡緩衝區膨脹。由於TCP的慢啓動，服務器傳輸在穩定的鏈接下會更有效率。因此你可能須要創建帶有緩存的HTTP/2服務器傳輸機制。但請記住，新的cache-digest規則會否認手動創建的須要緩存的服務器的請求。

18. 經過tree-shaking和code-splitting減小淨負載

Tree-shaking是經過保留那些在項目過程當中真正須要的代碼從而清理你的構建過程的一種方式。你能夠用Webpack 2來提出那些沒用的住配置文件，用UnCSS或Helium從CSS中取出不須要的樣式。同理，也能夠考慮學習一下如何編寫高效的CSS選擇器，以及如何避免膨脹和高費的樣式。

Code-splitting是另外一個Webpack特性，它能夠根據按需加載的塊將你的代碼分開。只要你在代碼中定義了分離點，Webpack便會處理好相關的輸出文件。它基本上能保證你初始下載的內容很小，並且在需求被添加時按需請求代碼。

Rollup所展現的結果要比Browserify配置文件所顯示的好得多。因此當咱們想使用相似工具的時候，或許應該看看Rollupify，它將ECMAScript2015模塊變成了一個更大的CommonJS模塊——由於小模塊沒準有出乎意料的高性能成本，這源自於你對打包工具模塊系統的選擇。

19. 提高渲染性能

使用相似CSS containment的方法對高消耗組建進行隔離，從而限制瀏覽器樣式的範圍，能夠做用在爲無canvas的瀏覽工做的佈局和裝飾工做中，或是用在第三方工具上。要確保頁面滾動和出現動畫效果時沒有延遲，別忘了以前提到過的每秒60幀的原則。若是沒辦法作到，那就儘量保證每秒幀數的大體範圍在15到60幀。使用CSS中的will-change通知瀏覽器哪些元素和屬性發生了變化。

也記得要衡量渲染執行中的性能（能夠用DevTools）。能夠參照Udacity上Paul Lewis的免費課程——瀏覽器渲染優化，做爲入門。還有一篇Sergey Chikuyonok的文章講了如何正確的用GPU動畫。

20. 預熱網絡鏈接，加快傳輸速度

使用頁面框架，對高消耗組建延遲加載（字體，JS文件，循環播放，視頻和內嵌框架）。使用資源提示來節省在dns-prefetch（指的是在後臺執行DNS檢索），preconnect（指要求瀏覽器在後臺進行握手連接（DNS，TCP，TLS）），prerender（指要求瀏覽器在後臺對特定頁面進行渲染），preload（指的是提早取出暫不執行的源文件）。根據你瀏覽器的支持狀況，儘可能使用preconnect來代替dns-prefetch，並且在使用prefetch和prerender要特別當心——後者（prerender）只有在你很是確信用戶下一步操做的狀況下再去使用（好比購買流程中）。

HTTP/2

21. 準備好使用HTTP/2

Google開始向着更安全網頁的方向努力，而且將全部Chrome上的HTTP網頁定義爲「不安全」時，你或許應該考慮是繼續使用HTTP/1.1，仍是將目光轉向HTTP/2環境。雖然初期投入比較大，可是使用HTTP/是大趨勢，並且在熟練掌握以後，你可使用service worker和服務器推送技術讓行性能再提高一大截。

如今，Google計劃把全部HTTP頁面標記爲不安全，而且將HTTP安全指示器設置爲與Chrome用來攔截HTTPS的紅色三角相同的圖標。

使用HTTP/2的環境的缺點在於你要轉移到HTTPS上，而且根據你HTTP/1.1用戶的數量（主要指使用過期操做系統和過期瀏覽器的用戶），你須要適應不一樣的建構過程，才能發送不一樣的建構。注意：不管是遷移仍是新的構建過程均可能很是棘手並且耗時不少。

22. 適當部署HTTP/2

重申，使用HTTP/2協議以前，你須要完全排查目前爲止你所使用協議的狀況。你須要在打包組建和同時加載不少小組間之間找到平衡。

一方面，你可能想要避免將不少資源鏈式連接，與其將你所有的界面分割成許多小模塊，不如將他們壓縮使之成爲建構過程的一部分，以後給它們賦予可檢索的信息並加載它們。這樣的話，對一個文件將再也不須要從新下載整個樣式清單或JavaScript文件。

另外一方面，封裝是頗有必要的，由於一次向瀏覽器發送太多JavaScript文件會出問題。首先，壓縮會形成損壞。得益於dictionary reuse，壓縮大文件不會對文件形成損害，壓縮小文件則否則。確實有方法能夠解決這個問題，但這不是本文討論的範疇。其次，瀏覽器還沒有優化到能夠對相似工做流進行優化。例如，Chrome會引起進程間通訊（IPCs），這些通訊的數量與資源的數量成正比，而這成百上千個資源將會消耗大量的瀏覽器的執行時間。

Chrome的Jake Archibald建議，爲了用HTTP/2達到最好的效果，考慮一下逐步加載CSS文件

固然你能夠考慮逐步加載CSS文件。很顯然，你這樣作對HTTP/1.1的用戶很是不利，因此你可能須要根據不一樣的瀏覽器創建多個版原本應對你的調度過程，這樣就會使過程略微複雜。你也能夠避免HTTP/2鏈接的合併，同時受益於HTTP/2來使用域名碎片，可是實現起來有些困難。

咱們到底應該作什麼呢？若是你粗略的用過HTTP/2，彷佛成功的發送過10個左右的包（在總是瀏覽器上運行的也不錯）。那你就能着手開始試驗而且爲你的網站找到平衡點。

23. 確保服務器安全可靠

全部的瀏覽器都支持HTTP/2而且使用TLS，這是有你可能想要避免安全警告，並刪除頁面上沒用的元素。好好檢查你的安全頭部是否設置正確，排除已知的缺陷並檢查證書。

若是尚未遷移到HTTP， 你那能夠先看看HTTPS準則（The HTTPS-Only Standard）。確保全部外部插件和監視腳本都能被HTTPS正確加載，確保沒有跨站腳本出現，HTTP腳本傳輸的安全頭和內容安全頭也都設置正確。

24. 你的服務器和CDN支持HTTP/2嗎？

不一樣服務器和CDN對HTTP/2的兼容性不一樣，你可使用TLS夠快嗎？一文來查看你有什麼選擇。

Is TLS Fast Yet？讓你能看看你的服務器和CDN在使用HTTP/2的時候你能使用的工具

25. Brotli和Zopfli兩種壓縮算法還在用嗎？

2015年，Google介紹了Brotli，一個新的開源無損數據格式，它已經被Chrome，Firefox和Opera很好的兼容了。具體使用時，Brotli所顯示出的效率要遠高於Gzip和Deflate。它根據不一樣的配置可能壓縮的時候會比較慢，可是壓縮速度慢最後會讓壓縮效率提升。並且解壓起來很是快。由於這個算法來自Google，因此瀏覽器只在用戶經過HTTPS訪問網頁的時候使用它，這個事情就不奇怪了。Brotli的隱患是它沒辦法在目前大部分服務器上預設，並且若是沒有NGINX或者Ubuntu，部署起來仍是有難度的。但其實你是能夠在不支持它的CDN上使用Brotli（經過service worker）。

你能夠看看Zopfli壓縮算法做爲備選，它將數據編碼爲Deflate，Gzip和Zlib格式。任何規範的Gzip壓縮資源都受益於Zopfli改進了Deflate編碼，由於文件會比Zlib壓縮的最大文件小3%-8%。問題在於文件會消耗大概80倍的時間去壓縮。這就是爲何在不怎麼會變得資源上使用Zopfli是不錯的選擇，這樣的文件通常都壓縮一次，下載屢次。

26. OCSP裝訂是否可使用？

讓服務器使用OCSP裝訂，能夠提高你TLS握手的速度。線證書狀態協議（OCSP）是做爲證書廢置列表協議的代替品被創造出來的。兩個協議均可以用來檢測SSL證書是否被取消。然而，OCSP不須要瀏覽器花時間下載和掃描證書信息的列表，因此它能夠減小握手時間。

27. 你是否開始使用IPv6？

由於咱們已經沒什麼IPv4的地址可用了，並且移動網絡大都開始使用IPv6（美國已經有50%的入口採用IPv6），將你的DNS升級到IPv6爲之後做打算是個不錯的選擇。要確保通網絡能夠支持雙棧協議——它須要容許IPv6和IPv4同時運行。畢竟IPv6不僅是作爲後備計劃的。並且研究顯示，伴隨鄰居發現（NDP）和路由優化，使用IPv6的網站要比普通網站快10%到15%。

28. 是否使用HPACK？

若是你在使用HTTP/2，看看你的服務器有沒有執行HPACK對HTTP的響應頭進行壓縮，來減小沒必要要的消耗。由於HTTP/2服務器相對較新，因此有些像HPACK這樣的規格目前尚未被支持。咱們能夠用H2spec來檢查HPACK是否在工做。

H2spec的截圖

29. service workers是否爲超高速緩存和網絡提供預設機制？

沒有通過優化的網絡能夠比用戶機器的本地緩存跑得更快。若是你的網站在HTTPS上運行，你能夠參考「實用主義者的service workers手冊」，而後把靜態資源存在service worker的緩存中，把離線預設（甚至離線頁面）存在用戶機器方便檢索，這樣比屢次進行網絡鏈接更有效。你還能夠參考Jake的離線使用手冊和免費的Udactiy課程「離線網絡應用」。若是瀏覽器支持，那就再好不過了，預設就能在任何地方代替網絡了。

測試與監聽

30. 監聽混合內容中的警告

若是你近期完成了HTTP到HTTPS的遷移，你能夠利用相似Report-URI.io一類的對主動和被動的混合內容警告都進行監聽。也能夠利用混合內容掃描器來對你使用HTTPS的網頁進行掃描。

31. 你的開發流程是否使用Devtools進行了優化？

選一個調試工具來對每個按鈕進行檢查。確保本身明白如何分析渲染性能和控制檯輸出、明白如何調試JavaScript以及編輯CSS樣式。Umar Hansa最近有一個關於使用DevTools調試和測試的分享，主要包括一些不經常使用的技巧和技術。

32. 是否使用代理瀏覽器和過期瀏覽器測試過？

僅僅使用Chrome和Firefox測試是不夠的。還應該看看你的網頁在代理瀏覽器和過期瀏覽器上運行的怎麼樣。好比UC瀏覽器和Opera Min, 它們在亞洲市場的份額很高（高達35%）。在推廣時，利用目標客戶所在國家的平均網速來進行測試，避免往後出現大的偏差。一樣的，不只要在節流網絡以及模擬的高數據處理設備上進行測試，還要在真實設備上測試。

33. 有無創建持續監聽？

在進行快速、無限制的測試時，最好使用一個我的的WebPageTest實例。創建一個能自動預警的性能預算監聽。創建本身的用戶時間標記從而測量並監測具體商用的數據。使用SpeedCurve對性能的變化進行監控，同時利用New Relic獲取WebPageTest無法提供的數據。SpeedTracker，Lighthouse和Calibre都是不錯的選擇。

快速入門

這份清單綜合性很強，幾乎介紹了全部的可用的優化方式。那麼，若是你只有一個小時進行優化，你應該幹什麼呢？讓咱們從中總結10個最有用的來。別忘了在你開始優化前和結束優化後，記錄你的結果，包括開始渲染時間以及在3G，有限鏈接下的速度。

1. 有線鏈接下，你的目標是將開始渲染時間下降至1s一下，而3G的目標是保持在3s一下，SpeedIndex值保持在1000一下。爲開始渲染時間和交互時間作優化。

2. 爲你主要的模板準備關鍵CSS文件，將它們放在頁面的<head>中（你可使用14KB）。

3. 對於你本身和第三方的腳本文件，儘量的延遲加載它們——尤爲是社交網站按鈕，播放器和高消耗的JavaScript文件。

4. 使用更快的dns-lookup，preconnect，prefetch，preload和prerender添加資源提示，從而加快傳輸速度。

5. 將字體一類屬性做爲子集，異步加載（或者使用系統字體代替）。

6. 優化圖片，並考慮在關鍵頁中使用WebP（例如登錄頁面）。

7. 確保HTTP的緩存頭和安全頭都被正確的設置。

8. 在服務器上使用Brotli或Zopfli壓縮算法。（若是不支持這兩個，嘗試一下Gzip）

9. 若是HTTP/2可用，使用HPACK壓縮算法，並監聽混合內容的警告。若是你在使用LTS，就可使用OCSP裝訂。

10. 若是可能，將相似字體，JavaScript文件以及圖片緩存在service worker緩存中——事實上越多越好！

結語

文中提到的一些優化可能超出了你工做的範圍，有的可能超出了你的預算，有的甚至對你正在使用的有些過期的代碼判了死刑。但不要緊，本文只是一個普通大綱（但願能作到綜合性強），你應該根據本身的工做環境列一份適合本身的清單。最重要的，在開始優化以前，先對項目中存在的問題有一個明確的瞭解。最後，祝你們2017年優化順利！

----------------------------------咱們須要的小夥伴------------------------------------

工做職責：

-Web前端的功能設計、開發和優化，開發可重用模塊
-實現與視覺稿、交互稿一致的跨平臺、瀏覽器、客戶端，兼容性好的移動端頁面和PC頁面
-前沿技術研究和新技術調研，

職位要求：

-精通JavaScript/HTML5/CSS3等相關前端開發技術，熟悉頁面架構和佈局，有良好的程序設計和架構能力；
-精通vue或react； 熟悉並熟練使用es6語法，熟悉node.js；
-掌握前端調試、性能優化、工程化等開發等相關技術；
-具備至少一年以上移動端網頁開發經驗；
-對web技術鑽研有強烈興趣，有良好的學習能力和強烈的進取心，能主動跟進新技術發展動態優先 ；
-學習能力強，強烈的責任心,具備較強的溝通能力及團隊合做精神 ；
-有較強的產品理解，能從技術角度推進產品優化；
-思惟縝密、思路清晰，較好的邏輯分析能力；
-瞭解一門後臺語言(php或java)者優先；

有意向的同窗,請發送簡歷到 xuheng@baidu .com :)