パフォーマンスとキャッシュ――サイトを速くする仕組みを理解しよう
Cursor や Claude Code を使ってアプリを作ってみると、「動くは動くけれど、なんか遅い」と感じる瞬間が必ずやってきます。ページが表示されるまでに3秒以上かかっていたり、スクロールするとがたつきが起きたり。
そこで今回のテーマはパフォーマンスとキャッシュです。難しそうに聞こえますが、基本の考え方はシンプルです。「同じものを何度も取りに行かない」「必要なものだけ送る」この2つを徹底することで、たいていのサイトは速くなります。
なぜ速さが大事なのか
Googleの調査によると、ページの表示速度が1秒から3秒に伸びると、離脱率は32%増加します。あなたが苦労して作ったサービスも、遅ければ見てもらえないうちに閉じられてしまいます。
また Googleは検索順位の評価指標にページ速度を含めています。速いサイトは検索結果で上位に表示されやすく、遅いサイトは不利になります。つまりパフォーマンスは、使いやすさだけでなくビジネス的にも重要な要素です。
キャッシュとは何か
キャッシュとは、一度取得したデータを手近な場所に保存しておき、次回以降は保存済みのデータを使うことで通信や処理を省略する仕組みです。
身近な例で言えば、毎朝コンビニで同じ雑誌を買いに行く代わりに、家に置いておいて必要なときに読む、というイメージです。
Webの世界では、キャッシュは主に3つの場所で働きます。
ブラウザキャッシュ
あなたのPCやスマートフォンのブラウザが、一度訪れたページの画像やCSS（スタイルシート）、JavaScriptファイルをローカルに保存します。次回同じページを開いたとき、ブラウザはサーバーに問い合わせることなく保存済みのファイルを使います。
これが一番身近なキャッシュで、同じサイトを繰り返し訪問するユーザーにとって大きな恩恵があります。
CDN（コンテンツデリバリーネットワーク）
CDNとは、世界中に分散して設置されたサーバー群のことです。あなたのサイトの静的ファイル（画像・動画・CSSなど）をユーザーの近くのサーバーに複製しておき、物理的な距離による遅延を減らします。
東京のユーザーがニューヨークにあるサーバーのデータを毎回取りに行くのではなく、大阪や東京にあるCDNのサーバーから取得できるので、表示が速くなります。Vercel や Cloudflare がこの機能を提供しています。
サーバーサイドキャッシュ
サーバー上でデータベースへの問い合わせ結果や計算結果を一時的に保存する仕組みです。例えば、アクセスのたびに1000件の商品データを毎回データベースから取得するのではなく、最初の1回だけ取得してサーバーに保存しておき、2回目以降はその保存済みデータを使います。
Cache-Control ヘッダーを理解する
Cache-Controlとは、WebサーバーがブラウザやCDNに対して「このファイルを何秒間キャッシュしてよいか」を指示するHTTPヘッダー（通信の際に付加されるメタ情報）のことです。
代表的な設定を見てみましょう。
Cache-Control: max-age=86400
これは「86400秒（＝24時間）はキャッシュしてよい」という意味です。画像やフォントなど、滅多に変わらないファイルには長い時間を設定します。
Cache-Control: no-cache
これは「キャッシュするが、使う前に必ずサーバーに確認せよ」という意味です。最新の状態を保ちながらも、変更がなければキャッシュを使うことができます。
Cache-Control: no-store
これは「一切キャッシュするな」という意味です。個人情報や決済情報など、絶対に保存してはいけないデータに使います。
Next.js を使っている場合、静的ファイルには自動で適切な Cache-Control が設定されます。あなたが意識すべきは、APIのレスポンスや動的に生成するページのキャッシュ設定です。
パフォーマンスの3つの指標（LCP・CLS・INP）
Googleが定めたコアウェブバイタルという指標があります。これはユーザーが感じる体験を数値化したものです。
LCP（Largest Contentful Paint）
LCPとは、ページの中で最も大きなコンテンツ（多くの場合はメイン画像や大きなテキスト）が画面に表示されるまでの時間です。
目標値は2.5秒以内です。これより遅いと「ページが遅い」と感じる原因になります。
CLS（Cumulative Layout Shift）
CLSとは、ページを読み込んでいる最中にコンテンツが突然ずれる現象の累積量を測る指標です。
例えば、広告がロードされた瞬間に文章がガクッと下にずれて、読んでいたところがわからなくなる経験はありませんか。それがレイアウトシフトです。目標値は0.1以下です。
INP（Interaction to Next Paint）
INPとは、ボタンをクリックしてから画面が反応するまでの時間です。
目標値は200ミリ秒以内です。これより遅いと「クリックしたのに反応しない」と感じます。2024年3月からCLS・LCPとともにGoogleの検索評価指標に組み込まれました。
Lighthouse でスコアを測る
Lighthouseとは、Google Chromeに内蔵されているウェブサイトの品質測定ツールのことです。パフォーマンス、アクセシビリティ、SEOなどを100点満点で採点してくれます。
使い方はとても簡単です。
- Google Chrome でチェックしたいページを開く
- F12キー（Macは Command+Option+I）で開発者ツールを開く
- 上部のタブから「Lighthouse」を選ぶ
- 「ページの読み込みを分析」ボタンをクリックする
- 30秒ほど待つと結果が表示される
結果画面には、スコアとともに「何が問題か」「どう直すか」が具体的に表示されます。英語ですが、Claude に「この Lighthouse の結果を日本語で説明して、改善方法を教えて」と貼り付けるだけで、わかりやすく解説してもらえます。
よくあるパフォーマンス問題と解決策
問題1：画像が重くてページが遅い
Webサービスで最もよくある遅さの原因が画像です。一眼レフで撮影した写真をそのままアップロードすると、1枚で5MBを超えることがあります。
解決策はWebPへの変換です。WebPとは、Googleが開発した画像フォーマットで、JPEGと比べて同じ画質でファイルサイズを25〜34%削減できます。
Next.js を使っている場合、next/image コンポーネントを使うだけで自動的にWebPへ変換・最適化してくれます。
import Image from 'next/image'
<Image
src="/photo.jpg"
alt="商品写真"
width={800}
height={600}
/>
これだけで、WebP変換・適切なサイズへのリサイズ・遅延読み込みが自動で行われます。
問題2：APIが遅い（N+1問題）
N+1問題とは、1回のデータ取得に必要なデータベースへの問い合わせが、取得件数に比例して増えてしまう問題のことです。
例えば、10件の商品一覧を表示するとき、各商品の詳細情報をそれぞれ1回ずつ問い合わせると、合計11回（1+10）のデータベース接続が発生します。100件なら101回です。これが典型的なN+1問題です。
Claude Code に対して「このAPIが遅い。N+1問題が起きていないか確認して、まとめて取得するように直して」と指示すると、多くの場合は適切な解決策を提案してくれます。
具体的には、複数の問い合わせを1回のJOIN（複数テーブルを一度に結合して取得する操作）にまとめることで解決します。
問題3：初期ロードが遅い
シングルページアプリケーション（SPA）と呼ばれる構成では、最初にすべてのJavaScriptをダウンロードしてからページを描画するため、初回表示が遅くなりがちです。
Next.js では SSR（サーバーサイドレンダリング）と ISR（増分静的再生成）という2つのアプローチで解決できます。
SSRとは、ユーザーがページを開いたタイミングでサーバー側でHTMLを生成して送る方式です。ブラウザはすぐに表示できる状態のHTMLを受け取るので、初期表示が速くなります。
ISRとは、サイトのビルド時に静的なHTMLを生成しておき、一定時間が経過したらバックグラウンドで自動的に再生成する方式です。静的ファイルの速さと、最新データを反映できる柔軟性を両立します。
ブログやECサイトのように「頻繁ではないが定期的に更新されるコンテンツ」には ISR が特に向いています。
実際の改善フロー
パフォーマンス改善は、むやみに「なんとなく速くする」のではなく、計測→特定→修正→再計測のサイクルで進めることが重要です。
ステップ1：Lighthouse でスコアを計測する 現状のスコアと問題点を把握します。「パフォーマンス 60点」という状態を記録しておきます。
ステップ2：問題の優先順位をつける Lighthouse が表示する改善候補の中から、効果が大きいものを優先します。「画像の最適化」で30点改善できるなら、まずそこから着手します。
ステップ3：Claude Code に修正を依頼する 「Lighthouse でこの問題が指摘された。修正してほしい」とスクリーンショットや結果テキストを貼り付けて依頼します。
ステップ4：再度 Lighthouse で計測する 修正後のスコアを確認し、改善されているかを検証します。
このサイクルを繰り返すことで、スコアを着実に上げていくことができます。
キャッシュ設定の落とし穴
キャッシュを設定するとき、1つだけ注意が必要です。それは「古いキャッシュが残り続ける問題」です。
例えば、CSSファイルに「1年間キャッシュしてよい」と設定した場合、あなたがCSSを修正してデプロイしても、ユーザーのブラウザには古いCSSがキャッシュされたまま残ります。
これを解決するのがキャッシュバスティングという手法です。キャッシュバスティングとは、ファイル名にハッシュ値（ファイルの内容から計算された固有の文字列）を含めることで、ファイルが更新されるたびにURLが変わり、ブラウザが新しいファイルを取得せざるを得なくする仕組みです。
Next.js は自動でこれを行ってくれます。ビルドするたびにファイル名が変わるので、ユーザーには常に最新のファイルが届きます。
まとめ
今回のポイントをまとめます。
キャッシュはブラウザ・CDN・サーバーサイドの3階層で機能し、Cache-Control ヘッダーで制御します。パフォーマンスの評価指標は LCP（表示速度）・CLS（レイアウトずれ）・INP（反応速度）の3つで、Lighthouse で計測できます。
よくある問題の解決策は、画像の重さには WebP 変換、APIの遅さには N+1 解消、初期ロードには SSR/ISR が有効です。
これらすべてを一度に完璧にしようとする必要はありません。まず Lighthouse を開いてスコアを確認するところから始めてみてください。スコアが表示されたら Claude に「この結果を見て、優先的に直すべきことを3つ教えて」と聞くだけで、次に何をすればよいかが見えてきます。
次回は認証とセキュリティについて解説します。ログイン機能を安全に実装するための基本知識を、非エンジニアでも理解できるように説明します。
もし「自分のサービスのパフォーマンスを診断してほしい」「どこから手をつければいいかわからない」という場合は、無料相談をご利用ください。Lighthouse の結果を見ながら、優先度の高い改善箇所を一緒に整理します。
