性能黃金法則:

只有10%-20%的最終用戶響應時間花在加載html文檔,其余80%-90%時間花在加載頁面所需的組件(腳本,圖片,樣式表,flasf..)

本文的內容就是來減少那80%-90%的時間.

減少HTTP請求

圖片地圖(Image Map)

通過<\map>標簽，把多個URL關聯到一個圖片上,來減少HTTP的開銷.

原理就是通過你點擊的圖片區域來映射你對應該區域的URL.

缺點:

無法手工進行定義區域坐標 定義的形狀單一 IE有兼容性問題 CSS Sprites

原理: 把多個碎圖片合在一張圖片上,在通過CSS的position來獲取你需要的圖片.

優點：

減少HTTP請求 減少圖片的加載量

困惑點:

網站建設

有人認為合并后的圖片會大于分散圖片之和,因為他們覺得合并的圖片含有留白.

實際上是小于為合并的,因為合并后一張圖片減少了圖片本身的開銷(顏色,格式等).

內聯圖片(Inline Images)

通過data:URL的格式在頁面使用圖片而無需HTTP請求.

缺點:

IE不支持 數據大小,質量受到限制. 合并腳本與樣式表

原理: 把一個頁面依賴的樣式合并為一個樣式,把依賴的所有腳本合并為一個腳本.

(現在的打包工具可以很方便做到這個)

使用內容發布網絡(CDN)

CDN: 一組分布在不同地理位置的服務器,來更高效的向用戶發布數據.

優點:

縮短響應時間 可以緩存,備份,擴展存儲能力 緩和web峰值的壓力

缺點:

你的響應時間會受到其他網站的影響,因為CDN提供商的所有客戶都是共用web服務器組. 無法直接控制組件服務器. 受限于CDN供應商本身服務器的性能.

添加expires頭

理解expires:

瀏覽器(代理)通過使用緩存來減少HTTP的請求數量,并減少響應大小.加速頁面的加載.

服務器通過expires頭告知客戶端可以在指定的時間內使用某個組件的副本.(超過那個時間就是無效的),直接從客戶端硬盤讀取數據,響應時間少.

Expires : Thu, 15 Apr 2016 20:00:00 GMT

Expires會要求服務器端時間與客戶端時間嚴格同步,并且一旦過期,服務器需要配制新的日期.

空緩存: 用戶第一次訪問你的網站,即使設置了Exppires頭也不會減少HTTP請求數量,因為此時瀏覽器的緩存是空的.

完整緩存: 如果你的所有可以緩存的組件都在緩存狀態.

所以使用長久的Expires頭的場景對象應該是那些不經常變化的組件:

Cache-Control:max-age = 315000000

通過Cache-Control:max-age可以指定一個組件被緩存多久,單位s。

如果同時有max-age和Expires,那么會重寫Expires.

壓縮組件

原理: 通過減少HTTP響應包的大小,來減少響應時間。

客戶端通過HTTP請求設置Accept-Encoding來標志對哪些壓縮的支持.

Accept-Encoding : gzip

服務器看到上述報頭,會使用客戶端的壓縮方式來壓縮響應.并通過Content-Encoding告知客戶端.

Content-Encoding : gzip

壓縮的內容: 理想的是任何響應文本(除了圖片，PDF)

壓縮帶來的成本:

服務器需要花費額外CPU周期來完成壓縮. 客戶端對響應需要進行解壓.

代理緩存：

問題點:

demo1

瀏覽器A(不支持gzip) --> 通過代理發送一個請求 --> 服務器 --> 服務器返回的響應那么就是沒壓縮的 --> 該響應被代理緩存并且發給瀏覽器A瀏覽器B(支持gzip) --> 通過同一個代理發送同一個URL --> 代理會使用之前緩存的未壓縮內容進行響應.這就沒達到壓縮的用途了

成都網站建設

demo2

瀏覽器A(支持gzip) --> 通過代理發生URL --> 服務器 --> 服務器返回壓縮后的響應 --> 代理緩存該響應 --> 并把響應發給客戶端瀏覽器B(不支持gzip) --> 通過同一代理發送同一URL --> 代理會使用之前已經緩存的壓縮的響應內容進行響應 --> 就尷尬了

解決辦法:在服務器的響應添加Vary頭.即

Vary : Accept-Encoding

原理:就是讓代理可以緩存響應的多個版本.

把樣式表放在頂部

目的: 改善整體的用戶體驗.讓瀏覽器逐漸顯示網頁內容,與用戶可以形成很好的視覺溝通.

白屏的概念:

你把樣式表放在文檔底部,有時候頁面加載緩慢你會發現頁面一片空白,直到突破內容又一下子填滿頁面.這就是白屏.

把樣式表放在文檔底部出現白屏的情況有以下幾種:

