我上個月發佈了一個行銷網站，在所有Lighthouse類別中都獲得100分。發送給用戶端的JavaScript總數：零位元組。不是「幾乎為零」或「最少」——確實為零。表單運作、導航運作、有深色模式切換，頁面轉換感覺很流暢。五年前這需要進行認真的妥協。在2026年，平台已經達到零JS不再是限制——而是一個合法的架構選擇的程度。

但是大多數關於漸進式增強的文章都弄錯了一點：這不是關於成為純粹主義者或討厭JavaScript。這是關於有意識地決定什麼在哪裡運作。讓我帶您了解我們在Social Animal如何處理這個問題、2026年中哪些變化使零JS對更多項目都可行、以及何時您絕對應該仍然使用用戶端代碼。

目錄

Progressive Enhancement & Zero-JS Websites in 2026

2026年漸進式增強的真正含義

漸進式增強自2000年代初就存在，但我交談的大多數開發人員仍然誤解它。他們認為這意味著「首先構建一個糟糕的HTML版本，然後用JavaScript使其變好」。這是倒序的。

漸進式增強意味著您的基線體驗運作。句號。HTML是您的基礎。CSS添加視覺層。JavaScript——如果您需要它——在頂部添加互動性。每層都是累加的。如果任何層失敗，下面的層仍然運作。

在2026年，這種哲學變得更加實用，因為HTML和CSS的基線功能已大幅擴展。五年前需要JavaScript的事情現在有本機平台解決方案：

  • 手風琴和揭示小工具 → <details> 和 <summary>
  • 模式和對話框 → <dialog> 元素
  • 表單驗證 → 約束驗證API
  • 平滑滾動 → scroll-behavior: smooth
  • 深色模式 → @media (prefers-color-scheme) 配合 :has() 選擇器技巧
  • 旋轉木馬 → CSS滾動貼靠配合 scrollbar-width
  • 彈出窗和工具提示 → Popover API
  • 錨點定位 → CSS錨點定位
  • 視圖轉換 → 視圖轉換API（跨文檔級別2）

2026年的網路平台不是2020年的網路平台。我們在沒有腳本的情況下可能實現的功能已大幅擴展。

平台改變了一切

Popover API

Popover API在2024年達到完全跨瀏覽器支持，到現在為止在任何重要的地方都是生產就緒的。在此之前，每個工具提示、下拉菜單和敬酒通知都需要JavaScript。現在：

<button popovertarget="my-menu">菜單</button>
<nav popover id="my-menu">
  <a href="/about">關於</a>
  <a href="/work">作品</a>
  <a href="/contact">聯繫</a>
</nav>

就這樣。點擊按鈕，彈出窗口出現。在外部點擊，它關閉。按Escape，它關閉。焦點管理已處理。預設可訪問。零JavaScript。

CSS錨點定位

這是真正開啟事物的一個。相對於觸發器定位工具提示曾經需要JavaScript來測量DOM位置。CSS錨點定位（2025年基線，現在完全穩定）以聲明方式處理它：

.trigger {
  anchor-name: --my-trigger;
}

.tooltip {
  position: fixed;
  position-anchor: --my-trigger;
  top: anchor(bottom);
  left: anchor(center);
  translate: -50% 8px;
}

將此與Popover API結合，您就擁有完全定位、可訪問的工具提示，零用戶端代碼。

跨文檔視圖轉換

視圖轉換級別2是使零JS網站感覺像SPA的原因。您添加一個CSS at-rule，突然之間在頁面之間導航就有平滑動畫轉換：

@view-transition {
  navigation: auto;
}

::view-transition-old(root) {
  animation: fade-out 0.2s ease;
}

::view-transition-new(root) {
  animation: fade-in 0.2s ease;
}

Chrome、Edge和Safari都現在支持它。Firefox預計在今年晚些時候推出。這個單一功能消除了團隊選擇SPA的最大原因之一——通過動畫轉換感知性能。

`:has()` 選擇器

:has() 選擇器（有時稱為「父選擇器」）自2024年以來一直穩定，它對於CSS專用互動性是真正變革性的：

