關於大型網站技術演進的思考（十三）--網站靜態化處理—CSI（5）

　　講完了SSI，ESI，下面就要講講CSI了 ，CSI是瀏覽器端的動靜整合方案，當我文章發表後有朋友就問我，CSI技術是否是就是經過ajax來加載數據啊，我當時的回答只是說你的理解有點片面，那麼到底什麼是CSI技術了？這個其實要和動靜資源整合的角度來定義。

　　CSI技術實際上是在頁面進行動靜分離後，將頁面加載分爲兩個步驟完成，第一步是加載靜態資源，靜態資源加載完畢後進行第二步驟加載動態資源。不過這個定義仍是表述的不全面，不全面的地方就是咱們要強調動靜分離的目的，咱們把頁面裏的動靜資源拆分出來是爲了將靜態資源作有效的緩存，這個靜態資源多是在靜態web容器上，也有多是在CDN上，也有多是在瀏覽器上，無論靜態資源是如何緩存的，咱們的目的都是爲了讓靜態資源加載的速度更快，若是咱們沒有讓靜態資源加載變得高效，就算咱們使用了CSI的形式來設計頁面，其實也沒有發揮CSI的優勢，反倒還會一不當心引入CSI的缺點。那什麼是CSI的缺點呢？具體以下：

　　CSI的缺點一：CSI不利於頁面的SEO即搜索引擎優化。搜索引擎的網絡爬蟲通常是根據url訪問頁面，獲取頁面的內容後去掉沒用的信息例如：css樣式，js腳本，而後分析剩下的文本內容，所以假如頁面的一部份內容須要進行異步加載，那麼這個加載控制確定是由javascript代碼來完成的，所以網絡爬蟲爬下來的頁面裏異步加載的操做是無法執行的（據說有些高級的爬蟲能夠執行異步的操做，抓取異步的內容，即使有這個技術，大部分主流的爬蟲仍是會忽略掉javascript代碼的也會忽略異步加載的內容的），這就會致使爬蟲爬的頁面裏有部分信息丟失了，因此說CSI對SEO不太友好。不過這個缺點咱們仔細分析下，可能並不會是那麼嚴重，前面咱們談論了不少靜態分離的策略，若是咱們動靜分離策略作的好，那麼動態資源基本都是不能被緩存的內容，常常發生變化的內容，這些變化的內容原本就不須要被網絡爬蟲爬到，就算真的被爬到，搜索引擎有個查詢結果指向了這個頁面，咱們點開這個頁面結果也是在頁面找不到被搜索的關鍵字，這種情形我相信不少朋友在使用搜索引擎時候都會碰到過。不過我想若是開發人員沒有正確使用CSI，那麼這塊他們可能也不會處理的特別好，所以這個缺點仍是很容易被引入的。

　　CSI的缺點二：咱們那麼費時費力想讓本身的網站靜態化，目的就是想讓頁面加載更快點，咱們簡簡單單把頁面加載分紅了兩個步驟進行，那麼這麼作就真的快嗎？這可不必定啊，其實動靜分離的作法和我上一個系列裏講到的數據庫讀寫分離有相似之處，數據庫讀寫分離咱們是經過拆分原表的讀寫之間的關聯關係，從而達到解決讀的瓶頸問題，而網頁的動靜分離是由於靜態資源很容易被優化，因此咱們要拆分動靜資源。因此當咱們對資源進行了動靜分離，可是又沒有優化靜態資源，這個一看就知道咱們缺乏一個加速頁面加載速度的操做，那麼真的能讓頁面加載快點，還真的很難說了，並且異步加載須要執行javascript代碼才行，可是靜態資源加載時候很容易形成javascript腳本被阻塞，若是阻塞的腳本正好是異步加載的部分，結果只會是比之前加載的更慢了。

　　因而可知，我在前面講到的SSI和ESI技術對於咱們在瀏覽器端發揮CSI技術優勢是很是有必要的，SSI和ESI作好了能讓動靜分離出的靜態資源加載的更加高效，這也就讓CSI操做的第一個步驟變得高效，第一個步驟處理好了咱們只要在頁面控制好腳本阻塞對異步加載的影響，那麼咱們就能夠達到提高整個頁面加載效率的目的了。此外我以爲CSI對SEO有重大影響是個僞命題，假如使用CSI形成了SEO效果不佳，那麼確定是咱們CSI方案設計的不到位。