在新窗口打開時候重新加載頁面時候(點擊刷新按鈕) 作為主頁時候

把樣式表放在頂部注意的情況:

使用link而不是@import加載樣式(@import加載性能不好,組件的加載是無序性) 樣式表在頁面的位置不影響加載的時間,只影響頁面的呈現

把腳本放在頁面底部

腳本會阻塞并行下載,也就是說如果你把腳本放在非底部的其他位置,位于腳本下面的代碼要等到腳本加載解析完才輪到它,這就妨礙了頁面的逐漸顯示原則.

避免CSS表達式

因為每當頁面發生變化(大小,事件交互等),CSS表達式都會重新求值計算，這就影響了頁面的性能.

使用外嵌組件(外部JS和CSS)而不是內聯

使用外部組件優點:

JS文件和CSS文件可以被瀏覽器緩存. 外部文件可以提高組件的重用率,方便維護.

減少DNS查找.

為什么減少DNS查找可以提升性能?

因為你在瀏覽器輸入一個URL，需要先經過DNS查找,找到你輸入的URL對應的主機的IP地址,在未找到之前,你是不可以獲取的到任何服務器資源的.所以減少DNS的開銷是有必要的.

DNS緩存

DNS的查找是可以被緩存來提供查找效率.也就是說你的DNS信息會緩存在瀏覽器里面和操作系統里面.

影響DNS的緩存的原因

TTL值: 告知客戶端對記錄緩存多久.

瀏覽器對緩存的DNS數量是有限制的.

通過Keep-Alive來重用現有鏈接

一個持久的TCP鏈接就無需要DNS查找.

通過減少唯一主機名的數量來減少并行加載的組件數量

精簡JS

減少不必要的字符(注釋,空白字符等)來改善組件的大小,減少加載時間 壓縮:在精簡基礎上進行壓縮

避免重定向

重定向的概念:就是把用戶從一個URL路由到另外一個URL.常見的重定向有301.302

為什么要避免使用重定向?

你如果使用了重定向,那么在文檔下載之前會有很多的一個空白期.這對用戶體驗相當不友好.所以重定向會延遲頁面所有東西.

移除重復的腳本

重復的腳本帶來的弊端:

多余的HTTP請求 執行JS的時間花費

配制ETag(實體標簽)

什么是ETag(實體標簽)?

ETag： 服務器和瀏覽器確定緩存組件有效性的一種機制

理解瀏覽器緩存的工作機制:

瀏覽器向服務器訪問一個URL,服務器返回響應中一個Expires字段.瀏覽器檢測該字段是否有效,有效就會使用瀏覽器緩存中的資源,再次請求時候不會發送HTTP，其實在重用緩存時候,需要發送一個GET請求,進行檢測時候有效,如果有效服務器會返回一個304 Not Modified.

服務器檢測組件與客戶端緩存資源是否匹配常用的方式:

通過最新修改的時間進行比較 通過比較實體標簽 通過修改時間進行比較

最新修改時間:指的是服務器在響應中會返回一個Last-Modified響應頭,告訴我們組件最后修改時間

當你再一次請求同一資源時候,瀏覽器在請求中會帶有If-Modified-Since字段,把最新修改的日期傳回到服務器,服務器把這個最新修改日期與之前的Last-Modified時間進行比較,如果匹配一致,服務器返回304,使用緩存的.

通過實體標簽(更加靈活)

ETag是唯一標志了組件版本的字符串,必須用引號引起來.

第一次請求資源時候,服務器會返回一個資源的ETag,

當瀏覽器再次請求該資源時候,瀏覽器會通過一個組件進行驗證,通過If-None-Match把ETag傳到原始服務器，服務器會進行比較剛剛傳過來的與之前的是否有變化,一致的話,服務器返回304.

ETag的問題點:

瀏覽器向一個服務器請求資源,獲得響應的一個ETag,當瀏覽器再次向另外一個服務器請求資源,這個時候兩者ETag是不匹配的.換言之對于有多個服務器處理請求的網站來說,ETag是有一定概率驗證失敗. 降低代理緩存的有效性.用戶緩存的ETag和代理緩存的ETag不匹配,導致重新請求原始服務器,浪費HTTP開銷.

ETag的解決辦法:

配制ETag或者移除ETag.

通過Ajax緩存

Ajax本質就是提升用戶體驗的.

優化Ajax請求

壓縮組件

減少DNS查找 精簡JS 避免重定向 ETag的處理

本文名稱：【成都網站建設】高性能網站建設指南筆記-成都創新互聯官方網站
標題來源：http://m.newbst.com/news33/226533.html

網站建設、網絡推廣公司-創新互聯，是專注品牌與效果的網站制作，網絡營銷seo公司；服務項目有網站建設等

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