本文先回顧了互聯網的早期歷史，探討當下動態網站廣泛流行的歷史成因。然後我們分析靜態網站在性能、編輯速度和自然搜索方面的優勢。
探討業界重新重視靜態網站以簡化web開發實踐的潮流
最開始，Web是靜態的。
早期互聯網是修補匠的樂園。儘管MySpace和Facebook經常被拿來做比較，但這兩項服務其實本質上就不一樣。它們都是在自己輝煌時代的“互聯網範式”的典型代表。
Myspace和Facebook都是社交網絡，但在MySpace上創建頁面需要有HTML和CSS的基本知識，畢竟這項服務是在2003年推出的。相比之下Facebook擁有易用的界面，這促成了它的成功並幫助它贏得了20億用戶。
MySpace與Facebook興衰成敗的背後是互聯網最大痛點的解決方案比拼——那就是如何與我們編輯的內容互動？大多數情況下有兩種方案：
-
所見即所得——顧名思義，這個範式的目的是讓編輯器的效果與最終呈現內容儘量一致。WordPress是所見即所得方案最知名的早期支持者之一，很快其他人也跟了上來。使用TinyMCE構建的Medium編輯器（如下所示）是是網上所見即所得體驗最出色的編輯器之一。
-
效率優先——所見即所得編輯器很容易上手，但往往設計笨重、功能有限。引入某種形式的語法會增加複雜度，但也能讓用戶更好地控制內容的最終呈現效果。此外由於語法（HTML，CSS，Markdown …）會強制執行格式化和排版操作，因此它不再依賴所使用的編輯器了。
WordPress的黃昏
WordPress很快佔領了互聯網：它目前擁有大約60％的CMS市場份額。WordPress太流行了，我們甚至可以從整個互聯網的層面來評價它的影響力：如今有大約三分之一的網站使用WordPress。
但成功並不意味着受歡迎。實際上高級用戶會出於各種原因放棄WordPress：
-
編輯：WP編輯器很糟糕，哪怕用新版的Guttenberg編輯內容也是一種痛苦。它又慢又笨重，還帶有一個複雜的塊邏輯。相比替代選項，用它來排版和編輯內容純粹就是浪費時間。此外，它默認不支持像腳註或內容列表等任何“智能功能”。想要用上這些功能需要複雜而荒謬的流程或者再加一個插件。
-
安全性：WordPress的成功招來了大量黑客。基於WP的大型網站都必須採用其它措施（比如插件？）來應對各種類型的黑客攻擊。此外WordPress支持從5.2.4（12年前發佈的版本）到7.2的所有PHP版本。再考慮到所有可用的插件和主題，可行的攻擊途徑簡直是無窮無盡的。這篇文章介紹了最常見的攻擊類型：https://kinsta.com/blog/is-wordpress-secure/
-
性能：開箱即用的WordPress性能非常糟糕。使用一些增強技術（緩存、CDN …）和一些設置可以加快速度——但這是用戶該做的工作嗎？Web框架的重點不就是儘量減少優化工作嗎？
-
插件膨脹：由於WordPress需要一大堆插件，它會拖慢網站的速度並影響網站的安全性。全新部署WP需要5-10個插件才能用，要“優化”出比較好的效果需要10-15個插件。
改成靜態頁面吧！
2003年WordPress發佈時並沒有多少有力的競爭對手。15年很快就過去了，今天互聯網已經有了激動人心的工具和框架，既可以爲作者撰寫的內容排版，也可以爲用戶託管並呈現內容。兩種技術共同發展，爲迴歸靜態的互聯網鋪平了道路。
先來看內容編輯這個話題，談一談Markdown。
Markdown的崛起
就在WordPress變得越來越臃腫的時候，它的替代方案已經既可以用來託管網站，也可以用於內容排版了。
對於內容來說，像Markdown這樣的新型輕量級標記語言甚至成爲了非技術性配置文件的可靠備選方案。Markdown的理念很簡單：只要花一小時時間熟悉語法表，幾乎就不用再費勁排版內容了。
事實上，Markdown直觀易懂而潛力非凡。作者只要使用Markdown編輯器搭配一些快捷鍵，就能在創作內容的同時完成排版工作。最重要的是Markdown提供了許多導出選項（HTML、PDF、LaTex、Doc …），而且無論最終輸出成什麼格式都不會影響內容的呈現效果。
還有一點容易被忽略的好處：使用Markdown時你可以在文檔層處理與文本相關的功能（腳註、標記、到某段的鏈接、目錄、表格和圖表等），而不必再起一層處理它們。這個特性極大提升了內容的可維護性和可移植性。
不僅編程需要版本控制：內容創作者也需要
爲了提升可靠性，版本控制與基於git的開發流程迅速在軟件產業普及，使整個開發流程更加可靠，更加安全。此外，用戶權限管理系統、分支邏輯和完整的文件歷史記錄，以及對比文件不同版本的能力都非常有用，很大程度上減小了錯誤改動的影響，使錯誤更容易修復。
但就在開發者有這麼一大堆新工具幫忙的時候，我們的內容創作者仍然在用Word撰寫文章，然後複製粘貼到WordPress的所見即所得編輯器裏，再開始與排版作鬥爭。那麼何不從開發產業借鑑一些先進的事物呢？
其實雖然聽起來挺奇怪，但Github的倉庫就可以當成一個非常好用的內容管理器來用：
-
簡單的用戶/訪問管理。GitHub的分支邏輯很適合編輯流程。比如在需要嚴格控制已發佈的內容時，則可以只向主編授予主分支上的合併權限，以確保一致性。
-
分支邏輯：使用GitHub倉庫作爲內容管理器來用的時候，倉庫的分支可以有很多用途。可以用一個分支作爲暫存環境，這樣作者就能在自己的設備上預覽內容的最終呈現效果。
-
文件歷史：在GitHub倉庫裏作者可以訪問文件的全部歷史記錄並輕鬆對比各個歷史版本。這個功能很方便，尤其適合多人共同創作的情況。
-
無設置：存儲庫一點即開，然後再用像Netlify這樣的服務點一下就能讓博客上線了。
性能問題之外還有受衆範圍問題
我們已經探討了靜態網站在性能或效率方面的好處所在。但光看這些指標是不夠的，我們需要退一步來考慮整體情況。
截至2017年，網站的平均頁面大小已經遠超3MB了。互聯網發展趨勢中，不僅網頁的尺寸是個問題，還有其它宏觀層面的問題。以下是自2011年以來網站頁面平均大小的變化趨勢，以供參考：
作爲對比，blog.call.tech的主頁只有10KB，每個頁面（包括圖像）的平均大小約爲400KB。
爲什麼我爲了看那麼幾行文字就要非要下載完整而臃腫的3MB多頁面？
我們周圍的人們可能都有一部新潮筆記本電腦/智能手機，還有高速網絡可用。可生活在互聯網服務落後的國家中的人們怎麼辦呢？網絡上大部分內容主體都是文字，裝載這些內容的頁面就應該是輕量級的纔對。爲什麼我爲了看那麼幾行文字就要非要下載完整而臃腫的3MB多頁面？
考慮你的網站訪客的感受
看起來這是發達世界的問題；實際上第三世界受這個問題影響更嚴重。網站糟糕的設計會讓很多人無法獲得可能讓他們受益的服務。此外，多餘的數據會讓網絡膨脹堵塞，需求更多資源，乃至推高服務的價格。
我們的觀點很明確：在2019年的今天，創建一個充斥非必要動態內容的網站是在濫用公共資源。互聯網是全世界共享的資源，我們何不用簡單的常識來避免公地悲劇的重演？
沒人喜歡性能低下的網站
那麼我們向那些喜歡設計臃腫十倍網站的開發者問一個問題：用戶和你們有什麼深仇大恨啊？ 互聯網用戶平均接入帶寬才7.2Mbps，這個速度下需要3秒多時間才能載入完一個頁面。
這意味着怎樣的影響？Neil Patel是SEO社區中的知名人物，他製作了一個關於這個話題的非常全面的信息圖。在報告中他估計有40％的用戶（和53％的移動用戶）會在網頁加載時間超過3秒時直接關掉頁面。因此根據這兩個數字，你就能得出以下讓人抓狂的結論：
新聞網站、媒體網站和其它站點就因爲它們無節制地使用動態渲染引擎而導致的低下性能表現，損失了起碼40%的潛在流量。這個數字還沒算上網站缺乏搜索引擎優化兼容性而導致的自然搜索流量損失。
所以我們還是讓網站減減肥吧。我們真需要這麼多腳本嗎？爲什麼讓動態引擎不斷生成重複靜態內容的做法竟然成了互聯網的標準？在2019年的今天，正確處理圖像（調整大小、壓縮、調整加載順序）有那麼難嗎？
爲什麼讓動態引擎不斷生成重複靜態內容的做法竟然成了互聯網的標準？
——Florent Chauveau
開始使用靜態Web
我們相信靜態網站很快就會重新開始流行了。與此同時，靜態網站在搜索引擎優化賽場上很容易就能擊敗臃腫的動態網站：是時候展現靜態的威力了！
Hugo非常適合我們的科技博客，因爲它簡化了我們的內容編輯流程，同時帶來了令人印象深刻的自然搜索流量：
幸運的是，自2008年Jekyll發佈以來，靜態網站生成器和其它相關服務正在蓬勃發展。
如果你正在考慮在下一個網站中使用靜態引擎，請查看我們的後續文章，其中介紹了開發者可用的主要框架和工具，以及開發優秀靜態網站的一些技巧和最佳實踐。
-
靜態Web前沿技術：https://blog.callr.tech/static-website-performance-seo/
-
GitLab+Docker與Hugo的CI/CD方案：https://blog.callr.tech/static-blog-hugo-docker-gitlab/
英文原文：https://blog.callr.tech/static-web-roots/
