設置input的擴展屬性autocomplete 爲off便可javascript
;function($,undefined) 前面的分號是什麼用處
;(function($){$.extend($.fn...
現般在一些 JQuery 函數前面有分號,在前面加分號能夠有多種用途:
一、防止多文件集成成一個文件後，高壓縮出現語法錯誤。
二、這是一個匿名函數，通常js庫都採用這種自執行的匿名函數來保護內部變量 (function(){})()。
三、由於undefined是window的屬性，聲明爲局部變量以後，在函數中若是再有變量與undefined做比較的話，程序就能夠不用搜索undefined到window，能夠提升程序性能。php
轉自這裏css
JSON 和 JSONP 兩兄弟
項目中遇到這個新事物，轉一篇不錯的總結，原文前端
現在ajax威風凜凜java
但說到AJAX就會不可避免的面臨兩個問題，第一個是AJAX以何種格式來交換數據？第二個是跨域的需求如何解決？node
這兩個問題目前都有不一樣的解決方案，好比數據能夠用自定義字符串或者用XML來描述，跨域能夠經過服務器端代理來解決。python
但到目前爲止最被推崇或者說首選的方案仍是用JSON來傳數據，靠JSONP來跨域。而這就是本文將要講述的內容。jquery
json與jsonpweb
json：一種數據交換格式
jsonp：一種依靠開發人員的聰明才智創造出的一種非官方跨域數據交互協議。
一個是描述信息的格式，一個是信息傳遞雙方約定的方法。
json的優勢
一、基於純文本，跨平臺傳遞極其簡單；
二、Javascript原生支持，後臺語言幾乎所有支持；
三、輕量級數據格式，佔用字符數量極少，特別適合互聯網傳遞；
四、可讀性較強，雖然比不上XML那麼一目瞭然，但在合理的依次縮進以後仍是很容易識別的；
五、容易編寫和解析，固然前提是你要知道數據結構；
JSON的缺點固然也有，但在做者看來實在是可有可無的東西，因此再也不單獨說明。
JSON的格式或者叫規則：
JSON可以以很是簡單的方式來描述數據結構，XML能作的它都能作，所以在跨平臺方面二者徹底不分伯仲。
一、JSON只有兩種數據類型描述符，大括號{}和方括號[]，其他英文冒號:是映射符，英文逗號,是分隔符，英文雙引號""是定義符。
二、大括號{}用來描述一組「不一樣類型的無序鍵值對集合」（每一個鍵值對能夠理解爲OOP的屬性描述），方括號[]用來描述一組「相同類型的有序數據集合」（可對應OOP的數組）。
三、上述兩種集合中如有多個子項，則經過英文逗號,進行分隔。
四、鍵值對以英文冒號:進行分隔，而且建議鍵名都加上英文雙引號」"，以便於不一樣語言的解析。
五、JSON內部經常使用數據類型無非就是字符串、數字、布爾、日期、null 這麼幾個，字符串必須用雙引號引發來，其他的都不用，日期類型比較特殊，這裏就不展開講述了，只是建議若是客戶端沒有按日期排序功能需求的話，那麼把日期時間直接做爲字符串傳遞就好，能夠省去不少麻煩。
JSON實例
// 描述一我的
var person = {
"Name": "Bob",
"Age": 32,
"Company": "IBM",
"Engineer": true
}
// 獲取這我的的信息
var personAge = person.Age;
// 描述幾我的
var members = [
{
"Name": "Bob",
"Age": 32,
"Company": "IBM",
"Engineer": true
},
{
"Name": "John",
"Age": 20,
"Company": "Oracle",
"Engineer": false
},
{
"Name": "Henry",
"Age": 45,
"Company": "Microsoft",
"Engineer": false
}
]
// 讀取其中John的公司名稱
var johnsCompany = members[1].Company;
// 描述一次會議
var conference = {
"Conference": "Future Marketing",
"Date": "2012-6-1",
"Address": "Beijing",
"Members":
[
{
"Name": "Bob",
"Age": 32,
"Company": "IBM",
"Engineer": true
},
{
"Name": "John",
"Age": 20,
"Company": "Oracle",
"Engineer": false
},
{
"Name": "Henry",
"Age": 45,
"Company": "Microsoft",
"Engineer": false
}
]
}
// 讀取參會者Henry是否工程師
var henryIsAnEngineer = conference.Members[2].Engineer;
JSONP
JSONP產生的緣由
1. ajax直接請求普通文件時存在跨域無權限訪問的額問題
2. web頁面調用js文件時則不受是否跨域的影響（凡是擁有「src」這個屬性的標籤都有跨域的能力好比<script>、<img>、<iframe>）
3. 所以，若是想經過純web端跨域訪問數據只有一種可能，就是在遠程服務器上設法把數據裝進js格式的文件裏
4. 已知json純字符數據格式能夠描述複雜數據，並且被js原生支持
5. 這樣子解決方案就呼之欲出了，web客戶端經過與調用腳本如出一轍的方式，來調用跨域服務器上動態生成的js格式文件（通常以JSON爲後綴），顯而易見，服務器之因此要動態生成JSON文件，目的就在於把客戶端須要的數據裝入進去。
6. 客戶端在對JSON文件調用成功以後，也就得到了本身所需的數據，剩下的就是按照本身需求進行處理和展示了，這種獲取遠程數據的方式看起來很是像AJAX，但其實並不同。
7. 爲了便於客戶端使用數據，逐漸造成了一種非正式傳輸協議，人們把它稱做JSONP，該協議的一個要點就是容許用戶傳遞一個callback參數給服務端，而後服務端返回數據時會將這個callback參數做爲函數名來包裹住JSON數據，這樣客戶端就能夠隨意定製本身的函數來自動處理返回數據了。
function getCitys() {
return $.ajax('http://api.miwifi.com/kujiale_proxy/get/openapi/city', {
dataType: 'jsonp',
success: function(rsp) {
if (rsp.code == 0) {
Cache.set('citys', rsp.data);
}
}
});
}
其餘
一、ajax和jsonp這兩種技術在調用方式上「看起來」很像，目的也同樣，都是請求一個url，而後把服務器返回的數據進行處理，所以jquery和ext等框架都把jsonp做爲ajax的一種形式進行了封裝；
二、但ajax和jsonp其實本質上是不一樣的東西。ajax的核心是經過XmlHttpRequest獲取非本頁內容，而jsonp的核心則是動態添加<script>標籤來調用服務器提供的js腳本。
三、因此說，其實ajax與jsonp的區別不在因而否跨域，ajax經過服務端代理同樣能夠實現跨域，jsonp自己也不排斥同域的數據的獲取。
四、還有就是，jsonp是一種方式或者說非強制性協議，如同ajax同樣，它也不必定非要用json格式來傳遞數據，若是你願意，字符串都行，只不過這樣不利於用jsonp提供公開服務。
document.body.scrollTop與document.documentElement.scrollTop兼容
項目中遇到這個小問題，看到有前輩總結，借來用一下
document.body.scrollTop與document.documentElement.scrollTop兼容
這兩天在寫一個JS的網頁右鍵菜單，在實現菜單定位的時候發現了這個問題：chrome竟然不認識document.documentElement.scrollTop！
看前輩們的文章，紛紛表示若是有文檔聲明（即網頁第一句的docType）的狀況下，標準瀏覽器是隻認識documentElement.scrollTop的，但chrome雖然我感受比firefox還標準，但卻不認識這個，在有文檔聲明時，chrome也只認識document.body.scrollTop.
因爲在不一樣狀況下，document.body.scrollTop與document.documentElement.scrollTop都有可能取不到值，那到底網頁的scrollTop值怎麼獲得呢？難道又要用javascript進行判斷？
其實沒必要。由於document.body.scrollTop與document.documentElement.scrollTop二者有個特色，就是同時只會有一個值生效。好比document.body.scrollTop能取到值的時候，document.documentElement.scrollTop就會始終爲0；反之亦然。因此，若是要獲得網頁的真正的scrollTop值，能夠這樣：
varsTop=document.body.scrollTop+document.documentElement.scrollTop;
這兩個值總會有一個恆爲0，因此不用擔憂會對真正的scrollTop形成影響。一點小技巧，但很實用。
URL中的#
做者：阮一峯 http://www.ruanyifeng.com/blog/2011/03/url_hash.html
1、#的涵義
#表明網頁中的一個位置。其右面的字符，就是該位置的標識符。好比，
http://www.example.com/index.html#print
就表明網頁index.html的print位置。瀏覽器讀取這個URL後，會自動將print位置滾動至可視區域。
爲網頁位置指定標識符，有兩個方法。一是使用錨點，好比<a name="print"></a>，二是使用id屬性，好比<div id="print" >。
2、HTTP請求不包括#
#是用來指導瀏覽器動做的，對服務器端徹底無用。因此，HTTP請求中不包括#。
好比，訪問下面的網址，
http://www.example.com/index.html#print
瀏覽器實際發出的請求是這樣的：
GET /index.html HTTP/1.1
Host: www.example.com
能夠看到，只是請求index.html，根本沒有"#print"的部分。
3、#後的字符
在第一個#後面出現的任何字符，都會被瀏覽器解讀爲位置標識符。這意味着，這些字符都不會被髮送到服務器端。
好比，下面URL的原意是指定一個顏色值：
http://www.example.com/?color=#fff
可是，瀏覽器實際發出的請求是：
GET /?color= HTTP/1.1
Host: www.example.com
能夠看到，"#fff"被省略了。只有將#轉碼爲%23，瀏覽器纔會將其做爲實義字符處理。也就是說，上面的網址應該被寫成：
http://example.com/?color=%23fff
4、改變#不觸發網頁重載
單單改變#後的部分，瀏覽器只會滾動到相應位置，不會從新加載網頁。
好比，從
http://www.example.com/index.html#location1
改爲
http://www.example.com/index.html#location2
瀏覽器不會從新向服務器請求index.html。
5、改變#會改變瀏覽器的訪問歷史
每一次改變#後的部分，都會在瀏覽器的訪問歷史中增長一個記錄，使用"後退"按鈕，就能夠回到上一個位置。
這對於ajax應用程序特別有用，能夠用不一樣的#值，表示不一樣的訪問狀態，而後向用戶給出能夠訪問某個狀態的連接。
值得注意的是，上述規則對IE 6和IE 7不成立，它們不會由於#的改變而增長曆史記錄。
6、window.location.hash讀取#值
window.location.hash這個屬性可讀可寫。讀取時，能夠用來判斷網頁狀態是否改變；寫入時，則會在不重載網頁的前提下，創造一條訪問歷史記錄。
7、onhashchange事件
這是一個HTML 5新增的事件，當#值發生變化時，就會觸發這個事件。IE8+、Firefox 3.6+、Chrome 5+、Safari 4.0+支持該事件。
它的使用方法有三種：
window.onhashchange = func;
<body onhashchange="func();">
window.addEventListener("hashchange", func, false);
對於不支持onhashchange的瀏覽器，能夠用setInterval監控location.hash的變化。
8、Google抓取#的機制
默認狀況下，Google的網絡蜘蛛忽視URL的#部分。
可是，Google還規定，若是你但願Ajax生成的內容被瀏覽引擎讀取，那麼URL中能夠使用"#!"，Google會自動將其後面的內容轉成查詢字符串_escaped_fragment_的值。
好比，Google發現新版twitter的URL以下：
http://twitter.com/#!/username
就會自動抓取另外一個URL：
http://twitter.com/?_escaped_fragment_=/username
經過這種機制，Google就能夠索引動態的Ajax內容。
網站性能優化
1. 儘可能減小HTTP請求次數
終端用戶響應的時間中，有80%用於下載各項內容。這部分時間包括下載頁面中的圖像、樣式表、腳本、Flash等。經過減小頁面中的元素能夠減小HTTP請求的次數。這是提升網頁速度的關鍵步驟。
減小頁面組件的方法其實就是簡化頁面設計。
那麼有沒有一種方法既能保持頁面內容的豐富性又能達到加快響應時間的目的呢？這裏有幾條減小HTTP請求次數同時又可能保持頁面內容豐富的技術。
- 合併文件是經過把全部的腳本放到一個文件中來減小HTTP請求的方法，如能夠簡單地把全部的CSS文件都放入一個樣式表中。當腳本或者樣式表在不一樣頁面中使用時須要作不一樣的修改，這可能會相對麻煩點，但即使如此也要把這個方法做爲改善頁面性能的重要一步。
- CSS Sprites是減小圖像請求的有效方法。把全部的背景圖像都放到一個圖片文件中，而後經過CSS的background-image和background-position屬性來顯示圖片的不一樣部分；
- 圖片地圖是把多張圖片整合到一張圖片中。雖然文件的整體大小不會改變，可是能夠減小HTTP請求次數。
圖片地圖只有在圖片的全部組成部分在頁面中是緊挨在一塊兒的時候才能使用，如導航欄。肯定圖片的座標和可能會比較繁瑣且容易出錯，同時使用圖片地圖導航也不具備可讀性，所以不推薦這種方法； - 內聯圖像是使用data:URL scheme的方法把圖像數據加載頁面中。這可能會增長頁面的大小。把內聯圖像放到樣式表（可緩存）中能夠減小HTTP請求同時又避免增長頁面文件的大小。
可是內聯圖像如今尚未獲得主流瀏覽器的支持。
減小頁面的HTTP請求次數是你首先要作的一步。這是改進首次訪問用戶等待時間的最重要的方法。如同Tenni Theurer的他的博客Browser Cahe Usage – Exposed!中所說，HTTP請求在無緩存狀況下佔去了40%到60%的響應時間。讓那些初次訪問你網站的人得到更加快速的體驗吧！
2. 減小DNS查找次數
域名系統（DNS）提供了域名和IP的對應關係，就像電話本中人名和他們的電話號碼的關係同樣。
當你在瀏覽器地址欄中輸入[url]www.wangjishun.com[/url]時，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查找次數和保持較高程度並行下載二者之間的權衡了。
3. 避免跳轉
跳轉是使用301和302代碼實現的。下面是一個響應代碼爲301的HTTP頭：
HTTP/1.1 301 Moved Permanently Location: [url]http://example.com/newuri[/url] Content-Type: text/html
瀏覽器會把用戶指向到Location中指定的URL。頭文件中的全部信息在一次跳轉中都是必需的，內容部分能夠爲空。無論他們的名稱，301和302響應都不會被緩存除非增長一個額外的頭選項，如Expires或者Cache-Control來指定它緩存。<meat />元素的刷新標籤和JavaScript也能夠實現URL的跳轉，可是若是你必需要跳轉的時候，最好的方法就是使用標準的3XXHTTP狀態代碼，這主要是爲了確保「後退」按鈕能夠正確地使用。
可是要記住跳轉會下降用戶體驗。在用戶和HTML文檔中間增長一個跳轉，會拖延頁面中全部元素的顯示，由於在HTML文件被加載前任何文件（圖像、Flash等）都不會被下載。
有一種常常被網頁開發者忽略卻每每十分浪費響應時間的跳轉現象。這種現象發生在當URL本該有斜槓（/）卻被忽略掉時。例如，當咱們要訪問[url]http://www.wangjishun.com[/url] 時，實際上返回的是一個包含301代碼的跳轉，它指向的是[url]http://www.wangjishun.com/[/url] （注意末尾的斜槓）。在Apache服務器中能夠使用Alias 或者 mod_rewrite或者the DirectorySlash來避免。
鏈接新網站和舊網站是跳轉功能常常被用到的另外一種狀況。這種狀況下每每要鏈接網站的不一樣內容而後根據用戶的不一樣類型（如瀏覽器類型、用戶帳號所屬類型）來進行跳轉。使用跳轉來實現兩個網站的切換十分簡單，須要的代碼量也很少。儘管使用這種方法對於開發者來講能夠下降複雜程度，可是它一樣下降用戶體驗。一個可替代方法就是若是二者在同一臺服務器上時使用Alias和mod_rewrite和實現。若是是由於域名的不一樣而採用跳轉，那麼能夠經過使用Alias或者mod_rewirte創建CNAME（保存一個域名和另一個域名之間關係的DNS記錄）來替代。
4. 可緩存的AJAX
Ajax常常被說起的一個好處就是因爲其從後臺服務器傳輸信息的異步性而爲用戶帶來的反饋的即時性。可是，使用Ajax並不能保證用戶不會在等待異步的JavaScript和XML響應上花費時間。在不少應用中，用戶是否須要等待響應取決於Ajax如何來使用。
例如，在一個基於Web的Email客戶端中，用戶必須等待Ajax返回符合他們條件的郵件查詢結果。記住一點，「異步」並不異味着「即時」，這很重要。
爲了提升性能，優化Ajax響應是很重要的。提升Ajxa性能的措施中最重要的方法就是使響應具備可緩存性，具體的討論能夠查看Add an Expires or a Cache-Control Header。其它的幾條規則也一樣適用於Ajax：
- Gizp壓縮文件
- 減小DNS查找次數
- 精簡JavaScript
- 避免跳轉
- 配置ETags
讓咱們來看一個例子：一個Web2.0的Email客戶端會使用Ajax來自動完成對用戶地址薄的下載。若是用戶在上次使用過Email web應用程序後沒有對地址薄做任何的修改，並且Ajax響應經過Expire或者Cacke-Control頭來實現緩存，那麼就能夠直接從上一次的緩存中讀取地址薄了。必須告知瀏覽器是使用緩存中的地址薄仍是發送一個新的請求。這能夠經過爲讀取地址薄的Ajax URL增長一個含有上次編輯時間的時間戳來實現，例如，&t=11900241612等。若是地址薄在上次下載後沒有被編輯過，時間戳就不變，則從瀏覽器的緩存中加載從而減小了一次HTTP請求過程。若是用戶修改過地址薄，時間戳就會用來肯定新的URL和緩存響應並不匹配，瀏覽器就會重要請求更新地址薄。
即便你的Ajxa響應是動態生成的，哪怕它只適用於一個用戶，那麼它也應該被緩存起來。這樣作能夠使你的Web2.0應用程序更加快捷。
5. 推遲加載內容
你能夠仔細看一下你的網頁，問問本身「哪些內容是頁面呈現時所必需首先加載的？哪些內容和結構能夠稍後再加載？
把整個過程按照onload事件分隔成兩部分，JavaScript是一個理想的選擇。例如，若是你有用於實現拖放和動畫的JavaScript，那麼它就以等待稍後加載，由於頁面上的拖放元素是在初始化呈現以後才發生的。其它的例如隱藏部分的內容（用戶操做以後才顯現的內容）和處於摺疊部分的圖像也能夠推遲加載
工具能夠節省你的工做量：
YUI Image Loader能夠幫你推遲加載摺疊部分的圖片，YUI Get utility是包含JS和 CSS的便捷方法。好比你能夠打開Firebug的Net選項卡看一下Yahoo的首頁。
當性能目標和其它網站開發實踐一致時就會相得益彰。這種狀況下，經過程序提升網站性能的方法告訴咱們，在支持JavaScript的狀況下，能夠先去除用戶體驗，不過這要保證你的網站在沒有JavaScript也能夠正常運行。在肯定頁面運行正常後，再加載腳原本實現如拖放和動畫等更加花哨的效果。
6. 預加載
預加載和後加載看起來彷佛偏偏相反，但實際上預加載是爲了實現另一種目標。預加載是在瀏覽器空閒時請求未來可能會用到的頁面內容（如圖像、樣式表和腳本）。使用這種方法，當用戶要訪問下一個頁面時，頁面中的內容大部分已經加載到緩存中了，所以能夠大大改善訪問速度。
下面提供了幾種預加載方法：
- 無條件加載：觸發onload事件時，直接加載額外的頁面內容。以Google.com爲例，你能夠看一下它的spirit image圖像是怎樣在onload中加載的。這個spirit image圖像在google.com主頁中是不須要的，可是卻能夠在搜索結果頁面中用到它。
- 有條件加載：根據用戶的操做來有根據地判斷用戶下面可能去往的頁面並相應的預加載頁面內容。在search.yahoo.com中你能夠看到如何在你輸入內容時加載額外的頁面內容。
- 有預期的加載：載入從新設計過的頁面時使用預加載。這種狀況常常出如今頁面通過從新設計後用戶抱怨「新的頁面看起來很酷，可是卻比之前慢」。問題可能出在用戶對於你的舊站點創建了完整的緩存，而對於新站點卻沒有任何緩存內容。所以你能夠在訪問新站以前就加載一部內容來避免這種結果的出現。在你的舊站中利用瀏覽器的空餘時間加載新站中用到的圖像的和腳原本提升訪問速度。
7. 減小DOM元素數量
一個複雜的頁面意味着須要下載更多數據，同時也意味着JavaScript遍歷DOM的效率越慢。好比當你增長一個事件句柄時在500和5000個DOM元素中循環效果確定是不同的。
大量的DOM元素的存在乎味着頁面中有能夠不用移除內容只須要替換元素標籤就能夠精簡的部分。你在頁面佈局中使用表格了嗎？你有沒有僅僅爲了佈局而引入更多的<div>元素呢？也許會存在一個適合或者在語意是更貼切的標籤能夠供你使用。
YUI CSS utilities能夠給你的佈局帶來巨大幫助：
grids.css能夠幫你實現總體佈局，font.css和reset.css能夠幫助你移除瀏覽器默認格式。它提供了一個從新審視你頁面中標籤的機會，好比只有在語意上有意義時才使用<div>，而不是由於它具備換行效果才使用它。
DOM元素數量很容易計算出來，只須要在Firebug的控制檯內輸入：
document.getElementsByTagName(‘*’).length
那麼多少個DOM元素算是多呢？這能夠對照有很好標記使用的相似頁面。好比Yahoo!主頁是一個內容很是多的頁面，可是它只使用了700個元素（HTML標籤）。
8. 根據域名劃分頁面內容
把頁面內容劃分紅若干部分能夠使你最大限度地實現平行下載。因爲DNS查找帶來的影響你首先要確保你使用的域名數量在2個到4個之間。例如，你能夠把用到的HTML內容和動態內容放在[url]www.example.org[/url]上，而把頁面各類組件（圖片、腳本、CSS)分別存放在statics1.example.org和statics.example.org上。
你可在Tenni Theurer和Patty Chi合寫的文章Maximizing Parallel Downloads in the Carpool Lane找到更多相關信息。
9. 使iframe的數量最小
ifrmae元素能夠在父文檔中插入一個新的HTML文檔。瞭解iframe的工做理而後才能更加有效地使用它，這一點很重要。
<iframe>優勢：
- 解決加載緩慢的第三方內容如圖標和廣告等的加載問題
- Security sandbox
- 並行加載腳本
<iframe>的缺點：
- 即時內容爲空，加載也須要時間
- 會阻止頁面加載
- 沒有語意
10. 不要出現404錯誤
HTTP請求時間消耗是很大的，所以使用HTTP請求來得到一個沒有用處的響應（例如404沒有找到頁面）是徹底沒有必要的，它只會下降用戶體驗而不會有一點好處。
有些站點把404錯誤響應頁面改成「你是否是要找***」，這雖然改進了用戶體驗可是一樣也會浪費服務器資源（如數據庫等）。最糟糕的狀況是指向外部JavaScript的連接出現問題並返回404代碼。首先，這種加載會破壞並行加載；其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分看成JavaScript代碼來執行。
11. 使用內容分發網絡
用戶與你網站服務器的接近程度會影響響應時間的長短。把你的網站內容分散到多個、處於不一樣地域位置的服務器上能夠加快下載速度。可是首先咱們應該作些什麼呢？
按地域佈置網站內容的第一步並非要嘗試從新架構你的網站讓他們在分發服務器上正常運行。根據應用的需求來改變網站結構，這可能會包括一些比較複雜的任務，如在服務器間同步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是一個只須要相對簡單地修改代碼實現顯著改善網站訪問速度的方法。
12. 爲文件頭指定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文件頭，增長了緩存在瀏覽器中內容的數量，而且能夠在用戶接下來的請求中再次使用這些內容，這甚至都不須要經過用戶發送一個字節的請求。
13. 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壓縮全部可能的文件類型是減小文件體積增長用戶體驗的簡單方法。
14. 配置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
15. 儘早刷新輸出緩衝
當用戶請求一個頁面時，不管如何都會花費200到500毫秒用於後臺組織HTML文件。在這期間，瀏覽器會一直空閒等待數據返回。在PHP中，你能夠使用flush()方法，它容許你把已經編譯的好的部分HTML響應文件先發送給瀏覽器，這時瀏覽器就會能夠下載文件中的內容（腳本等）然後臺同時處理剩餘的HTML頁面。這樣作的效果會在後臺煩惱或者前臺較空閒時更加明顯。
輸出緩衝應用最好的一個地方就是緊跟在<head />以後，由於HTML的頭部分容易生成並且頭部每每包含CSS和JavaScript文件，這樣瀏覽器就能夠在後臺編譯剩餘HTML的同時並行下載它們。 例子：
… <!– css, js –> </head> <?php flush(); ?> <body> … <!– content –>
爲了證實使用這項技術的好處，Yahoo!搜索率先研究並完成了用戶測試。
16. 使用GET來完成AJAX
請求Yahoo!Mail團隊發現，當使用XMLHttpRequest時，瀏覽器中的POST方法是一個「兩步走」的過程：首先發送文件頭，而後才發送數據。所以使用GET最爲恰當，由於它只需發送一個TCP包（除非你有不少cookie）。IE中URL的最大長度爲2K，所以若是你要發送一個超過2K的數據時就不能使用GET了。
一個有趣的不一樣就是POST並不像GET那樣實際發送數據。根據HTTP規範，GET意味着「獲取」數據，所以當你僅僅獲取數據時使用GET更加有意義（從語意上講也是如此），相反，發送並在服務端保存數據時使用POST。
17. 把樣式表置於頂部
在研究Yahoo!的性能表現時，咱們發現把樣式表放到文檔的<head />內部彷佛會加快頁面的下載速度。這是由於把樣式表放到<head />內會使頁面有步驟的加載顯示。
注重性能的前端服務器每每但願頁面有秩序地加載。同時，咱們也但願瀏覽器把已經接收到內容儘量顯示出來。這對於擁有較多內容的頁面和網速較慢的用戶來講特別重要。向用戶返回可視化的反饋，好比進程指針，已經有了較好的研究並造成了正式文檔。在咱們的研究中HTML頁面就是進程指針。當瀏覽器有序地加載文件頭、導航欄、頂部的logo等對於等待頁面加載的用戶來講均可以做爲可視化的反饋。這從總體上改善了用戶體驗。
把樣式表放在文檔底部的問題是在包括Internet Explorer在內的不少瀏覽器中這會停止內容的有序呈現。瀏覽器停止呈現是爲了不樣式改變引發的頁面元素重繪。用戶不得不面對一個空白頁面。
HTML規範清楚指出樣式表要放包含在頁面的<head />區域內：「和<a />不一樣，<link />只能出如今文檔的<head />區域內，儘管它能夠屢次使用它」。不管是引發白屏仍是出現沒有樣式化的內容都不值得去嘗試。最好的方案就是按照HTML規範在文檔<head />內加載你的樣式表。
18. 避免使用CSS表達式
CSS表達式是動態設置CSS屬性的強大（但危險）方法。Internet Explorer從第5個版本開始支持CSS表達式。下面的例子中，使用CSS表達式能夠實現隔一個小時切換一次背景顏色：
如上所示，expression中使用了JavaScript表達式。CSS屬性根據JavaScript表達式的計算結果來設置。expression方法在其它瀏覽器中不起做用，所以在跨瀏覽器的設計中單獨針對Internet Explorer設置時會比較有用。
表達式的問題就在於它的計算頻率要比咱們想象的多。不只僅是在頁面顯示和縮放時，就是在頁面滾動、乃至移動鼠標時都會要從新計算一次。給CSS表達式增長一個計數器能夠跟蹤表達式的計算頻率。在頁面中隨便移動鼠標均可以輕鬆達到10000次以上的計算量。
一個減小CSS表達式計算次數的方法就是使用一次性的表達式，它在第一次運行時將結果賦給指定的樣式屬性，並用這個屬性來代替CSS表達式。若是樣式屬性必須在頁面週期內動態地改變，使用事件句柄來代替CSS表達式是一個可行辦法。若是必須使用CSS表達式，必定要記住它們要計算成千上萬次而且可能會對你頁面的性能產生影響。
19. 使用外部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，可是在頁面下載完成後動態下載外部文件，在子頁面中使用到這些文件時，它們已經緩存到瀏覽器了。
20. 削減JavaScript和CSS
精簡是指從去除代碼沒必要要的字符減小文件大小從而節省下載時間。消減代碼時，全部的註釋、不須要的空白字符（空格、換行、tab縮進）等都要去掉。在JavaScript中，因爲須要下載的文件體積變小了從而節省了響應時間。精簡JavaScript中目前用到的最普遍的兩個工具是JSMin和YUI Compressor。YUI Compressor還可用於精簡CSS。
混淆是另一種可用於源代碼優化的方法。這種方法要比精簡複雜一些而且在混淆的過程更易產生問題。在對美國前10大網站的調查中發現，精簡也能夠縮小原來代碼體積的21%，而混淆能夠達到25%。儘管混淆法能夠更好地縮減代碼，可是對於JavaScript來講精簡的風險更小。
除消減外部的腳本和樣式表文件外，<script>和<style>代碼塊也能夠而且應該進行消減。即便你用Gzip壓縮過腳本和樣式表，精簡這些文件仍然能夠節省5%以上的空間。因爲JavaScript和CSS的功能和體積的增長，消減代碼將會得到益處。
21. 用<link>代替@import
前面的最佳實現中提到CSS應該放置在頂端以利於有序加載呈現。
在IE中，頁面底部@import和使用<link>做用是同樣的，所以最好不要使用它。
22. 避免使用濾鏡
IE獨有屬性AlphaImageLoader用於修正7.0如下版本中顯示PNG圖片的半透明效果。這個濾鏡的問題在於瀏覽器加載圖片時它會終止內容的呈現而且凍結瀏覽器。在每個元素（不只僅是圖片）它都會運算一次，增長了內存開支，所以它的問題是多方面的。
徹底避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替，這種格式能在IE中很好地工做。若是你確實須要使用AlphaImageLoader，請使用下劃線_filter又使之對IE7以上版本的用戶無效。
23. 把腳本置於頁面底部
腳本帶來的問題就是它阻止了頁面的平行下載。HTTP/1.1 規範建議，瀏覽器每一個主機名的並行下載內容不超過兩個。若是你的圖片放在多個主機名上，你能夠在每一個並行下載中同時下載2個以上的文件。可是當下載腳本時，瀏覽器就不會同時下載其它文件了，即使是主機名不相同。
在某些狀況下把腳本移到頁面底部可能不太容易。好比說，若是腳本中使用了document.write來插入頁面內容，它就不能被往下移動了。這裏可能還會有做用域的問題。不少狀況下，都會遇到這方面的問題。
一個常常用到的替代方法就是使用延遲腳本。DEFER屬性代表腳本中沒有包含document.write，它告訴瀏覽器繼續顯示。不幸的是，Firefox並不支持DEFER屬性。在Internet Explorer中，腳本可能會被延遲但效果也不會像咱們所指望的那樣。若是腳本能夠被延遲，那麼它就能夠移到頁面的底部。這會讓你的頁面加載的快一點。
24. 剔除重複腳本
在同一個頁面中重複引用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文件頭等。
25. 減小DOM訪問
使用JavaScript訪問DOM元素比較慢，所以爲了得到更多的應該頁面，應該作到：
- 緩存已經訪問過的有關元素
- 線下更新完節點以後再將它們添加到文檔樹中
- 避免使用JavaScript來修改頁面佈局
有關此方面的更多信息請查看Julien Lecomte在YUI專題中的文章「高性能Ajax應該程序」。
26. 開發智能事件處理程序
有時候咱們會感受到頁面反應遲鈍，這是由於DOM樹元素中附加了過多的事件句柄而且些事件句病被頻繁地觸發。這就是爲何說使用event delegation（事件代理）是一種好方法了。若是你在一個div中有10個按鈕，你只須要在div上附加一次事件句柄就能夠了，而不用去爲每個按鈕增長一個句柄。事件冒泡時你能夠捕捉到事件並判斷出是哪一個事件發出的。
你一樣也不用爲了操做DOM樹而等待onload事件的發生。你須要作的就是等待樹結構中你要訪問的元素出現。你也不用等待全部圖像都加載完畢。
你可能會但願用DOMContentLoaded事件來代替onload，可是在全部瀏覽器都支持它以前你可以使用YUI 事件應用程序中的onAvailable方法。
27. 減少Cookie體積
HTTP coockie能夠用於權限驗證和個性化身份等多種用途。coockie內的有關信息是經過HTTP文件頭來在web服務器和瀏覽器之間進行交流的。所以保持coockie儘量的小以減小用戶的響應時間十分重要。
有關更多信息能夠查看Tenni Theurer和Patty Chi的文章「When the Cookie Crumbles」。這們研究中主要包括：
- 去除沒必要要的coockie
- 使coockie體積儘可能小以減小對用戶響應的影響
- 注意在適應級別的域名上設置coockie以便使子域名不受影響
- 設置合理的過時時間。較早地Expire時間和不要過早去清除coockie，都會改善用戶的響應時間。
28. 對於頁面內容使用無coockie域名
當瀏覽器在請求中同時請求一張靜態的圖片和發送coockie時，服務器對於這些coockie不會作任何地使用。所以他們只是由於某些負面因素而建立的網絡傳輸。全部你應該肯定對於靜態內容的請求是無coockie的請求。建立一個子域名並用他來存放全部靜態內容。
若是你的域名是[url]www.example.org[/url]，你能夠在static.example.org上存在靜態內容。可是，若是你不是在[url]www.example.org上而是在頂級域名example.org[/url]設置了coockie，那麼全部對於static.example.org的請求都包含coockie。在這種狀況下，你能夠再從新購買一個新的域名來存在靜態內容，而且要保持這個域名是無coockie的。Yahoo!使用的是ymig.com，YouTube使用的是ytimg.com，Amazon使用的是images-anazon.com等等。
使用無coockie域名存在靜態內容的另一個好處就是一些代理（服務器）可能會拒絕對coockie的內容請求進行緩存。一個相關的建議就是，若是你想肯定應該使用example.org仍是[url]www.example.org[/url]做爲你的一主頁，你要考慮到coockie帶來的影響。忽略掉www會使你除了把coockie設置到*.example.org（*是泛域名解析，表明了全部子域名譯者dudo注）外沒有其它選擇，所以出於性能方面的考慮最好是使用帶有www的子域名而且在它上面設置coockie。
29. 優化圖像
設計人員完成對頁面的設計以後，不要急於將它們上傳到web服務器，這裏還須要作幾件事：
你能夠檢查一下你的GIF圖片中圖像顏色的數量是否和調色板規格一致。 使用imagemagick中下面的命令行很容易檢查：
identify -verbose image.gif
若是你發現圖片中只用到了4種顏色，而在調色板的中顯示的256色的顏色槽，那麼這張圖片就還有壓縮的空間。
嘗試把GIF格式轉換成PNG格式，看看是否節省空間。大多數狀況下是能夠壓縮的。因爲瀏覽器支持有限，設計者們每每不太樂意使用PNG格式的圖片，不過這都是過去的事情了。如今只有一個問題就是在真彩PNG格式中的alpha通道半透明問題，不過一樣的，GIF也不是真彩格式也不支持半透明。所以GIF能作到的，PNG（PNG8）一樣也能作到（除了動畫）。下面這條簡單的命令能夠安全地把GIF格式轉換爲PNG格式：
convert image.gif image.png
「咱們要說的是：給PNG一個施展身手的機會吧！」
在全部的PNG圖片上運行pngcrush（或者其它PNG優化工具）。例如：
pngcrush image.png -rem alla -reduce -brute result.png
在全部的JPEG圖片上運行jpegtran。這個工具能夠對圖片中的出現的鋸齒等作無損操做，同時它還能夠用於優化和清除圖片中的註釋以及其它無用信息（如EXIF信息）：
jpegtran -copy none -optimize -perfect src.jpg dest.jpg
30. 優化CSS Spirite
在Spirite中水平排列你的圖片，垂直排列會稍稍增長文件大小；
Spirite中把顏色較近的組合在一塊兒能夠下降顏色數，理想情況是低於256色以便適用PNG8格式；
便於移動，不要在Spirite的圖像中間留有較大空隙。這雖然不大會增長文件大小但對於用戶代理來講它須要更少的內存來把圖片解壓爲像素地圖。100×100的圖片爲1萬像素，而1000×1000就是100萬像素。
31. 不要在HTML中縮放圖像
不要爲了在HTML中設置長寬而使用比實際須要大的圖片。若是你須要：
<img width=」100″ height=」100″ src=」mycat.jpg」 alt=」My Cat」 />
那麼你的圖片（mycat.jpg）就應該是100×100像素而不是把一個500×500像素的圖片縮小使用。
32. favicon.ico要小並且可緩存
favicon.ico是位於服務器根目錄下的一個圖片文件。它是一定存在的，由於即便你不關心它是否有用，瀏覽器也會對它發出請求，所以最好不要返回一個404 Not Found的響應。因爲是在同一臺服務器上，它每被請求一次coockie就會被髮送一次。這個圖片文件還會影響下載順序，例如在IE中當你在onload中請求額外的文件時，favicon會在這些額外內容被加載前下載。
所以，爲了減小favicon.ico帶來的弊端，要作到：
文件儘可能地小，最好小於1K
在適當的時候（也就是你不要打算再換favicon.ico的時候，由於更換新文件時不能對它進行重命名）爲它設置Expires文件頭。你能夠很安全地把Expires文件頭設置爲將來的幾個月。你能夠經過覈對當前favicon.ico的上次編輯時間來做出判斷。
Imagemagick能夠幫你建立小巧的favicon。
33. 保持單個內容小於25K
這條限制主要是由於iPhone不能緩存大於25K的文件。注意這裏指的是解壓縮後的大小。因爲單純gizp壓縮可能達不要求，所以精簡文件就顯得十分重要。
查看更多信息，請參閱Wayne Shea和Tenni Theurer的文件「Performance Research, Part 5: iPhone Cacheability – Making it Stick」。
34. 打包組件成複合文本
把頁面內容打包成複合文本就如同帶有多附件的Email，它可以使你在一個HTTP請求中取得多個組件（切記：HTTP請求是很奢侈的）。當你使用這條規則時，首先要肯定用戶代理是否支持（iPhone就不支持）
前端必知的ajax
簡介
異步交互
此篇只介紹部分方法，想了解更多就猛戳這裏
1. load( url, [data], [callback] ) ：載入遠程 HTML 文件代碼並插入至 DOM 中。
url (String) : 請求的HTML頁的URL地址。
data (Map) : (可選參數) 發送至服務器的 key/value 數據。
callback (Callback) : (可選參數) 請求完成時(不須要是success的)的回調函數。
這個方法默認使用 GET 方式來傳遞的，若是[data]參數有傳遞數據進去，就會自動轉換爲POST方式的。jQuery 1.2 中，能夠指定選擇符，來篩選載入的 HTML 文檔，DOM 中將僅插入篩選出的 HTML 代碼。語法形如 "url #some > selector"。
這個方法能夠很方便的動態加載一些HTML文件，例如表單。
2. jQuery.get( url, [data], [callback] )：使用GET方式來進行異步請求
參數：
url (String) : 發送請求的URL地址.
data (Map) : (可選) 要發送給服務器的數據，以 Key/value 的鍵值對形式表示，會作爲QueryString附加到請求URL中。
callback (Function) : (可選) 載入成功時回調函數(只有當Response的返回狀態是success纔是調用該方法)。
這是一個簡單的 GET 請求功能以取代複雜 $.ajax 。請求成功時可調用回調函數。若是須要在出錯時執行函數，請使用 $.ajax。示例代碼：
$.get("./Ajax.aspx", {Action:"get",Name:"lulu"}, function (data, textStatus){
//返回的 data 能夠是 xmlDoc, jsonObj, html, text, 等等.
this; // 在這裏this指向的是Ajax請求的選項配置信息，請參考下圖
alert(data);
//alert(textStatus);//請求狀態：success，error等等。
固然這裏捕捉不到error，由於error的時候根本不會運行該回調函數
//alert(this);
});
點擊發送請求：
jQuery.get()回調函數裏面的 this ，指向的是Ajax請求的選項配置信息：
3. jQuery.post( url, [data], [callback], [type] ) ：使用POST方式來進行異步請求
參數：
url (String) : 發送請求的URL地址.
data (Map) : (可選) 要發送給服務器的數據，以 Key/value 的鍵值對形式表示。
callback (Function) : (可選) 載入成功時回調函數(只有當Response的返回狀態是success纔是調用該方法)。
type (String) : (可選)官方的說明是：Type of data to be sent。其實應該爲客戶端請求的類型(JSON,XML,等等)
這是一個簡單的 POST 請求功能以取代複雜 $.ajax 。請求成功時可調用回調函數。若是須要在出錯時執行函數，請使用 $.ajax。
4. jQuery.getScript( url, [callback] ) : 經過 GET 方式請求載入並執行一個 JavaScript 文件。
參數
url (String) : 待載入 JS 文件地址。
callback (Function) : (可選) 成功載入後回調函數。
jQuery 1.2 版本以前，getScript 只能調用同域 JS 文件。 1.2中，您能夠跨域調用 JavaScript 文件。注意：Safari 2 或更早的版本不能在全局做用域中同步執行腳本。若是經過 getScript 加入腳本，請加入延時函數。
這個方法能夠用在例如當只有編輯器focus()的時候纔去加載編輯器須要的JS文件.下面看一些示例代碼：
加載並執行 test.js。
jQuery 代碼:
$.getScript("test.js");
加載並執行 AjaxEvent.js ，成功後顯示信息。
jQuery 代碼:
$.getScript("AjaxEvent.js", function(){
alert("AjaxEvent.js 加載完成並執行完成.你再點擊上面的Get或Post按鈕看看有什麼不一樣？");
});
jQuery.ajax( options ) : 經過 HTTP 請求加載遠程數據
這個是jQuery 的底層 AJAX 實現。簡單易用的高層實現見 $.get, $.post 等。
$.ajax() 返回其建立的 XMLHttpRequest 對象。大多數狀況下你無需直接操做該對象，但特殊狀況下可用於手動終止請求。
注意： 若是你指定了 dataType 選項，請確保服務器返回正確的 MIME 信息，(如 xml 返回 "text/xml")。錯誤的 MIME 類型可能致使不可預知的錯誤。見 Specifying the Data Type for AJAX Requests 。
當設置 datatype 類型爲 'script' 的時候，全部的遠程(不在同一個域中)POST請求都回轉換爲GET方式。
$.ajax() 只有一個參數：參數 key/value 對象，包含各配置及回調函數信息。詳細參數選項見下。
jQuery 1.2 中，您能夠跨域加載 JSON 數據，使用時需將數據類型設置爲 JSONP。使用 JSONP 形式調用函數時，如 "myurl?callback=?" jQuery 將自動替換 ? 爲正確的函數名，以執行回調函數。數據類型設置爲 "jsonp" 時，jQuery 將自動調用回調函數。(這個我不是很懂)
參數列表：
| 參數名 | 類型 | 描述 |
| url | String | (默認: 當前頁地址) 發送請求的地址。 |
| type | String | (默認: "GET") 請求方式 ("POST" 或 "GET")， 默認爲 "GET"。注意：其它 HTTP 請求方法，如 PUT 和 DELETE 也能夠使用，但僅部分瀏覽器支持。 |
| timeout | Number | 設置請求超時時間（毫秒）。此設置將覆蓋全局設置。 |
| async | Boolean | (默認: true) 默認設置下，全部請求均爲異步請求。若是須要發送同步請求，請將此選項設置爲 false。注意，同步請求將鎖住瀏覽器，用戶其它操做必須等待請求完成才能夠執行。 |
| beforeSend | Function | 發送請求前可修改 XMLHttpRequest 對象的函數，如添加自定義 HTTP 頭。XMLHttpRequest 對象是惟一的參數。function (XMLHttpRequest) { |
| cache | Boolean | (默認: true) jQuery 1.2 新功能，設置爲 false 將不會從瀏覽器緩存中加載請求信息。 |
| complete | Function | 請求完成後回調函數 (請求成功或失敗時均調用)。參數： XMLHttpRequest 對象，成功信息字符串。function (XMLHttpRequest, textStatus) { |
| contentType | String | (默認: "application/x-www-form-urlencoded") 發送信息至服務器時內容編碼類型。默認值適合大多數應用場合。 |
| data | Object, String |
發送到服務器的數據。將自動轉換爲請求字符串格式。GET 請求中將附加在 URL 後。查看 processData 選項說明以禁止此自動轉換。必須爲 Key/Value 格式。若是爲數組，jQuery 將自動爲不一樣值對應同一個名稱。如 {foo:["bar1", "bar2"]} 轉換爲 '&foo=bar1&foo=bar2'。 |
| dataType | String | 預期服務器返回的數據類型。若是不指定，jQuery 將自動根據 HTTP 包 MIME 信息返回 responseXML 或 responseText，並做爲回調函數參數傳遞，可用值: "xml": 返回 XML 文檔，可用 jQuery 處理。 "html": 返回純文本 HTML 信息；包含 script 元素。 "script": 返回純文本 JavaScript 代碼。不會自動緩存結果。 "json": 返回 JSON 數據 。 "jsonp": JSONP 格式。使用 JSONP 形式調用函數時，如 "myurl?callback=?" jQuery 將自動替換 ? 爲正確的函數名，以執行回調函數。 |
| error | Function | (默認: 自動判斷 (xml 或 html)) 請求失敗時將調用此方法。這個方法有三個參數：XMLHttpRequest 對象，錯誤信息，（可能）捕獲的錯誤對象。function (XMLHttpRequest, textStatus, errorThrown) { |
| global | Boolean | (默認: true) 是否觸發全局 AJAX 事件。設置爲 false 將不會觸發全局 AJAX 事件，如 ajaxStart 或 ajaxStop 。可用於控制不一樣的Ajax事件 |
| ifModified | Boolean | (默認: false) 僅在服務器數據改變時獲取新數據。使用 HTTP 包 Last-Modified 頭信息判斷。 |
| processData | Boolean | (默認: true) 默認狀況下，發送的數據將被轉換爲對象(技術上講並不是字符串) 以配合默認內容類型 "application/x-www-form-urlencoded"。若是要發送 DOM 樹信息或其它不但願轉換的信息，請設置爲 false。 |
| success | Function | 請求成功後回調函數。這個方法有兩個參數：服務器返回數據，返回狀態function (data, textStatus) { |
這裏有幾個Ajax事件參數：beforeSend ，success ，complete ，error 。咱們能夠定義這些事件來很好的處理咱們的每一次的Ajax請求。注意一下，這些Ajax事件裏面的 this 都是指向Ajax請求的選項信息的(請參考說 get() 方法時的this的圖片)。
本文參考來源http://www.cnblogs.com/yeer/archive/2009/07/23/1529460.html
簡單理解同步與異步
何謂同步
一句話總結：必須一件一件事作,等前一件作完了才能作下一件事
進程同步：就是在發出一個功能調用時，在沒有獲得結果以前，該調用就不返回，這時程序是出於阻塞的，只有接收到返回的值或消息後才往下執行其餘的命令。
例子
就是實時處理（如打電話），好比服務器一接收客戶端請求，立刻響應，這樣客戶端能夠在最短的時間內獲得結果，可是若是多個客戶端，或者一個客戶端發出的請求很頻繁，服務器沒法同步處理，就會形成涌塞。
同步如打電話，通訊雙方不能斷（咱們是同時進行，同步），你一句我一句，這樣的好處是，對方想表達的信息我立刻能收到，可是，我在打着電話，我沒法作別的事情。
何謂異步
一句話總結：發佈事情命令就行，完事自行通知
當一個異步過程調用發出後，調用者不能馬上獲得結果。實際處理這個調用的部件在完成後，經過狀態、通知和回調來通知調用者。
例子
就是分時處理（如收發短信），服務器接收到客戶端請求後並非當即處理，而是等待服務器比較空閒的時候加以處理，能夠避免涌塞。
異步如收發收短信，對比打電話，打電話我必定要在電話的旁邊聽着，保證雙方都在線，而收發短信，對方不用保證此刻我必定在手機旁，同時，我也不用時刻留意手機有沒有來短信。這樣的話，我看着視頻，而後來了短信，我就處理短信（也能夠不處理），接着再看視頻。
其餘解釋
同步和異步的區別
舉個例子：普通B/S模式（同步）AJAX技術（異步）
同步：提交請求->等待服務器處理->處理完畢返回 這個期間客戶端瀏覽器不能幹任何事
異步: 請求經過事件觸發->服務器處理（這是瀏覽器仍然能夠做其餘事情）->處理完畢
總之：
同步在必定程度上能夠看作是單線程，這個線程請求一個方法後就待這個方法給他回覆，不然他不往下執行（死心眼）。
異步在必定程度上能夠看作是多線程的（廢話，一個線程怎麼叫異步），請求一個方法後，就無論了，繼續執行其餘的方法。
若有高見，歡迎留言~
本文參考http://blog.csdn.net/tennysonsky/article/details/45111623
那些年，咱們被耍過的bug——haslayout
你被IE的bug耍過幾回了？
IE，這個令全部網站設計人員討厭，但又不得不爲它工做的瀏覽器。不管是六、7仍是8，它們都有一個共同的渲染標準haslayout，因此haslayout 是一個很是有必要完全弄清除的概念。大多 數IE下的顯示錯誤，就是源於它。
什麼是Layout呢？
"Layout" 是IE特有的一個屬性，並非W3C標準，不少的ie下的css bug都與其息息相關。它決定了一個對象（就是一個標籤div、li等）在內容中如何顯示、與周圍對象的位置關係、以及怎樣響應程序或用戶產生的事件。
這個屬性能夠被一些css強制激活。一些HTML標籤默認具備haslayout。
PS：一個對象的layout屬性被激活，它的具體表現就是haslayout=true。咱們能夠用IE Developer Toolbar工具看到被激活的對象帶有"haslayout = -1"的屬性。
特別注意的是，hasLayout 在 IE 8 及以後的 IE 版本中已經被拋棄，因此在實際開發中只需針對 IE 8 如下的瀏覽器爲某些元素觸發 hasLayout 。
一個元素觸發 hasLayout 會影響一個元素的尺寸和定位，這樣會消耗更多的系統資源，所以 IE 設計者默認只爲一部分的元素觸發 hasLayout （即默認有部分元素會觸發 hasLayout ，這與 BFC 基本徹底由開發者經過特定 CSS 觸發並不同），這部分元素以下：
-
<html>, <body> <table>, <tr>, <th>, <td> <img> <hr> <input>, <button>, <select>, <textarea>, <fieldset>, <legend> <iframe>, <embed>, <object>, <applet> <marquee>
不少狀況下，咱們把 hasLayout的狀態改爲true 就能夠解決很大部分ie下顯示的bug。
hasLayout屬性不能直接設定，你只能經過設定一些特定的css屬性來觸發並改變 hasLayout 狀態。下面列出能夠觸發hasLayout的一些CSS屬性值。
-------------------------------------
display
啓動haslayout的值:inline-block
取消hasLayout的值:其餘值
--------------------------------------
width/height
啓動hasLayout的值：除了auto之外的值
取消hasLayout的值：auto
---------------------------------------
position
啓動hasLayout的值：absolute
取消hasLayout的值：static
----------------------------------------
float
啓動hasLayout的值：left或right
取消hasLayout的值：none
---------------------------------------
zoom
啓動hasLayout的值：有值
取消hasLayout的值：narmal或者空值
（zoom是微軟IE專有屬性，能夠觸發hasLayout但不會影響頁面的顯示效果。zoom: 1經常使用來除錯，不過 ie 5 對這個屬性不支持。）
----------------------------------------
writing-mode: tb-rl
這也是微軟專有的屬性。
ie7還有一些額外的屬性能夠觸發該屬性（不徹底列表）：
min-height: (任何值)
max-height: (任何值除了none)
min-width: (任何值)
max-width: (任何值除了none)
overflow: (任何值除了visible)
overflow-x: (任何值除了visible)
overflow-y: (任何值除了visible)5
position: fixed
重置haslayout
在沒有其它屬性激活layout的狀況下，使用下面的css能夠重置haslayout屬性：
- width, height (設爲 "auto")
- max-width, max-height (設爲 "none")(在 IE 7 中)
- position (設爲 "static")
- float (設爲 "none")
- overflow (設爲 "visible") (在 IE 7 中)
- zoom (設爲 "normal")
- writing-mode (從 "tb-rl" 設爲 "lr-t")
display 屬性的不一樣：當用"inline-block"激活了haslayout 屬性時，就算在一條獨立的規則中覆蓋這個屬性爲"block"或"inline"，haslayout 這個標誌位也不會被重置爲 false。
把 mid-width, mid-height 設爲它們的默認值"0"仍然會賦予 hasLayout，可是 IE 7 卻能夠接受一個不合法的屬性"auto"來重置 hasLayout。
haslayout 問題引發的常見 bug
IE6 及更低版本的雙空白邊浮動 bug
bug 修復: display:inline;
IE5-6/win 的 3 像素偏移 bug
bug 修復: _height:1%;
IE6 的躲躲貓(peek-a-boo) bug
bug 修復: _height:1%;
這裏列出觸發 hasLayout 元素的一些效果
1.阻止外邊距摺疊
兩個相連的 div 在垂直上的外邊距會發生疊加，而觸發 hasLayout 的元素之間則不會有這種狀況發生，以下圖：
也能夠查看 Demo 。
上圖的例子中，三個 div 各包含一個 p 元素，三個 div 及其包含的 p 元素都有頂部和底部的外邊距，但只有第三個 div 的邊距沒有與它的子元素 p 的外邊距摺疊。這是由於第三個 div 使用 zoom: 1 觸發了 hasLayout ，阻止了它與它的子元素的外邊距摺疊。
另外，例子中也使用了 overflow: hidden 觸發元素的 BFC ，這利用了 BFC 阻止外邊距摺疊的特性達到元素在 IE 與現代瀏覽器下的表現統一。
2.能夠包含浮動的子元素，即計算高度時包括其浮動子元素
效果如圖：
上圖的例子中，有兩個 div ，它們各包含一個設置了浮動的 p 元素，但第一個 div 實際被瀏覽器判斷爲沒有高度和寬度，即高度爲 0 ，上下邊框重疊在一塊兒。而第二個 div 使用 zoom: 1 觸發了 hasLayout ，能夠包含浮動元素，所以能正確表現出高度，其邊框位置也正常了。
本例子中也使用了 overflow: hidden 觸發 BFC ，跟上例類似，這利用了 BFC 能夠包含浮動子元素的特性達到元素在 IE 與現代瀏覽器下的表現統一。
3.背景圖像顯示問題
元素背景圖不能正確顯示是網頁重構中最多見的問題之一了，在 IE 7 及如下的 IE 版本中，沒有設置高度、寬度的元素每每不能顯示出背景圖（背景色則顯示正常），這實際上與 hasLayout 有關。實際的狀況是，沒有觸發 hasLayout 的元素不能顯示背景圖，上面有說過，觸發 hasLayout 也就是使到元素擁有佈局，換句話說，擁有佈局的元素才能正確顯示背景圖。以下圖：
也能夠看 Demo (在 IE 7 或更低版本的 IE 下查看以觀察背景圖問題)。
上圖兩個 div 都設置了背景圖，但只有使用 zoom: 1 觸發了 hasLayout 的第二個 div 才能正確顯示背景圖。
本例子中沒有觸發元素的 BFC ，這是由於在現代瀏覽器中，元素自己並無背景圖顯示問題。
能夠看出，上面的第1、二個例子中，爲了使到元素在 IE (包括低版本 IE 以及較新版本的 IE)和現代瀏覽器中表現儘可能統一同時觸發了 hasLayout 和 BFC ，而第三個例子中的問題由於只在低版本 IE 中出現，因此只需爲低版本 IE 觸發 hasLayout ，這些技巧在實際項目中須要特別注意。
上面也有說道，hasLayout 與不少 IE 下的顯示 bugs 都有關，實際上不少莫名奇妙的 bugs 都因 hasLayout 而起，所以只要適當的觸發元素的 hasLayout ，不少 IE bugs 每每就能解決。