一，代碼優化： 代碼優化是任何優化技術的第一步，因為歸根結底網頁上的一切都是構建在代碼之上的。優秀的代碼可以節省寬頻，減少渲染延遲，以及提高頁面的可讀性和長遠的可維護性。下麵列出了一些在Web應用中編寫任何代碼時都應該記住的最佳實踐。 1，使用遵循Web標準的代碼。 2，精簡代碼。 3，減少HTTP ...
一，代碼優化：
代碼優化是任何優化技術的第一步，因為歸根結底網頁上的一切都是構建在代碼之上的。優秀的代碼可以節省寬頻，減少渲染延遲，以及提高頁面的可讀性和長遠的可維護性。下麵列出了一些在Web應用中編寫任何代碼時都應該記住的最佳實踐。
1，使用遵循Web標準的代碼。
2，精簡代碼。
3，減少HTTP請求數。
1）單個資源文件必須少於15KB（在未縮的情況上）。
針對iPhone設計的頁面需要將各個資源文件的大小限制在15KB以內，以得到最優的緩存行為。iPhone最多可以緩存105個15KB以下的資源文件。在達到緩存數量上限以後，新緩存的文件會覆蓋緩存中的舊的文件。
2）全局緩存資源必須少於1.5KB.
儘管iPhone能夠緩存很多資源文件，但加起來最多只能緩存大概1.5MB.緩存可用位元組數的上限大約為105*15=1575KB.
3）設備關機會後清空HTTP緩存。
如果用戶需要強制重啟設備，緩存中的資源就會丟失。這是由於在iPhone上，Safari從系統記憶體中分配空間來創建緩存文件，但並沒有把緩存組件寫入持久性的存儲設備中。
4）關閉標簽頁也會清空HTTP緩存。
關閉掉所有標簽，只留下空白標簽後再關掉Safari也會清空緩存。
從開發的視角來看，這種類型的緩存是不可靠的。因為它清空的頻率太高，也難以緩存一個現代網頁的大部分資源。即便是壓縮到極致的JavaScript框架或CSS文件都很難將大小控制在15k以內，更不用說幾乎所有的Web應用用到的圖片都會超過這個大小。萬幸的是我們還有更好的選擇來實現目標，即HTML5提供的離線功能。
4，合併CSS和JavaScript文件。
5，減少DOM操作。
二，圖片優化。
1，優化色彩深度。
2，使用CSS精靈圖。
3，千萬不要縮放圖片。
始終根據設備視口或是設計元素的寬高來以合適的尺寸使用圖片。別指望Safari能自動把一個圖片縮放到合適的大小。唯一可以例外的是，當我們在指定設備的Web應用中插入圖片時，可以通過設置值為100%的寬度來同時自適應於橫屏或是豎屏視圖。
這一法則同樣也可以縮短網頁的載入時間及頁面中每次運行JavaScript時給用戶體驗造成的延時，遵守這一法則非常重要，同時也別忘了給圖片設定寬度和高度，這樣也助於減少渲染所用的時間。這一法則同樣縮短了網頁的載入時間以及頁面中每次運行JavaScript時給用戶體驗造成的延時。
三，應用壓縮。
Safari支持GZIP壓縮，所以將Web應用的一些資源進行壓縮會是個不錯的想法，這樣可以提升用戶體驗的層次。我們可以決定什麼時候 壓縮HTML5頁面，CSS3樣式表或是JavaScript代碼，然而卻並沒有必要去壓縮圖片或者是PDF文檔，因為這些類型的資源是已經壓縮過的。對圖片或者PDF文檔進行壓縮是白白浪費CPU資源，甚至有可能反而增大文件體積。
對於伺服器來說，為了使用Web應用能使用GIP壓縮過的資源，伺服器必須配置為在請求時自動提供壓縮過的資源。另外一方面，客戶端必須支持這種壓縮類型的文件。
GIP壓縮並不骨文件格式的限制，因此這是給網頁大幅”瘦身“的最簡易的方式。GZIP壓縮可以將文件減少大概70%。
雖然好處很明顯，但世界上沒有十全十美，一般而言GZIP壓縮也有一些不足之外。
1，我們需要個個支持GZIP壓縮的瀏覽器。當然，針對我們的情況這並不是一個問題，因為Safari和其他基於WebKit的瀏覽器都支持GZip.
2, 我們無法壓縮力片和PDF文檔，因為它們本身就是一種壓縮格式。
3，由於Safari需要實時地解壓縮資源，某些情況下這一過程會增加CUP時鐘周期和開銷，以致抵消了可能帶來的好處。所以，最好先測試一下，以確保不會被這些額外開銷造成弊大於利的情況。
四，可用性優化。
1，可用性檢查。
2，可用性測試。
參考資料：《iOS Web應用開發》
