本ページはプロモーション（広告）が含まれています

最近、フロントエンドの選択肢は豊富すぎて、正直しんどいです。最前線で活躍しているエンジニアの方々は化け物か？と思います。
「とりあえず Next.js」という空気もまだありますが、“読む体験が主役”のサイトでは、Astroのほうが近道になる場面が増えていると考えてます。

AstroはHTMLで完成させて配り、必要なところだけJSを載せる（Islands Architecture）という思想のフレームワークです。
これにより初回表示が軽く、検索エンジンや支援技術にも優しい土台を作りやすく、コードも素直にまとまります。

つまり、コーポレートサイト、LP、ブログ、ドキュメントなど、「読ませる」領域に強いということです。
一方で、単一画面で状態が複雑に回る大型SPAは、Next.js / SvelteKit / Nuxt / Remixといった“アプリの本職”が得意です。
目的に合わせて道具を選ぶのが、心身ともに健やかです。

“0 JS by default”が効く
成果に直結する“標準装備”：画像・プリロード・コンテンツ管理
React/Vue/Svelteの“混在”OK：資産を捨てない移行
置き場所の自由度：静的/SSR/Edgeをアダプターで切替
DXが軽い：Viteベースの高速HMRと.astroの素直さ
こういう案件に向いている（採用チェックリスト）
向かない／工夫が必要なケース（正直に）
実装で感じた“良かった点”：スコアと運用の両立
スニペット集（実務で使ったもの）
導入の最短ルート（コマンドだけでOK）
ディレクトリ運用
段階移行の作戦
よくある質問（FAQ）
付録：最小レイアウト（抜粋）
まとめ
参考リンク

“0 JS by default”が効く

Astroは基本、サーバ（あるいはビルド時）でHTMLを作り切るので、JSを書かなければ本当に0KBで配れます。
必要なUIだけを島（island）としてReact/Vue/Svelte等で水和し、client:visible などの指示子で「いつロードするか」まで制御できます。

これにより、初回ダウンロードと実行コストを最小化できます。
LCP（最大視覚コンテンツの描画）やINP（総合的な応答性）にも好影響が出やすく、特にテキスト中心のページで“効き目”を体感しやすいはずです。

「島って何？」の最短ルートは公式の概念ページがわかりやすいです。
また、AstroがデフォルトでJSランタイムを持たないという点は、クラウドフレアの公式ガイドにも明記されています。

成果に直結する“標準装備”：画像・プリロード・コンテンツ管理

Astroにはastro:assetsの画像最適化が入っています。
<Image /> や getImage() を使えば、AVIF/WebP/JPEGの最適生成やレスポンシブ対応が素直に書けます。
「ヒーロー画像が重い問題」を小さな手間で抑えられるのが実務ではありがたいです。

さらに、<img fetchpriority="high"> や <link rel="preload" as="image"> を併用してLCP画像の取得を優先させると、LCPのブレを小さくできます。
fetchpriority はブラウザに「この画像、最優先で」と伝えるヒントです。仕様はMDNがまとまっています。

Markdown/MDXはContent Collections（中でZodを使用）で型付き管理が可能です。
フロントマターの崩れをビルドで検知できるので、「なんで落ちた？」が減ります。
記事を大量に抱えるドキュメントやメディアで特に効きます。

React/Vue/Svelteの“混在”OK：資産を捨てない移行

AstroはUIフレームワーク非依存で、React/Preact/Vue/Svelte/Solidなどを同一プロジェクト内で共存できます。
既存パーツを必要箇所だけ“島”として移植し、点から面へ段階的に移行する戦略が取りやすいです。

「全部Astroに乗せ替え」ではなく、痛みの少ない部分から差し替える。
この堅実さは、チームの心理的安全性にも効きます。

置き場所の自由度：静的/SSR/Edgeをアダプターで切替

基本は静的配信（SSG）で高速・低運用。
必要に応じてオンデマンドレンダリング（SSR）や各社のEdge環境に切り替えることもできます。
Vercel / Netlify / Cloudflare / Node向けアダプターが整備されており、LPから中〜大規模サイトまでスコープを広げやすいです。

