欧美vvv,亚洲第一成人在线,亚洲成人欧美日韩在线观看,日本猛少妇猛色XXXXX猛叫

于加載精簡來說，最大的好處莫過于對頁面的加速。加速有兩點：

第一是由于資源加載量減少，對于頁面首屏加載速度的提升；

第二是某些加載精簡的方法，會在一定程度上加快頁面的渲染速度。

同時，由于加載量的減少，剩下了一些帶寬，從而減少了帶寬費用。

當然，事情都有兩面的地方。加載精簡會在一定程度上影響頁面的SEO；部分方法也會造成一些額外的腳本開銷。

尋找合適你的方法很重要，畢竟每個網站性質、用處、節點都可能不同。比如項目初期，可能宣傳和擴散知名度方面重要些，這時候建議不要大量使用動態生成內容的方式，影響SEO。

第1章 存儲資源

　1.1 離線存儲

1.1.1 為了移動

由于瀏覽器支持情況不同，離線存儲在PC端沒有大量的使用，反而在移動端的支持情況越來越好，如今Android、iOS都能使用離線存儲，所以離線存儲廣泛的使用于離線APP應用。

對于離線存儲，最重要的便是manifest文件。我們將需要緩存的文件列入cache段，將不需要緩存的內容列入network段即可。

當瀏覽器加載頁面時，發現manifest文件后，會檢查它的內容是不是有修改，如果是，重新下載cache段的文件并緩存；如果不是，則跳過。

需要注意的是，當我們使用離線存儲時，瀏覽器會強行只讀離線緩存的文件。我們需要將頁面使用到的所有的資源都列入manifest文件中，不論是在cache段，還是network段。否則瀏覽器將報錯，說找不到文件。

1.1.2 更新

對離線存儲的資源更新，需要修改manifest文件的內容。當然，我們一般不會隨意修改文件名已達到修改manifest文件內容的目的。一般的做法是，在文件內新增一行注釋，注釋中寫明目前的版本號，以后每次需要更新的時候，修改版本號就行了。

另外，我們可能需要功能更加強大的離線存儲緩存更新的機制。試想一個新聞類的APP，我們需要在手機離線時讀取本地存儲的數據，當APP發現用戶聯網后，將讀取在線的內容，更新本地的數據和頁面信息。

對于圖2-5，我們使用HTML5新提供的online時間在頁面加載的時候判斷手機是否在線。監聽window的online和offline時間，可以判斷手機是不是已經聯網。一旦檢測到手機聯網，我們就可以調用applicationCache對象的update方法，去檢測manifest文件是否有更新，如果有，下載新的版本。當updateready時，使用swapCache方法刷新緩存。

當然swapCache不能刷新頁面的內容，只是把離線存儲的文件更新成我們下載的新內容，我們還需要再使用JS替換頁面的內容。

1.1.3 殘缺美

在使用離線存儲的時候，總有些感到不是很爽的地方，列出來吐吐槽。

首先是兩個更新的問題。我們知道，修改manifest文件后，瀏覽器會重新下載文件，而且是全部重新下載。這其實很蛋疼，有時候我們只需要更新其中一個文件，有點兒殃及池魚的感覺。另外，在更新manifest文件后，我們需要刷新兩次頁面才能將最終的新內容呈現在頁面上。

然后，如果我有很多文件要存儲，需要把文件一個一個列入cache段里，就算使用程序生成，出來的manifest文件也有一定的體積。對于一個需要緩存300個文件的頁面，使用相對路徑，生成的manifest文件也有4K。在碰上更新的話，下載量有點兒大。

最后，對于同一個頁面的帶參URL路徑，離線存儲會當成不同的新文件進行緩存。如果您有100個不同的參數需要穿，而用戶竟然訪問過這100個文件，那就……

1.2 本地存儲

1.2.1 本地存儲的方法

