『壹』 前端性能優化之路——圖片篇。
本人是一名前端開發者，在公司負責目前負責信息流服務，為五大手機廠商和各大App提供服務，每天的請求就是以億計算，加上我們又做了SSP和DSP，就是類似於網路廣告聯盟，騰訊廣點通這種。接觸過的應該知道，所以前端優化一直是我頭痛的問題，不僅要注重用戶體驗，同時要兼顧收益，有時候必須犧牲一些用戶體驗，但是作為一名有思想的前端，還是努力規避掉，希望能和從事相同業務的同學一起學習交流一下，話不多說，就來分享我的性能優化之路，有什麼不對的知識點，麻煩大家指出批評。
yahoo軍規把大部分的前端優化都提到了，而在js優化這一塊如果有興趣的額，推薦大家去看《 高性能javascript 》,書里講的非常詳細。 https://segmentfault.com/a/1190000008481413
Media Queries 調用高清背景圖
通過 devicePixelRatio的值，就可以區分普通顯示屏和高清屏，當devicePixelRatio值等於1時（也就是最小值），那麼它普通顯示屏，當devicePixelRatio值大於1(通常是1.5、2.0)，那麼它就是高清顯示屏。這時候我們可以讓UI准備2套圖片，甚至是3套圖片，不同像素的圖利用媒體查詢結合 devicePixelRatio 可以區分普通顯示屏和高清顯示屏，並給出了如下CSS設計方案：
也可以用less或者sass
如果省時間通用性高，就像我們是服務端用nginx對圖片進行處理，想要什麼樣尺寸的圖片自己裁切,我們提供了按比例縮放和自定尺寸的裁切方法，地址後拼接字元串就行。
與其他圖片格式相比，在肉眼無法分辨圖片質量差異的情況下，WebP的空間佔用是最小的，目前國內外各大互聯網公司都已經開始應用這一圖片格式。比如美團
想實現首先是判斷，即識別單次訪問的來源瀏覽器是否支持 webp 格式，其次是執行，如果該瀏覽器支持，則將原圖替換為 webp 格式，並返回。如果不支持，則顯示原格式圖片。 http://caniuse.mojijs.com/Home/Html/item/key/webp/index.html
在識別階段，我們有兩種方法：
1. Server 處理
只要有請求，服務端就能拿到你的User-Agent信息，通過對瀏覽器進行分類，支持webp放在白名單里，不支持的則為黑名單。判斷為白名單，則直接調用，返回webp格式圖片；反之，則顯示原圖。這種方式的優點在於，只需定期維護白名單即可，邏輯簡單；缺點則在於不可擴展、不可測試、UA判斷會出現不準確的情況。
Server處理中的另一種方式是通過讀取 JavaScript 種下的 cookie來實現判斷。這種方式的優點是表現穩定，訪問速度更快，切換無壓力。但缺點是，頁面靜態化會導致用戶切換瀏覽器時不能自主更新，圖片服務失效。比如用戶用支持webp的瀏覽器A請求頁面，這時緩存的靜態頁面均使用webp圖片，但當該用戶使用不支持webp的瀏覽器B時，訪問網頁則會出現請求不到圖片的報錯。
Client 處理，是美團雲為美團主站提供的處理方式。在這種處理方式中，瀏覽器端發送的beacon webp 請求後，通過檢測其載入情況來判定 webp 支持情況，然後瀏覽器寫一個cookie。之後通過讀取瀏覽器cookie判斷是否支持webp，就可以進行下一步替換操作了。
2.替換圖片過程中也是有兩種處理方式：
在 server 端處理的優點是對下游開發者透明，缺點是靜態頁面的緩存數量會翻倍。
替換方式如下：
在 client 端處理可以比較好地應對頁面靜態化的情況，主要針對懶載入（非首屏）的圖片進行處理，直接通過修改懶載入器來實現。
對非懶載入的圖片暫時沒有特別好的辦法。目前，可用替換路徑的方式來處理。
Client 處理實際上效果也是不錯的，美團頁面里90%以上的圖片都是懶載入的，基本上都可以滿足需求。對於大多數用戶來說，採用Client 處理實現webp轉換是個不錯的選擇。
既然提到圖片這一塊，我有忍不住想扯寫些題外的tracking Pixel（像素追蹤），幾乎所有網站都會做數據的採集，上報統計。特別是我們做SSP、DSP廣告這塊需要獲取例如
數據永遠說的是實話，數據證明一切可能。如facebook廣告投放的跨境電商朋友都會使用facebook Pixel(像素追蹤)以獲得各環節的精準數據。這樣追蹤數據後，我們才能投放廣告後銷量上去了，哪個才是效果最好的，哪個效果不好，進而通過多個數據對比，對廣告進行合理的調整優化。
國內搜狗、網路、360、新浪都是用這種 tracking Pixel 方法，實際就是利用1px 的圖片，在圖片地址後綴拼接你需要的信息參數，瀏覽器在請求任何資源的時候會發送當前系統的數據，比如瀏覽器信息，操作系統信息，作為http請求頭送過去，他們就能統計了。
為什麼不用js請求統計？
並不是所有的頁面都支持JS的！NoJSStats的實現機制就是網站分析中點擊流數據獲取的方式之一——Web Beacons，即在頁面中嵌入一個1像素的透明圖片，當該頁面被瀏覽時，圖片就會被請求載入，於是在後端的伺服器日誌中就會記錄該圖片的請求日誌，這樣就可以獲得日誌記錄。
例如網路：
本文引用@美團雲 提供的webP方法，感謝。
『貳』 如何進行web前端性能優化
提起Web前端性能優化的問題，前端開發人員非常熟悉，對於一個網站而言，即使內容和功能再優秀，如果用戶需要花費很久的時間才能打開，這樣遲早會消耗用戶的耐心，並最終失去用戶。
那如何才能優化前端性能？歸納為三步
一、關鍵資源位元組數
位元組數也就是通常說的減少資源文件（js、css、image、video...）的大小。
1、壓縮衫螞
前端使用uglify混淆壓縮
後端開啟gzip
對圖片進行壓縮，使用壓縮比例更高的格式（WebP）
2、緩存
強緩存（http狀態碼：200），不用請求服務運納器直接使用本地緩存，協商緩存（http狀態碼：304），使用時先請求伺服器若被告知緩存沒過期則使用本地緩存，不用下載資源，使用localstorage對數據進行存儲。
3、針對首屏優化
對非關鍵資源延遲載入、非同步載入，減少首屏資源大小
二、關鍵資源連接數
1、合並請求
使用http2.0的多路復用合並請求配置combo，在無法使用http2.0的情況下作為一種合並資源請求的手段。
2、減少圖片請求數
使用spite圖，使用svg-symbol。
3、針對一些場景採用css、js內聯的方式。
4、使用強緩存減少了一次伺服器請求。
5、非關鍵資源延遲、非同步載入，減少了首屏資源連接數。
三、關鍵渲染路徑
1、bigpipe分塊輸出
這里主要是因為要完成一整個頁面的輸出後端需要處理很多個任務，我們可以將這些多個任務進行分塊，誰先完成誰就先輸出，最終通過JS回填的方式輸出DOM節點，這種方式主要解決了直出頁面阻塞的問題。
2、bigrender分塊渲染
常規的手段就是採用前端模板渲染頁面，針對首屏時間主要減少了首次構建DOM樹時的節點數
3、針對reflow，repaint，composit路徑處理。
4、涉及到動畫時關於layer的概旁塌沒念renderlayer、graphicslayer。
5、css放在頭部、js放底部避免阻塞DOM樹的構建，關於css、js的位置對於頁面渲染的影響大家可以關注下相關的文章。核心：css資源不會阻塞DOM樹的構建但會阻塞DOM的渲染，JS會阻塞DOM樹的構建，CSS會阻塞JS的執行。
『叄』 你有用過哪些前端性能優化的方法
這個是面試常問的問題了。
我來簡單說下幾個方面：
1.減少http請求：在YUI35規則中也有提到，主要是優化js、css和圖片資源三個方面，因為html是沒有辦法避免的。因此，我們可以做一下的幾項操作：
合並js文件
合並css文件
雪碧圖的使用(css sprite)
使用base64表示簡單的圖片
2.減少資源體積
壓縮css
壓縮js
壓縮圖片
3.圖片載入處理：
圖片預載入
圖片懶載入
首屏載入時進度條的顯示
就簡單說這些，特別詳細的可以網上看下。
『肆』 前端性能優化的具體方法有哪些
解決辦法一：
減少http請求次數：CSS Sprites, JS、CSS源碼壓縮、圖片大小控制合適；網頁Gzip，CDN託管，data緩存 ，圖片伺服器。
前端模板 JS+數據，減少由於HTML標簽導致的帶寬浪費，前端用變數保存AJAX請求結果，每次操作本地變數，不用請求，減少請求次數
用innerHTML代替DOM操作，減少DOM操作次數，優化javascript性能。
當需要設置的樣式很多時設置className而不是直接操作style。
少用全局變數、緩存DOM節點查找的結果。減少IO讀取操作。
避免使用CSS Expression（css表達式)又稱Dynamic properties(動態屬性)。
圖片預載入，將樣式表放在頂部，將腳本放在底部 加上時間戳。
解決辦法二：
減少HTTP請求次數
使用CDN：CDN在前端開發的作用
避免空的src和href
為文件頭指定Expires
使用gzip壓縮內容
把CSS放到頂部
把JS放到底部
避 免使用CSS表達式
將CSS和JS放到外部文件中
避免跳轉
可緩存的AJAX
使用GET來完成AJAX請求
『伍』 前端性能優化總結(一)-js、css優化
移動互聯網時代，用戶對於網頁的打開速度要求越來越高。首屏作為直面用戶的第一屏，其重要性不言而喻。優化用戶體驗更是我們前端開發非常需要 focus 的東西之一。
從用戶的角度而言，當打開一個網頁，往往關心的是從輸入完網頁地址後到最後展現完整頁面這個過程需要的時間，這個時間越短，用戶體驗越好。所以作為網頁的開發者，就從輸入url到頁面渲染呈現這個過程中去提升網頁的性能。
所以輸入URL後發生了什麼呢？在瀏覽器中輸入url會經歷域名解析、建立TCP連接、發送http請求、資源解析等步驟。
http緩存優化是網頁性能優化的重要一環，這一部分我會在後續筆記中做一個詳細總結，所以本文暫不多做詳細整理。本文主要從網頁渲染過程、網頁交互以及Vue應用優化三個角度對性能優化做一個小結。
首先談談拿到服務端資源後瀏覽器渲染的流程：
關鍵渲染路徑是瀏覽器將 HTML、CSS、JavaScript 轉換為在屏幕上呈現的像素內容所經歷的一系列步驟。也就是我們剛剛提到的的的瀏覽器渲染流程。
為盡快完成首次渲染，我們需要最大限度減小以下三種可變因素:
首先，DOM 和 CSSOM 通常是並行構建的，所以 CSS 載入不會阻塞 DOM 的解析。
然而，由於 Render Tree 是依賴於 DOM Tree 和 CSSOM Tree 的，
所以他必須等待到 CSSOM Tree 構建完成，也就是 CSS 資源載入完成(或者 CSS 資源載入失敗)後，才能開始渲染。因此，CSS 載入會阻塞 Dom 的渲染。
由此可見，對於 CSSOM 縮小、壓縮以及緩存同樣重要，我們可以從這方面考慮去優化。
當瀏覽器遇到 script 標記時，會阻止解析器繼續操作，直到 CSSOM 構建完畢，JavaScript 才會運行並繼續完成 DOM 構建過程。
當頁面中元素樣式的改變並不影響它在文檔流中的位置時（例如：color、background-color、visibility 等），瀏覽器會將新樣式賦予給元素並重新繪制它，這個過程稱為重繪。
迴流（Reflow）
當 Render Tree 中部分或全部元素的尺寸、結構、或某些屬性發生改變時，瀏覽器重新渲染部分或全部文檔的過程稱為迴流。
有時即使僅僅迴流一個單一的元素，它的父元素以及任何跟隨它的元素也會產生迴流。現代瀏覽器會對頻繁的迴流或重繪操作進行優化：瀏覽器會維護一個隊列，把所有引起迴流和重繪的操作放入隊列中，如果隊列中的任務數量或者時間間隔達到一個閾值的，瀏覽器就會將隊列清空，進行一次批處理，這樣可以把多次迴流和重繪變成一次。
當你訪問以下屬性或方法時，瀏覽器會立刻清空隊列:
因為隊列中可能會有影響到這些屬性或方法返回值的操作，即使你希望獲取的信息與隊列中操作引發的改變無關，瀏覽器也會強行清空隊列，確保你拿到的值是最精確的。
避免頻繁操作樣式，最好一次性重寫 style 屬性，或者將樣式列表定義為 class 並一次性更改 class 屬性。
避免頻繁操作 DOM，創建一個 documentFragment，在它上面應用所有 DOM 操作，最後再把它添加到文檔中。
也可以先為元素設置 display: none，操作結束後再把它顯示出來。因為在 display 屬性為 none 的元素上進行的 DOM 操作不會引發迴流和重繪。
避免頻繁讀取會引發迴流/重繪的屬性，如果確實需要多次使用，就用一個變數緩存起來。
對具有復雜動畫的元素使用絕對定位，使它脫離文檔流，否則會引起父元素及後續元素頻繁迴流。
圖片懶載入在一些圖片密集型的網站中運用比較多，通過圖片懶載入可以讓一些不可視的圖片不去載入，避免一次性載入過多的圖片導致請求阻塞（瀏覽器一般對同一域名下的並發請求的連接數有限制），這樣就可以提高網站的載入速度，提高用戶體驗。
將頁面中的img標簽src指向一張小圖片或者src為空，然後定義data-src（這個屬性可以自定義命名，我才用data-src）屬性指向真實的圖片。src指向一張默認的圖片，否則當src為空時也會向伺服器發送一次請求。可以指向loading的地址。注意，圖片要指定寬高。
當載入頁面時，先把可視區域內的img標簽的data-src屬性值負給src，然後監聽滾動事件，把用戶即將看到的圖片載入。這樣便實現了懶載入。
事件委託其實就是利用JS事件冒泡機制把原本需要綁定在子元素的響應事件（click、keydown……）委託給父元素，讓父元素擔當事件監聽的職務。事件代理的原理是DOM元素的事件冒泡。
優點：
例如有一個列表需要綁定點擊事件，每一個列表項的點擊都需要返回不同的結果。
傳統寫法：
傳統方法會利用for循環遍歷列表為每一個列表元素綁定點擊事件，當列表中元素數量非常龐大時，需要綁定大量的點擊事件，這種方式就會產生性能問題。這種情況下利用事件委託就能很好的解決這個問題。
改用事件委託：
輸入搜索時，可以用防抖debounce等優化方式，減少http請求；
這里以滾動條事件舉例：防抖函數 onscroll 結束時觸發一次，延遲執行
節流函數：只允許一個函數在N秒內執行一次。滾動條調用介面時，可以用節流throttle等優化方式，減少http請求；
下面還是一個簡單的滾動條事件節流函數：節流函數 onscroll 時，每隔一段時間觸發一次，像水滴一樣
參考鏈接： https://zhuanlan.hu.com/p/113864878?from_voters_page=true
『陸』 前端開發，頁面優化，性能優化有哪些方面
感覺前端的性能確實是很重要的，我談談我在實際項目中的應用。前端的應用主要從以下幾個方面進行優化：
1．減少http請求
HTTP協議是無狀態的應用層協議，意味著每次HTTP請求都需要建立通信鏈路、進行數據傳輸，而在伺服器端，每個HTTP都需要啟動獨立的線程去處理。這些通信和服務的開銷都很昂貴，減少HTTP請求的數目可有效提高訪問性能。減少HTTP的主要手段是合並CSS、合並JavaScript、合並圖片。將瀏覽器一次訪問需要的JavaScript、CSS合並成一個文件，這樣瀏覽器就只需要一次請求。圖片也可以合並，多張圖片合並成一張，如果每張圖片都有不同的超鏈接，可通過CSS偏移響應滑鼠點擊操作，構造不同的URL。
2．使用瀏覽器緩存
對一個網站而言，CSS、JavaScript、Logo、圖標這些靜態資源文件更新的頻率都比較低，而這些文件又幾乎是每次HTTP請求都需要的，如果將這些文件緩存在瀏覽器中，可以極好地改善性能。通過設置HTTP頭中Cache-Control和Expires的屬性，可設定瀏覽器緩存，緩存時間可以是數天，甚至是幾個月。在某些時候，靜態資源文件變化需要及時應用到客戶端瀏覽器，這種情況，可通過改變文件名實現，即更新JavaScript文件並不是更新JavaScript文件內容，而是生成一個新的JS文件並更新HTML文件中的引用。使用瀏覽器緩存策略的網站在更新靜態資源時，應採用批量更新的方法，比如需要更新10個圖標文件，不宜把10個文件一次全部更新，而是應一個文件一個文件逐步更新，並有一定的間隔時間，以免用戶瀏覽器突然大量緩存失效，集中更新緩存，造成伺服器負載驟增、網路堵塞的情況。
3．啟用壓縮
在伺服器端對文件進行壓縮，在瀏覽器端對文件解壓縮，可有效減少通信傳輸的數據量。文本文件的壓縮效率可達80%以上，因此HTML、CSS、JavaScript文件啟用GZip壓縮可達到較好的效果宴襪。但是壓縮對伺服器和瀏覽器產生一定的壓力，在通信帶寬良好，而伺服器資源不足的情況下要權衡考慮。
4．CSS放在頁面最上面、JavaScript放在頁面最下面
瀏覽器會在下載完全部CSS之後才對整個頁面進行渲染，因此最好的做法是將CSS放在頁面最上面，讓瀏覽器盡快下載CSS。JavaScript則相反，瀏覽器在載入JavaScript後立即執行，有可能會阻塞整個頁面，造成頁面顯示緩慢，因此JavaScript最好放在頁面最下面。但如果頁面解析時就需要用到JavaScript，這時放在底閉祥坦部就不合適了。
5．減少Cookie傳輸
Cookie在每次響應請求中，如果太大勢必會影響性能，所以沒必要網cookie放的就不放，針對性的選擇放入cookie的數據。
總之，優化轎桐的方法還很多，我感觸最深的是第4項，有些js文件大引用如果放到最前面對性能損耗很大。
『柒』 前端怎麼優化大數據頁面
1.減少HTTP請求次數
盡量合並圖片、CSS、JS。比如載入一個頁面，如果有5個css文件的話，那麼會發出5次http請求，這樣會讓用戶第一次訪問你的頁面的時候會長時間等待。而如果把這個5個文件合成一個的話，就只需要發出一次http請求，節省網路請求時間，加快頁面的載入。
2.使用CDN
網站上靜態資源即css、js全都使用cdn分發，圖片亦然。
3.避免空的src和href
當link標簽的href屬性為空、script標簽的src屬性為空的時候，瀏覽器渲染的時候會把當前頁面的URL作為它們的屬性值，從而把頁面空襪巧的內容載入進來作為它斗鍵們的值。所以要避免犯這樣的疏忽。
4.為文件頭指定Expires
Exipres是用來設置文件的好乎過期時間的，一般對css、js、圖片資源有效。他可以使內容具有緩存性，這樣下回再訪問同樣的資源時就通過瀏覽器緩存區讀取，不需要再發出http請求