ウェブサイト速度最適化 2026 — Core Web Vitals 90+ 達成法
从速度、质量、隐私和移动端体验四个维度比较免费图片压缩服务，重点覆盖批量速度、清晰度、隐私策略和移动端体验差异，用于发布前的选型依据。内容适用于博客、详情页和社媒素材的实际发布流程。
> **要点まとめ** 2026年時点のGoogle Core Web Vitals(コアウェブバイタル)は、LCP(最大コンテンツの描画)< 2.5秒、INP(次の描画までのインタラクション)< 200ms、CLS(累積レイアウトシフト)< 0.1が基準です。この3指標はGoogleのSEOランキングシグナルに直接関わります。特に効果が大きい施策は、① WebP/AVIFへの画像変換 ② フォントのpreload ③ JavaScriptバンドルのコード分割 ④ CDN設定。Next.jsを使っている場合は、標準機能を正しく使うだけでも90+を十分に狙えます。
Core Web Vitalsとは? Core Web Vitals(コアウェブバイタル)は、Googleがユーザー体験を評価するために定めた3つの主要なパフォーマンス指標です。2021年以降、SEOランキングシグナルとしても使われています。
3つのコア指標 | 指標 | 正式名称 | 測定対象 | 良好 | 改善が必要 | 不良 |
|---|---|---|---|---|---|
| **LCP** | Largest Contentful Paint | 最大コンテンツ(画像・テキスト)の描画時間 | < 2.5秒 | 2.5〜4秒 | > 4秒 |
| **INP** | Interaction to Next Paint | ユーザーのクリック/タップ後の画面反応時間 | < 200ms | 200〜500ms | > 500ms |
| **CLS** | Cumulative Layout Shift | 読み込み中の予期しないレイアウトの移動 | < 0.1 | 0.1〜0.25 | > 0.25 | ※ FID(First Input Delay)は2024年にINPへ置き換えられました。
なぜCore Web Vitalsが重要なのか? - **SEOへの直接的な影響**: Googleのランキングアルゴリズムに含まれており、コンテンツの質が同等なら、パフォーマンスの高いサイトが評価されやすくなります
**ユーザー離脱**: LCPが3秒を超えると、モバイルの離脱率は53%増加します(Google調査)
**広告収益**: AdSense RPMはページ滞在時間と連動しやすいため、速いサイトほど収益面でも有利です
**コンバージョン率**: ECサイトでは1秒の遅延でコンバージョン率が7%低下するとされています(Akamai調査)
LCP最適化(最大コンテンツの描画) LCPは、多くの場合、ヒーロー画像や大きなテキストブロックの読み込み時間に左右されます。
画像最適化(最も効果が大きい方法) #### WebP/AVIF形式の使用 | 形式 | 容量削減 | ブラウザ対応 |
|---|---|---|
| JPEG | 基準 | 100% |
| WebP | 25〜35%削減 | 98%+ |
| AVIF | 40〜50%削減 | 90%+(2026年基準) |
<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" alt="ヒーロー画像" width="1200" height="628" loading="eager">
</picture>
#### Next.js Imageコンポーネントの活用 // next/imageはWebP/AVIF自動変換 + 遅延読み込み + サイズ最適化
import Image from 'next/image' // LCP対象画像:priority属性が必須
<Image src="/hero.jpg" alt="ヒーロー画像" width={1200} height={628} priority // LCP画像には必ずpriorityを追加 quality={85}
/>
LCPリソースのpreload
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<link rel="preload" as="font" href="/fonts/main.woff2" type="font/woff2" crossorigin>
サーバー応答時間の短縮(TTFB) | 方法 | 効果 | 実装方法 |
|---|---|---|
| **CDNの利用** | 世界中のエッジでキャッシュ | Cloudflare、Vercel Edge |
| **キャッシュヘッダー** | 再訪問時の読み込みを高速化 | Cache-Control: max-age=31536000 |
| **サーバーサイドキャッシング** | DBクエリ結果をキャッシュ | Redis、Cloudflare KV |
INP最適化(インタラクション反応時間) INPは、クリック・タップ・キーボード入力のあと、ブラウザが次の画面を描画するまでにかかる時間を測る指標です。
JavaScript実行の最適化 #### メインスレッドのブロッキングを減らす // ❌ 悪い例:重い同期処理がクリックハンドラ内にある
button.addEventListener('click', () => { const result = heavyComputation(data) // メインスレッドをブロック updateUI(result)
}) // ✅ 良い例:Web Workerにオフロード
const worker = new Worker('heavy-worker.js')
button.addEventListener('click', () => { worker.postMessage(data) // 別スレッドで処理
})
worker.onmessage = (e) => updateUI(e.data)
#### イベントハンドラの最適化 // Debounceで過度なイベント呼び出しを防ぐ
function debounce(fn, delay) { let timer return (...args) => { clearTimeout(timer) timer = setTimeout(() => fn(...args), delay) }
} // スクロール・resizeなど頻繁に発生するイベントに適用
window.addEventListener('resize', debounce(handleResize, 100))
JavaScriptバンドルの最適化 #### Code Splitting(コード分割) // Next.js:dynamic importで遅延ロード
import dynamic from 'next/dynamic' // ファーストビューに表示されないコンポーネントは遅延ロード
const HeavyChart = dynamic(() => import('./HeavyChart'), { loading: () => <div>チャート読み込み中...</div>, ssr: false // クライアント専用ならSSRをオフに
})
#### Tree Shaking // ❌ 悪い例:lodash全体をインポート(70KB+)
import _ from 'lodash'
const result = _.chunk(array, 3) // ✅ 良い例:必要な関数のみインポート(1KB)
import chunk from 'lodash/chunk'
const result = chunk(array, 3)
CLS最適化(累積レイアウトシフト) CLSは、広告・画像・動的コンテンツなどが読み込み中に表示位置をずらすことで発生します。
画像・動画のサイズを明示
<img src="photo.jpg" width="800" height="600" alt="写真">
<img src="photo.jpg" alt="写真">
広告スペースの予約 /* 広告コンテナに最小高さを予約 */.ad-container { min-height: 250px; /* 広告領域を事前確保 */ display: flex; align-items: center; justify-content: center;
}
フォント読み込みの最適化 /* font-display: swap → フォント読み込み前にシステムフォントでテキストを即座に表示 */
@font-face { font-family: 'MyFont'; src: url('/fonts/myfont.woff2') format('woff2'); font-display: swap; /* optionalも検討(CLSがさらに低い) */
}
実戦最適化チェックリスト
Lighthouse 90+達成のための30項目チェックリスト **LCP関連(10項目)**
[ ] LCP要素を特定(DevTools → Performanceタブ)
[ ] LCP画像 → priorityまたはpreloadを適用
[ ] ヒーロー画像をWebP/AVIFに変換
[ ] next/imageを使用(自動最適化)
[ ] 画像サイズをsrcsetでレスポンシブ提供
[ ] CDNの利用(Cloudflare Pages、Vercel Edge)
[ ] TTFB < 600msを確認
[ ] サーバーサイドキャッシング(ISR/SSGを優先)
[ ] 不要なリダイレクトを削除
[ ] サードパーティスクリプトを遅延読み込みにする **INP関連(10項目)**
[ ] Lighthouse → INPスコアを確認
[ ] Long Tasks(50ms+)を排除 → DevTools Performanceタブ
[ ] 重い計算 → Web Workerへ移行
[ ] JavaScriptバンドルサイズ < 200KB(圧縮ベース)
[ ] 不要なポリフィルを削除
[ ] React:useMemo/useCallbackで最適化
[ ] イベントハンドラにDebounce/Throttleを適用
[ ] アニメーションはCSS transitionを使用(JSアニメーションは避ける)
[ ] サードパーティスクリプトにasync/defer属性を追加
[ ] Largest Contentful関連のJS実行順序を最適化 **CLS関連(10項目)**
[ ] すべての画像・動画にwidth/heightを明示
[ ] 広告コンテナに最小高さを予約
[ ] 動的に挿入されるコンテンツ → 最下部に配置
[ ] フォント → font-display: swapを適用
[ ] フォントpreloadタグを追加
[ ] transform/opacityのみを使うアニメーション(レイアウト変更を避ける)
[ ] skeleton loaderでコンテンツスペースを事前確保
[ ] sticky/fixed要素がコンテンツを押し下げないか確認
[ ] 無限スクロール → コンテンツ挿入時にユーザー位置を維持
[ ] タブ切り替えアニメーション → overflow: hiddenで高さを固定
計測ツール | ツール | 用途 | アクセス方法 |
|---|---|---|
| **PageSpeed Insights** | LCP/INP/CLSの実数値 | pagespeed.web.dev |
| **Lighthouse** | 総合パフォーマンススコア | Chrome DevTools → Lighthouse |
| **WebPageTest** | 世界各地点での計測 | webpagetest.org |
| **Chrome DevTools** | 詳細プロファイリング | F12 → Performanceタブ |
| **Core Web Vitals Report** | 実ユーザーデータ(CrUX) | Search Console → Core Web Vitals |
ツールリンク - [ページ速度計測ツール](/tools/page-speed) — 自分のサイトのLighthouseスコアを確認
[メタタグ検査ツール](/tools/meta-checker) — SEOメタタグの状況をチェック
FAQ
Q1. Core Web Vitalsの改善はSEO順位にどのくらい影響しますか?
A: GoogleはCore Web Vitalsを「Tiebreaker(同点時の決定要素)」と説明しています。コンテンツの品質が同等であれば、パフォーマンスに優れたサイトが優先されやすくなります。直接的な重み付けは公開されていませんが、モバイルページエクスペリエンス(Mobile Page Experience)には明確に関わります。実務上も、LCP 4秒+のサイトと2秒未満のサイトではランキング差が確認されています。
Q2. Lighthouseスコア90+とCore Web Vitals合格は同じ意味ですか?
A: 同じではありません。Lighthouseスコアはシミュレーション環境で測るラボデータで、Core Web Vitals(CWV)は実際のユーザーデータ(Field Data / CrUX)に基づきます。Lighthouseで100点を取っていても、実ユーザー環境ではLCPが悪いケースがあります。SEOへの影響を見るうえでは、Google Search ConsoleのCore Web Vitalsレポートを確認するのが重要です。
Q3. Next.jsを使えば自動的にパフォーマンスが良くなりますか?
A: ある程度は改善されます。Next.jsは画像最適化(next/image)、フォント最適化(next/font)、コード分割、SSG/ISRなどを標準で提供しています。ただし、priority設定、不要なサードパーティスクリプトの削除、画像サイズの明示などは開発者側で正しく実装する必要があります。標準機能をきちんと使うだけでも、Lighthouse 85〜95+は十分に狙えます。
Q4. 画像をWebPに変換すると画質は落ちますか?
A: 適切な品質設定(quality=80〜90)であれば、肉眼ではほとんど差が分かりません。WebPは同等画質のJPEGに比べてファイルサイズを25〜35%小さくできます。AVIFはさらに圧縮率が高い一方で、エンコードに時間がかかります。オンラインツール(Squoosh、Cloudinary)やnext/imageを使えば、自動変換も可能です。
Q5. CLSスコアがすぐに0.1を超えてしまうのですが、原因はどう特定しますか?
A: Chrome DevTools → Performanceタブで録画し、「Layout Shift」の項目を確認します。PageSpeed Insightsの「Avoid large layout shifts」診断でも、どの要素が動いているかを確認できます。主な原因は、① サイズ未指定の画像 ② 広告読み込み時のレイアウトシフト ③ フォント切り替え(FOUT) ④ 動的コンテンツの挿入です。
Q6. サードパーティスクリプト(Google Analytics、Hotjarなど)はパフォーマンスにどのくらい影響しますか?
A: 影響はかなり大きいです。一般的に、サードパーティスクリプトによってLighthouseスコアが10〜20点下がることがあります。Google Analytics 4(GA4)はasync読み込みに対応しているため比較的影響は小さいものの、Hotjarやインターコムのような重いスクリプトはINPを大きく悪化させます。next/scriptのstrategy="afterInteractive"または"lazyOnload"で遅延読み込みを適用してください。
Q7. モバイルのLCPがデスクトップより常に遅いのですが、どう改善しますか?
A: モバイルはネットワーク速度(3G〜4G)やCPU性能の制約があるため、LCPが遅くなりやすい環境です。改善策は、① ヒーロー画像のモバイル専用小型バージョンを提供(srcset) ② モバイルで不要な画像を非表示 ③ CSSをインライン化してクリティカルパスを最適化 ④ CDNエッジでHTMLをキャッシュ、などです。目標はモバイルでもLCP < 2.5秒です。
Q8. Cloudflareを使うとCore Web Vitalsは自動的に改善されますか?
A: Cloudflare CDNを使うとTTFB(サーバー応答時間)が短くなり、LCP改善に役立ちます。特に韓国以外の地域からの訪問者に対しては、エッジキャッシングの効果が大きく出ます。さらに、Cloudflareの自動ミニファイ(JS/CSS/HTML)、Rocket Loader(JS遅延)、Polish(画像圧縮)を有効にすれば、追加のパフォーマンス改善も期待できます。