　　有人認爲CSI還會有個缺點，不過筆者我並不認爲這是一個缺點，這實際上是一個設計問題，好與壞是根據我的的操做習慣所決定的。這個別人認爲的缺點是什麼呢？它就是使用CSI技術時候，雖然頁面很快的被加載出來了，可是動態內容那部分可能會顯示一個正在加載的提示，那麼這就致使頁面用戶友好性下降，其實這種同步和異步加載混搭操做實在太常見了，幾乎全部大型門戶網站，電商網站還有一大堆數不盡的網站都是採用同步和異步混搭的加載方式，假如這些網站不這麼作，我相信這些網站例如首頁加載必定會慢的讓人吐血，由於它們不少網頁裏面內容實在太多，圖片也都有點爆棚了，因此它們不得不使用同步和異步混搭的加載方式，甚至不少靜態資源例如圖片，flash這些東西也會採起異步加載方式。說到這裏，估計有人仍是以爲不服氣，他就是不喜歡頁面加載時候還要出現個正在加載提示，可是網頁裏又很是須要CSI帶來的好處，那麼咱們該如何解決這個問題呢？這個問題很好解決，首先願意使用CSI技術也就說明用戶仍是很願意使用異步的加載技術的，不喜歡則是正在加載的提示，這說明用戶想要在作同步加載操做時候不要摻雜異步操做，雖然如今ajax技術大行其道，可是ajax技術有個同步加載是沒有辦法解決的，那就是咱們在瀏覽器地址欄裏輸入網站url請求頁面 ，因此面對上面的需求咱們只要保證這種同步操做只是一個純粹的同步操做而不要摻雜異步加載便可，這個方案仍是很好實施的，這裏我就再也不累述了。

　　動靜分離後咱們會把靜態資源進行緩存，前面文章裏講了一大堆都是在講服務端的靜態資源緩存，如今講到了CSI已經到了瀏覽器端，那麼咱們就得談談瀏覽器的緩存操做。頁面的緩存操做就是使用http的expires和cache-control，咱們首先看看下面的寫法：

<meta http-equiv="pragma" content="no-cache">

<meta http-equiv="cache-control" content="no-cache">

<meta http-equiv="expires" content="0">

 

　　這是我如今作的java的web項目裏，jsp和vm文件都會使用的meta配置，它的目的就是讓頁面不要被瀏覽器緩存，可是若是使用CSI技術，同時動靜分離作的很好，那麼在頁面頭部其實咱們能夠再也不這麼寫了，咱們可讓頁面在合理的時間範圍內被瀏覽器緩存，若是該頁面作了緩存操做，那麼之後咱們再訪問該頁面，網頁的加載效率就會變得更高了。

　　這裏還有個問題，在雅虎優化網站的建議裏，爲了充分利用網頁並行加載的特色，咱們每每會把圖片，外部的js和css文件放置在單獨的靜態web容器或CDN上，那麼這些文件每每也是能夠被瀏覽器緩存，這個咱們又如何設置才能讓瀏覽器知道要緩存它們呢？這裏咱們以apache爲例，爲了讓靜態資源被瀏覽器緩存，apache須要使用mod_expires模塊，而後在apache的配置文件裏添加以下配置：

 

<FilesMatch "\.(gif|jpg|png|js|css">ExpiresDefault "access plus 10 years"</FilesMatch>

　　那麼瀏覽器訪問此apache上的靜態資源後，瀏覽器就會把圖片和該服務器上的js和css文件緩存在瀏覽器裏。

　　咱們看看被緩存的靜態資源是如何被使用的，以下圖所示：

 

　　當http的響應碼是304的時候，那麼瀏覽器就會從緩存裏讀取資源了，這裏有的朋友可能會感到奇怪爲何緩存的資源還要發送個http請求了？理解這個咱們就要了解下緩存的機制，緩存的含義是臨時保存某些東西，既然是臨時保存，那麼就應該有個保存的有效期，咱們定義緩存的方式是經過http完成的，那麼按道理檢查緩存是否過時也應該是http來決定的，所以每次使用緩存時候咱們要發個請求到服務端，服務端會檢查下資源是否過時了，若是沒有過時，服務端返回個304的響應碼，304的返回響應是沒有http報文體的，因此這個http請求的返回數據是很是小的，所以這個http效率仍是很高的，若是服務端發現資源過時了那麼服務端就會把新資源返回給瀏覽器了，其實這個檢測資源是否過時的請求有個專有名詞叫作條件Get請求。至於服務端是如何完成檢查操做，本系列在講web前端優化時候會詳細闡述，這裏就不深刻了。看到這裏估計有朋友又有疑問了，爲何緩存是否過時不能在瀏覽器端來作了？這主要是瀏覽器作這個檢查很是不許，由於用戶的電腦時鐘不必定準確，或者用戶電腦時鐘和服務端不一致，若是再加上時區那麼就更加麻煩了，因此緩存失效最好是在服務端進行，這樣緩存的有效期的準確性才能獲得保證。html5的出現，瀏覽器緩存的能力大大加強了，不過使用html5技術進行緩存我尚未深刻研究過，因此這裏也不講述了，有興趣的朋友能夠本身研究下。

　　好了，CSI主題內容講完了，講到CSI技術和瀏覽器咱們就能夠開始本系列另外一個重要內容先後端分離了，這將是我下篇的主題，我在本身博客裏屢次講到先後端分離，立刻又要再次講了，此次講是我這麼長時間作先後端分離研究的大總結了。

　　最後，祝你們新年快樂，新的一年喜氣洋洋，開開心心哦。