Smashing Magazine 如何管理內容：從 WordPress 遷移到 JAMstack
已發表: 2022-03-10本文得到了我們在 Netlify 的親愛的朋友的大力支持，Netlify 是一個用於自動化現代 Web 項目的多合一平台。 謝謝！
每次開發人員談論 WordPress，他們的市場份額百分比都會發生變化。 “ 20% 的網站都在 WordPress 上！ ” “ 40% 的網站都在 WordPress 上！ ” 無論百分比是多少，信息都是一樣的：就採用而言，WordPress 是巨大的。
那麼，為什麼採用這種方式，使用 WordPress 的網站會考慮遷移到 JAMstack 呢？ 在這個由兩部分組成的文章系列中，我們將使用您現在正在閱讀的站點的案例研究來介紹實際的 WordPress 遷移。
我們將討論得失，我們希望早點知道的事情，以及我們感到驚訝的事情。 然後我們將跟進一個可能的遷移路徑的技術演示——不是完全脫離 WordPress——而是如何為分離的 WordPress 提供服務，這樣你就可以兩全其美：WordPress 的 JAMstack 實現，它為你提供了所有其儀表板和功能的強大功能，以及更好的性能和安全性。
讓我們深入挖掘！
為什麼？
2015 年，Netlify 聯合創始人 Mathias Biilmann 和 Smashing 創始人 Vitaly Friedman 進行了交談。 隨著 JAMstack 架構開始流行，Smashing 對堆棧的想法越來越感興趣。 Vitaly 和 Markus（Smashing 的前常務董事）詢問 Matt 如果 Smashing 從他們傳統的 WordPress/LAMPstack 站點遷移到 JAMstack 架構會發生什麼。
作為一項實驗，Matt 從 Smashing 中抓取所有 HTML 並將其託管在 Netlify 上，從 CDN 靜態交付內容。 結果令人信服——靜態版本的平均速度是其六倍以上！
這種類型的架構之所以如此有效，部分原因是您訪問頁面時不會按需編譯頁面。 由於您直接從 Content Delivery Network 提供預先構建的內容，因此該站點已經“存在”並可供用戶使用。
由於您通過 CDN 提供服務，因此您還可以在全球範圍內分發內容——更接近潛在訪問者。 沒有中心起源點，這對於任何希望為所有讀者快速提供速度的在線出版物而言都是至關重要的。
於是舞台就擺好了。 Smashing Magazine 遷移到 JAMstack — 特別是作為一個平台的 Netlify。 在其 10 年的運營中，Smashing 從一個小型在線出版物發展成為一個大型 WordPress 博客，銷售書籍、會議門票和研討會等商品。
這個網站有幾個部分：
- WordPress 博客
- Rails 工作委員會
- Shopify 商店
- 會議現場的另一個 CMS
當 Netlify 首次開始遷移時，該網站遇到了一些性能問題，受到 20K 評論和數千篇文章的拖累。 Smashing 還對將身份驗證作為新訂閱計劃的一部分以及重新設計以獲得更現代的外觀感興趣。
可靠性
Smashing 經常實現其他平台的夢想：通過龐大的社區廣泛分享文章。 但是，當某個帖子的流量達到臨界點時，Smashing 經常會遇到中斷問題。 為了緩解這種情況，大量使用 WordPress 插件被引入到他們的堆棧中，但他們仍然努力保持良好的正常運行時間指標。
遷移到 Netlify 後，Smashing 團隊可以避免出現數據庫連接錯誤，並且即使在文章看到大量流量時也不必擔心停機。 為什麼？ 因為在沒有服務器的情況下提供服務時，不必生成和提供預構建的內容——它已經存在，可以查看。 除了整個靜態頁面外，當場沒有任何請求。
通過 CDN 提供服務也讓 Smashing 在安全方面更容易入睡。 wp-login.php長期以來一直是安全漏洞和攻擊媒介的來源。 無法以相同的方式訪問預構建的內容，並且安全漏洞並不普遍。
緩存失效
Smashing 循環遍歷了每個 WordPress 緩存插件，結果各不相同，問題也很多。 Smashing 的 Vitaly Friedman 提到，
“我們遇到的主要問題與我們每隔一周都會遇到的‘錯誤建立數據庫連接’有關，我們確實嘗試了每一個 WordPress 緩存插件。 性能還不錯（總體而言），但我們希望進一步改進它。 此外，我們確實希望通過一個平台推出會員資格並將所有不同的產品（會議、職位發布、文章、書籍、電子書）連接起來，而使用 WordPress 實現這一目標非常困難。”
遷移到 Netlify 後，Smashing 團隊可以看到即時緩存失效，同時還提供緩存和高性能內容，而無需額外開銷。
部署站點時，HTML 文件託管在 Netlify 的 CDN 上。 它針對高速緩存命中率和第一個字節的快速時間進行了優化，同時能夠立即使所有已更改的 HTML 文件無效。 Netlify 還對指向 CSS 文件、圖像、字體或 JS 文件等資產的所有鏈接進行指紋識別，並為 Smashing 提供永久緩存它們的緩存標頭。 指紋保證它們是唯一的，並且如果您更新新版本，則會提供新版本。
工作流程
查看現有設置，遷移的一個重要原因只是為了統一現有屬性。 必須在所有這些不同的技術堆棧和設置之間進行上下文切換成為了工程師們面臨的一個難以維護的問題。
以前他們的基礎設施分散在這麼多不同的系統中時，這個遷移過程也統一了所有東西，使主站點、會議站點、訂閱和電子商務部分都一起工作，而不是用不同的堆棧單獨維護。 這有助於保持較低的開發成本和一致的開發人員在所有屬性上工作的經驗。
事實證明，WordPress 遷移部分是最大和最精緻的。 Netlify 嘗試從 WP 導出器導出數據，卻發現內容有嵌入需要保留，或者有時被插件更改。 為了與網站上的內容保持一致，編寫了一系列抓取工具，按文章、資產、評論和主頁進行細分。
編寫和轉換後，它會被加載到 GitHub 中的新存儲庫中，並改用 Netlify CMS。 Netlify CMS 的獨特之處在於它是輕量級的，並將內容編輯器集成到 Git 工作流程中——這意味著它實際上將從 git 存儲庫而不是數據庫中提取和提供 markdown 文件。 此外，Netlify CMS 與平台無關，可與（幾乎）所有存儲在 GitHub 中的靜態站點生成器和站點一起使用。
當時，Sara Soueidan 作為一名自由前端開發人員在 Smashing 工作，負責他們的重新設計。 她創建了一個組件庫來構建前端架構，並評論說使用起來要簡單得多，因為她直接在 git 中工作，即使在使用 CMS 時也是如此。
“我推送到存儲庫的所有內容都直接應用於模式庫，這意味著您不必維護兩組不同的組件......這種連續性很棒！ 我所要做的就是編寫 HTML、CSS 和 JavaScript 並推送到 repo，一切都像魔術一樣工作。 工作流程非常棒。”
綜上所述，對於如此高流量和規模的用例，Netlify CMS 有時可能過於輕量級。 Smashing 定期有客座作者和完整的編輯人員。 WordPress 提供的一些豐富功能對這類高度協作的環境非常有幫助。
這就是為什麼在下面的教程中，我們將引導您完成一個無頭模型，您仍然可以從 WordPress 儀表板為內容創建者獲得好處，但通過 API 使用 WordPress 並讓開發依賴於以 git 為中心的工作流程，這很容易供開發人員維護。 敬請關注！
框架選擇
在 Matt Biilmann 創建的初始原型中，他使用最小的 Preact 編寫了所有內容，並與 Hugo 配對，因為他非常關注性能。 他只是使用道具並保持一切都很輕巧。 當他將該項目交給 Smashing 的開發人員 Ilya Pukhalski 維護時，他發現 Preact 缺少一些他們缺少的功能來利用 React 的生態系統。 最終，Redux 和其他庫的收益超過了成本。
現在回想起來，Matt 說他會使用 Vue，當時它的市場份額並不大（我發誓我沒有讓他這麼說）。 我問了一個顯而易見的問題：為什麼不是 Svelte？ 由於注重性能的人傾向於使用該庫。 他提到 Svelte 還沒有 Vue 的生態系統。
當馬特反思他是否還會使用 Hugo 時，他說他喜歡 Hugo，但他發現這個項目特別困難的是它沒有足夠的插件系統——創建橫幅廣告和類似的東西Hugo 對這種性質的可編程性不夠，他需要注入腳本來完成它。 這些腳本往往會減慢構建過程。 也就是說，我們仍然在netlify.com 上將Hugo 用於我們自己的網站並喜歡它——這個警告特別針對 Smashing 網站的需求。
如果他能再做一次，他可能會選擇 Eleventy，它在創建插件和其他可擴展腳本方面具有豐富的能力。 或者，如果他使用 Vue，Nuxt 會為他提供一些不錯的插件功能，同時允許成為該框架的不錯選擇，提供服務器端渲染、路由和靜態生成。
建設大型網站
使用像 Smashing 這樣大的網站時出現了一個問題，也許您已經知道它是什麼，我們剛剛談到了它。 確實，對於在 CDN 上提供的任何大型預建頁面站點，性能仍然很好，因為我們沒有為用戶即時構建任何東西。
但這種好處只有在站點是預先構建的情況下才能實現，而且這個過程可能很耗時。 雖然更傳統的網站會在您請求時構建頁面，但我們實際上是提前創建每個頁面，以防用戶可能需要它。 它使性能超級快！ 但是現在這個時間已經轉移到了開發和發佈時間——創建每個頁面都需要時間。
對於較小的網站來說，這不是什麼大問題，但在 Smashing Magazine 的規模上，我們需要更多地考慮那個時間，特別是這樣人們才能在每天積極創建內容的同時保持高生產力。
Netlify 所做的是創建一個大型/production-articles文件夾，其中包含他們已經託管的數千篇文章中的大部分。 然後，創建一個名為content/articles的單獨工作目錄，可以放置正在創建和編輯的文章。
這個構建過程意味著在該站點上工作的每個人都在處理一小部分用於本地開發的文章，而不受等待整個構建過程的阻礙。 這個過程由一個 gulp 任務來管理以準備生產文章，並讓 Hugo 騰出時間來處理正在積極處理的事情。
這種方法的一個缺點是它仍然需要運行整個構建，從而使過程變慢。 在較小的出版物中，這可能不太重要，但在 Smashing 的規模上，它確實會減慢出版過程。
開源 API
一開始，我們提到 Smashing 有興趣遷移他們現有的電子商務解決方案，處理 WordPress 之外的評論，並為身份驗證添加功能。 所有這些功能都是使用 Netlify 維護的開源解決方案構建的，將它們分解為無狀態 API：
- GoTell
用於處理大量評論的 API 和構建工具。 - 去商務
一個基於 Go 的小型 API，用於處理訂單和支付的電子商務網站。 - 真真
一個用 Golang 編寫的小型開源 API，可以作為一個獨立的 API 服務來處理項目的用戶註冊和身份驗證。 它基於 OAuth2 和 JWT，將處理用戶註冊、身份驗證和自定義用戶數據。
這些部分中的每一個都需要遷移和它們自己的獨特因素，雖然它們超出了本文的範圍，但它們都包含在 Matt 合著的名為“ JAMstack 上的現代 Web 開發”的免費書籍中。 我們還將在隨後的文章中對搜索和身份驗證進行一些像這樣的深入研究（帶有可用示例）。
結論
遷移順利進行。 粉碎？ 呃……進展順利。 Smashing 並沒有因為其自身的成功而受到懲罰——當一篇受歡迎的文章出現時，他們可以始終如一地提供內容，不再為大量負載而保釋。 與此同時，向 JAMstack 基礎架構的遷移帶來了更好的性能和安全性。
Smashing Magazine 前首席執行官 Markus Seyfferth 指出：
“首次加載的時間比以前快了很多……之前我們必須等待 HTML 文件提供800 毫秒，而現在是80 毫秒。”
這個過程是成功的，就像任何偉大的工程項目一樣，在此過程中吸取了教訓。 在本系列的下一篇文章中，我們將通過一個教程和演示，根據我們所學的內容來推薦我們的建議。 如果您想現代化您的 WordPress 開發並獲得 JAMstack 的性能和安全優勢，請繼續閱讀！