/* 無需JS切換深色模式 */
html:has(#dark-mode:checked) {
  color-scheme: dark;
  --bg: #1a1a2e;
  --text: #eee;
}

有一個隱藏的複選框和一個 <label>，您就有了一個運作中的深色模式切換。沒有JavaScript。狀態在會話期間持續，如果您想跨訪問持久化，您甚至可以通過小型增強腳本將其同步到 localStorage。

取代JavaScript的CSS專用模式

讓我列舉我們定期使用的模式。我談論的不是CSS藝術或新奇演示——這些是我們發佈給真實客戶的生產模式。

模式 舊方法 (JS) 2026方法 (CSS/HTML) 瀏覽器支持
下拉菜單 事件監聽器、焦點陷阱 Popover API + :has() 95%+
手風琴 切換類別、ARIA管理 <details> + ::details-content 96%+
模式對話框 焦點陷阱庫、滾動鎖定 <dialog> + ::backdrop 97%+
標籤 顯示/隱藏面板、ARIA標籤 單選按鈕 + :has() + scroll-snap 95%+
旋轉木馬 Swiper.js、Flickity scroll-snap + scroll-timeline 93%+
工具提示 Popper.js、Floating UI Popover API + 錨點定位 90%+
表單驗證 自訂驗證邏輯 約束驗證 + :user-valid 95%+
滾動動畫 Intersection Observer、GSAP animation-timeline: scroll() 88%+
主題切換 localStorage + DOM操作 複選框 + :has() + color-scheme 96%+
頁面轉換 用戶端路由 跨文檔視圖轉換 85%+

該表代表典型行銷網站或內容平台上可能的大約80%的互動模式。全部可實現，無需發佈單一千位元組的JavaScript。

標籤模式

這是我特別喜歡的一個。使用單選按鈕的CSS專用標籤：

<div class="tabs">
  <input type="radio" name="tab" id="tab1" checked>
  <label for="tab1">功能</label>
  <input type="radio" name="tab" id="tab2">
  <label for="tab2">定價</label>
  <input type="radio" name="tab" id="tab3">
  <label for="tab3">常見問題</label>
  
  <div class="panels">
    <div class="panel" id="panel1">功能內容...</div>
    <div class="panel" id="panel2">定價內容...</div>
    <div class="panel" id="panel3">常見問題內容...</div>
  </div>
</div>

