http://www.cnblogs.com/JeffreyZhao/archive/2009/07/05/talk-about-page-statilization.html

??? “靜態頁”，在Web應用程序開發中是很常見的概念。只是我發現目前還是有相當部分的朋友，在這方面的存在一定的誤區。因此現在獨立寫一篇文章，也想把一些問題講講清楚，以后在討論的時候也好有個準。

　　不久前有朋友寫了一篇題為《提供生成靜態頁核心代碼》的文章，介紹了一種“向硬盤寫入頁面文件”的方式。這篇文章的內容在此并不多作討論，這里引用一下作者給出的摘要：

網頁生成靜態Html文件有許多好處，比如生成html網頁有利于被搜索引擎收錄，不僅被收錄的快還收錄的全。前臺脫離了數據訪問，減輕對數據庫訪問的壓力，加快網頁打開速度。

　　這種說法存在一個嚴重的問題，因為它混淆了兩個概念：“靜態頁”有利于網站性能，和“靜態頁”有利于SEO。有朋友可能會說：“這兩點說的都沒有錯啊，不信你去搜索引擎上查一下，都有很多資料”。是的，這兩種說法都能在搜索引擎上找出“依據”來，只可惜在這種兩種情況下的“靜態頁”所指的內容，或者說是“做法”完全不同，可以說沒有任何關系。換句話說，這里造成“混淆”的原因是“指代不明”。為了方便闡述，在本文接下來的部分中將盡可能避免“靜態頁”，“靜態化”等詞語，而是使用以下兩種區分明顯的說法進行闡述：

• 規范頁面URL
• 緩存頁面內容

規范頁面URL

　　如今在開發的Web應用程序時，往往需要從客戶端獲取一些信息，然后根據這些信息生成頁面。例如，我們需要從客戶端獲取一個“頁碼”，然后在頁面上呈現出這一頁的內容。從客戶端傳遞信息的方式有多種，其中最常見的便是通過Query String進行傳遞。例如，我們可以通過Article.aspx?id=3這樣的方式來請求id為3的文章。不過如果純粹使用Query String來傳遞信息的話，一個URL可能會帶有許多項Query String。例如ArticleList.aspx?page=3&keywords=helloworld&category=6&....。

　　有種說法是，這樣的URL由于明顯是動態的，因此搜索引擎對它的處理會有所負面傾斜，例如將其權值放低。因此，很多程序都會把為URL規范為特別的形式，例如Article/3，甚至是Article_3.html。使用htm或html作為URL的結尾，是為了“欺騙”搜索引擎，讓搜索引擎以為這是一個直接從存儲設備上直接讀取的資源，它不會改變，因此“它的權值會相對提高”。實際上老趙并不同意這個說法，而且似乎也沒有實際案例可以證明這一點——當然我也無法證否，因此無法判斷這個說法的正確性。不過這篇文章并不是在追究這個問題，在這里我們暫且認為它有道理吧。

　　要實現這點，我們所要實現的是進行URL重寫。URL重寫的目的，是在服務器端把客戶端請求的URL（如Article_3.html）當作另一個請求進行處理（如Article.aspx?id=3）。請注意，這個工作是在服務器端完成的：

客戶端	服務器端
Article_3.html	Article_3.html => Article.aspx?id=3 => 處理 => 輸出

　　對于搜索引擎的爬蟲來說，它根本意識不到這個URL是在直接讀取資源，還是經過了動態的請求。我們是Web應用程序的編寫者，對于一個請求我們可以使用我們任意的方式進行處理，想欺騙搜索引擎還不是易如反掌？不過這種做法對于網站性能來說是否有幫助？沒有，肯定沒有。

　　這種改變URL，想要獲取更好SEO效果的做法，有些人也會把它叫做“偽靜態化”。老趙不知道這種說法合不合適，我是從來不會使用這樣的說法的。

緩存頁面內容

