WEB前端效能測試優化指標
加快您的網站的最佳實踐
1、Make fewer HTTP requests （最大限度地減少HTTP請求）
終端使用者響應的時間中，有80%用於下載各項內容。這部分時間包括下載頁面中的影象、樣式表、指令碼、Flash等。通過減少頁面中的元素可以減少HTTP請求的次數。這是提高網頁速度的關鍵步驟。
減少頁面元件的方法其實就是簡化頁面設計。那麼有沒有一種方法既能保持頁面內容的豐富性又能達到加快響應時間的目的呢？這裡有幾條減少HTTP請求次數同時又可能保持頁面內容豐富的技術。
合併檔案是通過把所有的指令碼放到一個檔案中來減少HTTP請求的方法，如可以簡單地把所有的CSS檔案都放入一個樣式表中。當指令碼或者樣式表在不同頁面中使用時需要做不同的修改，這可能會相對麻煩點，但即便如此也要把這個方法作為改善頁面效能的重要一步。
CSS Sprites是減少影象請求的有效方法。把所有的背景影象都放到一個圖片檔案中，然後通過CSS的background-image和background-position屬性來顯示圖片的不同部分；
圖片地圖是把多張圖片整合到一張圖片中。雖然檔案的總體大小不會改變，但是可以減少HTTP請求次數。圖片地圖只有在圖片的所有組成部分在頁面中是 緊挨在一起的時候才能使用，如導航欄。確定圖片的座標和可能會比較繁瑣且容易出錯，同時使用圖片地圖導航也不具有可讀性，因此不推薦這種方法；
內聯影象是使用data:URL scheme的方法把影象資料載入頁面中。這可能會增加頁面的大小。把內聯影象放到樣式表（可快取）中可以減少
減少頁面的HTTP請求次數是你首先要做的一步。這是改進首次訪問使用者等待時間的最重要的方法。如同Tenni Theurer的他的部落格Browser Cahe Usage - Exposed!中所說，HTTP請求在無快取情況下佔去了40%到60%的響應時間。讓那些初次訪問你網站的人獲得更加快速的體驗吧！
2、Use a Content Delivery Network (CDN)（使用內容分發網路）
使用者與你網站伺服器的接近程度會影響響應時間的長短。把你的網站內容分散到多個、處於不同地域位置的伺服器上可以加快下載速度。但是首先我們應該做些什麼呢？
按地域佈置網站內容的第一步並不是要嘗試重新架構你的網站讓他們在分發伺服器上正常執行。根據應用的需求來改變網站結構，這可能會包括一些比較複雜的任 務，如在伺服器間同步Session狀態和合並資料庫更新等。要想縮短使用者和內容伺服器的距離，這些架構步驟可能是不可避免的。
要記住，在終端使用者的響應時間中有80%到90%的響應時間用於下載影象、樣式表、指令碼、Flash等頁面內容。這就是網站效能黃金守則。和重新設計你的 應用程式架構這樣比較困難的任務相比，首先來分佈靜態內容會更好一點。這不僅會縮短響應時間，而且對於內容分發網路來說它更容易實現。
內容分發網路（Content Delivery Network，CDN）是由一系列分散到各個不同地理位置上的Web伺服器組成的，它提高了網站內容的傳輸速度。用於向用戶傳輸內容的伺服器主要是根據 和使用者在網路上的靠近程度來指定的。例如，擁有最少網路跳數（network hops）和響應速度最快的伺服器會被選定。
一些大型的網路公司擁有自己的CDN，但是使用像Akamai Technologies，Mirror Image Internet， 或者Limelight Networks這樣的CDN服務成本卻非常高。對於剛剛起步的企業和個人網站來說，可能沒有使用CDN的成本預算，但是隨著目標使用者群的不斷擴大和更加 全球化，CDN就是實現快速響應所必需的了。以Yahoo來說，他們轉移到CDN上的網站程式靜態內容節省了終端使用者20%以上的響應時間。使用CDN是 一個只需要相對簡單地修改程式碼實現顯著改善網站訪問速度的方法。
3、Add Expires headers新增一個Expires或Cache-Control頭
這條守則包括兩方面的內容：
對於靜態內容：設定檔案頭過期時間Expires的值為“Never expire”（永不過期）
對於動態內容：使用恰當的Cache-Control檔案頭來幫助瀏覽器進行有條件的請求
網頁內容設計現在越來越豐富，這就意味著頁面中要包含更多的指令碼、樣式表、圖片和Flash。第一次訪問你頁面的使用者就意味著進行多次的HTTP請求，但 是通過使用Expires檔案頭就可以使這樣內容具有快取性。它避免了接下來的頁面訪問中不必要的HTTP請求。Expires檔案頭經常用於影象檔案，
但是應該在所有的內容都使用他，包括指令碼、樣式表和Flash等。
瀏覽器（和代理）使用快取來減少HTTP請求的大小和次數以加快頁面訪問速度。Web伺服器在HTTP響應中使用Expires檔案頭來告訴客戶端內容需
要快取多長時間。下面這個例子是一個較長時間的Expires檔案頭，它告訴瀏覽器這個響應直到2010年4月15日才過期。
Expires: Thu, 15 Apr 2010 20:00:00 GMT
如果你使用的是Apache伺服器，可以使用ExpiresDefault來設定相對當前日期的過期時間。下面這個例子是使用ExpiresDefault來設定請求時間後10年過期的檔案頭：
ExpiresDefault "access plus 10 years"
要切記，如果使用了Expires檔案頭，當頁面內容改變時就必須改變內容的檔名。依Yahoo!來說我們經常使用這樣的步驟：在內容的檔名中加上版本號，如yahoo_2.0.6.js。
使用Expires檔案頭只有會在使用者已經訪問過你的網站後才會起作用。當用戶首次訪問你的網站時這對減少HTTP請求次數來說是無效的，因為瀏覽器的緩 存是空的。因此這種方法對於你網站效能的改進情況要依據他們“預快取”存在時對你頁面的點選頻率（“預快取”中已經包含了頁面中的所有內容）。
Yahoo!建立了一套測量方法，我們發現所有的頁面瀏覽量中有75~85%都有“預快取”。通過使用Expires檔案頭，增加了快取在瀏覽器中內容的
數量，並且可以在使用者接下來的請求中再次使用這些內容，這甚至都不需要通過使用者傳送一個位元組的請求。
4、Compress components with gzip用gzip的壓縮內容
網路傳輸中的HTTP請求和應答時間可以通過前端機制得到顯著改善。的確，終端使用者的頻寬、網際網路提供者、與對等交換點的靠近程度等都不是網站開發者所能決定的。但是還有其他因素影響著響應時間。通過減小HTTP響應的大小可以節省HTTP響應時間。
從HTTP/1.1開始，web客戶端都預設支援HTTP請求中有Accept-Encoding檔案頭的壓縮格式：
Accept-Encoding: gzip, deflate
如果web伺服器在請求的檔案頭中檢測到上面的程式碼，就會以客戶端列出的方式壓縮響應內容。Web伺服器把壓縮方式通過響應檔案頭中的Content-Encoding來返回給瀏覽器。
Content-Encoding: gzip
Gzip是目前最流行也是最有效的壓縮方式。這是由GNU專案開發並通過RFC 1952來標準化的。另外僅有的一個壓縮格式是deflate，但是它的使用範圍有限效果也稍稍遜色。
Gzip大概可以減少70%的響應規模。目前大約有90%通過瀏覽器傳輸的網際網路交換支援gzip格式。如果你使用的是Apache，gzip模組配置和你的版本有關：Apache
1.3使用mod_zip，而Apache 2.x使用moflate。
瀏覽器和代理都會存在這樣的問題：瀏覽器期望收到的和實際接收到的內容會存在不匹配的現象。幸好，這種特殊情況隨著舊式瀏覽器使用量的減少在減少。Apache模組會通過自動新增適當的Vary響應檔案頭來避免這種狀況的出現。
伺服器根據檔案型別來選擇需要進行gzip壓縮的檔案，但是這過於限制了可壓縮的檔案。大多數web伺服器會壓縮HTML文件。對指令碼和樣式表進行壓縮同
樣也是值得做的事情，但是很多web伺服器都沒有這個功能。實際上，壓縮任何一個文字型別的響應，包括XML和JSON，都值得的。影象和PDF檔案由於
已經壓縮過了所以不能再進行gzip壓縮。如果試圖gizp壓縮這些檔案的話不但會浪費CPU資源還會增加檔案的大小。
Gzip壓縮所有可能的檔案型別是減少檔案體積增加使用者體驗的簡單方法。
5、Put CSS at top將樣式表在頂部
在研究Yahoo!的效能表現時，我們發現把樣式表放到文件的<head />內部似乎會加快頁面的下載速度。這是因為把樣式表放到<head />內會使頁面有步驟的載入顯示。
注重效能的前端伺服器往往希望頁面有秩序地載入。同時，我們也希望瀏覽器把已經接收到內容儘可能顯示出來。這對於擁有較多內容的頁面和網速較慢的使用者來說
特別重要。向用戶返回視覺化的反饋，比如程序指標，已經有了較好的研究並形成了正式文件。在我們的研究中HTML頁面就是程序指標。當瀏覽器有序地載入文 件頭、導航欄、頂部的logo等對於等待頁面載入的使用者來說都可以作為視覺化的反饋。這從整體上改善了使用者體驗。
把樣式表放在文件底部的問題是在包括Internet Explorer在內的很多瀏覽器中這會中止內容的有序呈現。瀏覽器中止呈現是為了避免樣式改變引起的頁面元素重繪。使用者不得不面對一個空白頁面。
HTML規範清楚指出樣式表要放包含在頁面的<head />區域內：“和<a
/>不同，<link />只能出現在文件的<head />區域內，儘管它可以多次使用它”。無論是引起白屏還是出現沒有樣式化的內容都不值得去嘗試。最好的方案就是按照HTML規範在文
檔<head />內載入你的樣式表。
6、Put JavaScript at bottom把JavaScript底部
指令碼帶來的問題就是它阻止了頁面的平行下載。HTTP/1.1
規範建議，瀏覽器每個主機名的並行下載內容不超過兩個。如果你的圖片放在多個主機名上，你可以在每個並行下載中同時下載2個以上的檔案。但是當下載指令碼 時，瀏覽器就不會同時下載其它檔案了，即便是主機名不相同。
在某些情況下把指令碼移到頁面底部可能不太容易。比如說，如果指令碼中使用了document.write來插入頁面內容，它就不能被往下移動了。這裡可能還會有作用域的問題。很多情況下，都會遇到這方面的問題。
一個經常用到的替代方法就是使用延遲指令碼。DEFER屬性表明指令碼中沒有包含document.write，它告訴瀏覽器繼續顯示。不幸的 是，Firefox並不支援DEFER屬性。在Internet
Explorer中，指令碼可能會被延遲但效果也不會像我們所期望的那樣。如果指令碼可以被延遲，那麼它就可以移到頁面的底部。這會讓你的頁面載入的快一點。
7、Avoid CSS expressions
避免使用CSS表示式
CSS表示式是動態設定CSS屬性的強大（但危險）方法。Internet Explorer從第5個版本開始支援CSS表示式。下面的例子中，使用CSS表示式可以實現隔一個小時切換一次背景顏色：
background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );
如上所示，expression中使用了JavaScript表示式。CSS屬性根據JavaScript表示式的計算結果來設定。expression方法在其它瀏覽器中不起作用，因此在跨瀏覽器的設計中單獨針對Internet
Explorer設定時會比較有用。
表示式的問題就在於它的計算頻率要比我們想象的多。不僅僅是在頁面顯示和縮放時，就是在頁面滾動、乃至移動滑鼠時都會要重新計算一次。給CSS表示式增加一個計數器可以跟蹤表示式的計算頻率。在頁面中隨便移動滑鼠都可以輕鬆達到10000次以上的計算量。
一個減少CSS表示式計算次數的方法就是使用一次性的表示式，它在第一次執行時將結果賦給指定的樣式屬性，並用這個屬性來代替CSS表示式。如果樣式屬性
必須在頁面週期內動態地改變，使用事件控制代碼來代替CSS表示式是一個可行辦法。如果必須使用CSS表示式，一定要記住它們要計算成千上萬次並且可能會對你 頁面的效能產生影響。
8、Make JavaScript and CSS external
JavaScript和CSS放在外部
很多效能規則都是關於如何處理外部檔案的。但是，在你採取這些措施前你可能會問到一個更基本的問題：JavaScript和CSS是應該放在外部檔案中呢還是把它們放在頁面本身之內呢？
在實際應用中使用外部檔案可以提高頁面速度，因為JavaScript和CSS檔案都能在瀏覽器中產生快取。內建在HTML文件中的JavaScript
和CSS則會在每次請求中隨HTML文件重新下載。這雖然減少了HTTP請求的次數，卻增加了HTML文件的大小。從另一方面來說，如果外部檔案中的
JavaScript和CSS被瀏覽器快取，在沒有增加HTTP請求次數的同時可以減少HTML文件的大小。
關鍵問題是，外部JavaScript和CSS檔案快取的頻率和請求HTML文件的次數有關。雖然有一定的難度，但是仍然有一些指標可以一測量它。如果一
個會話中使用者會瀏覽你網站中的多個頁面，並且這些頁面中會重複使用相同的指令碼和樣式表，快取外部檔案就會帶來更大的益處。
許多網站沒有功能建立這些指標。對於這些網站來說，最好的堅決方法就是把JavaScript和CSS作為外部檔案引用。比較適合使用內建程式碼的例外就是 網站的主頁，如Yahoo!主頁和My
Yahoo!。主頁在一次會話中擁有較少（可能只有一次）的瀏覽量，你可以發現內建JavaScript和CSS對於終端使用者來說會加快響應時
間。
對於擁有較大瀏覽量的首頁來說，有一種技術可以平衡內建程式碼帶來的HTTP請求減少與通過使用外部檔案進行快取帶來的好處。其中一個就是在首頁中內建
JavaScript和CSS，但是在頁面下載完成後動態下載外部檔案，在子頁面中使用到這些檔案時，它們已經快取到瀏覽器了。
9、Reduce DNS lookups（減少DNS查詢）
域名系統（DNS）提供了域名和IP的對應關係，就像電話本中人名和他們的電話號碼的關係一樣。當你在瀏覽器位址列中輸入www.dudo.org時，DNS解析伺服器就會返回這個域名對應的IP地址。DNS解析的過程同樣也是需要時間的。一般情況下返回給定域名對應的IP地址會花費20到120毫秒的時間。而且在這個過程中瀏覽器什麼都不會做直到DNS查詢完畢。
快取DNS查詢可以改善頁面效能。這種快取需要一個特定的快取伺服器，這種伺服器一般屬於使用者的ISP提供商或者本地區域網控制，但是它同樣會在使用者使用 的計算機上產生快取。DNS資訊會保留在作業系統的DNS快取中（微軟Windows系統中DNS Client Service）。大多數瀏覽器有獨立於作業系統以外的自己的快取。由於瀏覽器有自己的快取記錄，因此在一次請求中它不會受到作業系統的影響。
Internet Explorer預設情況下對DNS查詢記錄的快取時間為30分鐘，它在登錄檔中的鍵值為DnsCacheTimeout。Firefox對DNS的查詢 記錄快取時間為1分鐘，它在配置檔案中的選項為network.dnsCacheExpiration（Fasterfox把這個選項改為了1小時）。
當客戶端中的DNS快取都為空時（瀏覽器和作業系統都為空），DNS查詢的次數和頁面中主機名的數量相同。這其中包括頁面中URL、圖片、指令碼檔案、樣式表、Flash物件等包含的主機名。減少主機名的數量可以減少DNS查詢次數。
減少主機名的數量還可以減少頁面中並行下載的數量。減少DNS查詢次數可以節省響應時間，但是減少並行下載卻會增加響應時間。我的指導原則是把這些頁面中 的內容分割成至少兩部分但不超過四部分。這種結果就是在減少DNS查詢次數和保持較高程度並行下載兩者之間的權衡了。
10、Minify JavaScript and CS（縮小JavaScript和CSS）
精簡是指從去除程式碼不必要的字元減少檔案大小從而節省下載時間。消減程式碼時，所有的註釋、不需要的空白字元（空格、換行、tab縮排）等都要去掉。在
JavaScript中，由於需要下載的檔案體積變小了從而節省了響應時間。精簡JavaScript中目前用到的最廣泛的兩個工具是JSMin和YUI
Compressor。YUI Compressor還可用於精簡CSS。
混淆是另外一種可用於原始碼優化的方法。這種方法要比精簡複雜一些並且在混淆的過程更易產生問題。在對美國前10大網站的調查中發現，精簡也可以縮小原來 程式碼體積的21%，而混淆可以達到25%。儘管混淆法可以更好地縮減程式碼，但是對於JavaScript來說精簡的風險更小。
除消減外部的指令碼和樣式表文件外，<script>和<style>程式碼塊也可以並且應該進行消減。即使你用Gzip壓縮過指令碼
和樣式表，精簡這些檔案仍然可以節省5%以上的空間。由於JavaScript和CSS的功能和體積的增加，消減程式碼將會獲得益處。
11、Avoid URL redirects（避免重定向）
跳轉是使用301和302程式碼實現的。下面是一個響應程式碼為301的HTTP頭：
HTTP/1.1 301 Moved Permanently
Location: http://example.com/newuri
Content-Type: text/html
瀏覽器會把使用者指向到Location中指定的URL。標頭檔案中的所有資訊在一次跳轉中都是必需的，內容部分可以為空。不管他們的名稱，301和302響
應都不會被快取除非增加一個額外的頭選項，如Expires或者Cache-Control來指定它快取。<meat />元素的重新整理標籤和JavaScript也可以實現URL的跳轉，但是如果你必須要跳轉的時候，最好的方法就是使用標準的3XXHTTP狀態代
碼，這主要是為了確保“後退”按鈕可以正確地使用。
但是要記住跳轉會降低使用者體驗。在使用者和HTML文件中間增加一個跳轉，會拖延頁面中所有元素的顯示，因為在HTML檔案被載入前任何檔案（影象、Flash等）都不會被下載。
有一種經常被網頁開發者忽略卻往往十分浪費響應時間的跳轉現象。這種現象發生在當URL本該有斜槓（/）卻被忽略掉時。例如，當我們要訪問http://astrology.yahoo.com/astrology 時，實際上返回的是一個包含301程式碼的跳轉，它指向的是http://astrology.yahoo.com/astrology/ （注意末尾的斜槓）。在Apache伺服器中可以使用Alias 或者 mod_rewrite或者the DirectorySlash來避免。
連線新網站和舊網站是跳轉功能經常被用到的另一種情況。這種情況下往往要連線網站的不同內容然後根據使用者的不同型別（如瀏覽器型別、使用者賬號所屬型別）來 進行跳轉。使用跳轉來實現兩個網站的切換十分簡單，需要的程式碼量也不多。儘管使用這種方法對於開發者來說可以降低複雜程度，但是它同樣降低使用者體驗。一個 可替代方法就是如果兩者在同一臺伺服器上時使用Alias和mod_rewrite和實現。如果是因為域名的不同而採用跳轉，那麼可以通過使用Alias 或者mod_rewirte建立CNAME（儲存一個域名和另外一個域名之間關係的DNS記錄）來替代。
12、Remove duplicate JavaScript and CSS（刪除重複的指令碼和樣式）
在同一個頁面中重複引用JavaScript檔案會影響頁面的效能。你可能會認為這種情況並不多見。對於美國前10大網站的調查顯示其中有兩家存在重複引 用指令碼的情況。有兩種主要因素導致一個指令碼被重複引用的奇怪現象發生：團隊規模和指令碼數量。如果真的存在這種情況，重複指令碼會引起不必要的HTTP請求和
無用的JavaScript運算，這降低了網站效能。
在Internet Explorer中會產生不必要的HTTP請求，而在Firefox卻不會。在Internet
Explorer中，如果一個指令碼被引用兩次而且它又不可快取，它就會在頁面載入過程中產生兩次HTTP請求。即時指令碼可以快取，當用戶過載頁面時也會產 生額外的HTTP請求。
除增加額外的HTTP請求外，多次運算指令碼也會浪費時間。在Internet Explorer和Firefox中不管指令碼是否可快取，它們都存在重複運算JavaScript的問題。
一個避免偶爾發生的兩次引用同一指令碼的方法是在模板中使用指令碼管理模組引用指令碼。在HTML頁面中使用<script />標籤引用指令碼的最常見方法就是：
<script type="text/javascript" src="menu_1.0.17.js"></script>
在PHP中可以通過建立名為insertScript的方法來替代：
<?php insertScript("menu.js") ?>
為了防止多次重複引用指令碼，這個方法中還應該使用其它機制來處理指令碼，如檢查所屬目錄和為指令碼檔名中增加版本號以用於Expire檔案頭等。
13、Configure entity tags (ETags)（配置實體標記ETag）
Entity tags（ETags）（實體標籤）是web伺服器和瀏覽器用於判斷瀏覽器快取中的內容和伺服器中的原始內容是否匹配的一種機制（“實體”就是所說的“內
容”，包括圖片、指令碼、樣式表等）。增加ETag為實體的驗證提供了一個比使用“last-modified
date（上次編輯時間）”更加靈活的機制。Etag是一個識別內容版本號的唯一字串。唯一的格式限制就是它必須包含在雙引號內。原始伺服器通過含有
ETag檔案頭的響應指定頁面內容的ETag。
HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: "10c24bc-4ab-457e1c1f"
Content-Length: 12195
稍後，如果瀏覽器要驗證一個檔案，它會使用If-None-Match檔案頭來把ETag傳回給原始伺服器。在這個例子中，如果ETag匹配，就會返回一
個304狀態碼，這就節省了12195位元組的響應。 GET /i/yahoo.gif HTTP/1.1
Host: us.yimg.com
If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
If-None-Match: "10c24bc-4ab-457e1c1f"
HTTP/1.1 304 Not Modified
ETag的問題在於，它是根據可以辨別網站所在的伺服器的具有唯一性的屬性來生成的。當瀏覽器從一臺伺服器上獲得頁面內容後到另外一臺伺服器上進行驗證時
ETag就會不匹配，這種情況對於使用伺服器組和處理請求的網站來說是非常常見的。預設情況下，Apache和IIS都會把資料嵌入ETag中，這會顯著
減少多伺服器間的檔案驗證衝突。
Apache 1.3和2.x中的ETag格式為inode-size-timestamp。即使某個檔案在不同的伺服器上會處於相同的目錄下，檔案大小、許可權、時間戳等都完全相同，但是在不同伺服器上他們的內碼也是不同的。
IIS 5.0和IIS 6.0處理ETag的機制相似。IIS中的ETag格式為Filetimestamp:ChangeNumber。用ChangeNumber來跟蹤
IIS配置的改變。網站所用的不同IIS伺服器間ChangeNumber也不相同。
不同的伺服器上的Apache和IIS即使對於完全相同的內容產生的ETag在也不相同，使用者並不會接收到一個小而快的304響應；相反他們會接收一個正
常的200響應並下載全部內容。如果你的網站只放在一臺伺服器上，就不會存在這個問題。但是如果你的網站是架設在多個伺服器上，並且使用Apache和
IIS產生預設的ETag配置，你的使用者獲得頁面就會相對慢一點，伺服器會傳輸更多的內容，佔用更多的頻寬，代理也不會有效地快取你的網站內容。即使你的 內容擁有Expires檔案頭，無論使用者什麼時候點選“重新整理”或者“過載”按鈕都會發送相應的GET請求。
如果你沒有使用ETag提供的靈活的驗證模式，那麼幹脆把所有的ETag都去掉會更好。Last-Modified檔案頭驗證是基於內容的時間戳的。去掉
ETag檔案頭會減少響應和下次請求中檔案的大小。微軟的這篇支援文稿講述瞭如何去掉ETag。在Apache中，只需要在配置檔案中簡單新增下面一行代
碼就可以了：
FileETag none
如果是多伺服器負載均衡，可以設定為FileETag MTime Size，apache預設設定為FileETag
INode MTime Size，去掉INode。
Last-Modified 只能精確到s，那麼可能存在短時內修改很多次。ETAG是類似於檔案唯一標識，只要不變，則就不會重新請求。
ETag如何幫助提升效能
聰明的伺服器開發者會把ETags和GET請求的“If-None-Match”頭一起使用，這樣可利用客戶端（例如瀏覽器）的快取。因為伺服器首先產生ETag，伺服器可在稍後使用它來判斷頁面是否已經被修改。本質上，客戶端通過將該記號傳回伺服器要求伺服器驗證其（客戶端）快取。 其過程如下： 客戶端請求一個頁面（A）。 伺服器返回頁面A，並在給A加上一個ETag。 客戶端展現該頁面，並將頁面連同ETag一起快取。 客戶再次請求頁面A，並將上次請求時伺服器返回的ETag一起傳遞給伺服器。 伺服器檢查該ETag，並判斷出該頁面自上次客戶端請求之後還未被修改，直接返回響應304（未修改——Not Modified）和一個空的響應體。
作用
Etag 主要為了解決 Last-Modified 無法解決的一些問題。 1、一些檔案也許會週期性的更改，但是他的內容並不改變(僅僅改變的修改時間)，這個時候我們並不希望客戶端認為這個檔案被修改了，而重新GET; 2、某些檔案修改非常頻繁，比如在秒以下的時間內進行修改，(比方說1s內修改了N次)，If-Modified-Since能檢查到的粒度是s級的，這種修改無法判斷(或者說UNIX記錄MTIME只能精確到秒