DXが軽い：Viteベースの高速HMRと.astroの素直さ

開発サーバはViteベースでHMRが高速です。
.astro はHTMLに近い記法なので、“まずマークアップを完成→必要な箇所だけJS”という健康的な流れが自然に身につきます。

HMRや開発体験の背景は、Astro CLIリファレンスとViteのドキュメントがまとまっています。
チームのスピード感に関わるので、軽視しないほうが得です。

こういう案件に向いている（採用チェックリスト）

ページ数が多い／読ませる時間が長い（コーポレート／メディア／ドキュメント／ブログ）。
LCP・CLSの安定が“土台から”作りやすいです。画像最適化＋プリロードが素直に効いてきます。
既存のReact/Vueパーツを生かしたい。
島として必要箇所から差し込んでいけるため、大移行より点移行が現実的です。
サイトマップや画像など、標準的な運用を最小の設定で回したい。
@astrojs/sitemap が用意されています。
SEOやアクセシビリティの初速をとりたい。
サーバ側でHTMLを作るため、クローラや支援技術に優しい初期状態を出しやすいです。これは“速さ”と同じくらい重要です。

向かない／工夫が必要なケース（正直に）

単一画面で巨大な状態管理（ドラッグ＆ドロップ、リアルタイム連携、多層バリデーションの大量フォーム）。
ここはNext.js / SvelteKit / Nuxt / Remixといったフルスタック系が素直です。NextのApp Router + Server Componentsは“アプリ”の文脈で真価を発揮します。
島同士の濃い相互通信。
グローバルストアやURL設計でまとめられますが、部分水和の前提を理解した設計力が要ります。
迷うなら、まずは島間の依存を薄く保つ構成から。

実装で感じた“良かった点”：スコアと運用の両立

Lighthouseで安定して高得点に乗せやすい

Best Practicesで指摘されがちな“外部リンクの安全性”は、target="_blank" に rel="noopener noreferrer" を添えるだけで解決します（これはこれでどうなの？とは思いますが）。
Lighthouseの該当監査とMDNの解説が一次情報としてわかりやすいです。

LCPが安定しやすい

astro:assets による最適化＋fetchpriority／<link rel="preload" as="image">の併用で、LCP画像の到着が早く安定しました。
体感としても安心感があります。

INP（総合応答性）の考え方に合う

INPは2024年にFIDを置き換えた安定版のCore Web Vitalです。
Astroは“初期JSを最小にする”ので、不要な実行負荷が減り、入力応答の悪化要因を避けやすいです。
もちろん設計と実装の質が前提ですが、土台として相性は良好です。

ダークモードはOKLCHトークンで軽く

色はOKLCHでCSS変数を切っておくと、明暗切替でもコントラストと一貫性を保ちやすいです。
「なぜOKLCHが扱いやすいのか」はMDNと解説記事が参考になります。

CSS運用の型がハマる

グローバルは最小限（tokens/base/utilities）＋見た目は各 .astro の <style> に閉じる運用だと、ページ単位で最小CSSができます。
“まずHTMLを完成→島を足す”というAstroの流儀と噛み合って、保守もしやすいです。

整形とテストの軽量オーケストレーション

Biomeで整形＆静的解析、Playwrightでスモーク（コンソールエラーやナビ開閉など）を回すと、目に見えないほころびを早めに拾えます。
どちらもドキュメントが充実していて導入障壁が低いのが良いところです。

スニペット集（実務で使ったもの）

“島”として必要時だけ水和（client:visible）

---
// Counter.jsx を“島”として必要時だけ水和
import Counter from '../components/Counter.jsx';
---
<article>…本文は静的にレンダリング…</article>
<Counter client:visible />   <!-- スクロールで見えたらJSロード -->

指示子のリファレンスは公式にまとまっています。
client:load / :idle / :visible / :media / :only など。

ヒーロー画像（最適化＋高優先度）

<Image
  src={hero}
  alt="ヒーロー"
  widths={[480, 768, 1200]}
  formats={['avif','webp','jpeg']}
  sizes="100vw"
  loading="eager"
  fetchpriority="high"
