很實用的web效能測試外掛:Yslow , PageSpeed
package org.springframework.web.servlet.resource; import java.io.IOException; import java.io.UnsupportedEncodingException; import java.net.URLDecoder; import java.nio.charset.Charset; import java.util.ArrayList; import java.util.HashMap; import java.util.List; import java.util.Map;import javax.servlet.ServletException; import javax.servlet.ServletResponse; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import org.springframework.beans.factory.InitializingBean;import org.springframework.context.ApplicationContext; import org.springframework.context.EmbeddedValueResolverAware; import org.springframework.core.io.Resource; import org.springframework.core.io.UrlResource; import org.springframework.core.io.support.ResourceRegion; import org.springframework.http.HttpHeaders;import org.springframework.http.HttpMethod; import org.springframework.http.HttpRange; import org.springframework.http.MediaType; import org.springframework.http.converter.ResourceHttpMessageConverter; import org.springframework.http.converter.ResourceRegionHttpMessageConverter; import org.springframework.http.server.ServletServerHttpRequest; import org.springframework.http.server.ServletServerHttpResponse; import org.springframework.util.Assert; import org.springframework.util.ClassUtils; import org.springframework.util.CollectionUtils; import org.springframework.util.ObjectUtils; import org.springframework.util.ResourceUtils; import org.springframework.util.StringUtils; import org.springframework.util.StringValueResolver; import org.springframework.web.HttpRequestHandler; import org.springframework.web.accept.ContentNegotiationManager; import org.springframework.web.accept.PathExtensionContentNegotiationStrategy; import org.springframework.web.accept.ServletPathExtensionContentNegotiationStrategy; import org.springframework.web.context.request.ServletWebRequest; import org.springframework.web.cors.CorsConfiguration; import org.springframework.web.cors.CorsConfigurationSource; import org.springframework.web.servlet.HandlerMapping; import org.springframework.web.servlet.support.WebContentGenerator; import org.springframework.web.util.UrlPathHelper; /** * {@code HttpRequestHandler} that serves static resources in an optimized way * according to the guidelines of Page Speed, YSlow, etc. * * <p>The {@linkplain #setLocations "locations"} property takes a list of Spring * {@link Resource} locations from which static resources are allowed to be served * by this handler. Resources could be served from a classpath location, e.g. * "classpath:/META-INF/public-web-resources/", allowing convenient packaging * and serving of resources such as .js, .css, and others in jar files. * * <p>This request handler may also be configured with a * {@link #setResourceResolvers(List) resourcesResolver} and * {@link #setResourceTransformers(List) resourceTransformer} chains to support * arbitrary resolution and transformation of resources being served. By default * a {@link PathResourceResolver} simply finds resources based on the configured * "locations". An application can configure additional resolvers and transformers * such as the {@link VersionResourceResolver} which can resolve and prepare URLs * for resources with a version in the URL. * * <p>This handler also properly evaluates the {@code Last-Modified} header * (if present) so that a {@code 304} status code will be returned as appropriate, * avoiding unnecessary overhead for resources that are already cached by the client. * * @author Keith Donald * @author Jeremy Grelle * @author Juergen Hoeller * @author Arjen Poutsma * @author Brian Clozel * @author Rossen Stoyanchev * @since 3.0.4 */ public class ResourceHttpRequestHandler extends WebContentGenerator implements HttpRequestHandler, EmbeddedValueResolverAware, InitializingBean, CorsConfigurationSource { // Servlet 3.1 setContentLengthLong(long) available? private static final boolean contentLengthLongAvailable = ClassUtils.hasMethod(ServletResponse.class, "setContentLengthLong", long.class); ... }
YSlow可以對網站的頁面進行分析，並告訴你為了提高網站效能，如何基於某些規則而進行優化。 YSlow可以分析任何網站，併為每一個規則產生一個整體報告，如果頁面可以進行優化，則YSlow會列出具體的修改意見。
YSlow的安裝：
1、安裝 firebug外掛。針對不同的瀏覽器外掛也是不同的，例如 針對chrome.外掛名稱為：Firebug Lite for Google Chrome。官網下載地址為：https://chrome.google.com/webstore/search/firebug%20%20for%20chrome
點選新增至chrome ，安裝後，Firebug Lite按鈕將會出現在谷歌瀏覽器位址列右側，一個小蟲子圖示在哪裡顯示著。點選即可啟用。
2、安裝YSLOW外掛，官網下載地址為：http://developer.yahoo.com/yslow/
點選安裝即可。安裝後，YSlow按鈕會在 chrome的右上角顯示。
YSlow的使用
點選YSlow按鈕，啟動外掛，點選Run Test 測試當前頁面。在新彈出的介面中按照重要性顯示了影響此頁面效率的元素，其中A類評分為最高，F為最低。
一般來說提高網頁效率依照下面14條準則。
第一條：Make Fewer HTTP Requests 儘可能的減少HTTP的Request請求數。
80%的使用者響應時間都是浪費在前端。而這些時間主要又是因為下載圖片、樣式表、JavaScript指令碼、flash等檔案造成的。減少這些資原始檔的Request請求數將是提高網頁顯示效率的重點。
這裡好像有個矛盾，就是如果我減少了很多的圖片，樣式，指令碼或者flash，那麼網頁豈不是光禿禿的，那多難看呢？其實這是一個誤解。我們只是說盡量的減少，並沒有說完全不能使用。減少這些檔案的Request請求數，當然也有一些技巧和建議的：
1：用一個大圖片代替多個小圖片。
這的確有點顛覆傳統的思維了。以前我們一直以為多個小圖片的下載速度之和會小於一個大圖片的下載速度。但是現在利用httpwatch工具的對多個頁面進行分析後的結果表明事實並不是這樣。
第一張圖是一個大小為40528bytes的337*191px的大圖片的分析結果。
第二張圖是一個大小為13883bytes的280*90px的小圖片的分析結果。
一個大小為40528bytes的337*191px的大圖片的分析結果（點選圖片可以檢視完整大圖片）
一個大小為13883bytes的280*90px的小圖片的分析結果（點選圖片可以檢視完整大圖片）
第一張大圖片花費時間為：
Blocked：13.034s
Send：0.001s
Wait：0.163s
Receive：4.596s
TTFB：0.164s
NetWork：4.760s
功耗時：17.795s
真正用於傳輸大檔案花費的時間為Reveive時間，即4.596s，多數的時間是用來檢索快取和確定連結是否有效的Blocked時間，供花費13.034s，佔總時間的73.2%。
第二張小圖片花費時間為：
Blocked：16.274s
Send：小於0.001s
Wait：0.117s
Receive：0.397s
TTFB：0.118s
NetWork：0.516s
功耗時：16.790s
真正用於傳輸檔案的花費時間是Reveive時間，即0.397s，這的確要比剛才大檔案的4.596s小很多。但是他的Blocked時間為16.274s，佔總時間的97%。
如果這些資料還不夠說服你的話，讓我們看看下面這張圖。這裡列出了某個網頁中所有圖片中的花費時間示意圖。當然，裡面的圖片有大有小，規格不一。
大約80%以上的時間是用來檢索快取和確定連結是否有效的Blocked時間。
其中藏青色的為傳輸檔案花費的Reveive時間，而前面白色的為檢索快取和確認連結是否有效的Blocked時間。鐵一樣的事實告訴我們：
§ 大檔案和小檔案下載所需時間的確是不同的，差異的絕對值不大。而且下載所需時間佔總耗費時間比例很小。
§ 大約80%以上的時間是用來檢索快取和確定連結是否有效的Blocked時間。無論檔案大小，這個時間的花費大致是相同的。而且所佔總耗費時間的比例是極大的。
§ 一個100k的大圖片總耗費時間絕對大於4個25k的小圖片的總耗費時間。而且主要差別就是4個小圖片的Blocked時間絕對大於1個大圖片的Blocked時間。
所以如果可能還是使用大圖片來替代過多的瑣碎的小圖片吧。這也是為什麼翻轉門的效率要高於圖片替換實現的滑動門的原因。
但是，請注意：也不能用太大的單張圖片，因為那樣會影響到使用者體驗。例如個幾兆的背景圖片的使用絕對不是一個好主意。
2：合併你的css檔案。
我以前犯了一個錯誤，你在看我《樣式表的組織與規劃》的系列文章中會知道。當時，我為了方便組織和規劃樣式表，將用於不同用途的樣式表文件分離開來，形成不同的css檔案。然後在頁面中根據需要引用多個css檔案。根據“儘可能的減少HTTP的Request請求數”準則我們知道，那樣的確是不合理的，因為那樣會產生更多的HTTP的Request請求數。從而降低網頁的效率。所以，從提高網頁效率的角度上而言，我們還是應該將所有的css寫在同一個css檔案中。但是問題又來了。那麼怎麼來很好的組織和規劃樣式表呢？這的確是個矛盾。我現在的做法是採用兩套版本。編輯版和釋出版。編輯版仍然使用多個css檔案以便於規劃和組織。而等到釋出的時候，再將多個css檔案合併到一個檔案中去，從而達到減少HTTPRequest請求數的目的。
3：合併你的javascript檔案。
原因和處理方法同上，不再贅言。
第二條：Use a Content Delivery Network 使用CDN
這個看上去好像很深奧的樣子，但是隻要結合中國的網路特色，這個便不難理解了。“北方伺服器”、“南方伺服器”、“電信伺服器”、“網通伺服器”……這些詞聽起來是那麼熟悉和壓抑。如果，一個北京的電信使用者試圖從廣東的網通伺服器上開啟一個類似《桌布合集》帖子的網頁時，你就能很深刻的理解。
鑑於這個不是我們開發人員力所能及的準則，所以這裡也就不多言了。
圖:這個圖也算有點中國特色了
第三條：Add an Expires Header 新增週期頭
這個也並非開發人員來控制，而是網站伺服器管理員的職責。所以，如果作為開發人員的你不瞭解和明白也沒有關係。還是把這個準則告訴公司的網站伺服器管理員。
第四條：Gzip Components 啟用Gzip壓縮
這個大家應該比較熟悉。Gzip的思想就是把檔案先在伺服器端進行壓縮，然後再傳輸。這對於體積較大的純文字型的檔案有特效。鑑於這也並非開發人員，而是網站伺服器管理員的工作範疇，這裡就不詳細講解了。如果你對此感興趣，可以資訊貴公司的網站伺服器管理人員。
第五條：Put CSS at the Top 把CSS樣式放在頁面的上方。
無論是HTML還是XHTML還是CSS都是解釋型的語言，而非編譯型的。所以CSS到上方的話，那麼瀏覽器解析結構的時候，就已經可以對頁面進行渲染。這樣就不會出現，頁面結構光禿禿的先出來，然後CSS渲染，頁面又突然華麗起來，這樣太具有“戲劇性”的頁面瀏覽體驗了。
第六條：Move Scripts to the Bottom 將指令碼放在底部
原因同第五條一樣。只是指令碼一般是用來於使用者互動的。所以如果頁面還沒有出來，使用者連頁面都不知道什麼樣子，那談互動簡直就是扯談。所以，指令碼和CSS正好相反，指令碼應該放在頁面的底部。
第七條：Avoid CSS Expressions 避免使用CSS中的Expressions
圖:CSS中的Expressions其實也是一種if判斷
首先有必要先說明一下CSS Expressions是什麼一個東西。其實它就像其它語言中的if……else……語句。這樣在CSS中就可以進行簡單的邏輯判斷了。舉個簡單的例子——
<style>
input{&& this.readOnly==true)?"#0000ff":"#ff0000")}
</style>
<INPUT TYPE="text" NAME="">
<INPUT TYPE="text" NAME="" readonly="true">
這樣css就可以根結一些情況分別使用不同的樣式了。如果你對這個感興趣可以到我的部落格上閱讀相關的文章—— 《CSS中的expression系列文章》。但是CSS中Expressions 的代價卻是極高的。當你的頁面需要根據判斷來渲染效果的元素很多的時候，那麼你的瀏覽器將長期處於假死狀態，從而給使用者帶來極差的使用者體驗。
第八條：Make JavaScript and CSS External 將javascript和css獨立成外部檔案
這一條好像和第一條有點矛盾。的確，如果從HTTP的request請求數來講的話，這樣做的確是降低了效率。但是之所以這麼做，是因為另外一個重要的考慮因素——快取。因為外部的引用檔案會被瀏覽器快取，所以如果javascript和css體積較大的時候，我們將它們獨立成外部檔案。這樣當用戶只要瀏覽一次以後，這些體積較大的js和css檔案就能被快取起來，從而極高地提高使用者再次訪問時的效率。
第九條：Reduce DNS Lookups 減少DNS查詢
DNS域名解析系統。大家都知道我們之所以能記住那麼多的網址，是因為我們記住的都是單詞，而非http://202.153.125.45這樣的東西，而幫我們把那些單詞和202.153.125.45這樣的ip地址聯絡起來的就是DNS。那這一條對我們到底有什麼真正意義上的指導意義呢？其實有兩條：
1：如果不是必須，請不要把網站放到兩臺伺服器上。
2：網頁中的圖片、css檔案、js檔案、flash檔案等等，不要太多的分散在不同的網路空間中。這就是為什麼那種只發一個網站中的桌布圖片的帖子，要比桌布圖片來源於不同網站的帖子顯示要快得多的原因。
第十條：Minify JavaScript and CSS 減少JavaScript和CSS檔案的體積
這點很好理解。在你的最終釋出版本中把沒有必要的空行、空格和註釋全部去掉。顯然手工去處理效率太低，好在網上到處都是用於壓縮這些東西的工具。壓縮JavaScript程式碼體積的工具隨處可見，我便不再列舉了，這裡我只提供一個用於壓縮css程式碼體積的線上工具網站——http://www.cssdrive.com/index.php/main/csscompressor
它提供了多種壓縮方式，可以適應多種要求。
第十一條：Avoid Redirects 避免跳轉
我只從網頁開發人員的角度來解讀此條。那麼我們可以解讀到什麼東西呢？2點——
1：“此域名已過期，5秒鐘以後，頁面將跳轉到http://www.xxxxxx.com/index.html頁面”，這句話看起來的確很熟悉。但是，我就奇怪了，為什麼不直接連結到那個頁面呢？
2：一些連結地址請更明確的寫出來。例如:將http://justinyoung.cnblogs.com/ 寫成http://justinyoung.cnblogs.com （注意最後面一個“/”符號）。的確，這兩個網址都能訪問到我的部落格，但是，事實上，它們是有區別的。http://justinyoung.cnblogs.com 的結果是個301響應，它會被重新指向http://justinyoung.cnblogs.com/ 。但是顯然，中間多浪費了一些時間。
第十二條 Remove Duplicate Scripts 移除重複的指令碼
這個準則的道理很淺顯，但是真正在工作中，很多人卻因為“專案時間緊”、“太累了”、“初期沒有規劃好”……這樣的理由搪塞過去了。你，的確可以找很多的理由不去處理這些多餘重複的指令碼程式碼，如果你的網站不需要更高的效率和後期維護的話。
也正是這點，我提醒大家一些，一些javascript框架、javascript包一定要慎用。至少要問一下：用了這個js kit 到底給我們多少方便，提高了多少工作效率。然後，再與它因為多餘的、重複的程式碼帶來的負面效果比較一下。
第十三條：Configure ETags 配置你的實體標籤
首先來講講什麼是Etag吧。Etag（Entity tags ）實體標籤。這個tag和你在網上經常看到的標籤雲那種tag有點區別。這個Etag不是給使用者用的，而是給瀏覽器快取用的。Etag是伺服器告訴瀏覽器快取，快取中的內容是否已經發生變化的一種機制。通過Etag，瀏覽器就可以知道現在的快取中的內容是不是最新的，需不需要重新從伺服器上重新下載。這和“Last-Modified”的概念有點類似。很遺憾作為網頁開發人員對此無能為力。他依然是網站伺服器人員的工作範疇。如果，你對此有興趣，可以諮詢貴公司的網站伺服器管理員。
第十四條：Make Ajax Cacheable 上面的準則也適用Ajax
現在的Ajax好像有點被神話了，好像網頁只要Ajax了，那麼就不存在效率問題了。其實這是一種誤解。拙劣的使用Ajax不會讓你的網頁效率更高，反而會降低你的網頁效率。Ajax的確是個好東西，但是請不要過分的神話它。使用Ajax的時候也要考慮上面的那些準則。
點選【Components】選單
這個檢視是一個頁面所有部件的資訊列表。從中我們可以得知每個部件的各種詳細資訊。如：型別、URL、Expires資料、狀態、大小、讀取時間、ETag資訊等等。通過對這個列表的分析，我們就可以知道到底是什麼東西最耗費我們的資源，從而有針對性的進行優化。
點選【Statistics】選單
這個檢視會告訴你頁面的總體統計資訊。包括頁面大小、css樣式表大小、指令碼檔案大小、總體圖片大小、flash檔案大小和css中用到的圖片檔案大小。還會告訴你，哪些東西被快取了，快取了多少等等。
https://www.cnblogs.com/wajika/p/6278825.html
原文地址：http://blog.sina.com.cn/s/blog_6c9da636010103va.html
pagespeed 讓你的網站頁面開啟速度飛起來！
點選進入後，在搜尋框裡面搜尋“firebug”
點選安裝後，火狐瀏覽器會自動下載安裝，安裝完了以後火狐瀏覽器會提示你重新啟動。 （二）、firebug安裝成功後，就可以安裝pagespeed外掛了。 https://dl-ssl.google.com/page-speed/current/page-speed.xpi 火狐版本下的pagespeed下載地址 點選，自動下載安裝以後，火狐會提示再一次重啟。重啟完了pagespeed算是真正地安裝成功。 （三）、使用圖示 開啟一個網站，如般若網路營銷的網址www.redww.com 按F12啟動firebug外掛，如圖所示：
點選工具條最末端的page speed按鈕，出現上圖所示介面，點選分析，外掛開始運作。稍等片刻，分析完了以後出現的分析結果如圖所示：
在搜尋框裡面搜尋page speed，出現搜尋結果頁面後，點選安裝：
下載以後，自動安裝，直到chrome瀏覽器上出現了圖示：
點選分析之後，稍等片刻，會出現分析結果：
https://www.cnblogs.com/niaowo/p/4001533.html