　　動態生成一個頁面的開銷往往很大，例如需要多次查詢數據庫或者外部服務。為了減少服務器端的開銷，為了加快網站的運行效率，有時候在服務器端會將一個頁面的整體內容保存為一個文件，這樣每次在服務器端獲取客戶端請求的時候，只要讀取相應的文件即可，而不需要重新查詢數據庫或外部服務并重新生成頁面內容：

客戶端	服務器端
Article.aspx?id=3	Article.aspx?id=3 => 讀取文件 => 輸出

　　同樣的，這些事情完全是在服務器端進行的處理，搜索引擎的爬蟲對此一無所知。即使搜索引擎認為Article.aspx?id=3這樣的請求是由服務器端即時生成的（當然搜索引擎真不會考慮這些），我們編寫的服務器端邏輯同樣可以直接讀取磁盤上的文件，并且直接輸出。這種做法自然是為了效率，不過……

　　這種做法和SEO有沒有關系？沒有任何關系，因為爬蟲根本不知道我們做了這些。

　　這種做法是否需要在硬盤上生成一個html文件？沒有必要，我可以生成txt文件，可以生成jeffz文件，甚至我可以不生成文件，而是將頁面內容直接存放在內存中，甚至是高性能的Key/Value Store里。

　　這種做法是否需要把URL修改為html結尾？沒有必要，URL改不改都無所謂，改成什么也都無所謂。

總結

　　有時候事情其實就是那么簡單，但是還是會讓人混淆。一句話聽上去很正確，但是一旦“指代不明”，正確的話也變成錯誤的了。例如本文一開始引用的文章，它是為了“緩存頁面內容”而使用的做法，這個做法和SEO沒有任何關系，因此說“生成html網頁有利于被搜索引擎收錄，不僅被收錄的快還收錄的全”是將其目的與“規范頁面URL”混淆了起來。錯誤產生在這里。在那片文章后面的評論中，有朋友回復說目前的搜索引擎已經不關心URL是否是html還是別的什么形式了。這種說法可能也是正確的，不過并沒有談在點子上。因為無論搜索引擎如何處理HTML，文章的內容都和搜索引擎沒有一絲一縷關系。

　　因此，如果您以后要談“靜態頁”或網頁“靜態化”的時候，請區分您究竟是在談“規范頁面URL”還是“緩存頁面內容”。

　　如果您說“靜態頁有助于SEO”，明白人知道您是再指“規范頁面URL”，而某些朋友可能就會認為您是指在服務器端緩存頁面內容。

　　如果您說“靜態頁有助于提高網站性能”，明白人知道您是指“緩存頁面內容”，而某些朋友可能就會認為您是指使用“URL重寫”來規范URL樣式。

　　如果您說“靜態頁，既有助于SEO，又有助于提高網站性能”，那么（我希望）明白人就會帶您來看現在這篇文章，而某些朋友可能就會……哎哎。

補充說明

　　有朋友提到靜態資源適合被CDN分發，其實不然。CDN難道不能分發動態請求生成的內容了嗎？對于CDN來說，動態和靜態是沒有區別的。不說CDN，就說Squid吧，Squid知道后面連接的請求是靜態還是動態的嗎？是Windows系統還是Linux嗎？其實這就是“分層”，抽象出來以后完全不知道后端的遞交方式。而且換個角度想，世界上有“靜態請求”這個東西嗎？不都是需要經過Web服務器處理的嗎？只不過，一個是復雜運算，一個是直接讀取硬盤文件。對訪問者來說，是看不出任何區別的。CDN分發的也只是“請求內容”而不會關心“內容的生成方式”。

　　此外，有朋友給出了一份應該說“比較權威”的說明，各位不妨參考一下：動態網址與靜態網址

轉載于:https://www.cnblogs.com/aaa6818162/archive/2009/07/08/1518906.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的谈*静态页*（或网页*静态化*）的时候，请区分一些概念（转）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。