“靜態(tài)頁”，在Web應(yīng)用程序開發(fā)中是很常見的概念。只是我發(fā)現(xiàn)目前還是有相當(dāng)部分的朋友，在這方面的存在一定的誤區(qū)。因此現(xiàn)在獨立寫一篇文章，也想把一些問題講講清楚，以后在討論的時候也好有個準(zhǔn)。

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

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

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

• 規(guī)范頁面URL
• 緩存頁面內(nèi)容

規(guī)范頁面URL

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

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

　　要實現(xiàn)這點，我們所要實現(xiàn)的是進(jìn)行URL重寫。URL重寫的目的，是在服務(wù)器端把客戶端請求的URL（如Article_3.html）當(dāng)作另一個請求進(jìn)行處理（如Article.ASPx?id=3）。請注意，這個工作是在服務(wù)器端完成的：

　　對于搜索引擎的爬蟲來說，它根本意識不到這個URL是在直接讀取資源，還是經(jīng)過了動態(tài)的請求。我們是Web應(yīng)用程序的編寫者，對于一個請求我們可以使用我們?nèi)我獾姆绞竭M(jìn)行處理，想欺騙搜索引擎還不是易如反掌？不過這種做法對于網(wǎng)站性能來說是否有幫助？沒有，肯定沒有。

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

緩存頁面內(nèi)容

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

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

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

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

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

總結(jié)

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

　　因此，如果您以后要談“靜態(tài)頁”或網(wǎng)頁“靜態(tài)化”的時候，請區(qū)分您究竟是在談“規(guī)范頁面URL”還是“緩存頁面內(nèi)容”。

　　如果您說“靜態(tài)頁有助于SEO”，明白人知道您是再指“規(guī)范頁面URL”，而某些朋友可能就會認(rèn)為您是指在服務(wù)器端緩存頁面內(nèi)容。

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

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

補(bǔ)充說明

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

　　此外，有朋友給出了一份應(yīng)該說“比較權(quán)威”的說明，各位不妨參考一下：動態(tài)網(wǎng)址與靜態(tài)網(wǎng)址

NET技術(shù)：談*靜態(tài)頁*（或網(wǎng)頁*靜態(tài)化*），轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。