ページ速度最適化

画像が最適化されていない

JPEGやPNGをそのままアップロードしているケースが最も多い問題です。WebP変換・サイズリサイズ・遅延読み込みの3点セットが未実装だと、LCPが3〜5秒以上になることは珍しくありません。

JavaScriptバンドルが大きすぎる

未使用のライブラリを含んだまま全ページで読み込んでいると、JavaScriptのパースと実行でメインスレッドが長時間ブロックされます。バンドルサイズが1MB超の場合はコード分割が急務です。

サーバーレスポンス（TTFB）が遅い

動的ページでデータベースクエリやAPI呼び出しに時間がかかっているケースです。CDNキャッシュが効いていない・サーバーが遠い・クエリが最適化されていないことが主な原因です。

レンダリングブロックリソースがある

headタグ内にasync/deferなしのscriptタグや大きなCSSファイルがあると、ブラウザがページ描画を開始できません。Lighthouseの「Eliminate render-blocking resources」警告が出ている場合は優先的に対応します。

CDNを使っていない

単一のオリジンサーバーから全ユーザーにコンテンツを配信していると、地理的な距離によるレイテンシーが発生します。国内ユーザー向けでも日本国内のエッジノードからの配信でTTFBを200ms以下に短縮できます。

フォントの読み込みが遅い

Google Fontsから複数のフォントファイルを読み込んでいる場合、外部DNSルックアップとファイル取得の待機時間が発生します。next/fontへの移行やpreconnect設定で大幅に改善できます。

画像・iframeにwidth/heightがない

画像やiframeのサイズが未指定だとブラウザはスペースを確保できず、読み込み完了後にレイアウトが動きます（CLS）。全ての画像にwidth・heightを必ず指定するか、aspect-ratioを使います。

サードパーティスクリプトが多すぎる

タグマネージャー・チャットウィジェット・ABテストツール・ヒートマップなどが重複・累積することで、初期読み込みが大幅に遅くなります。各スクリプトの遅延読み込み化と不要なタグの削除が必要です。

Webフォントが多すぎる・バリアントが多い

デザインのために複数のウェイト（100・300・400・700・900）や複数の書体を読み込んでいると、合計ファイルサイズが数百KBになります。使用するウェイトを2〜3種類に絞ることが重要です。

ファーストビュー画像にlazyが設定されている

LCP要素（ファーストビューのメイン画像）にloading="lazy"を設定すると、ブラウザが表示領域に入るまで読み込みを遅らせるため、LCPが悪化します。ファーストビュー画像にはpriorityを設定し、スクロール後の画像にのみlazyを使います。

PageSpeed Insightsで現状スコアを計測する

pagespeed.web.dev にURLを入力し、モバイル・PCそれぞれのスコアを記録します。「Opportunities」（改善機会）と「Diagnostics」（診断）のセクションを確認し、スクリーンショットを保存して改善前後の比較に使います。フィールドデータ（実ユーザーのデータ）がある場合は、ラボデータと合わせて確認します。

Chrome DevToolsのNetworkタブで大きなリソースを特定する

Chrome DevTools（F12）→ Networkタブを開き、ページを読み込みます。「Size」列でソートし、大きなファイル（画像・JS・CSS・フォント）を特定します。1MB超の画像ファイルや数百KBのJSバンドルがあれば、それが最初の改善対象です。

LCP要素を特定しfetchpriorityとpreloadを設定する

Chrome DevToolsのPerformanceタブでLCP要素を特定します（Timingsセクションに表示されます）。LCP要素が画像の場合、Next.jsでは`<Image priority>`を追加するだけでpreloadが自動適用されます。LCP要素がテキストの場合はWebフォントのpreloadを検討します。

全画像をWebP/AVIFに変換し適切なサイズにリサイズする

