網站前端和後台機能優化的34條名貴經歷和辦法。本站提示廣大學習愛好者：（網站前端和後台機能優化的34條名貴經歷和辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是網站前端和後台機能優化的34條名貴經歷和辦法正文
1 削減HTTP要求數目 (Minimize HTTP Requests)
tag:content
80%的用戶呼應時光被消費在前端，而這個中的絕年夜多半時光是用於下載頁面中的圖片、款式表、劇本和Flash這些組件。削減這些組件的數目便可以削減展現頁面所需的要求數，而這是進步網頁呼應速度的症結。
樸實的頁面設計固然是削減組件的一種門路，但有無能統籌豐碩的頁面內容和疾速的呼應速度的辦法呢？上面就是一些不錯的技能，能在供給豐碩的頁面展示的同時，削減Http要求數目：
歸並文件，經由過程把一切劇本置於一個劇本文件裡或許把一切款式表放於一個款式表文件中，從而削減Http要求的數目。當分歧頁面須要運用分歧的劇本或款式時，歸並這些文件會是一個很年夜的挑釁，不外在宣布網站時停止這類歸並，將是進步網站呼應速度的主要一步。
CSS Sprites是削減圖片要求的首選計劃。把一切的配景圖片歸並到一張圖中，應用CSS的background-image 和background-position 屬性去掌握展示適當的圖片區域。
Image maps把多張圖片組分解為一張圖片。圖片的總年夜小是不變的，但削減Http要求數會進步頁面的呼應速度。Image maps只能用於圖片在網頁中相鄰的情形，好比導航條。制訂image maps中的圖片坐標是個很費事的進程，並且輕易失足。同時給導航應用image maps也其實不易讀，所以其實不推舉應用。
內聯圖片應用data: URL scheme 把圖片數據嵌入頁面，但這會增長Html文檔的年夜小。把內聯圖片歸並到你被緩存的的款式表中是一個能既削減HTTP要求數又不會增長頁面年夜小的辦法。但今朝其實不是一切的主流閱讀器都支撐內聯圖片。
削減頁面的Http要求數目是第一步，並且關於進步用戶首次拜訪體驗是最主要的一步。正如在 Tenni Theurer的blog中的Browser Cache Usage - Exposed!裡描寫的，天天，有 40%-60%的訪客並沒有你的網站的緩存文件。進步這些首次訪客的拜訪速度是進步用戶體驗的症結。
2 應用內容散布式收集 (Use a Content Delivery Network)
tag:server
用戶銜接你的網站辦事器的速度影響呼應的快慢。把你的網站安排在多台散布於分歧地區的辦事器上，會讓用戶認為你的頁面加載速度更快。那末我們應當從哪裡開端呢？
不要一開端就把從新設計你的網站使其可以或許順應散布式構造作為完成網站地區散布的第一步。依據你的網站的龐雜水平分歧，更新網站構造的進程或許會包括諸好像步會話狀況、在辦事器間復制數據庫等一系列龐雜的步調。如許你進步用戶拜訪速度的目標反而會被更新網站架構的任務延誤。
記住，用戶80-90%的拜訪時光被消費鄙人載頁面中的圖片、款式表、劇本、Flash這些組件上。這是網站展現的黃金軌則。那末與其從新設計網站的構造，不如先完成這些靜態組件的散布。這不只僅可以年夜幅削減呼應時光，並且因為內容散布式收集（content delivery networks）的存在，這將是個很簡略的任務。
內容散布式收集（CDN）是一系列散布在分歧地區的辦事器的聚集，可以或許更有用的給用戶發送信息。它會依據一種權衡網域間隔的辦法，拔取為某個用戶發送數據的辦事器。好比，達到用戶起碼跳或許最快響應速度的辦事器會被選中。
一些年夜型Internet公司具有他們本身的CDN，但應用公用的CDN辦事供給商更加劃算，好比 Akamai Technologies, Mirror Image Internet, 或許Limelight Networks。關於剛起步的公司和小我網站來講，CDN辦事的消費或許會偏高。但當你的目的用戶愈來愈多並且趨於國際化，用CDN來下降呼應時光就很需要了。在Yahoo!，把靜態的內容從本身的收集辦事器移到CDN進步了用戶20%乃至更多的拜訪速度。轉向CDN會是一個只須要絕對簡略的代碼更新的任務，並且那將會明顯的進步你的網站拜訪速度。
3 給頭部添加一個掉效期或許Cache-Control (Add an Expires or a Cache-Control Header)
tag:server
這條軌則包括兩方面：
網頁設計愈來愈豐碩，頁面裡包括了愈來愈多的劇本、款式表、圖片和Flash。頁面的首次拜訪者或許會發送多個HTTP要求，但經由過程給頭部添加掉效期，你可使那些組件被緩存。這會防止下次閱讀頁面時的不用要的HTTP要求。給圖片文件的頭部設置掉效時光更加經常使用，但包含劇本文件、款式表和 Flash之類的一切組件的頭部都應當被設置掉效時光。
閱讀器（還有署理辦事器）應用緩存以削減HTTP要求的數目和年夜小，進步網頁的加載速度。辦事器在HTTP響應中經由過程頭部中的過時時光告訴客戶端一個組件可以被緩存多久。上面是一個far future的過時頭部，告知閱讀器這個呼應直到2010年4月15日才會過時：
Expires: Thu, 15 Apr 2010 20:00:00 GMT
假如你應用的是Apache辦事器，應用ExpiresDefault 指令會設置一個絕對於以後時光的過時時光。這裡有一個經由過程ExpiresDefault 指令把過時時光設為要求時光以後10年的例子：
ExpiresDefault "access plus 10 years"
記住，假如你應用了far future過時頭部，你必需在組件更新時改換它的名字。在Yahoo!我們平日在扶植網站的進程中履行如許的步調：組件的名字裡包括了它的版本，好比：yahoo_2.0.6.js。
應用一個far future過時頭部只會在用戶曾經拜訪你的網站以後起感化。它不會影響一個沒有緩存的首次拜訪者的HTTP要求數目。所以這一切的後果取決於若干用戶拜訪頁面時有一份預緩存（一份"預緩存"中曾經包括了頁面的一切組件）。我們對此在Yahoo！做過測試，發明具有預緩存的用戶在 75-85%。給頭部添加far future掉效期，可以增長閱讀器緩存的組件數目偏重復用於隨後的頁面閱讀而不須要經由過程用戶的收集發送哪怕一個字節。
4 Gzip緊縮組件(Gzip Components)
tag:server
前台工程師的決議計劃可以或許明顯的削減在收集上傳輸 HTTP要求和呼應消費的時光。確切，終端用戶的帶寬速度、Internet辦事供給商和銜接交流機的辦事器這些身分都是開辟小組所不克不及掌握的。但還有一些其它身分會影響呼應的時光，好比緊縮文件，就會削減HTTP呼應的年夜小從而削減呼應的時光。
從HTTP/1.1開端，Web客戶端就被設定為支撐HTTP要求的頭部中Accept-Encoding指定的緊縮格局：
Accept-Encoding: gzip, deflate
當辦事器檢測到要求頭部中的這一代嗎，它就會應用客戶端供給的辦法列表中的一個來緊縮呼應內容。而辦事器經由過程呼應頭部中的Content- Encoding來告訴客戶端它所應用的緊縮方法：
Content-Encoding: gzip
Gzip是以後最經常使用也是最有用的緊縮方法，GNU項目開辟了這一辦法而且相符RFC 1952尺度。別的一種你能夠見過的緊縮格局是deflate，但它沒有那末有用和經常使用。
應用gzip緊縮平日會削減70%的呼應年夜小。以後閱讀器中年夜約90%的Internet通信傳輸聲明支撐gzip。假如你應用Apache辦事器，設置裝備擺設gzip的模塊取決於辦事器的版本：Apache 1.3 應用mod_gzip ，而Apache 2.x 應用mod_deflate。
閱讀器和署理會有一些已知的成績，能夠招致閱讀器的預期內容和取得的現實緊縮內容不婚配。榮幸的是，這類情形跟著舊閱讀器的應用者削減而削減。 Apache的模塊可以經由過程主動添加恰當的變更呼應文件頭來處理這些成績。
辦事器會依據文件類型選擇gzip緊縮的內容，但普通情形下，辦事器選擇緊縮的內容會過於局限。年夜部門網站會緊縮它們的Html文檔，而緊縮劇本和款式表也是值得一做的，但許多網站並沒有如許做，現實上，緊縮在包含 XML和JSON在內的任何文本呼應都是值得的。圖片和PDF文件不該該被gzip緊縮，由於它們曾經是被緊縮了的文件，gzip它們不只糟蹋CPU乃至還有增年夜文件年夜小的能夠。
Gzip盡量多的文件類型是削減頁面年夜小從而進步用戶體驗的一個簡略的辦法。
5 把款式表放在後面(Put Stylesheets at the Top)
tag:css
在研討Yahoo！的機能時，我們發明把款式表挪到文檔的頭部可讓頁面的加載顯得更快。由於把款式表放在頭部可讓頁面慢慢出現。
關懷網站機能的前台工程師平日願望頁面可以或許慢慢加載；即，我們願望閱讀器可以或許把曾經取得的內容盡快展示。這關於內容許多的頁面和收集銜接較慢的用戶尤其主要。賜與用戶視覺上的反應（好比進度提醒）的主要性，曾經經由了很詳實的論證。而關於我們來講，Html 頁面自己便可以作為進度提醒！當閱讀器慢慢加載頁面時，頭部、導航條、頂部的logo等等這些都可以作為對正在期待頁面的用戶的可視的反應。而這會從全體上進步用戶體驗。
把款式表放在文檔的最初，會招致包含IE在內的年夜部門閱讀器不停止慢慢出現。閱讀器為了不當款式轉變時重繪元素而中斷出現。用戶會非常無聊的看到一個空白的頁面。
Html標准明白劃定款式表應當被包括在頁面的HEAD中：“和A分歧，LINK只能在文檔的HEAD部位湧現，但它可以湧現屢次。”空白的屏幕或許因為沒有運用款式而惹起的內容的閃現都不值得去測驗考試。最好的辦法是遵守HTML標准，把款式表放在文檔的HEAD部位。
6 把劇本放在最初(Put Scripts at the Bottom)
tag:javascript
劇本能夠會梗塞並發的下載。HTTP/1.1標准建議閱讀器在每一個域名下只停止兩個並發下載。假如你把圖片放在多個域名下，可以完成多於兩個的並發下載。當劇本被下載時，即便應用分歧的域名。閱讀器也不會停止任何其它的下載。
有些情形下把劇本放究竟部其實不太輕易。好比，劇本應用了document.write 來添加部門頁面中的內容，就不克不及放到頁面中更前面的地位。還能夠有感化域的成績。許多情形下，還有一些變通的辦法。
平日的建議是應用延遲劇本。DEFER屬性注解劇本不包括document.write，並且提醒閱讀器持續展示。不幸的是，Firefox不支撐DEFER屬性。IE中，劇本可以被延遲，但其實不如你希冀的那末久。假如一個劇本可以被延遲，那末它也能夠被放在頁面的底部。這會讓你的頁面加載的更快。
7 不應用CSS表達式 (Avoid CSS Expressions)
tag:css
CSS表達式是一種無力的（同時也很風險的）靜態設置CSS屬性的辦法。從IE5開端支撐CSS表達式。好比，應用CSS表達式可以完成配景色彩每小時變換的後果。
background-color: expression_r( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );
如上所示，表達式辦法采取了 Javascript的表達。CSS屬性則被設為Javascript表達式的成果。其它的閱讀器會疏忽CSS表達式，所以關於設置專屬IE的屬性以便在分歧閱讀器間能有分歧的體驗是有效的。、
而CSS表達式的成績是它比年夜多半人希冀的履行次數更頻仍。表達式不只僅在頁面展示和從新設置年夜小的時刻履行，在頁面轉動，乃至用戶在頁面上移動鼠標時都邑履行。給CSS表達式添加一個計數器可以跟蹤CSS在甚麼時刻和如何履行。在頁面上挪動鼠標可以隨意馬虎的發生一萬次以上的履行。
應用一次性的表達式是削減CSS表達式的履行次數的一個辦法，當表達式第一次履行時，CSS表達式會被一個肯定的值取代。假如在頁面熟命周期中，款式屬性必需靜態的設定，應用事宜處置替換CSS表達式是一個可選的辦法。假如必需應用CSS表達式，要記得它們會履行上千次並影響頁面的機能。
8 應用內部的JavaScript和CSS (Make JavaScript and CSS External)
tag:javascript,css
許多機能規矩都是處理如何處置自力的組件的成績的。然則，斟酌這些之前，你應當先斟酌一個更根本的成績：JavaScript和CSS應當被放於內部的文件，照樣內聯在頁面裡？
在現實運用中應用內部的文件常常發生更快的頁面，由於閱讀器會緩存JavaScript和CSS文件。而內聯在頁面裡的JavaScript和CSS會在每次要求頁面時下載。這會削減所需的HTTP要求數，但增年夜HTML文檔的體積。而另外一方面，假如放在內部文件裡的JavaScript和CSS被閱讀器緩存，則既不消增長HTTP要求的數目，HTML文檔的體積也會削減。
症結的成績是，內部的JavaScript和CSS的組件被緩存的頻率和HTML文檔被要求的次數相干。固然很難去量化，但可以被用許多目標權衡。假如你的網站的用戶在每一個會話中閱讀了許多網頁並且許多頁面重用了雷同的JavaSctipt和款式表，緩存內部文件是有很年夜潛伏的利益的。
許多網站都相符如許的目標。關於這些網站來講，最好的處理計劃是把JavaScript和CSS宣布為零丁的文件。獨一的破例，關於主頁，內聯的文件更好一些，例如 Yahoo!'s front page 和 My Yahoo!。主頁在每一個會話中只要很少閱讀（或許只要一次），你會發明內聯的 JavaScript和CSS會讓終端用戶的呼應更快。
關於有許多頁面閱讀量的首頁來講，有許多能均衡內聯文件所供給的HTTP要求削減的後果與內部文件緩存取得的利益的技能。一種如許的技能就是把JavaScript和CSS內聯在說夜裡，但在頁面完成加載時靜態下載內部文件。隨後的頁面會挪用閱讀器中曾經緩存的內部文件。
9 削減DNS的查詢 (Reduce DNS Lookups)
tag:content
正如德律風簿令人名和他們的德律風號碼絕對應，域名體系（DNS）可以或許使域名和IP地址絕對應。當你在閱讀器中鍵入http://www.yahoo.com，閱讀器鏈接的DNS解析器會前往辦事器的 IP地址。域名解析會消耗一些時光，DNS查找給定域名的IP地址普通會消耗20-120毫秒。在DNS查找停止前，閱讀器不會從目的域名那邊下載任何器械。
DNS查詢會被緩存以便優化機能。會有一個專門的緩存辦事器停止緩存，用戶的ISP或許當地收集會保護它，但自力用戶的電腦裡也會有緩存。DNS信息存在於操作體系的DNS緩存裡（微軟Windows操作體系裡的“DNS客戶辦事”）。年夜部門閱讀器有它們本身的緩存，與操作體系的緩存相自力。當閱讀器在本身的緩存裡保留了DNS的記載，它不會向操作體系收回要求記載的請求。
IE默許緩存DNS查詢30分鐘，在注冊表的DnsCacheTimeout的鍵值中設定。Firefox則緩存DNS查詢一分鐘，在設置裝備擺設network.dnsCacheExpiration 中設定。（Fasterfox 將它變成一小時。）
當客戶真個DNS緩存被清空（包含閱讀器和操作體系的緩存），DNS查詢的數目同等於網頁中零丁的域名的數目。包含頁面中的鏈接，圖片，劇本文件，款式表，Flash對象等。削減分歧域名的數目則會削減DNS查詢的數目。
削減分歧域名的數目能夠削減頁面並行的下載數目。削減 DNS查詢延長了呼應時光，但削減了並行下載數或許會增長呼應時光。我的建議是將組件散布在兩到四個域名之間。這能很好的折衷削減DNS查詢進步的速度和保持較高程度的並行下載的後果。
10 減少JavaScript和CSS (Minify JavaScript and CSS)
tag:javascript,css
減少是指從代碼中刪除不用要的字母，削減文件體積從而進步加載速度。縮減代碼時須要移除一切的正文，和不須要的空白（空格，新行和tab）。如許處置JavaScript以後，會因為下載文件的體積被削減而進步呼應的機能。兩個經常使用的縮減JavaScript代碼的對象是JSMin 和YUI Compressor。YUI compressor也能夠緊縮CSS。
代碼混雜是另外一個可用於源代碼的優化計劃。它比緊縮更加龐雜，並且在混雜的進程中更輕易發生 Bug。縱不雅U.S.的前十年夜網站，緊縮取得了21%的體積減小而代碼混雜到達了25%。固然代碼混雜的緊縮水平更高，但緊縮JavaScript的風險更小。
不只僅要緊縮內部的劇本和款式表，內斂的<script>和<style>部門也能夠並且應該被緊縮。即便你gzip了你的劇本和款式，緊縮它們依然能削減5%以上的體積。跟著JavaScript和CSS的運用和體積的增長，緊縮你的代碼取得的收益也會愈來愈多。
11 防止重定向 (Avoid Redirects)
tag:content
重定向停止於 301或302狀況碼。這裡有一個301呼應的HTTP頭的例子：
閱讀器會主動把用戶轉向Location域中指明的Url地址。HTTP頭裡包括了重定向所需的一切信息。呼應的主體普通是空的。301或許302呼應都不會被現實緩存，除非添加額定的頭部，好比 Expires或許Cache- Control指清楚明了它應當被緩存。meta refresh標簽和JavaScript也能夠將用戶重定向到分歧的URL，但假如你必需履行重定向，最好的辦法是應用尺度的3XX HTTP狀況代碼，以便使撤退退卻按鈕任務正常。
須要謹記的是，重定向下降了用戶體驗。在用戶和HTML文檔之間拔出的重定向耽擱了頁面的出現和組件下載，由於它們都弗成能在取得HTML文檔之前開端。
一種最糟蹋機能的重定向頻仍產生而收集開辟者們卻常常沒無意識到，那就是本地址中應該有一個左斜線（/）卻沒有的時刻。好比，拜訪http://astrology.yahoo.com/astrology會招致一個301效應偏重定向到http://astrology.yahoo.com/astrology/（留意這裡加了一個左斜線）。在Apache中，這可使用mod_rewrite,或許在Apache事宜處置中應用DirectorySlash指令來修補。
應用重定向的另外一個罕見場景是銜接舊網站和新網站。還包含銜接網站的分歧部門，或許在分歧情形下（好比根據閱讀器的類型，用戶的類型等）重定向用戶。應用重定素來銜接兩個網站很簡略並且須要很少的額定代碼。固然在這些情形下應用重定向削減了開辟者的費事，但卻下降了用戶體驗。假如兩部門在統一個辦事器上，可使用Alias 和rewrite來替換重定向。假如域名變革惹起了重定向，可以創立一個CNAME（一種可以創立一個體名使一個域名指向另外一個的DNS記載）聯合 Alias 或許mod_rewrite來替換重定向。
12 移除反復的劇本 (Remove Duplicate Scripts)
tag:javascript
在統一個頁面中包括兩個雷同的劇本文件下降了機能。這其實不如你想象的那末罕有。在對美國十年夜網站中的檢討中，發明它們中的兩個包括了反復的劇本。有兩個重要身分增長了一個頁面包括兩個雷同劇本的概率——團隊的年夜小和劇本的數目。當劇本被反復包括時，因為增長了不用要的HTTP要求和JavaScript的履行，影響了機能。
不用要的HTTP要求在IE中存在，而Firefox終沒有。在IE中，假如一個內部劇本被包括了兩次並且沒有被緩存，在頁面加載的進程中會發生兩次HTTP要求。即便劇本被緩存了，當用戶重載頁面時，過剩的HTTP要求也會產生。
發生過剩的HTTP要求的同時，屢次履行劇本也會糟蹋時光。在Firefox和IE中，不管能否被緩存，劇本都邑被反復履行。
防止劇本被不測加載兩次的一個辦法是在你的模板體系中履行一個劇本治理模塊。平日的方法是在HTML頁面中應用SCRIPT標簽來添加一個劇本：
<script type="text/javascript" src="menu_1.0.17.js"></script>
HP 中，可以選擇創立一個叫做insertScript的辦法：
<?php insertScript("menu.js") ?>
這個函數不只僅能避免劇本被反復加載屢次，還可以處理劇本的其他成績，好比自力性檢測和為劇本添加版本號碼以應對far future Expires頭部。
13 設定ETags (Configure ETags)
tag:server
實體標簽（ETags）是辦事器和閱讀器用於肯定閱讀器中緩存的組件和辦事器中的能否對應的一種機制。（"entity"是組件的另外一種說法：圖片、劇本、款式表等等）添加 ETags用於鑒別組件供給了比純真應用“最初修正時光”更加靈巧的機制。ETag是一個獨一標識組件的特定版本的字符串。它的獨一格局標准是字符串必需被引號援用。起源辦事器應用ETag呼應頭來設定一個組件的ETag：
當閱讀器晚些時刻須要檢測一個組件時，它應用If-None-Match 頭部把ETag傳回起源辦事器。假如ETag婚配了，會前往一個304狀況碼，在這個例子裡它會削減12195個字節的呼應：
ETag的成績是它們常常在網站的一個辦事器中被設為獨一的，當閱讀器從一個辦事器獲得了組件並在稍後試圖到另外一個辦事器驗證時，ETag會不婚配，而這在應用多個辦事器來處置要求的網站中是很罕見的。默許情形下，Apache和IIS在ETag中嵌入的數據戲劇性的削減了運用多台辦事器的網站的ETag驗證勝利概率。
Apache1.3和2.新版本的ETag格局是inode-size- timestamp。固然一個給定的文件在多台辦事器中處於統一個目次，並且有異樣的年夜小，權限，時光戳，但它的inode在分歧辦事器中是分歧的。
IIS5.0和6.0有異樣的成績。IIS中ETag的格局是Filetimestamp:ChangeNumber。 ChangeNumber用來跟蹤IIS設置裝備擺設的轉變次數。一個網站的一切IIS弗成能有雷同的ChangeNumber。
這招致的成果是，Apache和IIS對完整雷同的組件發生的ETag在分歧辦事器間不克不及婚配。假如ETags不婚配，用戶不會獲得小而快的304呼應，而是一個通俗的200呼應和組件的一切數據。假如你把你的網站放在了一個辦事器裡，這不會是一個成績。但假如你的網站有多台辦事器，並且你應用了Apache和IIS 默許的ETag設置裝備擺設，你的用戶會拜訪頁面的速度會變慢，你的辦事器加載的水平更高，消費了更年夜的帶寬，署理辦事器不克不及有用的緩存你的內容。即便你的組件有一個ar future Expires頭部，當用戶重載或許刷新頁面時，仍然會發送一個GET要求。
假如你不盤算應用ETags供給的靈巧的驗證形式，你最好把ETag一切移除。Last-Modified頭部的驗證方法賜與組件的時光戳。移除ETag 同時削減呼應和隨後的要求中的HTTP頭部年夜小。這篇微軟的支撐文檔描寫了如何在IIS中移除 ETags。在Apache中，你只需在Apache設置裝備擺設文件中添加以下一行：
14 讓Ajax可以緩存 (Make Ajax Cacheable)
tag:content
Ajax 的利益之一是它能給用戶供給剎時的呼應，由於它從辦事端異步要求數據。但Ajax不克不及包管用戶在等待那些異步的JavaScript和XML呼應前往時甚麼都不做。在運用法式中，用戶能否持續期待取決於Ajax如何運用。好比，在一個基於Web的Email客戶端用戶會等待Ajax前往他們所搜刮的郵件信息。記住異步其實不代表“即刻”。
為了進步機能，優化Ajax呼應很主要。進步Ajax機能最主要的方法是使呼應緩存，正如“添加一個過時刻日懈弛存掌握頭”這一節評論辯論的。這些准繩異樣實用於Ajax。
我們看一個例子。一個Web2，0的郵件客戶端能夠會用Ajax主動下載用戶地址簿。假如用戶從前次應用郵件網站以來沒有修正她的地址簿，那末假如Ajax呼應應用了歷久掉效時光或許緩存掌握頭部，地址簿便可以從緩存中讀掏出來。閱讀器必需原告知“應用之前的緩存地址簿”而不是“要求一個新的地址簿”。可以在地址簿Ajax的URL中添加一個標識用戶最初一次修正地址簿的時光戳，好比，&t=1190241612。假如地址簿從最初一次下載後沒有被更改，時光戳將雷同而地址簿將會從閱讀器的緩存中獲得來替換額定的HTTP傳輸。假如用戶更改了她的地址簿，時光戳會包管新的URL不會懈弛存中的婚配，並且閱讀器會要求會要求更新的地址簿記載。
即便你的Ajax呼應時靜態創立的，並且只實用於一個用戶，它們仍然會被緩存。如許做會讓你的Web2.0運用法式更快。
15 更早的刷新緩沖區 (Flush the Buffer Early)
tag:server
當用戶要求一個頁面，辦事端會消費200至500毫秒的時光組合HTML頁面。在這時代，閱讀器會靜靜期待數據到來。PHP中有flush（）函數，它許可你向閱讀器發送部門停當的HTML呼應，如許閱讀器可以在辦事器處置余下的HTML頁面時去獲得組件。如許的利益重要在勞碌的後台和輕松的前台間可以看到。
在HEAD前面是放置刷新操作的好處所，由於頭部的HTML代碼更輕易發生，並且可讓你放置任何CSS和JavaScript文件，以便閱讀器在後台任務仍然停止時並行開端獲得組件。
例子：
... <!-- css, js -->
</head>
<?php flush(); ?>
<body>
... <!-- content -->
Yahoo! search先行研討而且停止了真人測試證實了應用這項技巧的利益。
16 在Ajax要求中應用GET辦法 (Use GET for AJAX Requests)
tag:server
Yahoo! Mail 團隊發明停止XMLHttpRequest的時刻，POST辦法在閱讀器平分兩步履行：先發送頭部，然後發送數據。所以最好應用只發送一個TCP包（除非你有許多的cookie）的GET辦法。IE中URL的最年夜長度是2000，所以假如你發送跨越 2000的數據就不克不及應用GET辦法。
一個風趣的景象是，POST辦法其實不像GET那樣現實發送數據（而Get則名不虛傳）。基於 HTTP標准，GET辦法意味著取回數據，所以當你只是要求數據時應用GET辦法更加成心義（從語義下去說），而在發送須要貯存在辦事器真個數據時則相反應用POST。
17 後加載組件 (Post-load Components)
tag:content
你可以細心打量下你的頁面然後自問：“甚麼是在頁面初始化時必需的？”那末其他的內容和組件可以放在前面。
JavaScript是幻想的用來朋分onload事宜之前和以後的選擇。例如你有履行拖放、下拉和動畫的JavaScript代碼和菜單，它們可以稍後加載，由於用戶在初始出現以後才會在頁面上拖動元素。其他的可以被後加載的處所包含隱蔽的內容（當用戶做某項操作才會展示的內容）和被折疊的圖片。
可以贊助你的對象有： YUI Image Loader能贊助你延緩加載折疊的圖片，並且YUI Get utility 可以或許很簡略的包裝運轉中的JS和CSS。好比，翻開Firebug的收集選項卡去檢查Yahoo! Home Page。
當機能目標和其它網站開辟的好的理論分歧時是不錯的。漸進加強的不雅念告知我們當支撐JavaScript時，會進步用戶體驗，但你必需確保在沒有JavaScript時頁面也能任務。所以當你確保頁面任務正常時，你會經由過程延後加載的那些更花梢的劇本好比拖放和動畫，來加強你的頁面。
18 事後加載組件 (Preload Components)
tag:content
預加載看起來和後加載准繩是個抵觸，但它實際上是為了別的一個目標。預加載組件讓你可以應用閱讀器的余暇時光來加載以後須要的組件（好比圖片，款式表和劇本）。如許當用戶閱讀下一個頁面的時刻，年夜部門組件都曾經在緩存裡了而頁面會加載的更快。
有幾種預加載的類型：
19 減小DOM元素的數目 (Reduce the Number of DOM Elements)
tag:content
龐雜的頁面意味著更多的字節須要被下載並且也意味著在JavaScript中遍歷DOM更慢。好比你在頁面中添加一個事宜，讓它在500或許 5000個DOM元素中輪回，它們的效力是分歧的。
更多的DOM元素注解有些標簽須要被改進而其實不必定須要移除現實內容。你能否為了結構而應用繁瑣的網一樣的表格？你能否只是為了填補一些結構的成績而應用了更多的div標簽？或許還有更好和更相符語義的標簽可使用。
DOM 元素的數目很好檢測，只需在Firebug的掌握台裡輸出：
document.getElementsByTagName_r('*').length
那末若干DOM元素算多呢？檢查下相似的應用較好的標簽的頁面。好比Yahoo! Home Page是一個很豐碩的頁面但只要700以下的DOM元素（HTML 標簽）。
20 分域安排部件：Split Components Across Domains
tag：內容
將部件朋分能使你取得最年夜的並行下載效力。但你同時須要留意不應用多於2~4個域名，以免DNS查詢招致的成績。例如，你可以將HTML內容和靜態的組建放於 www.example.org域名下，將靜態組件分離放於static1.example.org和static2.example.org之下。
檢查Tenni Theurer和Patty Chi的"Maximizing Parallel Downloads in the Carpool Lane"獲得更多關於並行下載的信息。
21 削減Iframe的數目 Minimize the Number of iframes
tag：內容
Iframes 可以或許使HTML文檔被拔出進父級文檔中。起首須要明白iframe的任務方法，能力有用的應用這一情勢。
<iframe> 的長處：
<iframe> 的缺陷：
22 防止404毛病 No 404s
tag：內容
一個取得沒用的404呼應的HTTP要求關於名貴的HTTP要求資本來講是完整不用要的，並且如許還會減慢用戶的體驗。
有的網站供給了有贊助的404毛病信息，好比"你能否在尋覓……？"，如許固然能進步用戶體驗，但異樣糟蹋了辦事端資本（好比數據庫）。特別不妙的是在要求一個內部的Javascript劇本文件掉敗時取得的一個404毛病，由於如許不只會梗塞並行的下載，並且閱讀器會測驗考試剖析404呼應的內容，來辨識它能否是有效的Javascript代碼。
23 削減Cookie的年夜小 Reduce Cookie Size
tag：cookie
有多種來由讓我們運用HTTP cookie，好比身份驗證，或許特性化設置。Cookie中的信息在辦事端和閱讀器間被放在HTTP頭中交流。盡可能削減cookie的體積對削減用戶取得呼應的時光非常主要。
檢查Tenni Theurer和Patty Chi的"When the Cookie Crumbles"獲得更多信息。
24 為部件應用沒有cookie的域名 Use Cookie-free Domains for Components
tag：cookie
當閱讀其要求一個靜態圖片並一同發送cookie時，辦事器其實不須要這些cookie。如許只是毫有益處的創立了過剩的收集流量。應該包管靜態的部件在要求時沒有攜帶cookie，所以須要把你的靜態部件放在另外一個子域名下。
假如你的域名是www.example.org，你可以將你的靜態部件放在static.example.org中。假如你把cookie設置在頂級域名example.org上而不是 www.example.org，那末一切發送至static.example.org的要求會包含那些cookie。在這類情形下，你可以買一個全新的沒有cookie的域名來放置你的靜態部件。Yahoo！應用了yimg.com，YouTube試用了ytimg.com，Amazon應用的是 images-amazon.com。
將靜態部件放於沒有cookie的域名下的另外一個利益是一些署理辦事器會謝絕緩存有cookie 的部件。於此相干的一點是，假如你疑惑你應當為你的首頁應用example.org照樣www.example.org，斟酌cookie的贏下。省略 www會讓你不能不把cookie寫到*.example.org下，所以斟酌機能，最好應用www.子域名，然後把cookie寫到這個子域名下。
25 削減DOM的讀取 Minimize DOM Access
tag：javascript
應用Javascript讀取 DOM元素很慢，所認為了取得呼應更快的頁面，你應當：
26 開辟靈活的事宜處置法式 Develop Smart Event Handlers
tag：javascript
假如有太多的事宜處置邏輯安排在DOM樹的分歧元素上，它們的頻仍履行會拖慢頁面的呼應速度。而應用事宜拜托是一個好的處理辦法。假如在一個Div中有10個按鈕，與其在每一個按鈕上都放一個事宜處置法式，步入只在Div上放一個事宜處置法式。事宜會冒泡上溯，如許你就會捕捉這一事宜，並找出是哪一個按鈕提議的它。
異樣，你其實不須要期待onload事宜來啟動一些操作DOM樹的法式。你只須要包管你須要操作的元素可用便可以了。你不須要期待一切的圖片下載終了，你應該應用DOMContentLoaded事宜來替換onload事宜，固然，今朝其實不是一切閱讀器都支撐這一事宜，你可使用YUI Event組件，個中包括了一個onAvailable函數。
檢查Julien Lecomte的"High Performance Ajax Applications"獲得更多信息。
27 選擇<link>而不是@import Choose <link> over @import
tag：css
後面提到把CSS應該放在最頂端來供給預顯。在IE中，放在頁面底部的@import和<link>後果是一樣的，所以最好不要用它。
28 不應用過濾器 Avoid Filters
tag：css
IE專有的AlphaImageLoader過濾器是為懂得決半通明真色PNG圖片在IE7之前的版本中顯示的成績。這個過濾器會在圖片下載時梗塞住展現。並且它會消費內存並影響每一個元素而不只僅是每張圖片，所以這個過濾器的成績許多。
所以最好在IE中完整不應用AlphaImageLoader過濾器，而應用漸淡的 PNG8圖片。假如你明白須要AlphaImageLoader，請應用hack _filter，從而不影響到你的IE7+的用戶。
29 優化圖片 Optimize Images
tag：images
當設計師制造好網站的圖片後，還有些工作應當是你在把這些圖片上傳到辦事器之前做的。
30 優化CSS精靈 Optimize CSS Sprites
tag：images
31 不要在HTML中縮放圖片 Don't Scale Images in HTML
tag：images
不要應用年夜小跨越須要的圖片，即便你可以或許在HTML中設置它的屬性。假如你須要
<img width="100" height="100" src="mycat.jpg" alt="My Cat" />
那末就應用正好100*100px的圖片，而不是應用縮放後的500*500的圖片。
32 應用小的可緩存的Favicon.ico Make favicon.ico Small and Cacheable
tag：images
favicon.icon是放在辦事器根目次的一個圖片，它是個費事卻不能不處置，由於即便你不關懷，閱讀器仍然會要求這張圖片，所以最好不要供給一個404的毛病。並且因為它是在統一辦事器下的，Cookie也會跟著每次要求一並發送。這張圖片異樣攪擾下載隊列，好比在IE中，當你在onload 事宜中要求額定的組件時，favicon會在這些額定組件之前下載。
所認為了削減favicon.ico的晦氣影響，我們應該：
Imagemagick 可以或許贊助你創立小圖片。
33 包管組件年夜小小於25K Keep Components under 25K
tag：mobile
這一限制是由於iPone不會緩存年夜於25K的組件，留意這裡指的是未緊縮前的年夜小。這就是為何減少年夜小很主要，由於單單gzip其實不足夠。
檢查Wayne Shea和Tenni Theurer的"Performance Research, Part 5: iPhone Cacheability - Making it Stick"獲得更多信息。
34 把組件打包進多部門文檔中 Pack Components into a Multipart Document
tag：mobile
把組件打包進多部門文檔相似一封包括有附件的郵件，它能讓你經由過程一個HTTP要求獲得多個組件（記住HTTP要求是很昂貴的）。當你應用這一技巧，請先檢討客戶端能否支撐它(iPone不支撐)。
