1、如何進行web前端性能優化
1，css精靈！
2，代碼壓縮
3，高質量的JS代碼肯定能省很多事！封裝JS，重復調用方法！這樣會減少很多操作
4，請減少對DOM的操作
5，使用JSON格式來進行數據交換
6，高效使用HTML標簽和CSS樣式
7，使用CDN加速（內容分發網路）
8，精簡CSS和JS文件
9，注意控制Cookie大小和污染
2、web前端網站性能優化怎麼壓縮傳輸
壓縮可以對純文本可以壓縮至原內容的40%, 從而節省了60%的數據傳輸，GZIP是一種常用的壓縮編碼。因此，對文本類型的資源如CSS、JS、HTML啟用GZIP壓縮加速http傳輸速度。推薦你去三人行慕課上學習，比較全面
3、常見的前端性能優化手段都有哪些？都有多大收益
規則01：盡量減少HTTP請求
前端優化的黃金准則指導著前端頁面的優化策略：只有10%-20%的最終用戶響應時間花在接受請求的HTML文檔上，剩下的80%-90%時間花在為HTML文檔所引用的所有組件（圖片、腳本、樣式表等）進行的HTTP請求上。因此，改善響應時間的最簡單途徑就是減少組件的數量，並由此減少HTTP請求的數量。當然很多人就會說，既然這樣，那我們就減少頁面組件的數量不就OK了嗎？那你試試，你會掀起一場性能優化和產品設計之間的大PK。
所以，我們要減少HTTP請求是要平衡性能和設計的。如果找到這個平衡點呢？書中從以下幾個方面做了介紹，我逐一說明：
① 圖片地圖
初看「圖片地圖」四個字，對非專業的前端人員來說一頭霧水，我的第一印象就是這樣的，咱們以京東的移動站點為例，右側用戶和購物車的圖標，正常實現我會選擇如下方式：
<a href=」用戶跳轉頁面URL」>
<div class=」定義用戶icon顯示的樣式表」></div>
</a>
<a href=」購物車跳轉頁面URL」>
<div class=」 定義用戶icon顯示的樣式表」></div>
</a>
這種方式無可厚非的，但是兩張圖片就有兩個HTTP請求，這明顯是增加了頁面中的HTTP請求。那麼我們可以把這兩個HTTP請求變成一個嗎？
答案當然是可以的，這就是圖片地圖：允許在一張圖片上關聯多個URL，而目標URL的選擇取決於用戶單擊了圖片上的哪個位置。
這樣上面京東兩個圖標合並成一張圖片，這樣圖片的HTTP請求就減少了一個。
示例代碼如下：
<img src=合並後的圖片>
<map name=」map1」>
<areashape=」rect」 coords=」0,0,40,40」 href=」用戶跳轉頁面URL」>
<areashape=」rect」 coords=」50,0,90,40」 href=」購物車跳轉頁面URL」>
</map>
不過圖片地圖只支持矩形形狀，其他形狀不支持。
② 請CSS喝「雪碧」（CSS Sprites）CSS Sprites一句話：將多個圖片合並到一張單獨的圖片，這樣就大大減少了頁面中圖片的HTTP請求。
③ 內聯圖片和腳本使用data:URL（Base64編碼）模式直接將圖片包含在Web頁面中而無需進行HTTP請求。但是此種方法存在明顯缺陷：- 不受IE的歡迎；- 圖片太大不宜採用這種方式，因為Base64編碼之後會增加圖片大小，這樣頁面整體的下載量會變大；- 內聯圖片在頁面跳轉的時候不會被緩存。（大圖片可以使用瀏覽器的本地緩存，在首次訪問的時候保存到瀏覽器緩存中，典型的是HTML5的manifest緩存機制以及LocalStorage等）。
④ 樣式表的合並將頁面樣式定義、腳本、頁面本身代碼嚴格區分開，但是樣式表、腳本也不是分割越細越好，因為沒多引用一個樣式表就增加一次HTPP請求，能合並的樣式表盡量合並。一個網站有一個公用樣式表定義，每個頁面只要有一個樣式表就OK啦。
通過以上四個努力之後，你會發現你的網頁響應時間最多能減少一半，這不是作者說大話，也不是我狂吹，我親手用我的移動網站首頁做了一個嘗試，本地測試之後響應時間能減少40%左右。所以減少頁面HTTP請求數量，是一個很重要的原則。遵循此原則可以同時改善首次訪問和後續訪問的響應時間，而每一個網站的首次響應時間會決定用戶之後還來不來的重要原因。
規則02：使用內容發布網路（CDN的使用）
什麼叫內容發布網路（CDN）？它是一組分布在多個不同地理位置的Web伺服器，用於更加有效地向用戶發布內容。主要用於發布頁面靜態資源：圖片、css文件、js文件等。如此，能輕易地提高響應速度。關於CDN的具體詳細原理以及優缺點，各位可以自行詢問度娘或者google。
規則03：添加Expires頭
瀏覽器使用緩存來減少HTTP請求的數據，並減小HTTP響應的大小，使頁面載入更快。Web伺服器使用Expires頭來告訴瀏覽器它可以使用一個組件的當前副本，直到指定的deadline為止。HTTP規范中稱此頭為：在這一時間之後響應被認為失效。個人對這塊表示不想使用，其實就是一句話，把一些css、js、圖片在首次訪問的時候全部緩存到瀏覽器本地，從我做移動網站的過程中發現，其實沒有這么復雜，完全可以使用HTML5提供的本地緩存機制就OK了。關於HTML5本地緩存機制，各位可以查閱相關資料。後續我也會對HTML5的緩存機制進行介紹的。
規則04：壓縮組件（使用Gzip方式）
書中關於壓縮從gzip壓縮方式到如何壓縮講了很多，我想直接跳過，對於做PC網站或者移動網站來說，急需要壓縮的是css文件和js文件，至於如何壓縮，網上有很多在線工具，去挑選一個自己用的順手看的順眼的就好，當然也有人選擇對HTML進行壓縮，這樣也可以。但是實際工作中我沒有這么做。之所謂沒有這么做，是因為我覺得很麻煩。不要鄙視我，畢竟我不是一個真正意義上的前端工程師，哈哈！
規則05：將CSS樣式表放在頂部
如果將css樣式定義放在頁面中或者頁面底部，會出現短暫白屏或者某一區域短暫白板的情況，這和瀏覽器的運營機制有關的，不管頁面如何載入，頁面都是逐步呈現的。所以在每做一個頁面的時候，用Link標簽把每一個樣式表定義放在head中。
規則06：將javascript腳本放在底部
瀏覽器在載入css文件時，頁面逐步呈現會被阻止，直到所有css文件載入完畢，所以要把css文件的引用放到head中去，這樣在載入css文件時不會組織頁面的呈現。但是對於js文件，在使用的時候，它下面所有也頁面內容的呈現都會被阻塞，將腳本放在頁面越靠下的地方，就意味著越多的內容能夠逐步呈現。
規則07：避免使用CSS表達式
CSS表達式是動態玩CSS的一種很強大的方式，但是強大的同時也存在很高的危險性。因為css表達式的頻繁求值會導致css表達式性能低下。如果真想玩css表達式，可以選用只求值一次的表達式或者使用事件處理來改變css的值。
規則08：使用外部javascript和CSS內聯js和css其實比外部文件有更快的響應速度，那為什麼還要用外部呢？因為使用外部的js和css可以讓瀏覽器緩存他們，這樣不僅HTML文檔大小減少，而且不會增加HTTP請求數量。另外，使用外部js和css可以提高組件的可復用性。
規則09：減少DNS查詢
DNS查詢有時間開銷，通常一個瀏覽器查找一個給定主機名的IP地址需要20-120ms。緩存DNS：緩存DNS查詢可以很好地提高網頁性能，一旦緩存了DNS查詢，之後對於相同主機名的請求就無需進行再次的DNS查找，至少短時間內不需要。所以在使用頁面中URL、圖片、js文件、css文件等時，不要使用過多不同的主機名。
規則10：精簡javascript
如何精簡？
其實W3Cfuns已經給大家准備好精簡JS所需的所有工具「前端神器」，這點W3Cfuns為大家做的很不錯，在這個規則里我們就用到「JS壓縮/混淆/美化工具」
最初始的精簡方式：就是移除不必要的字元減小js文件大小，改善載入時間。包括所有的注釋、不必要的空白字元。
高級一點的精簡方式就是：混淆。
它不但會移除不必要的字元，還會改寫代碼，比如函數和變數的名字會被改成很短的字元串，這樣使js代碼更簡練更難閱讀。
但是我一般很少使用混淆，一個現在互聯網時代，代碼沒有必要整的那麼神秘，大可以大家一起share，天下代碼一起抄，只要抄出自己的特色就ok了。
而且一旦使用混淆，對於js代碼的維護和調試都很復雜，因為有時候混淆之後的js代碼完全看不懂。其實實際開發過程中，從文件大小和代碼可復用性來說，不僅僅是js代碼需要精簡，css代碼一樣也很需要精簡。
規則11：避免重定向
重定向的英文是Redirect，用於將用戶從一個URL重新跳轉到另一個URL。
最常見的Redirect就是301和302兩種。
關於重定向的性能影響這里就不說了，自行查閱相關資料吧。
在我們實際開發中避免重定向最簡單也最容易被忽視的一個問題就是，設置URL的時候，最後的「/」，有些人有時候會忽略，其實你少了「/」，這時候的URL就被重定向了，所以在給頁面鏈接加URL的時候切記最後的「/」不可丟。
規則12：刪除重復腳本
重復的js代碼除了有不必要的HTTP請求之外，還會浪費執行js的時間。
將你使用的js代碼模塊化，可以很好地避免這個問題，至於js模塊化如何實現，現在有很多可以使用的開源框架，我用的比較多的是我們公司玉伯的Sea.js。
規則13：配置ETag
Etag（Entity Tag），實體標簽，是Web伺服器和瀏覽器用戶確認緩存組件的有效性的一種機制。寫的很復雜，對我這種非專業的前端開發人員來說，有點過了，關於這個原則有興趣的自己看吧。
規則14：使Ajax可緩存
針對頁面中主動的Ajax請求返回的數據要緩存到本地，當然這個是針對短期內不會變化的數據。如果不確定數據變化周期的話，可以增加一個修改標識的判斷，我正常處理過程中會給一些Ajax請求返回的數據增加一個MD5值的判斷，每次請求會判斷當前MD5是否變化，如果變化了取最新的數據，如果不變化，則不變。
4、簡單談談前端性能優化
這個話題，賊大。
個人認為：核心在於，HTTP 請求的減少版和請求包大小的減少再加上對代碼的重構。權
HTTP 請求的減少，瞧瞧現在的前端工程化，工程化的作用之一正是將那些散亂的 js 、css 庫全部都集成起來，壓縮成一個文件，這么多文件壓縮成一個，這請求不就減少了么~還有一個就是」精靈圖技術「也是優化的體現，就不展開了。
請求包大小的減少，這個簡直是能減就減啊，比如以前的時候，我們需要將圖片直接發送到瀏覽器上是吧，現在可以不用！如果只是發生一段代碼到客戶的瀏覽器上，然後客戶用自己的機器生成圖片，這得有多快啊，畢竟一段代碼大還是一張圖片大還是很容易分清的，特別的是 GIF 圖！這時候用上 svg 或是 canvas 技術，就不需要發送巨大的 GIF 圖片了，只需要調用瀏覽器的資源生成圖像即可。
重構，反正不滿意重構就是了，滿意了加功能然後繼續重構就是了。
但這都是還只是皮毛啊這是，如果用到框架，那還要講到框架的優化，因為前端框架的優化同樣是性能優化，那都能寫幾十頁了都......
如果再深入講到瀏覽器自身......啊，要死了死了，技術是無窮的，命是有限的！
5、常用的前端性能優化方法有哪些?
1、減少http請求，合理設置 HTTP緩存
2、使用瀏覽器緩存
3、啟用壓縮
4、CSS Sprites，合並 CSS圖片，減少請求數
5、CSS放在頁面最上部，javascript放在頁面最下面
6、在前端性能優化中，html壓縮有沒有必要
1, 只有在原始網頁抄文件比襲較大時候，HTML壓縮才會節省一些空間
2, 只要伺服器開啟Gzip壓縮，網頁HTML是否壓縮對整個網頁傳送體積影響不大
總結：HTML壓縮本身對網站性能提升意義不大，很多時候只是起到混淆一下代碼作用讓其他人難以查看而已。當你的訪客足夠多的時候，節省一個位元組的大小可能都會導致大量的成本節省。
7、前端性能優化中，為什麼設置style屬性會導致reflow
請問 reflow 是什麼意思？我做了5年網頁，都沒有聽說過這個單詞。
現在的設備性能版很好的，優權化樣式性能基本上是沒有意義的，現在是開發效率至上的時代。
以前是不推薦用 style 屬性的，因為不能作為類復用，但是現在不同了，太特殊的樣式，比如就某一個頁面某一個標簽用到，為他而設一個類，還要想名字，還要在樣式表中找到它的爸爸，是非常浪費時間的，現在開發網頁，很經常用到 style 標簽或屬性。
8、web前端網站性能優化怎麼優化引用文件位置
有一些插件需要引用到遠程的圖片、CSS、JS、圖標等，如果遠程的資源連接網速不佳，如國外的某些資源，會造成網頁阻塞，同樣也會造成頁面展示問題，盡量能把引用遠程的資源能本地化。推薦你去三人行慕課上學習，比較全面
9、前端性能優化什麼意思
如果前端優化得好，他不僅可以為企業節約成本，他還能給用戶帶來更多的用戶，因為增強的用戶體驗。說了這么多，那麼我們應該如何對我們前端的頁面進行性能優化呢？一般說來，web前端指網站業務邏輯之前的部分，包括瀏覽器載入、網站視圖模型、圖片服務、CDN服務等，主要優化手段有瀏覽器訪問、使用反向代理才、CDN等。