Next.jsではnext/imageコンポーネントを使うと自動でWebP変換が行われます。静的な画像はSquoosh（squoosh.app）でWebP変換し、表示サイズの1.5〜2倍の解像度でリサイズします。Retina対応は2xを上限にし、それ以上は過剰です。ファーストビュー以外の画像には必ずloading="lazy"を設定します。

JavaScriptのバンドルサイズを分析し不要なコードを削除する

Next.jsでは`next build`後に`.next/stats.html`（Bundle Analyzerを有効にした場合）でバンドルを可視化できます。`@next/bundle-analyzer`を導入し、大きなライブラリを特定します。momentjsをday.jsに置き換える・lodashを個別インポートにするなど、軽量な代替ライブラリへの移行が効果的です。

サードパーティスクリプトを遅延読み込みに変換する

Google Tag Manager・チャットウィジェット・ヒートマップツールなどを`afterInteractive`または`lazyOnload`のStrategyでNext.jsのScriptコンポーネントを使って読み込みます。絶対に必要なスクリプト以外は`lazyOnload`にし、ページのインタラクティブ性を確保してから読み込みます。

フォントをnext/fontでセルフホスティング化する

Next.jsのnext/fontを使うと、Google Fontsのフォントファイルがビルドジョブでローカルにダウンロードされ、外部リクエストなしでフォントが配信されます。`font-display: swap`が自動設定され、CLSも最小化されます。使用するウェイトは2〜3種類に絞ります。

CDNを設定しHTTPキャッシュヘッダーを最適化する

静的アセット（画像・フォント・CSS・JS）のCache-Controlヘッダーに`max-age=31536000, immutable`を設定します。Next.jsのVercelデプロイでは自動でCDNキャッシュが機能します。オリジンサーバーにはCloudflareを前置することで、追加コストなしでCDNを導入できます。

Google Search ConsoleのCore Web Vitalsで実ユーザーの数値を確認する

改善後は2〜4週間待ちます。Search ConsoleのCore Web Vitalsレポートに実ユーザーのデータが反映されるのに時間がかかるためです。「良好」URLの割合が増加していれば改善が実データに表れています。改善前後の数値を記録しレポートに残します。

継続的なモニタリングとアラートの設定

PageSpeed InsightsのAPIを定期的に叩くか、SpeedCurveやCalibreなどのパフォーマンス監視ツールを導入します。デプロイのたびにLighthouse CIを実行し、スコアが一定以下に落ちたらアラートを出す仕組みを構築することで、パフォーマンスリグレッションを防ぎます。

Core Web Vitals「良好」の割合

Google Search ConsoleのCore Web Vitalsレポートで確認。LCP・CLS・INP全てが「良好」のURLが全体の何割かを追います。改善施策後、4週間以上で変化が現れます。

PageSpeed Insightsのスコア（モバイル・PC）

施策前後のスコアを記録し比較します。モバイルスコアが50未満の場合は70以上を目標に設定し、70以上の場合は90+を目指します。

直帰率（Bounce Rate）の変化

Google Analyticsで速度改善対象ページの直帰率を計測します。LCPが1秒改善されると直帰率が5〜15%程度低下するケースが多く見られます。

TTFBの数値

PageSpeed InsightsのDiagnosticsセクションまたはChrome DevToolsのNetworkタブでServer Response Timeを確認します。800ms以下を目標値とします。

JS・CSS・画像のTransfer Size合計

Chrome DevToolsのNetworkタブでページ合計のTransfer Sizeを確認します。モバイルでは1MB以下、PCでは2MB以下を目標とします（画像が多いページは除く）。

検索順位（Speed改善後4〜8週間後）

Google Search Consoleの検索パフォーマンスレポートで対象ページの平均掲載順位を追います。Core Web Vitals改善が順位に反映されるまで数週間かかるため、継続的な確認が必要です。

コンバージョン率（CVR）の変化

Google Analyticsの目標設定またはGA4のコンバージョンイベントで、改善前後の問い合わせ・購入・申し込み率を比較します。表示速度の改善はCVRに直接影響します。