.tabs:has(#tab1:checked) .panels { --active: 0; }
.tabs:has(#tab2:checked) .panels { --active: 1; }
.tabs:has(#tab3:checked) .panels { --active: 2; }

.panels {
  display: flex;
  overflow: hidden;
  translate: calc(var(--active) * -100%) 0;
  transition: translate 0.3s ease;
}

.panel {
  min-width: 100%;
}

平滑、動畫化的標籤切換，零JavaScript。添加 role="tablist" 和適當的ARIA屬性以實現可訪問性，您就擁有了生產就緒組件。

Progressive Enhancement & Zero-JS Websites in 2026 - architecture

HTML優先互動性

超越CSS，HTML本身變得更加有能力。讓我強調我們使用的模式。

`` 元素

我知道 <dialog> 已經存在了一段時間，但許多團隊仍然求助於模式庫。不要。本機對話框處理焦點陷阱、滾動鎖定、Escape關閉和疊加的 ::backdrop 偽元素。

一個注意事項：您確實需要一點JavaScript來打開模式對話框（調用 .showModal()）。但對於漸進式增強，您可以使觸發器成為指向單獨頁面的連結，然後如果可用，使用JS增強：

<a href="/contact" class="js-dialog-trigger" data-dialog="contact-form">
  聯繫我們
</a>

<dialog id="contact-form">
  <form method="dialog">
    <!-- 表單欄位 -->
    <button type="submit">發送</button>
  </form>
</dialog>

沒有JavaScript：用戶導航到 /contact。有JavaScript：對話框內聯打開。兩者都運作。這就是漸進式增強。

沒有JavaScript的表單

表單是零JS方法的最大勝利。本機HTML表單將數據提交到伺服器。這就是它們的設計目的。使用現代伺服器端框架，您不需要 e.preventDefault() 和 fetch() 呼叫：

<form action="/api/contact" method="POST">
  <input type="email" name="email" required>
  <textarea name="message" required minlength="10"></textarea>
  <button type="submit">發送</button>
</form>

:user-valid 和 :user-invalid 偽類（現在基線）讓您無需JS即可設定驗證狀態的樣式，但僅在用戶交互後——不再有頁面加載時的紅邊框。

input:user-invalid {
  border-color: var(--error);
  outline-color: var(--error);
}

input:user-valid {
  border-color: var(--success);
}

發佈零JS的伺服器端框架

為漸進式增強選擇正確的框架非常重要。以下是主要參與者在2026年的表現。

Astro

Astro仍然是零JS輸出的金標準。默認情況下它發佈HTML和CSS，您可以使用 client: 指令按組件選擇加入JavaScript。我們在行銷網站、文檔和內容豐富的平台上廣泛使用它——查看我們的Astro開發能力了解具體信息。

---
// 這個組件發佈零JavaScript
const posts = await fetch('https://api.example.com/posts').then(r => r.json());
---
<ul>
  {posts.map(post => <li><a href={post.url}>{post.title}</a></li>)}
</ul>

Astro 5（自2025年初穩定）添加了伺服器島嶼和改進的內容層API。思維模型很簡單：除非您明確說明，否則所有內容都是伺服器呈現的。

Eleventy (11ty)

Eleventy 3.0繼續對零JS網站表現出色。它是一個純靜態網站生成器——對用戶端JavaScript沒有任何觀點。如果您想要它，您手動添加它。我們發現它對於較小的網站和博客是理想的，其中構建時間簡單性很重要。

帶有伺服器組件的Next.js

Next.js在這裡很有趣。伺服器組件（App Router中的默認值）不將JavaScript發佈給用戶端。但Next.js運行時本身為水合、路由和預取添加了基線JS有效負載。您無法用Next.js達到真正的零JS，但對於互動應用，您可以獲得非常接近。查看我們的Next.js開發工作——我們在幾個項目上推動了這個邊界。

SvelteKit

SvelteKit讓您使用 export const csr = false 按頁面禁用JavaScript。輸出是純HTML/CSS。這是一個很好的中間立場——您獲得Svelte組件的開發人員體驗，但可以有選擇地禁用用戶端呈現。

框架 默認JS輸出 零JS可能？ 最佳用途
Astro 5 0 KB 是（默認） 內容網站、行銷
Eleventy 3 0 KB 是（默認） 博客、文檔、簡單網站
Next.js 15 ~85-100 KB 否（運行時必需） 網路應用、動態內容
SvelteKit 2 ~15-25 KB 是（按頁面選擇退出） 混合網站
Fresh (Deno) 0 KB 是（島嶼架構） 基於Deno的項目
Enhance 0 KB 是（HTML優先） 網路組件網站

何時零JavaScript是錯誤的選擇

如果我只談論零JS何時運作，我會對您做損害。以下是它不運作的時候：

實時協作。 如果您正在構建類似Figma、Google Docs或聊天應用程式的東西，您需要WebSockets和用戶端狀態管理。無法繞過。

複雜數據可視化。 D3、Observable Plot或deck.gl用於地圖——這些需要JavaScript。您可以將靜態圖表伺服器呈現為SVG（我們會這樣做），但任何互動都需要用戶端代碼。

富文本編輯器。 ProseMirror、TipTap、Lexical——這些本質上是用戶端應用程式。漸進式增強在這裡意味著提供 <textarea> 後備，這實際上相當合理。

用戶端搜尋。 如果您想要即時搜尋邊輸入邊搜尋，無需在每次按鍵時都命中伺服器，您需要用戶端搜尋索引（Pagefind、Lunr、Fuse.js）。Pagefind值得特別提出——它是一個構建時搜尋索引，最初只加載~5 KB。

驗證流程。 OAuth重定向無需JS即可運作，但令牌刷新、會話管理和受保護的用戶端路由通常需要一些腳本。

視頻/音頻播放器。 自訂播放器需要JavaScript。但 <video> 和 <audio> 元素具有本機控制項可以完美運作，無需它。

我推薦的模式：從零JS開始，在用戶體驗確實需要它的地方有目的地添加它。這正是Astro的島嶼架構所啟用的——95%的頁面是靜態HTML，唯一的互動小工具得到水合。

性能基準：JS vs 零JS

我們一直在追蹤我們客戶項目的性能。以下是我們在2025-2026年期間構建的生產網站的真實數字。

指標 典型React SPA Next.js (App Router) Astro (零JS) 改進
第一個內容繪製 1.8秒 0.9秒 0.4秒 快78%
最大內容繪製 2.5秒 1.3秒 0.6秒 快76%
互動時間 3.2秒 1.8秒 0.4秒 快87%
總阻塞時間 450毫秒 180毫秒 0毫秒 減少100%
JS傳輸大小 280 KB 105 KB 0 KB 減少100%
Lighthouse性能 65-75 85-95 100 --
核心網路生命力通過率 55% 82% 99% --

這些數字對真實商業成果很重要。Google在2025年變得越來越透明地談論CWV對搜尋排名的影響。Searchmetrics的一項研究發現，通過所有核心網路生命力的網站平均排名位置比失敗的網站高24%。這個差距正在擴大。

對於我們的客戶，我們看到了可測量的改進：一個電子商務品牌在從React SPA遷移到基於Astro的商店後，有機流量增加了15%，選擇性水合。他們的無頭CMS架構保持不變——我們只是改變了前端消費和呈現內容的方式。

構建漸進式增強策略

以下是我們遵循的實踐手冊：

步驟1：審計您的JavaScript

在您構建任何新內容之前，查看您當前正在發佈的JavaScript，問：這是否需要在用戶端運作？

# 在Chrome DevTools中檢查JS使用情況的快速方法
# 覆蓋標籤 → 重新加載 → 查看初始頁面加載時實際執行多少JS

我們定期發現發佈的JavaScript有40-60%在初始頁面加載時永遠不會執行。這是死代碼、未使用的polyfill或未被觸發的功能。

步驟2：分類您的互動性

將每個互動功能放在以下三個存儲桶之一中：

  1. 平台本機 ——可以單獨使用HTML/CSS完成（使用平台）
  2. 增強 ——無需JS運作，有JS更好（漸進式增強）
  3. 需要JS ——完全不可能無需用戶端代碼（發佈它）

對自己誠實。大多數事情落在存儲桶1或2。

步驟3：選擇正確的框架

如果您正在構建內容網站、文檔、行銷頁面或博客——選擇Astro或Eleventy。不要僅因為您的團隊知道React而為行銷網站選擇Next.js。架構不匹配會浪費您的性能。

如果您正在構建具有重大用戶端互動性的應用程式，Next.js或SvelteKit配合選擇性伺服器呈現更有意義。盡可能使用伺服器組件，僅在必要時使用用戶端組件。

我們幫助團隊做出完全相同的決定——查看我們的能力或聯繫我們，如果您想討論您的具體情況。

步驟4：無JavaScript測試

這是每個人都跳過的步驟。在您的瀏覽器中禁用JavaScript並導航您的網站。它運作嗎？用戶可以：

  • 閱讀內容？ ✓
  • 在頁面之間導航？ ✓
  • 提交表單？ ✓
  • 訪問關鍵信息？ ✓

如果沒有，您的增強策略有漏洞。

零JS網站的實世界架構

讓我分享我們在幾個客戶項目中使用的具體架構：

┌─────────────────────────────────────────┐
│              CDN (Cloudflare)            │
│         靜態HTML/CSS資產                 │
├─────────────────────────────────────────┤
│          Astro SSG / SSR層               │
│     在構建/請求時獲取內容               │
├─────────────────────────────────────────┤
│            無頭CMS                      │
│    (Sanity / Storyblok / Payload)       │
├─────────────────────────────────────────┤
│          表單處理程序服務               │
│     (Cloudflare Workers / Resend)       │
└─────────────────────────────────────────┘

內容存在於無頭CMS中。Astro在構建時（或對於頻繁更新的內容在請求時）拉取它。輸出是純HTML和CSS，部署到CDN邊緣。表單提交到無伺服器功能，該功能處理驗證和電子郵件傳遞。

整個前端具有零JavaScript。CMS為內容編輯提供了很好的體驗。表單無需用戶端代碼即可運作。頁面轉換使用跨文檔視圖轉換。這很快、無障礙且有適應力。

對於需要選擇性互動的網站——比如一個頁面上的產品配置器——我們使用Astro的島嶼架構只水合該組件。網站的其餘部分保持靜態。

這是我們定期構建的那種架構。如果您對這種方法的定價感到好奇，查看我們的定價頁面——零JS網站通常構建速度更快，託管成本更便宜。

常見問題

漸進式增強在2026年仍然相關嗎？ 比以往更相關。支持Popover API、CSS :has()、視圖轉換和 <dialog> 的95%+瀏覽器中，網路平台可以處理以前需要JavaScript的互動性。漸進式增強不是過去哲學——這是一個實用的工程策略，導致更快、更有適應力和更無障礙的網站。

您能用零JavaScript構建完整網站嗎？ 絕對可以。行銷網站、博客、文檔、投資組合甚至電子商務店面可以用零用戶端JavaScript構建。表單本機提交，導航使用標準鏈接（使用視圖轉換進行拋光），互動組件如手風琴、模式和工具提示都有HTML/CSS本機解決方案。您無法無需JS構建的網站是實時應用程式、富文本編輯器和複雜數據可視化。

零JavaScript如何影響SEO？ 在幾乎每種情況下都是正面的。搜尋引擎可以立即索引HTML內容，無需等待JavaScript執行。核心網路生命力分數戲劇性改進——特別是總阻塞時間，降到零。Google的排名系統獎勵快速、無障礙的頁面，零JS網站始終達到更高的Lighthouse分數和更好的CWV通過率。

2026年零JavaScript網站的最佳框架是什麼？ Astro對大多數零JS項目是最強選擇。默認情況下它輸出零JavaScript，讓您在需要時按組件添加用戶端互動性。Eleventy是較簡單網站的另一個優秀選項。兩者都有成熟的生態系統、良好的文檔和活躍的社區。選擇通常歸結為您是否想要基於組件的編寫（Astro）或基於範本的簡潔（Eleventy）。

CSS專用互動組件對可訪問性運作嗎？ <details>、<dialog> 和Popover API等本機HTML元素預設是無障礙的——它們自動處理焦點管理、鍵盤導航和ARIA語義。CSS專用模式使用複選框hack需要更多護理：您應該添加適當的ARIA角色並確保鍵盤可操作性。一般來說，本機HTML解決方案比自訂JavaScript實現更無障礙，因為瀏覽器供應商已經為您完成了可訪問性工作。

視圖轉換無需JavaScript如何運作？ 跨文檔視圖轉換（規格的級別2）完全通過CSS運作。您添加 @view-transition { navigation: auto; } 規則，瀏覽器自動在頁面導航之間創建動畫轉換。您可以使用 ::view-transition-old() 和 ::view-transition-new() 偽元素自訂動畫。無需JavaScript。Chrome、Edge和Safari在2026年支持它，Firefox支持預計不久。

有多少百分比的用戶禁用JavaScript？ 只有大約1-2%的用戶主動禁用JavaScript。但這不是重點。對於比這更多的用戶，JavaScript失敗——不穩定的連接、公司防火牆、瀏覽器擴展、CDN中斷和解析錯誤都會導致JS失敗。英國政府數位服務發現，1.1%的用戶沒有取得JavaScript增強，儘管JS已啟用。漸進式增強保護所有這些用戶。

我可以使用帶有零JavaScript前端的無頭CMS嗎？ 是的，這是最好的組合之一。CMS為內容團隊提供豐富的編輯體驗，而前端（使用Astro或Eleventy構建）在構建時通過API消費內容並輸出純HTML/CSS。CMS JavaScript在編輯器的瀏覽器中運作，不在您的訪客瀏覽器中。這種解耦為您提供了最好的兩個世界：很好的編寫體驗和為最終用戶的零JS性能。