userData是IE提供的一個本地存儲方法，他將需要存儲的內容放置在本地的一個XML文件中，并在頁面的一個元素中設置一個調用的錨點。具體使用方法為：使用getElementById獲取頁面內的一個元素，使用addBehavior(“#default#userData”)對其添加本地存儲的行為；使用setAttribute將需要存儲的內容對其進行賦值，并用save(“XXX”)方法將內容存儲在名為XXX的XML文件中；使用load(“XXX”)方法加載本地的XXX.xml文件，并用getAttribute獲取已經存儲的內容。

關于HTML5本地存儲localStorage的詳細方法，請參見我的翻譯文章《網絡應用程序本地存儲的前世今生》。

對于IE瀏覽器，使用IE提供的userData方法；對于支持HTML5的瀏覽器(Firefox、Chrome、Safari、Opera等)，使用localStorage提供的方法；對于其他瀏覽器使用常規方法加載內容。

1.2.2 資源處理

對于本地存儲，我們可以使用來存儲數據，或者能轉為數據形式的文件。例如一些SEO要求不高的文字，鏈接等等。

對于圖片、CSS、JS等文件，我們也可以轉為文本來存儲在本地。這種方式大量應用于移動端。例如《掌上英雄聯盟》APP的圖片大部分都轉化為base64編碼存儲在本地（不用離線存儲的原因前面提及了）。Google和Bing的移動版，也將CSS和JS拆分后本地存儲了。

另外，對于本地存儲更新，我的做法是：先判斷本地是否存在已存儲的內容，如果沒有數據或者版本已過期（所謂版本是我設置的一個變量，當修改這個變量時即為版本過期），加載相應的JS數據，通過一個函數將數據處理為需要的格式，然后存儲在本地；如果有且版本沒過期，直接從本地獲取數據。接著將數據通過函數進行進一步的處理，插入相對應的結構中。

第2章 按需加載

2.1 滾動加載

2.1.1 滾動加載的方法

其實這是很多大型網站都使用了的方法，比如淘寶、拍拍等等。對于不同顯示器分辨率不同，所以第一屏高度不一樣，節省的加載量所浮動。

首先，記錄所有需要滾動加載對象的縱坐標值到一個數組。然后使用JS的監聽方法（IE是attachEvent，其他瀏覽器是addEventListener），監聽頁面的scroll事件。一旦頁面滾動，就會執行一個編寫的函數，來判斷對象是否處于瀏覽器的當前一屏內，如果是，將加載對象，如果不是，繼續監聽。當頁面內的所有對象都被加載后，取消監聽。

對于圖片，滾動頁面后，我們可以看到如圖3-2的效果。

2.1.2 板塊滾動加載

其實把每個板塊按照上面說的那種方式，像圖片一樣，滾動加載就可以實現這種效果，類似于bigPipe+Lazyload。

我們將頁面拆分為框架、板塊、板塊內容，甚至可以細分到板塊樣式、板塊腳本。當頁面滾動完成時，判斷處于當前屏的板塊，動態并行加載板塊內容。這種方式可以大大減少頁面的加載量，但會影響SEO。

2.2 點擊加載

2.2.1 形式

點擊后動態加載有很多形式，這是我們平時使用最多的方式。諸如頁卡、翻頁、展開、下拉、切屏等等都會使用到。以往的我們可能直接在頁面寫入內容，或者使用include載入，并將看不到的內容隱藏掉。但如果用戶并沒有點擊切換，那么直接加載這些內容就產生多余的加載量。

2.2.2 觸發加載

一般來說，動態填充數據的前期判斷有兩種形式。

一種是使用條件語句，判斷內容區域是否有內容，如果沒有，填充內容。這種方式最容易想到，但每次觸發的時候都會判斷一次。

另外一種是監聽的方式。我們監聽觸發的對象是否被點擊，如果點擊，就像目標對象填充內容，然后取消這個監聽。

很顯然，第二種方式只需執行一次，測試結果也表明這種方式是最快的。

2.2.3 數據插入方式

我們的新聞系統在生成新聞列表的時候，會根據我們的模板同時生成html頁面、xml文件（我們很少使用）、json文件，在選擇將列表插入頁面的時候，我們有兩種方式。

一種是動態加載json文件，用JS生成內容，插入頁面；另一種是使用XHR加載html文件，使用responseText獲取內容，插入頁面。

其實，使用第二種方法有明顯的好處。第一是，html文件體積比json文件小，加載量減少；第二是直接使用html文件，減少了JS動態生成結構的開銷。

2.3 延時加載

對于一組有加載時間間隔的資源，我們其實可以對其做加載延時，按照其前后出現的順序，在時間間隔后即時加載下一個資源。例如輪播廣告就很適合這么做。

2.3.1 輪播廣告

以往輪播廣告的加載模式是一次性全部加載，雖然采用延遲加載，但用戶可能不會瀏覽到所有的輪播廣告。當用戶在首頁只停留5秒時（例如輪播廣告設置的是5秒切換一次），第二張廣告圖片以后的圖片加載就沒有必要了。

其實我們可以這樣，第一次加載第一張廣告圖片，當5秒后，判斷第二張圖片是否加載過，如果沒有，加載第二張圖片，以此類推。判斷的方式很簡單，我們只要在初期生成輪播廣告結構的時候，不設置img標簽的src屬性，然后加載時判斷這張圖片是否有src屬性，如果沒有，加載圖片并設置這個屬性。

這樣，如果用戶在首頁停留時長只有14秒，那么就節省了第4、5張廣告圖片的下載量，大約有100K左右。

第3章 其他方式

3.1 文件壓縮

3.1.1 代碼

老生常談的方法。我們可以將代碼里多余的空格，回車，無用標簽刪除，替換名字較長的變量名等等方式減少腳本文件大小。

3.1.2 多媒體

對于圖片，不同格式，不同壓縮率都會造成圖片大小的千差萬別。選擇一個合適并且圖片質量可以接受的壓縮方式，可以節省很大一筆加載量。

對于視頻、音頻、Flash來說，也都一樣，碼率、格式等等方面都會對大小造成影響。

3.2 CSS 3

CSS 3是一個不算太新，但由于我朝瀏覽器限制而得不到大范圍應用的技術。其實我們可以在一些效果表現不是很重要的頁面使用CSS 3來針對瀏覽器做一些差異化效果，已達到減少加載量的目的。

3.2.1 替換圖片

對于移動端，或者一些PC頁面，我們可以用CSS 3來替換一些圖片效果，比如漸變、陰影、圓角等等。

例如圖4-4中的綠色按鈕，使用CSS 3漸變和圖片所造成的加載量差距很大，在能使用CSS 3的時候，盡量不要使用圖片。

3.2.2 替換JS動畫

一些對象移動、寬高變換等效果，其實可以使用CSS 3動畫來實現。例如使用CSS 3和JS，來實現一個對象左右切換的效果，需要的代碼量如圖4-6所示。我們可以看到，CSS 3的代碼量極少，而且執行過程中沒有JS那些復雜的運算。

3.3 服務器

3.3.1 GZIP

雅虎13條里的內容。其壓縮比例很大，大部分網站都使用了。

3.3.2 緩存

設置Expires、Cache-Control以減少頁面加載量，使瀏覽器從本地讀取緩存。

Expires和Cache-Control

max-age均用于檢測文件是否過期，如果沒有，瀏覽器讀取本地緩存。Expires是HTTP1.0的內容，需要返回一個304 Not Modified，并且過期時間是GMT時間，一旦客戶端日期不準確，可能導致失效。Cache-Control是HTTP1.1的內容，使用文件自身的age值來做和請求時間對比，相對穩定。

3.3.3 優圖

優圖是公司開發的，用于圖片無損壓縮的系統。目前互娛已經接入，在圖片上傳到服務器時，自動進行無損壓縮，加載量減少的效果非常明顯。

第4章 三個話題

4.1 對比

在以前一次分享文檔中，有同學提問為啥要拋開瀏覽器與服務器的緩存機制，自己實現一套本地存儲機制，有沒有什么特別的優勢。其實相對與傳統緩存來說，本地存儲的好處有4點。

一是，對于存儲需要處理的數據來說，本地存儲可以在第一次加載的時候就將處理的數據存在本地，而傳統緩存策略需要每次加載的時候都處理一次數據。

二是，本地存儲相對穩定，有獨立的存儲空間，一般不會向服務器發送請求，而傳統緩存時常會丟失。

三是，相對于傳統緩存策略，本地存儲的讀取速度要更快些。當然，也有例外，Chrome的本地存儲讀取速度要慢于緩存文件的加載。

四是，對于iOS設備，Safari在重啟后（包含本身的重啟，或者設備的重啟），緩存會被清空，而本地存儲和離線存儲不會。

4.2 SEO

4.2.1 Landing Page

對于互娛這邊的游戲，客戶端會有一個Landing Page，上面包含了最新的新聞，活動等等信息，玩家每次啟動客戶端都會看到這個頁面。

根據監控，Landing Page平均每天給官網帶來250w左右的PV，而官網平均每日PV大約1000多萬。這個量應該完全填補了SEO的損失。而且游戲官網的用處一般僅限于給玩家提供游戲的功能服務、新聞、活動信息等等，玩家查詢游戲攻略、資料一般會去媒體站，而不是游戲官網。

圖5-1 《英雄聯盟》的Landing Page

4.2.2 內頁鏈接

在某些內容需要動態加載的時候，我們可以寫一個到內頁的鏈接，讓搜索引擎爬蟲順著這個鏈接到內頁去記錄信息。

例如頁卡中的新聞列表需要動態填充，如果不做處理，爬蟲可能無法獲取這些列表中的新聞鏈接。我們可以像圖5-2的那兩種方式，寫一個到列表頁的鏈接，這樣爬蟲就可以順著這個鏈接到列表頁去抓取信息。

4.3 效果

4.3.1 健康度

健康度是我們以前接的加載時間檢測系統，最近我們換用了OZ系統。使用了以上方法的網站，在3秒健康度上，有了很大的提升。

4.3.2 請求減少

采用以上方式減少加載量，雖然會造成整個網頁的全部請求量有少許增加，但因為是按需加載，所以可以大大減少首屏請求量。

4.3.3 帶寬消耗

在我們接入優圖后，圖片服務器的帶寬消耗大大減少。在圖片壓縮一半后，我們的帶寬消耗減少了4G。

由于公司系統只能針對服務器做帶寬消耗監控，所以我們看不到做文件存儲和按需加載后的帶寬減少情況，但我們可以大概算算。如果一個游戲官網全部頁面平均每天有PV1500w，用戶平均每次加載頁面節省10KB，假設第1天正常加載，后29天全部讀緩存，每月可以節省帶寬488MB。對于有幾十款游戲產品的我們來說，這是一個很可觀的量。

結束語

正如開篇所說的那樣，介紹的這些方法，有部分會傷害SEO，增加腳本開銷。所以大家在使用的時候需要進行一個合理的選擇。

例如對于一個新產品，SEO相對更加重要些，這個時候可以適當選用一些減少加載量的方法；當產品成熟，有大量用戶的時候，可以考慮進行更加深入的加載量優化。

希望此文檔能幫助到今后做網站加載量優化的同學。

隨著Web App的發展，越來越多的移動端App使用HTML5的方式來開發，除了一些HybridApp以外，其他一部分Web App還是通過瀏覽器來訪問的，通過瀏覽器訪問就需要聯網發送請求，這樣就使得用戶在離線的狀態下無法使用App，同時Web App中一部分資源并不是經常改變，并不需要每次都向服務器發出請求，出于這些原因，HTML5提出的一個新的特性：離線存儲。通過離線存儲，我們可以通過把需要離線存儲在本地的文件列在一個manifest配置文件中，這樣即使在離線的情況下，用戶也可以正常使用App。

首先來講解下離線存儲的使用方法，說起來也很簡單。只要在你的頁面頭部像下面一樣加入一個manifest的屬性就可以了。

<!DOCTYPE HTML>
<html manifest = "cache.manifest">
...
</html>

然后cache.manifest文件的書寫方式，就像下面這樣：

CACHE MANIFEST
#v0.11
CACHE:
js/app.js
css/style.css
NETWORK:
resourse/logo.png
FALLBACK:
/ /offline.html

離線存儲的manifest一般由三個部分組成:

1.CACHE:表示需要離線存儲的資源列表，由于包含manifest文件的頁面將被自動離線存儲，所以不需要把頁面自身也列出來。

2.NETWORK:表示在它下面列出來的資源只有在在線的情況下才能訪問，他們不會被離線存儲，所以在離線情況下無法使用這些資源。不過，如果在CACHE和NETWORK中有一個相同的資源，那么這個資源還是會被離線存儲，也就是說CACHE的優先級更高。

3.FALLBACK:表示如果訪問第一個資源失敗，那么就使用第二個資源來替換他，比如上面這個文件表示的就是如果訪問根目錄下任何一個資源失敗了，那么就去訪問offline.html。

瀏覽器怎么解析manifest

那么瀏覽器是怎么對離線的資源進行管理和加載的呢？這里需要分兩種情況來討論。

• 在線的情況下，瀏覽器發現html頭部有manifest屬性，它會請求manifest文件，如果是第一次訪問app，那么瀏覽器就會根據manifest文件的內容下載相應的資源并且進行離線存儲。如果已經訪問過app并且資源已經離線存儲了，那么瀏覽器就會使用離線的資源加載頁面，然后瀏覽器會對比新的manifest文件與舊的manifest文件，如果文件沒有發生改變，就不做任何操作，如果文件改變了，那么就會重新下載文件中的資源并進行離線存儲。
• 離線的情況下，瀏覽器就直接使用離線存儲的資源。

這個過程中有幾個問題需要注意。

• 如果服務器對離線的資源進行了更新，那么必須更新manifest文件之后這些資源才能被瀏覽器重新下載，如果只是更新了資源而沒有更新manifest文件的話，瀏覽器并不會重新下載資源，也就是說還是使用原來離線存儲的資源。
• 對于manifest文件進行緩存的時候需要十分小心，因為可能出現一種情況就是你對manifest文件進行了更新，但是http的緩存規則告訴瀏覽器本地緩存的manifest文件還沒過期，這個情況下瀏覽器還是使用原來的manifest文件，所以對于manifest文件最好不要設置緩存。
• 瀏覽器在下載manifest文件中的資源的時候，它會一次性下載所有資源，如果某個資源由于某種原因下載失敗，那么這次的所有更新就算是失敗的，瀏覽器還是會使用原來的資源。
• 在更新了資源之后，新的資源需要到下次再打開app才會生效，如果需要資源馬上就能生效，那么可以使用window.applicationCache.swapCache()方法來使之生效，出現這種現象的原因是瀏覽器會先使用離線資源加載頁面，然后再去檢查manifest是否有更新，所以需要到下次打開頁面才能生效。

對于HTML5中離線存儲對象window.applicationCache有幾個事件需要我們關注下：

1.oncached:當離線資源存儲完成之后觸發這個事件

2.onchecking:當瀏覽器對離線存儲資源進行更新檢查的時候會觸發這個事件

3.ondownloading:當瀏覽器開始下載離線資源的時候會觸發這個事件

4.onprogress:當瀏覽器在下載每一個資源的時候會觸發這個事件，每下載一個資源就會觸發一次。

5.onupdateready:當瀏覽器對離線資源更新完成之后會觸發這個事件

6.onnoupdate:當瀏覽器檢查更新之后發現沒有資源更新的時候觸發這個事件