Jamstack是什麼？

Jamstack指的是一套用於構建現代網站的技術棧，可能過去的一些文章通常會把它們理解為J avaScript、 A PIs、 M arkup，但其實現在這個概念已經被擴大了，Jamstack的官網上將它的核心概念歸納為Pre-rendering 、 Enhancing with JavaScript 、 Supercharging with services 。

當然掉書袋沒什麼意思，用人話來解釋的話，當下絕大多數Jamstack 網站，都是這樣的技術棧：

1.使用網站生成器預渲染整個網站

整個網站在部署前，會被網站生成器（SSG, Static Site Generators）構建和優化為一系列的靜態頁面和靜態資源，這樣整個網站可以被託管在CDN上，加載速度得到最大程度地優化，安全性也得到保障。

這裡的網站生成器包括但不限於： Gatsby 、 Hugo 、 Jekyll 、 Eleventy 、 NextJS ……

2.使用Headless CMS（無頭CMS）管理動態內容

如果想要網站承載動態內容，那麼可以接入各種Headless CMS（無頭CMS），這些CMS系統會對外提供API，網站生成器可以調用這些API拉取數據，將動態數據渲染成為靜態頁面。

這裡的無頭CMS包括但不限於： Ghost 、 Strapi 、 Netlify-CMS 、 TinaCMS ……

3.使用HTTP API增強網站的功能

在登錄註冊、評論框等需要後端支持的能力上，Jamstack 網站通常會使用微服務提供的HTTP API，或者一些第三方的BaaS（後端即服務）能力。

除了以上三個主要特點以外，Jamstack 的網站通常還會有下面的特性：

• 全站託管於CDN 上
• 原子化發布（每次發布都是一次全量、原子性的發布）
• 靈活的文件緩存策略
• 基於Git 的全自動構建、部署流程

Jamstack有什麼優勢？

1.相比於純靜態網站

純靜態的網站很難承載動態的內容，內容改動通常都是要直接修改頁面的代碼，這對於內容管理人員（很可能是非技術人員）來說非常不友好。

而Jamstack 的網站，通常會使用無頭CMS 來將內容管理抽離出去，內容管理人員可以直接在這些CMS 系統的UI 界面上進行內容修改，然後觸發整個網站的重新預渲染，以及部署。

2.相比於傳統動態網站

這裡的“傳統動態網站”指的是用PHP、Ruby On Rails、JSP 甚至更古老的CGI 構建的網站，以及基於這些技術產生的建站工具比如WordPress、Drupal 等等。

這些傳統網站的劣勢在於，它們在運行時都需要一個實時在線的服務端，這些服務端負責處理請求、渲染頁面，這就很大程度上降低了服務的可伸縮性和穩定性（想像一下，你遷移擴容一個在線的WordPress 網站有多麼麻煩）。

Jamstack 由於是直接使用CDN 分發靜態的頁面，完全不需要渲染頁面的服務，網站的伸縮性、穩定性可以得到最大的保障。

3.相比於單頁應用（SPA）

大概五年前，隨著各種前端框架的成熟，越來越多的業務邏輯遷移到了前端處理，這也就誕生了SPA 的概念，也就是整個網站的UI 層，由瀏覽器端來完全接管。得益於HTML5 和現代瀏覽器的一系列特性，這樣的做法可以保證最好的用戶體驗。

但是SPA最大的問題在於它對SEO不友好，因為SPA的頁面內容都是靠瀏覽器異步獲取、渲染的，雖然Google為首的大多數搜索引擎漸漸地支持爬取SPA的內容，但是這依然是一個隱患。另外，由於SPA 需要異步加載數據，首屏內容需要在在加載、運行JS 之後才能看到，也給用戶打開網站的體驗帶來影響。

而Jamstack 的頁面本質上都是託管在CDN 上的靜態頁面，搜索引擎可以直接爬取這些靜態內容，首屏與靜態網站一樣，可以直接展示內容，而不需要等到加載運行JS 之後。

4.相比於SSR應用

目前市面上的幾大前端框架都支持了服務器端渲染，也就是SSR 的概念，這些SSR 技術也成為了Jamstack 的基礎之一。但是典型的SSR應用和傳統動態網站一樣，都是需要一個在線的服務來渲染頁面，同樣會有運維和安全性上的風險。

Jamstack 從技術角度上講，可以認為是SSR 技術的進階，也就是提前用SSR 預渲染大部分頁面，然後將這些頁面部署在CDN 上，隨後根據網站的數據變化，重複預渲染、部署即可。

特性	Jamstack	純靜態網站	傳統動態網站	單頁應用（SPA）	SSR應用
使用CDN全站加速	✅	✅	❌	✅
方便的內容管理	✅	❌	✅	✅	✅
SEO友好	✅	✅	✅	❌	✅
首屏渲染速度	✅	✅	❌	❌	✅
不需要在線服務	✅	✅	❌	✅	❌
安全性	✅	✅	✅

當然，Jamstack也不是萬金油，不可能完美適應所有場景，Jamstack最適合一些內容更新不太頻繁的網站（比如新聞、電商、文檔）。它不適合Feeds 流、聊天室、論壇、個性化推薦這樣高度動態化的網站，以及郵箱、編輯器這樣偏重型的Web 應用。

Jamstack的商業價值

在國外的電商行業，Headless Commerce（無頭電商）是一個非常火的概念。

所謂的無頭電商，就是把用戶端的UI 展現和整個電商後台服務進行解耦，去除掉了UI 層，也就是“頭”，畢竟每個公司都不想自己的網站、購買體驗和別人一樣。

無頭電商只對外暴露一系列的API，讓客戶公司可以使用這些API 構建自己的電商網站。舉一些具體的例子，比如Salesforce正在推行的Open Commerce API ，逐漸成為現在電商開放API的標準。換句話說，這個做法很類似現在國內很多公司在推行的“中台化” 、 “大中台小前台”的概念。

所以這和Jamstack 有什麼關係呢？

你會發現，Jamstack推行的這一套技術棧，包括預渲染動態數據的靜態頁面、無頭CMS 、微服務HTTP API ，幾乎和無頭電商的理念完全一致，或者說，無頭電商就是Jamstack 一個最貼切的應用場景。

在前段時間Vercel舉辦的Next.js Conf上，主要贊助商除了AWS、Github、Firebase這樣的雲平台以外，大部分都是適用於Jamstack的第三方API提供方、或者一些無頭CMS，這也從側面體現了Jamstack 目前在國外的生態繁榮。

但是在國內市場上，或許不那麼樂觀：國內Web網站本身就處於一個很尷尬的狀態，各大公司的主要業務都是以移動端App為主要入口，Web網站缺少流量來源，或許只有一些特性類型的業務（比如新聞、電商網站）需要Web站點；電商市場方面，國內大部分中小型公司都處於嚴重缺乏訊息化的狀態，更多依賴於阿里、京東這樣的大平台方提供的基礎系統，還遠遠沒有自建整套流程的需求，無頭電商也就無從談起。

尾聲

從技術角度上講，Jamstack本質是一種增強的靜態網站，它的出現很大程度上得益於各大雲廠商提供的雲上能力，包括更容易管控的CDN/DNS、Serverless Function、DevOps工具等等。

隨著國內相關雲計算基礎設施的成熟，Jamstack 在國內幾家云平台的支持程度也會慢慢提高，我們完全可以期待未來Jamstack 部分替代傳統的WordPress 等建站工具，變成新一代的建站技術棧。