/>

画像最適化は astro:assets、優先度ヒントは fetchpriority。

LCPプリロード（レイアウト側）

{preloadWebp && (
  <link rel="preload" as="image" href={preloadWebp}
        imagesrcset={`${preloadAvif} 1200w, ${preloadWebp} 1200w`}
        imagesizes="100vw" fetchpriority="high" />
)}

外部リンクの安全化（SafeLinkの中身）

export const SafeLink = (props) => (
  <a {...props} rel="noopener noreferrer" />
);

LighthouseのBest Practices対策として定番。

導入の最短ルート（コマンドだけでOK）

# 新規
pnpm create astro@latest
pnpm dev

# 画像最適化（sharp）
pnpm add sharp
pnpm approve-builds   # pnpm v10系
pnpm rebuild
pnpm install

# 整形＆テスト（任意）
pnpm add -D @biomejs/biome
pnpm run lint                 # = biome check --write .
pnpm exec playwright test

sharp は高速な画像処理ライブラリ、pnpm approve-builds はv10で入ったビルド承認フローです。
Playwright/Biomeの導入手順は公式が簡潔です。

ディレクトリ運用

src/
├─ assets/          # 画像（astro:assets）
├─ components/      # UIやブロック（各 .astro に <style> を同居）
├─ layouts/         # Base/SEO/プリロード集約
├─ pages/           # ルーティング
├─ scripts/         # 共通の小粒JS（nav.ts等）
└─ styles/          # tokens/base/utilities(+themes)

“グローバル最小＋見た目は各コンポーネントに閉じる”で、ページ単位の最小バンドルを狙います。
Astroの思想と噛み合うため、保守と改修のコストが読みやすいです。

段階移行の作戦

現行WPをヘッドレス化し、Astroでフロントを作る（REST/GraphQL/SDK）。
既存React/Vueの部品を“島”として必要箇所だけ移植。
管理画面やWebアプリはNext/SvelteKit等を別ホストで運用し、公開サイトはAstroに分離。

“全部載せ替え”ではなく、痛くないところから確実に。
混在を許容する設計がAstroの強みです。

よくある質問（FAQ）

Q. SSRや動的ページはできる？
A. 可能です。アダプターでNode/Edgeに対応し、静的とSSRを混在できます。
ただし巨大Webアプリを全部Astroで…は本職領域ではないので、サイトはAstro／アプリは専用フレームワークの分離が現実的です。

Q. 画像最適化でネイティブ依存が不安
A. sharp が必要です。CI/CDで一度通してキャッシュすれば安定します。

Q. 将来の保守は？
A. HTML中心＋グローバル最小で差分を追いやすく、島ごとの独立性で部分更新がやりやすいです。
設計のクセが“素直”なのが結局のコスト削減になります。

付録：最小レイアウト（抜粋）

---
// src/layouts/Base.astro
import { getImage } from 'astro:assets';
import '../styles/tokens.css';
import '../styles/base.css';
import '../styles/utilities.css';
const { title='サイト', description='説明', image, preloadImage, preloadWidth=1200 } = Astro.props;

let preloadAvif, preloadWebp;
if (preloadImage) {
  const [avif, webp] = await Promise.all([
    getImage({ src: preloadImage, format: 'avif', width: preloadWidth }),
    getImage({ src: preloadImage, format: 'webp', width: preloadWidth }),
  ]);
  preloadAvif = avif.src; preloadWebp = webp.src;
}
---
<!doctype html><html lang="ja"><head>
  <meta charset="utf-8" /><meta name="viewport" content="width=device-width, initial-scale=1" />
  <title>{title}</title><meta name="description" content={description} />
  {preloadWebp && (<link rel="preload" as="image" href={preloadWebp}
    imagesrcset={`${preloadAvif} 1200w, ${preloadWebp} 1200w`} imagesizes="100vw" fetchpriority="high" />)}
</head><body>
  <a href="#main" class="skip">メインへ</a>
  <main id="main"><slot /></main>
</body></html>