GoogleがCore Web Vitals（CWV）をランキング要因に組み込んで以降、Webパフォーマンスの最適化はSEOの観点からも無視できなくなりました。しかし、パフォーマンス改善は単にSEOのためだけではありません。ページの表示速度が1秒遅くなるとコンバージョン率が7%低下するというデータもあり、ビジネスに直結する課題です。
筆者が複数のプロダクトでCWV改善に取り組んだ経験から、実際に効果が高かった7つの手法を具体的なコード例とともに解説します。
Core Web Vitalsは以下の3つの指標で構成されています。
LCP改善に最も効果的なのが画像の最適化です。WebPやAVIFなどの次世代フォーマットへの変換と、適切なLazy Loadingの組み合わせが鍵となります。
入会申込
ログイン<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="ヒーロー画像"
width="1200" height="600"
loading="eager"
fetchpriority="high">
</picture>
<!-- ファーストビュー外の画像 -->
<img src="thumbnail.webp" alt="サムネイル"
width="400" height="300"
loading="lazy"
decoding="async">重要なのは、LCP要素となるヒーロー画像にはloading="eager"とfetchpriority="high"を指定することです。逆にファーストビュー外の画像にはloading="lazy"を設定して不要なリクエストを遅延させます。また、widthとheight属性を必ず指定してCLSの発生を防ぎましょう。
初期描画に必要なCSSをインライン化し、残りのCSSを非同期で読み込む手法は、LCPの改善に非常に有効です。
<head>
<style>
/* クリティカルCSS：ファーストビューに必要な最小限のスタイル */
body { margin: 0; font-family: sans-serif; }
.header { background: #1a1a2e; color: white; padding: 1rem; }
.hero { max-width: 1200px; margin: 0 auto; }
</style>
<link rel="preload" href="/css/main.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/main.css"></noscript>
</head>クリティカルCSSの抽出には、CrittersやCritical CSSといったツールが便利です。ビルドパイプラインに組み込むことで、自動的にクリティカルCSSを抽出できます。
JavaScriptのバンドルサイズはINPに直接影響します。動的インポートを活用したコード分割が基本戦略です。
// ルートベースのコード分割（React）
import { lazy, Suspense } from 'react';
const Dashboard = lazy(() => import('./pages/Dashboard'));
const Settings = lazy(() => import('./pages/Settings'));
function App() {
return (
<Suspense fallback={<LoadingSpinner />}>
<Routes>
<Route path="/dashboard" element={<Dashboard />} />
<Route path="/settings" element={<Settings />} />
</Routes>
</Suspense>
);
}加えて、サードパーティスクリプトは可能な限りasyncまたはdefer属性を付与して読み込みます。Google Analyticsやタグマネージャーなど、メインスレッドをブロックしがちなスクリプトは特に注意が必要です。
Webフォントの読み込みはCLSとLCPの両方に影響します。以下の対策を組み合わせることで、フォント起因のパフォーマンス低下を防げます。
/* font-displayの設定 */
@font-face {
font-family: 'NotoSansJP';
src: url('/fonts/NotoSansJP-Regular.woff2') format('woff2');
font-display: swap;
font-weight: 400;
unicode-range: U+3000-9FFF;
}<!-- プリロードで先行取得 -->
<link rel="preload" href="/fonts/NotoSansJP-Regular.woff2"
as="font" type="font/woff2" crossorigin>日本語フォントは特にファイルサイズが大きいため、unicode-rangeによるサブセット化が効果的です。使用する文字範囲を限定することで、フォントファイルのサイズを大幅に削減できます。
ブラウザに事前情報を与えるリソースヒントは、適切に使えば体感速度を劇的に向上させます。
<!-- DNS事前解決 -->
<link rel="dns-prefetch" href="//api.example.com">
<!-- 接続の事前確立 -->
<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<!-- 次のページのプリフェッチ -->
<link rel="prefetch" href="/next-page.html">preconnectはDNS解決、TCP接続、TLSハンドシェイクを事前に行います。CDNやAPI サーバーなど、確実にアクセスするオリジンに対して設定するのが効果的です。ただし、使いすぎると逆効果になるため、3つ程度に絞ることをお勧めします。
CLSの発生原因は多岐にわたりますが、特に多いのが広告枠、画像、動的コンテンツの挿入です。対策としては、事前にスペースを確保することが基本になります。
/* アスペクト比を保持するコンテナ */
.video-container {
aspect-ratio: 16 / 9;
width: 100%;
background-color: #f0f0f0;
}
/* 広告枠のスペース確保 */
.ad-slot {
min-height: 250px;
width: 300px;
}aspect-ratioプロパティは現在ほぼすべてのモダンブラウザでサポートされており、レスポンシブな要素のレイアウトシフト防止に非常に有効です。
フロントエンドの最適化だけでは限界があります。サーバーレスポンス時間（TTFB）が遅ければ、すべての指標に悪影響が出ます。
# Nginxでの基本的なキャッシュ設定
location ~* \.(js|css|png|webp|avif|woff2)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
location / {
add_header Cache-Control "no-cache";
try_files $uri $uri/ /index.html;
}静的アセットには長期キャッシュを設定し、HTMLにはキャッシュを使わない（ただしCDNでのエッジキャッシュは活用する）のが基本戦略です。さらに、CDNの導入とHTTP/2の有効化は、ほぼすべてのWebサイトで効果があります。
パフォーマンス改善は一度やって終わりではありません。新機能の追加やコンテンツの変更により、いつでも劣化する可能性があります。Lighthouse CIをCI/CDパイプラインに組み込み、パフォーマンスバジェットを設定することで、劣化を早期に検知できる体制を整えましょう。
7つの手法すべてを一度に実施する必要はありません。まずはPageSpeed InsightsやChrome DevToolsのLighthouseで現状を計測し、最もスコアの低い指標から優先的に対策することが重要です。筆者の経験では、画像最適化とクリティカルCSSの対応だけでLCPが40%以上改善したケースもあります。地道な改善の積み重ねが、最終的にユーザー体験とビジネス成果の向上につながります。
