Progressive Enhancement & Zero-JS Websites in 2026
先月、Lighthouseのすべてのカテゴリで100点を獲得したマーケティングサイトをリリースしました。クライアントに送信されたJavaScriptの総量:0バイト。「ほぼゼロ」や「最小限」ではなく、文字通りなし。フォームは機能し、ナビゲーションは機能し、ダークモードの切り替えがあり、ページの遷移はスナッピーに感じます。5年前だったら、深刻なトレードオフが必要だったでしょう。2026年には、プラットフォームがゼロJSが制限ではなく、正当なアーキテクチャの選択肢であるポイントに追いついています。
しかし、プログレッシブエンハンスメントについてのほとんどの記事が間違っていることがあります。それは純粋主義者であるか、JavaScriptを嫌うことについてではありません。それは、どこでなにが実行されるかについて意図的な決定を下すことについてです。Social Animalでどのようにアプローチするか、2026年でゼロJSがこれまで以上に多くのプロジェクトに対して実行可能にした変更、およびクライアント側のコードに確実に手を伸ばすべき時期について説明します。
目次
- 2026年のプログレッシブエンハンスメントが実際に意味するもの
- プラットフォームがすべてを変えました
- JavaScriptを置き換えるCSSのみのパターン
- HTMLファーストインタラクティブ
- ゼロJSを配信するサーバー側フレームワーク
- ゼロJavaScriptが間違った選択である場合
- パフォーマンスベンチマーク:JSとゼロJS
- プログレッシブエンハンスメント戦略の構築
- ゼロJSサイトの実世界アーキテクチャ
- FAQ

