⑴ 如何對前端性能進行優化
前端開發代碼優化、可維護性、瀏覽器兼容性是非常重要的課題。從實際的工程應用角度出發，最常遇見的前端優化問題。前端性能進行優化規則，基本可以涵蓋現在前端大部分的性能優化原則了，很多更加geek和精細優化方法都是從這些原則裡面延伸出來的。
前端性能進行優化都有哪些規則
減少HTTP請求次數
盡量合並圖片、CSS、JS。比如載入一個頁面有5個css文件的話，把這個5個文件合成一個的話，就只需要發出一次http請求，節省網路請求時間，加快頁面的載入。
2. 使用CDN
網站上靜態資源即css、js全都使用cdn分發，包括圖片
3. 避免空的src和href
當link標簽的href屬性為空、script標簽的src屬性為空的時候，瀏覽器渲染的時候會把當前頁面的URL作為它們的屬性值，從而把頁面的內容載入進來作為它們的值。所以要避免犯這樣的疏忽。
4. 為文件頭指定Expires
Exipres是用來設置文件的過期時間的，一般對css、js、圖片資源有效。 他可以使內容具有緩存性，這樣下回再訪問同樣的資源時就通過瀏覽器緩存區讀取，不需要再發出http請求。如下例子：
新浪微博的這個css文件的Expires時間是2016-5-04 09:14:14.
5. 使用gzip壓縮內容
gzip能夠壓縮任何一個文本類型的響應，包括html，xml，json。大大縮小請求返回的數據量。
6. 把CSS放到頂部
網頁上的資源載入時從上網下順序載入的，所以css放在頁面的頂部能夠優先渲染頁面，讓用戶感覺頁面載入很快。
7. 把JS放到底部
載入js時會對後續的資源造成阻塞，必須得等js載入完才去載入後續的文件 ，所以就把js放在頁面底部最後載入。
8. 避免使用CSS表達式
舉個css表達式的例子
font-color: expression( (new Date()).getHours()%3 ? 「#FFFFFF" : 「#AAAAAA" );
這個表達式會持續的在頁面上計算樣式，影響頁面的性能。並且css表達式只被IE支持。
9. 將CSS和JS放到外部文件中
目的是緩存文件，可以參考原則4。 但有時候為了減少請求，也會直接寫到頁面里，需根據PV和IP的比例權衡。
10. 權衡DNS查找次數
減少主機名可以節省響應時間。但同時，需要注意，減少主機會減少頁面中並行下載的數量。
IE瀏覽器在同一時刻只能從同一域名下載兩個文件。當在一個頁面顯示多張圖片時，IE 用戶的圖片下載速度就會受到影響。所以新浪會搞N個二級域名來放圖片。
下面是新浪微博的圖片域名，我們可以看到他有多個域名，這樣可以保證這些不同域名能夠同時去下載圖片，而不用排隊。不過如果當使用的域名過多時，響應時間就會慢，因為不用響應域名時間不一致。
11. 精簡CSS和JS
這里就涉及到css和js的壓縮了。比如下面的新浪的一個css文件，把空格回車全部去掉，減少文件的大小。現在的壓縮工具有很多，基本主流的前端構建工具都能進行css和js文件的壓縮，如grunt，glup等。
12. 避免跳轉
有種現象會比較坑爹，看起來沒什麼差別，其實多次了一次頁面跳轉。比如當URL本該有斜杠（/）卻被忽略掉時。例如，當我們要訪問http:// .com時，實際上返回的是一個包含301代碼的跳轉，它指向的是http:// .com/（注意末尾的斜杠）。在nginx伺服器可以使用rewrite；Apache伺服器中可以使用Alias 或者 mod_rewrite或者the DirectorySlash來避免。
另一種是不用域名之間的跳轉， 比如訪問http:// .com/bbs跳轉到http:// bbs..com/。那麼可以通過使用Alias或者mod_rewirte建立CNAME（保存一個域名和另外一個域名之間關系的DNS記錄）來替代。
13. 刪除重復的JS和CSS
重復調用腳本，除了增加額外的HTTP請求外，多次運算也會浪費時間。在IE和Firefox中不管腳本是否可緩存，它們都存在重復運算JavaScript的問題。
14. 配置ETags
它用來判斷瀏覽器緩存里的元素是否和原來伺服器上的一致。比last-modified date更具有彈性，例如某個文件在1秒內修改了10次，Etag可以綜合Inode(文件的索引節點(inode)數)，MTime(修改時間)和Size來精準的進行判斷，避開UNIX記錄MTime只能精確到秒的問題。 伺服器集群使用，可取後兩個參數。使用ETags減少Web應用帶寬和負載
15. 可緩存的AJAX
非同步請求同樣的造成用戶等待，所以使用ajax請求時，要主動告訴瀏覽器如果該請求有緩存就去請求緩存內容。如下代碼片段, cache:true就是顯式的要求如果當前請求有緩存的話，直接使用緩存
$.ajax({ url : 'url', dataType : "json", cache: true, success : function(son, status){ }
16. 使用GET來完成AJAX請求
當使用XMLHttpRequest時，瀏覽器中的POST方法是一個「兩步走」的過程：首先發送文件頭，然後才發送數據。因此使用GET獲取數據時更加有意義。
17. 減少DOM元素數量
這是一門大學問，這里可以引申出一堆優化的細節。想要具體研究的可以看後面推薦書籍。總之大原則減少DOM數量，就會減少瀏覽器的解析負擔。
18. 避免404
比如外鏈的css、js文件出現問題返回404時，會破壞瀏覽器的並行載入。
19. 減少Cookie的大小
Cookie裡面別塞那麼多東西，因為每個請求都得帶著他跑。
20. 使用無cookie的域
比如CSS、js、圖片等，客戶端請求靜態文件的時候，減少了 Cookie 的反復傳輸對主域名的影響。
21. 不要使用濾鏡
IE獨有屬性AlphaImageLoader用於修正7.0以下版本中顯示PNG圖片的半透明效果。這個濾鏡的問題在於瀏覽器載入圖片時它會終止內容的呈現並且凍結瀏覽器。在每一個元素（不僅僅是圖片）它都會運算一次，增加了內存開支，因此它的問題是多方面的。
完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替，這種格式能在IE中很好地工作。如果你確實需要使用AlphaImageLoader，請使用下劃線_filter又使之對IE7以上版本的用戶無效。
22. 不要在HTML中縮放圖片
比如你需要的圖片尺寸是50* 50
那就不用用一張500*500的大尺寸圖片，影響載入
23. 縮小favicon.ico並緩存
⑵ 以下哪些是常見的web前端性能關注點
前端性能關注的重點主要有以下幾點
1. 載入時間指標，主要包括三個時間斷
a. Time to First Impression
表示從用戶在瀏覽器鍵入url按下回車鍵一刻開始到頁面開始有反應(用戶可以在頁面中看見一點點內容)為止。經常能感覺到的一個信號就是網頁開始顯示title。
b.Time to onLoad Event
表示從頁面開始顯示內容,到瀏覽器開始觸發OnLoad函數這一時間段。只有當初始的文本和所引用的對象載入完成,瀏覽器才開始觸發OnLoad函數
c.Time to Fully Loaded
表示從上一時間段末到整個網頁完全載入完成(所有OnLoad函數以及相關的動態資源載入
完成)。在網頁中含有timeout或定時刷新之類處理時較為難判斷結束點。
2. 資源情況指標
網頁由初始的html文本中嵌入圖片以及通過XHR或者修改dom樹動態載入的內容組成,css負責樣式,js負責行為。所以當網頁資源過多為了下載資源客戶端和伺服器的網路來回就更多。下面是資源方面相關的指標。
a. Total Number of Requests
包括html網頁請求,css、js資源下載及其它網路請求。優化的目標之一是要盡量減少請求數。
b. Total Number of HTTP 300s/400s/500s
表示返回狀態為3009重定向）、400（客戶端錯誤）、500（伺服器端錯誤）的http請求。盡量避免這些請求以提高頁面load的時間。造成這些狀態的原因經常是伺服器的實施、配置和部署問題。
c. Total Size of Web Site
構成網頁元素總的大小。圖片或者js庫的增加都會對下載時間造成重要的影響。
d. Total Size of Images/CSS/JS
image、css、js在網頁元素大小中佔主要比例。
e. Total Number of XHR(XMLHttpRequest) Requests
通過js非同步從伺服器端獲得數據的請求數。一些js框架提供了跟伺服器端的更新機器就是XHR請求。通過配置可以減少XHR請求的數目
3. 網路連接指標
瀏覽器底層的網路連接對資源的下載速度有很大影響。資源的下載過程分為很多階段。下面介紹這些階段以及瀏覽器、網路、請求如何影響這些階段的時間
a. DNS Time
dns 查詢的時間。網頁請求會產生一次尋找該網頁資源所在主機的dns查詢。在同個域名進行網頁切換不會造成新的dns查詢。
b. Connect Time
指瀏覽器和伺服器之間建立tcp/ip連接的時間對於ssl連接包括握手的時間。網路連接過慢、使用ssl、使用短連接而非常連接都是造成connect time較多的原因。
c. Server Time
指收到請求後伺服器邏輯處理的時間
d. Transfer Time
這一指標與瀏覽器和伺服器之間的連接速度相一致通過減小傳輸內容或使用cdn來降Transfer Time。
e. Wait Time
等待時間和同一個域中服務資源的數量直接相關。每個域的瀏覽器的物理網路的限制，導致資源等待可用的連接。減少資源的數量（或將資源散布在不同的域）能將這一時間降低。平均等待時間的大小更能反映等待時間是否需要注意。
f. Number of Domains / Single Resource Domains
部署網站資源的域主機數量是很重要的，因為它影響的DNS連接和等待時間。專門用戶資源下載的域是必要的他將直接減少等待時間。應避免單一的資源域否則你將為dns查詢以及資源下載付出昂貴的代價。
⑶ 前端開發，頁面優化，性能優化有哪些方面
常用的優化有兩部分
第一：面向內容的優化
1. 減少 HTTP 請求
2. 減少 DNS 查找
3. 避免重定向
4. 使用 Ajax 緩存
5. 延遲載入組件
6. 預先載入組件
7. 減少 DOM 元素數量
8. 切分組件到多個域
9. 最小化 iframe 的數量
10. 不要出現http 404 錯誤
第二：面向 Server
1. 縮小 Cookie
2. 針對 Web 組件使用域名無關性的
⑷ 你有用過哪些前端性能優化的方法
這個是面試常問的問題了。
我來簡單說下幾個方面：
1.減少http請求：在YUI35規則中也有提到，主要是優化js、css和圖片資源三個方面，因為html是沒有辦法避免的。因此，我們可以做一下的幾項操作：
合並js文件
合並css文件
雪碧圖的使用(css sprite)
使用base64表示簡單的圖片
2.減少資源體積
壓縮css
壓縮js
壓縮圖片
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是否變化，如果變化了取最新的數據，如果不變化，則不變。
⑹ 前端性能優化的具體方法有哪些
解決辦法一：
減少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請求
⑺ 常用的前端性能優化方法有哪些
1、減少http請求，合理設置HTTP緩存
2、使用瀏覽器緩存
3、啟用壓縮
4、CSS Sprites，合並 CSS圖片，減少請求數
5、CSS放在頁面最上部，javascript放在頁面最下面
⑻ 簡單談談前端性能優化
這個話題，賊大。
個人認為：核心在於，HTTP 請求的減少和請求包大小的減少再加上對代碼的重構。
HTTP 請求的減少，瞧瞧現在的前端工程化，工程化的作用之一正是將那些散亂的 js 、css 庫全部都集成起來，壓縮成一個文件，這么多文件壓縮成一個，這請求不就減少了么~還有一個就是」精靈圖技術「也是優化的體現，就不展開了。
請求包大小的減少，這個簡直是能減就減啊，比如以前的時候，我們需要將圖片直接發送到瀏覽器上是吧，現在可以不用！如果只是發生一段代碼到客戶的瀏覽器上，然後客戶用自己的機器生成圖片，這得有多快啊，畢竟一段代碼大還是一張圖片大還是很容易分清的，特別的是 GIF 圖！這時候用上 svg 或是 canvas 技術，就不需要發送巨大的 GIF 圖片了，只需要調用瀏覽器的資源生成圖像即可。
重構，反正不滿意重構就是了，滿意了加功能然後繼續重構就是了。
但這都是還只是皮毛啊這是，如果用到框架，那還要講到框架的優化，因為前端框架的優化同樣是性能優化，那都能寫幾十頁了都......
如果再深入講到瀏覽器自身......啊，要死了死了，技術是無窮的，命是有限的！
⑼ web前端有哪些性能優
一，關鍵資源位元組數
位元組數也就是我通常說的減少資源文件（js,css,image,video...）的大小
1，壓縮
前端使用uglify混淆壓縮
後端開啟gzip
對圖片進行壓縮，使用壓縮比例更高的格式（webP）
強緩存（http狀態碼：200），不用請求伺服器直接使用本地緩存
協商緩存（http狀態碼：304），使用時先請求伺服器若被告知緩存沒過期則使用本地緩存，不用下載資源
使用localstorage對數據進行存儲
使用http2.0的多路復用合並請求
配置combo，在無法使用http2.0的情況下作為一種合並資源請求的手段
使用spite圖
使用svg-symbol
2，緩存
3，針對首屏優化
對非關鍵資源延遲載入、非同步載入，減少首屏資源大小
二，關鍵資源連接數
1，合並請求
2，減少圖片請求數
3，針對一些場景採用css、js內聯的方式
4，使用強緩存減少了一次伺服器請求
5，非關鍵資源延遲、非同步載入，減少了首屏資源連接數
三，關鍵渲染路徑
網上有張關於頁面渲染路徑的圖，這里我就不放了，大家有興趣自己網路下
1，bigpipe分塊輸出
這里主要是因為要完成一整個頁面的輸出後端需要處理很多個任務，我們可以將這些多個任務進行分塊，誰先完成誰就先輸出，最終通過JS回填的方式輸出DOM節點。這種方式主要解決了直出頁面阻塞的問題
2，bigrender分塊渲染
常規的手段就是採用前端模板渲染頁面，針對首屏時間主要減少了首次構建DOM樹時的節點數
3，針對reflow，repaint，composit路徑處理
4，涉及到動畫時關於layer的概念render layer、graphics layer
5，css放在頭部、js放底部避免阻塞DOM樹的構建，
關於css、js的位置對於頁面渲染的影響大家可以關注下相關的文章。
核心：css資源不會阻塞DOM樹的構建但會阻塞DOM的渲染，JS會阻塞DOM樹的構建，CSS會阻塞JS的執行
⑽ 前端開發 「性能」有多重要
關於頁面相應時間，有一條著名的「2-5-8原則」。當用戶訪問一個頁面：
在2秒內得到響應時，會感覺系統響應很快；
在2-5秒之間得到響應時，會感覺系統的響應速度還可以；
在5-8秒以內得到響應時，會感覺系統的響應速度很慢，但可以接受；
而超過8秒後仍然無法得到響應時，用戶會感覺系統糟透了，進而選擇離開這個站點，或者發起第二次請求。
對於一個網站如果希望抓住用戶，網站的速度以及穩定性是非常重要的。
從各式各樣的前端監控平台中，你都可以獲得頁面很多的性能指標。本文將介紹幾個幾個比較關鍵的指標，並給出相應的優化思路。
開始渲染時間
該時間點表示瀏覽器開始繪制頁面，在此之前頁面都是白屏，所以也稱為白屏時間。
該時間點可用公式Time To Start Render = TTFB（Time To First Byte） + TTDD（Time To Document Download） + TTHE（Time To Head End）表示。其中TTFB表示瀏覽器發起請求到伺服器返回第一個位元組的時間，TTDD表示從伺服器載入HTML文檔的時間，TTHE表示文檔頭部解析完成所需要的時間。在高級瀏覽器中有對應的屬性可以獲取該時間點。Chrome可通過chrome.loadTimes().firstPaintTime獲取，IE9+可以通過performance.timing.msFirstPaint獲取，在不支持的瀏覽器中可以根據上面公式通過獲取頭部資源載入完的時刻模擬獲取近似值。開始渲染時間越快，用戶就能更快的看見頁面。
對於該時間點的優化有：
1)優化伺服器響應時間，伺服器端盡早輸出
2)減少html文件大小
3)減少頭部資源,腳本盡量放在body中
DOM Ready
該時間點表示dom解析已經完成，資源還沒有載入完成, 這個時候用戶與頁面的交互已經可用了。用公式TimeTo Dom Ready = TTSR(Time To Start Render) + TTDC(Time To Dom Created) + TTST(Time To Script)可以表示。TTSR上面已經介紹過了，TTDC表示DOM樹創建所耗時間。TTST表示BODY中所有靜態腳本載入和執行的時間。在高級瀏覽器中有DOMContentLoaded事件對應。
詳細規范可以查看W3C的HTML5規范。從MDN文檔上可以看出該事件主要是指dom文檔載入解析完成，看上去很簡單，但是DOMContentLoaded事件的觸發與css,js息息相關，現在有專門的名詞Critical Rendering Path(關鍵呈現路徑)來描述。
在不支持DOMContentLoaded事件的瀏覽器中可以通過模擬獲取近似值，主要的模擬方法有：
1）低版本webkit內核瀏覽器可以通過輪詢document.readyState來實現
2）ie中可通過setTimeout不斷調用documentElement的doScroll方法，直到其可用來實現
具體實現方法可以參考主流框架(jquery等)的實現。 DOM Ready時間點意味著用戶與頁面可以進行交互了，因此越早越好，對於該時間點的優化有：
1）減少dom結構的復雜度，節點盡可能少，嵌套不要太深
2）優化關鍵呈現路徑
首屏時間
該時間點表示用戶看到第一屏頁面的時間，這個時間點很重要但是很難獲取，一般都只能通過模擬獲取一個近似時間。一般模擬方法有：
1）不斷獲取屏幕截圖，當截圖不再變化時，可以視為首屏時間。可參考webPagetest的Speed Index演算法；
2）一般影響首屏的主要因素是圖片的載入，通過頁面載入完後判斷圖片是否在首屏內，找出載入最慢的一張即可視為首屏時間。當然還需考慮其他細節，具體可參考【7天打造前端性能監控系統】
針對該時間點的優化有：
1）頁面首屏的顯示盡量不要依賴於js代碼，js盡量放到domReady後執行或載入
2）首屏外的圖片延遲載入
3）首屏結構盡量簡單，首屏外的css可延遲載入
onload
該時間點是window.onload事件觸發的時間，表示原始文檔和所有引用的內容已經載入完成，用戶最明顯的感覺就是瀏覽器tab上loading狀態結束。
該時間點的優化方式有：
1）減少資源的請求數和文件大小
2）將非初始化腳本放到onLoad之後執行
3）無需同步的腳本非同步載入
為了優化整站性能，頁面onload的時候可以考慮做一些預載入，把其它頁面需要用到的資源預先載入進來。