2026年のプログレッシブエンハンスメントが実際に意味するもの
プログレッシブエンハンスメントは2000年代初期から存在していますが、私が話す大多数の開発者はまだそれを誤解しています。彼らはそれが「最初に悪いHTMLバージョンを構築し、次にJavaScriptで良くする」ことを意味すると考えています。それは後ろ向きです。
プログレッシブエンハンスメントは、ベースラインエクスペリエンスが機能することを意味します。期間。HTMLはあなたの基礎です。CSSはビジュアルレイヤーを追加します。JavaScript(必要な場合)はその上にインタラクティブ性を追加します。各レイヤーは加算的です。任意のレイヤーが失敗した場合、下層のレイヤーは引き続き機能します。
2026年では、HTMLとCSSのベースライン機能が劇的に拡張されているため、この哲学はこれまで以上に実用的になっています。5年前にJavaScriptが必要だったものは、ネイティブプラットフォームソリューションを持っています:
- アコーディオンと開示ウィジェット →
<details>と<summary> - モーダルとダイアログ →
<dialog>要素 - フォーム検証 → Constraint Validation API
- スムーズスクロール →
scroll-behavior: smooth - ダークモード →
@media (prefers-color-scheme)with:has()selector tricks - カルーセル → CSS scroll snap with
scrollbar-width - ポップオーバーとツールチップ → Popover API
- アンカーポジショニング → CSS Anchor Positioning
- ビュー遷移 → View Transitions API (Level 2 for cross-document)
2026年のウェブプラットフォームは2020年のウェブプラットフォームではありません。スクリプティングなしに可能なことの大規模な拡張がありました。
プラットフォームがすべてを変えました
Popover API
Popover APIは2024年に完全なクロスブラウザサポートに達し、今では本番環境対応はどこでも重要です。これより前は、すべてのツールチップ、ドロップダウンメニュー、およびトースト通知にはJavaScriptが必要でした。今:
<button popovertarget="my-menu">Menu</button>
<nav popover id="my-menu">
<a href="/about">About</a>
<a href="/work">Work</a>
<a href="/contact">Contact</a>
</nav>
それだけです。ボタンをクリックするとポップオーバーが表示されます。外側をクリックするとそれが削除されます。Escapeを押すと削除されます。フォーカス管理は処理されます。デフォルトでアクセス可能です。ゼロJavaScript。
CSS Anchor Positioning
これが本当に物事を開いたものです。トリガーを相対的に位置付けることは、DOMの位置を測定するためにJavaScriptが必要でした。CSS Anchor Positioning(2025年のベースライン、現在は完全に安定しています)は宣言的に処理します:
.trigger {
anchor-name: --my-trigger;
}
.tooltip {
position: fixed;
position-anchor: --my-trigger;
top: anchor(bottom);
left: anchor(center);
translate: -50% 8px;
}
これをPopover APIと組み合わせると、クライアント側のコードがなく、完全に配置されたアクセス可能なツールチップが得られます。
クロスドキュメント View Transitions
View Transitions Level 2は、ゼロJSサイトをSPAのように感じさせるものです。CSSアット規則を追加するだけで、ページ間の移動がスムーズなアニメーション遷移を持つようになります:
@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を選択した主な理由の1つを排除します —アニメーション遷移を通じた知覚パフォーマンス。
`: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) | ブラウザサポート |
|---|---|---|---|
| ドロップダウンメニュー | Event listeners, focus traps | Popover API + :has() |
95%+ |
| アコーディオン | Toggle classes, ARIA management | <details> + ::details-content |
96%+ |
| モーダル | Focus trap libraries, scroll lock | <dialog> + ::backdrop |
97%+ |
| タブ | Show/hide panels, ARIA tabs | Radio buttons + :has() + scroll-snap |
95%+ |
| カルーセル | Swiper.js, Flickity | scroll-snap + scroll-timeline |
93%+ |
| ツールチップ | Popper.js, Floating UI | Popover API + Anchor Positioning | 90%+ |
| フォーム検証 | Custom validation logic | Constraint Validation + :user-valid |
95%+ |
| スクロールアニメーション | Intersection Observer, GSAP | animation-timeline: scroll() |
88%+ |
| テーマ切り替え | localStorage + DOM manipulation | Checkbox + :has() + color-scheme |
96%+ |
| ページ遷移 | Client-side routing | Cross-document View Transitions | 85%+ |
このテーブルは、典型的なマーケティングサイトまたはコンテンツプラットフォーム上のインタラクティブパターンのおおよそ80%を表します。すべてが単一キロバイトのJavaScriptを配信せずに実現可能です。
タブパターン
これは特に好んでいる1つです。ラジオボタンを使用したCSSのみのタブ:
<div class="tabs">
<input type="radio" name="tab" id="tab1" checked>
<label for="tab1">Features</label>
<input type="radio" name="tab" id="tab2">
<label for="tab2">Pricing</label>
<input type="radio" name="tab" id="tab3">
<label for="tab3">FAQ</label>
<div class="panels">
<div class="panel" id="panel1">Features content...</div>
<div class="panel" id="panel2">Pricing content...</div>
<div class="panel" id="panel3">FAQ content...</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属性を追加すると、本番対応のコンポーネントが得られます。

HTMLファーストインタラクティブ
CSSを超えて、HTML自体はより多くの能力を持つようになりました。使用するパターンを強調しましょう。
`
<dialog> はしばらく存在していることを知っていますが、多くのチームはモーダルライブラリに手を伸ばし続けています。しないで。ネイティブダイアログはフォーカストラップ、スクロールロック、Escape で閉じる、および ::backdrop 疑似要素をオーバーレイのために処理します。
1つの問題:モーダルダイアログを開くには少しのJavaScriptが必要です(.showModal() を呼び出す)。ただし、プログレッシブエンハンスメントの場合は、トリガーを別のページへのリンクにすることができ、利用可能な場合はJSで拡張します:
<a href="/contact" class="js-dialog-trigger" data-dialog="contact-form">
Get in touch
</a>
<dialog id="contact-form">
<form method="dialog">
<!-- form fields -->
<button type="submit">Send</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">Send</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をオプトインします。マーケティングサイト、ドキュメンテーション、およびコンテンツが豊富なプラットフォームで広く使用しています。
---
// このコンポーネントはゼロ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についての見解なし。それが必要な場合は、手動で追加します。小規模なサイトやブログでビルド時の単純さが重要な場合に理想的であることがわかりました。
Server ComponentsによるNext.js
Next.jsはここで興味深いです。Server Components(App Routerのデフォルト)はクライアントにJavaScriptを配信しません。ただし、Next.jsランタイム自体は水分補給、ルーティング、およびプリフェッチのためにベースラインJSペイロードを追加します。Next.jsでゼロ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ファースト) | Webコンポーネントサイト |
ゼロ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なしで機能します。
推奨するパターン:ゼロJSで開始し、ユーザーエクスペリエンスが本当に必要な場所に外科的に追加します。これはまさにAstroのアイランドアーキテクチャが有効にするものです —ページの95%は静的HTMLであり、1つのインタラクティブウィジェットがハイドレートされます。
パフォーマンスベンチマーク:JSとゼロJS
クライアントプロジェクト全体のパフォーマンスを追跡しています。これらは、2025~2026年に構築した本番サイトからの実数です。
| メトリック | 典型的なReact SPA | Next.js (App Router) | Astro (ゼロJS) | 改善 |
|---|---|---|---|---|
| First Contentful Paint | 1.8s | 0.9s | 0.4s | 78% 高速化 |
| Largest Contentful Paint | 2.5s | 1.3s | 0.6s | 76% 高速化 |
| Time to Interactive | 3.2s | 1.8s | 0.4s | 87% 高速化 |
| Total Blocking Time | 450ms | 180ms | 0ms | 100% 削減 |
| JS Transfer Size | 280 KB | 105 KB | 0 KB | 100% 削減 |
| Lighthouse Performance | 65-75 | 85-95 | 100 | -- |
| Core Web Vitals Pass Rate | 55% | 82% | 99% | -- |
これらの数字は実際のビジネス成果にとって重要です。Googleは、CWVがランキングに与える影響についてますますこっそりしています。Searchmetricsによる2025年の調査では、すべてのCore Web Vitalsに合格しているサイトが、不合格のサイトよりも平均ランキング位置が24%高かったことが判明しました。そのギャップは広がっています。
クライアントにとって、測定可能な改善が見られました。あるeコマースブランドは、React SPAからAstroベースのストアフロントへの移行後、オーガニックトラフィックが15%増加しました。彼らのヘッドレスCMSアーキテクチャは同じままでした —フロントエンドがコンテンツを消費およびレンダリングする方法を変更しただけです。
プログレッシブエンハンスメント戦略の構築
ここに従う実践的な戦略があります:
ステップ1:JavaScriptを監査する
新しいものを構築する前に、現在配信しているJavaScriptを見て、次のことを尋ねてください:これはクライアントで実行される必要がありますか?
# Chrome DevTools でJSの使用を確認する快速な方法
# Coverage tab → Reload → 初期ロード時に実際に実行されるJSの量を確認
で、配信されたJavaScriptの40~60%が初期ページロード時に実行されないことを日常的に発見します。それは死んだコード、未使用のポリフィル、またはトリガーされていない機能です。
ステップ2:インタラクティビティを分類する
すべてのインタラクティブな機能を3つのバケットのいずれかに入れます:
- プラットフォームネイティブ —HTML/CSSのみで実行可能(プラットフォームを使用)
- 拡張 —JSなしで機能し、JSあればより良い(プログレッシブエンハンスメント)
- JSが必要 —クライアント側のコードなしでは本当に不可能(配信してください)
自分に正直になってください。ほとんどのものはバケット1または2に属します。
ステップ3:正しいフレームワークを選択する
コンテンツサイト、ドキュメンテーション、マーケティングページ、またはブログを構築している場合 —AstroまたはEleventyに手を伸ばしてください。チームがReactを知っているというだけでマーケティングサイト用にNext.jsを選択しないでください。アーキテクチャの不一致はパフォーマンスの低下につながります。
重大なクライアント側インタラクティビティを持つアプリケーションを構築している場合、選択的なサーバーレンダリングを備えたNext.jsまたはSvelteKitはより理にかなっています。可能な限りServer Componentsを使用し、クライアントコンポーネントは必要な場所でのみ使用します。
チームがこれらの決定を下すのを支援することは私たちが定期的に行っていることです。特定の状況について話し合いたい場合は、お気軽にお問い合わせください。
ステップ4:JavaScriptなしでテストする
これはすべての人がスキップするステップです。ブラウザでJavaScriptを無効にしてサイトを移動してください。機能しますか?ユーザーは以下を実行できますか:
- コンテンツを読む?✓
- ページ間を移動する?✓
- フォームを送信する?✓
- 重要な情報にアクセスする?✓
そうでない場合、拡張戦略に穴があります。
ゼロJSサイトの実世界アーキテクチャ
複数のクライアントプロジェクトで使用した具体的なアーキテクチャを共有してみましょう:
┌─────────────────────────────────────────┐
│ CDN (Cloudflare) │
│ Static HTML/CSS assets │
├─────────────────────────────────────────┤
│ Astro SSG / SSR Layer │
│ Fetches content at build/request │
├─────────────────────────────────────────┤
│ Headless CMS │
│ (Sanity / Storyblok / Payload) │
├─────────────────────────────────────────┤
│ Form Handler Service │
│ (Cloudflare Workers / Resend) │
└─────────────────────────────────────────┘
コンテンツはヘッドレスCMSに住んでいます。Astroはビルド時(またはコンテンツの更新頻度が高い場合はリクエスト時)にコンテンツをプルしています。出力は純粋なHTMLとCSSで、CDNエッジにデプロイされます。フォームはサーバーレス関数に送信されます。検証とメール配信を処理します。
フロントエンド全体にはゼロJavaScriptがあります。CMS はコンテンツエディタに優れたエクスペリエンスを提供します。フォームはクライアント側のコードなしで機能します。ページ遷移はクロスドキュメント View Transitions を使用します。高速で、アクセス可能で、回復力があります。
選択的なインタラクティビティが必要なサイトの場合 —製品コンフィギュレータを1ページに言う —Astroのアイランドアーキテクチャを使用して、そのコンポーネントだけをハイドレートしています。サイトの残りの部分は静的なままです。
これは私たちが定期的に構築するアーキテクチャの種類です。このアプローチの価格設定に興味がある場合は、料金ページをご覧ください —ゼロJSサイトは通常、より速く構築でき、ホストするのがより安いです。
FAQ
2026年でもプログレッシブエンハンスメントはまだ関連がありますか?
これまで以上に関連があります。Popover API、CSS :has()、View Transitions、および <dialog> に対して95%以上のブラウザサポートがある場合、ウェブプラットフォームは以前にJavaScriptが必要だったインタラクティビティを処理できます。プログレッシブエンハンスメントは過去からの哲学ではありません —それはより速く、より回復力があり、より素アクセス可能なウェブサイトをもたらす実践的なエンジニアリング戦略です。
JavaScriptなしで完全なウェブサイトを構築できますか?
絶対に。マーケティングサイト、ブログ、ドキュメンテーション、ポートフォリオ、さらにはeコマースストアフロントもクライアント側JavaScriptなしで構築できます。フォームはネイティブに送信し、ナビゲーションは標準リンクを使用し(View Transitionsでポーランド)、インタラクティブなコンポーネント(アコーディオン、モーダル、ツールチップ)はすべてHTML/CSSネイティブソリューションを持ちます。JSなしで構築できないサイトはリアルタイムアプリ、リッチテキストエディタ、および複雑なデータ可視化です。
ゼロJavaScriptはSEOにどのような影響を与えますか?
ほぼすべての場合において肯定的です。検索エンジンはJavaScript実行を待たずにHTMLコンテンツを即座にインデックスできます。Core Web Vitals スコアは劇的に改善します —特にTotal Blocking Time、ゼロに低下します。Googleのランキングシステムは高速でアクセス可能なページに報酬を与え、ゼロJSサイトは一貫してLighthouseスコアが高く、CWV合格率が良くなります。
2026年のゼロJavaScriptウェブサイトに最適なフレームワークは何ですか?
Astroは、ほとんどのゼロJSプロジェクトに最強の選択肢です。デフォルトではゼロJavaScriptを出力し、必要に応じてコンポーネント単位でクライアント側インタラクティビティを追加できます。Eleventyはシンプルなサイトにとってもう1つの優れた選択肢です。どちらも成熟したエコシステム、優れたドキュメンテーション、およびアクティブなコミュニティを持っています。選択は通常、コンポーネントベースのオーサリング(Astro)またはテンプレートベースの単純性(Eleventy)を望むかどうかを下ります。
CSS のみのインタラクティブコンポーネントはアクセシビリティに対応していますか?
<details>、<dialog>、Popover APIなどのネイティブHTML要素は、デフォルトでアクセス可能です —フォーカス管理、キーボードナビゲーション、およびARIAセマンティクスを自動的に処理します。チェックボックスハックを使用するCSSのみのパターンにはより多くの注意が必要です。適切なARIAロールを追加し、キーボード操作を確認する必要があります。一般に、ネイティブHTMLソリューションはカスタムJavaScript実装よりもアクセス可能です。ブラウザベンダーはあなたのためにアクセシビリティの仕事をしているからです。
Cross-document View Transitions はJavaScriptなしでどのように機能しますか?
Cross-document View Transitions(仕様のLevel 2)は、CSSを通じて完全に機能します。@view-transition { navigation: auto; } ルールを追加すると、ブラウザはページナビゲーション間で自動的にアニメーション遷移を作成します。::view-transition-old() および ::view-transition-new() 疑似要素でアニメーションをカスタマイズできます。JavaScriptは不要です。Chrome、Edge、およびSafariは2026年でこれをサポートしており、Firefoxサポートは間もなく予定されています。
JavaScriptが無効にされているユーザーの割合はどのくらいですか?
JavaScriptを積極的に無効にしているユーザーは約1~2%だけです。しかし、それが問題ではありません。JavaScriptが有効になっているにもかかわらず、多くのユーザーがJavaScript強化を得られていません —不安定な接続、企業ファイアウォール、ブラウザ拡張機能、CDN障害、および解析エラーはすべてJSの失敗を引き起こします。英国政府デジタルサービスは、JSが有効でも、1.1%のユーザーがJavaScript強化を得られていないことを発見しました。プログレッシブエンハンスメントはこれらすべてのユーザーを保護します。
ヘッドレスCMSをゼロJavaScriptフロントエンドで使用できますか?
はい、これは最高の組み合わせの1つです。CMSはコンテンツチームに豊富な編集エクスペリエンスを提供し、フロントエンド(AstroまたはEleventyで構築)はビルド時にAPIを介してコンテンツを消費し、純粋なHTML/CSSを出力します。CMS JavaScriptはエディタのブラウザで実行され、訪問者のブラウザでは実行されません。この分離により、最良の両方の世界が得られます。優れたオーサリング体験とエンドユーザーのゼロJSパフォーマンス。