2025年7月07日·1 分
初心者のためのサイト速度：実際に読み込み時間を改善するには
初心者向けに、実際にページ読み込み時間を改善する方法を解説します：画像最適化、キャッシュ、ホスティング、コード整理、Core Web Vitals、そしてまず試すべき手早い対策。
初心者向けに、実際にページ読み込み時間を改善する方法を解説します：画像最適化、キャッシュ、ホスティング、コード整理、Core Web Vitals、そしてまず試すべき手早い対策。
「サイトが遅い」と言うとき、人々が通常指しているのは次のどちらかです：
「読み込み時間」は単一のストップウォッチの数字ではありません。ページは段階的に読み込まれます：ブラウザがファイル（HTML、画像、フォント、スクリプト）を要求し、ダウンロードし、それを使えるページに変換します。店を開けることに例えると、鍵を開け、照明を付け、棚を並べ、ようやく接客準備が整う、といった流れです。
速度は次に影響します：
50個のマイクロ最適化は必要ありません。多くの初心者サイトで最大の改善は短いリストから得られます：画像、過剰なJavaScript/CSS、サードパーティウィジェット、そしてサーバー／ホスティングの応答時間です。
このガイドは実用的でリスクが低く、実際のページ読み込み時間を改善する手順に集中しています。アプリアーキテクチャの全面的な書き直し、カスタムキャッシュレイヤーの構築、大規模なエンジニアチーム向けのパフォーマンス予算などの高度なトピックには踏み込みません。目標は、サイトを壊さずに実行・検証できる変更を手に入れることです。
「サイトが遅い」と言うとき、人々が通常意味するのは主に3つです：主要コンテンツの表示が遅い、操作に対して反応が鈍い、あるいはレイアウトが読み込み中にジャンプする。GoogleのCore Web Vitalsはこれらの不満に対応しています。
LCP（Largest Contentful Paint）: 最大の「主要」要素（多くはヒーロー画像や見出しブロック）が表示されるまでの時間。LCPが遅いと、ユーザーはほとんど空白のページを見続けることになります。
INP（Interaction to Next Paint）: ユーザーが操作（タップ、クリック、入力）した後にページがどれだけ速く応答するか。INPが高いと、サイトはもたつく感じになります—ボタンの反応が遅れたり、メニューの開閉に遅延が出たりします。
CLS（Cumulative Layout Shift）: 読み込み中にページがどれだけジャンプするか。テキストがずれてボタンを誤タップしたら、それがCLSです。
**TTFB（Time to First Byte）**は、サーバー（とその間のすべての処理）が何かを送り始めるまでの時間です。TTFBが遅いと他のすべてが遅れます：画像のダウンロード開始が遅れ、フォントが遅れ、結果としてLCPが悪化することが多いです。TTFBの問題はしばしばホスティング、重いバックエンド処理、あるいはキャッシュの欠如を示します。
ラボテスト（Lighthouseなど）は特定の条件でのページ読み込みをシミュレートします。デバッグやビフォーアフターの比較に便利です。
実ユーザーデータ（フィールドデータ、たとえば PageSpeed Insights の CrUX）は訪問者が実際に体験するものを反映します。実際のユーザーにとって「本当に速く感じるか」はこちらが最も重要です。
ベースラインを取らずに「最適化」を始めると、時間を無駄にしたり、誤ってサイトを遅くしてしまうことがあります。まず20分かけて測定し、どの変更が効果的かを把握しましょう。
PageSpeed Insights を使うと迅速なスナップショットが得られます。フィールドデータ（実ユーザー体験、利用可能な場合）とラボデータ（シミュレーション）を報告します。注意すべき点：
詳細なラボテストは Chrome の Lighthouse を使ってください：
何がページを遅くしているかを知りたいときは、WebPageTest の ウォーターフォールビュー が非常に分かりやすいです。HTML、画像、フォント、スクリプト、サードパーティタグなど、ブラウザが待っている箇所を一つずつ表示します。
重要なページ（トップページや主要ランディングページ）で次をテストしてください：
各テストで書き留めること：
小さなログ（スプレッドシートで十分）を作り、日付、使用ツール、URL、結果、行った変更を記録します。1〜2点だけ同時に変更し、同じ条件で再テストしてください。
アプリを反復している場合（静的サイトだけでなく）、スナップショットを取って変更をテストし、問題があればロールバックできる仕組みを用意しておくと便利です。たとえば Koder.ai のようなプラットフォームは、チャットワークフローからReact/Goアプリを生成・ホストでき、スナップショットとロールバック機能で性能実験を安全に行えます。
遅いページはたいてい1つの謎めいた問題のせいではありません。いくつかの一般的な「重さと遅延」の問題が積み重なっていることが多いです（特にモバイルで顕著）。
画像はページで最も重い部分であることが多いです。ヒーロー画像が間違ったサイズで出力されているだけで数メガバイトになり、数秒を追加します。
よくある例：
JavaScriptはページが使えるようになるまでを遅らせることがあります。ページが「表示」されても、スクリプトの読み込み・解析・実行中は体感で遅く感じることがあります。
サードパーティスクリプト（チャット、ポップアップ、ヒートマップ、A/Bテスト、広告タグ、ソーシャル埋め込み）はしばしば問題を引き起こします。各スクリプトが追加のネットワークリクエストを生み、ブラウザの重要な作業を遅らせます。
ブラウザがページを読み込み始める前にサーバーを待っていることがあります。これはTTFBとして感じられます。原因は、力不足のホスティング、混雑したデータベース、最適化されていないテーマやプラグイン、あるいは毎回動的にページを作っていることなどです。
サイトが毎回ゼロから読み込むようになっていると、再訪問者は不利になります。キャッシュがなければサーバーは何度もページを再構築し、ブラウザは頻繁に変わらないファイルを再ダウンロードします。
また、フォントやスクリプト、スタイル、トラッカーなど小さなファイルが多数あると「リクエストのオーバーヘッド」が発生します。個々は小さくても合計の待ち時間は積み重なります。
朗報：これらの原因は修正可能で、多くの場合はこの順で対処すると最大の成果が得られます。
一つだけ改善するなら、画像です。多くの初心者サイトでは、画像がページのダウンロード「重さ」の大部分を占めます。良いニュースは、画像の修正は通常安全で、短時間で済み、デザインを変える必要がほとんどないことです。
よくあるミスは、大きな写真（例：4000px幅）をアップロードしてサイトでは800pxで表示することです。ブラウザは依然として大きなファイルをダウンロードします。
最大表示サイズに近いサイズで画像をエクスポートするようにしましょう。たとえばブログのコンテンツ幅が800pxなら、3000〜4000pxを不必要にアップロードしないでください。
JPEGやPNGも動作しますが、モダンフォーマットは同等の見た目でファイルサイズをかなり小さくできます。
CMSや画像プラグインが自動でWebP/AVIFを配信し、フォールバックを用意してくれるのが理想です。
圧縮で即効性のある改善が得られます。「見た目はほとんど変わらない」画像が30〜70%も小さくなることがあります。カメラ情報や位置データなどのメタデータは見た目に影響しないので削除してください。
実用ルール：品質に明確な劣化が見えるまで圧縮し、そこから一段戻すイメージで調整します。
srcset）でモバイルとデスクトップに応じたサイズを提供するモバイルユーザーにデスクトップ用サイズをダウンロードさせるべきではありません。レスポンシブ画像を使うと、ブラウザが画面幅に基づいて適切なサイズを選びます。
テーマやCMSが複数の画像サイズを自動生成するなら、ページのHTMLで srcset のような仕組みが使われているか確認してください。単一の巨大ファイルだけが出力されているのは避けたいです。
本格的なチューニング（コードの最小化など）に進む前に上位の画像だけを監査してください：
これら4点を徹底すれば、多くの場合すぐにサイト速度とページ読み込み時間が改善し、Core Web Vitalsに良い影響を与えます。
レイジーロードは、ページが全て同時にダウンロードするのを避け、表示直前まで画像（および場合によってはiframe）を遅らせる手法です。長いページや画面外に大量の画像がある場合に特に有効です。
次の場合に効果的です：
適切に使えば初期の作業量が減り、ページが速く感じられます。
ファーストスクリーンの最大の画像は多くの場合ヒーローです。これを遅延読み込みすると、ブラウザがリクエストを遅らせてしまい、LCPが悪化することがあります。
経験則：主要なヒーロー画像やファーストスクリーンの重要要素は遅延読み込みしてはいけません。
レイジーロードは画像出現時に「ジャンプ」を引き起こすことがあります。CLSを防ぐにはスペースを予約してください：
width と height を設定する、またはこうすることで画像が読み込まれてもレイアウトが安定します。
ファーストインプレッションに不可欠な画像やフォントは プリロード を検討し、ブラウザが早めに取得するようにします。ただしプリロードをやりすぎると帯域を奪い逆効果になるので節度を持って使ってください。
このチェックを /blog/how-to-measure-site-speed-before-you-change-anything の測定ステップと組み合わせると効果的です。
キャッシュはブラウザが「これは前にダウンロードしたから再利用できる？」と判断する仕組みです。同じロゴやCSSファイル、JavaScriptバンドルを毎回ダウンロードさせないことで再訪問が速くなりデータ利用も減ります—特にモバイルで効果的です。
ファイル（styles.css や app.js など）を送るときに、そのファイルをどれくらいの期間再利用してよいかを指示できます。ブラウザが30日間キャッシュしてよいと指示されていれば、次回訪問時にそのファイルは端末から素早く読み込まれます。
これは初回訪問を魔法のように速くするわけではありませんが、次のような場面で劇的に速さをもたらします：
静的ファイルは毎分変わるものではありません：画像、CSS、JavaScript、フォント。こうしたファイルは長めにキャッシュするのが良い候補です。
概念的には欲しい設定：
ホストやCMS、フレームワークに「静的アセットキャッシュ」のトグルがあることが多いです。開発者がいるなら、アセットに適切な Cache-Control ヘッダーを設定してもらってください。
長めにキャッシュしておくと「1か月後に更新してもユーザーに反映されないのでは？」という不安が出ます。解決策は バージョン付きファイル名 です。
例：
app.3f2a1c.jsstyles.a81b09.css内容が変わるとファイル名が変わるのでブラウザは新しいファイルとして取得します。これにより長いキャッシュと迅速な更新が両立します。
サービスワーカーを使うとキャッシュ制御をさらに細かく行え、オフライン動作を可能にすることもあります。ただし実装が不適切だと「古いコンテンツが出続ける」などのトラブルを招くので、初心者は上級オプションとして扱い、明確な目的と経験者による保守がある場合に検討してください。
CDN（コンテンツ配信ネットワーク）は、複数地域に分散したサーバー群が訪問者に近い場所からファイルを配信する仕組みです。すべてのリクエストが単一のホスティングサーバーまで届く代わりに、多くのリクエストを近くのサーバーで捌けるようになります。
CDNは主に静的アセット（画像、CSS、JavaScript、フォント、動画など）を速く配信するのに向いています。これらのファイルはコピーしてエッジサーバーに置き、多くの訪問者で共有できます。
特に効果的なのは、訪問者が複数都市／国に散らばっているサイト、メディアを多く配信するサイト、国外からのトラフィックがある広告キャンペーンを走らせるビジネスなどです。
距離は遅延を増やします。サーバーがある国と訪問者のいる大陸が違うと、すべてのファイルリクエストに余分な遅延がかかります。CDNはキャッシュされたファイルを訪問者の近くのエッジサーバーから配信することでその遅延を減らし、ページ読み込み時間とCore Web Vitalsに寄与することが多いです。
キャッシュヘッダーの誤設定でキャッシュされなかったり、逆に古いキャッシュが残ったりします。これを避けるにはバージョン付きファイル名を使い、CDNの「パージ」機能を覚えておいてください。
CDNは重い画像や肥大化したスクリプト、遅いホスティングの代替にはなりませんが、基礎が整っていれば強力な乗数効果をもたらします。
CSSとJavaScriptは「目に見えない重さ」としてページを遅くします。画像のように見てすぐ分かるわけではありませんが、ブラウザはこれらのファイルをダウンロードして解析・実行する必要があります。
最小化（minify）は空白やコメント、改行を取り除きます。ファイルサイズは小さくなり、ダウンロードは速くなります。
変わるもの：ファイルサイズ。変わらないもの：ブラウザがコードを解析・実行する負荷。ロード時にやることが多ければ、最小化だけでは根本解決になりません。最小化は短期の勝利です。
多くのサイトは「オールインワン」スタイルシートを読み込み、現在のページで使われないルールまで含みます。余分なCSSもダウンロードされ、描画を遅らせます。
実用的アプローチ：
critical CSS を出して、残りを遅延ロードするように頼む。目標は簡単：ホームページがサイト全体の重さを背負わないようにすること。
defer または async にする一部のスクリプトはページが利用可能になるのをブロックします。
defer を使うのが一般的に良い。async が適する。まずはファーストスクリーンに必要でないもの（メニュー、アニメーション、スライダー、追加のトラッキング）を defer にするところから始めてください。
大きなライブラリは数百KB、あるいはそれ以上を追加します。新しいプラグインやフレームワークを入れる前に：
スクリプトが少ないほど予期しない問題も少なくなり、特にモバイルではCPU時間がダウンロードサイズと同程度に重要です。
サードパーティスクリプトは別会社のサーバーから読み込むすべてのスクリプトです。機能をすばやく追加できる利点がありますが、ページ読み込み時間に対して最も予測不能で大きな影響を与えることが多いです。
主なカテゴリーは：
これらのスクリプトは追加ファイルをダウンロードし、多くのJavaScriptを実行し、時にはページの完了をブロックします。
Chrome DevTools → Performance を開き、ページ読み込みを記録して次を探します：
Lighthouse（DevTools → Lighthouse）でも「Reduce JavaScript execution time」や「Eliminate render-blocking resources」に関する推奨を確認できます。
初心者向けの勝ち筋いくつか：
フルのYouTubeやFacebook埋め込みを読み込む代わりに、サムネイル＋再生ボタンの軽いプレビューを表示し、ユーザーがクリックしたときに本体を読み込む方法が有効です。
これにより機能を残しつつ、特にモバイルでページを速く保てます。
TTFBはブラウザがページを要求してからサーバーが応答を開始するまでの時間です。料理で言えば「厨房が料理を作り始めるまでの時間」であり、料理がテーブルに届くまでではありません。
TTFBが高いと、いくら見た目が最適化されていてもページは遅く感じます—特にモバイル回線では遅延が目立ちます。
TTFBは主にサーバー側の処理時間によります：
画像やスクリプトを最適化しても、サーバーの応答が遅ければブラウザは空白のまま待たされます。
CMSや動的にページを生成するサイトなら、サーバーサイドのキャッシュ がTTFB改善に最も効きます。同じページを毎回再構築する代わりに、準備済みのレスポンスを返せます。
実用例：
テキスト系のファイル（HTML、CSS、JavaScript）は Brotli（推奨）か Gzip を有効にして圧縮してください。ネットワーク上を流れるデータ量が減り、特にモバイルでの体感速度が改善します。
より良いホスティングは確かにTTFBを改善しますが、最初はフロントエンドの明らかな問題（巨大な画像、過剰なサードパーティスクリプト、重いJavaScript）を先に直す方が賢明です。大量のファイルをダウンロードさせている段階でホスティングだけ速くしても、体感は大きく変わりません。
基礎が整ったらホスティング（CPU/RAMの増強、チューニングされたDB、ランタイムの最適化）をアップグレードするのが最終手段として有効です。
新製品を作る場合は、初めからホスティングの変数を少なくしたいなら、管理されたプラットフォームを検討してください。たとえば Koder.ai はアプリをグローバルにAWS上でホストし、デプロイ、カスタムドメイン、環境のロールバックをサポートし、地域間のパフォーマンステストやデータ所在地要件への対応に便利です。
大掛かりなプロジェクトは必要ありません。終わらせられる単純な順序と、悪化していないことを確認する方法、そして確実に効果のある修正を優先する姿勢があれば十分です。
Day 1: 測定（何も触らない）
重要なページを2〜3つ（ホーム、主要ランディング、人気のブログ/商品ページ）選び、次を実行：
モバイルでのベースラインとデスクトップも記録しましょう。可能なら実際の携帯でセルラー回線にてテストすると、ラボが見逃す問題が出ることがあります。
Days 2–3: 画像を直す（最速で確実な勝利）
優先すること：
数枚だけ変えて再テストし、効果を確認してください。
Days 4–5: キャッシュを整える（再訪問を格段に速く）
ブラウザキャッシュとサーバー／ページキャッシュを有効にし、同じ資産を何度も再生成・再ダウンロードさせないようにします。有効化後は再訪問で体感が速くなるか確認してください。
Days 6–7: JavaScriptを削る（長期的に大きな成果）
チェックするポイント：
ここでの小さな変更が、特にモバイルでのインタラクティビティとCore Web Vitalsを大きく改善することがあります。
大きな編集をするたびに次の3点を確認してください：
画像とキャッシュを最適化しても TTFBが高いまま なら、ホスティングやサーバー設定、遅いデータベース、あるいは重いバックエンド処理が原因であることが多いです。会員サイトやマーケットプレイスのような複雑なアプリでは「キャッシュすればよい」という単純な話にならないこともあり、その場合は外部の助けを検討してください。
詳しいサーバー応答時間に関する解説が必要なら /blog/ttfb-explained を参照してください。
ウェブサイトの速度は通常、次の2点を指します：
ページが「見た目上は読み込まれた」ように見えても、JavaScriptが忙しかったりレイアウトが揺れたりすると体感は遅くなります。
コアウェブバイタルはよくあるユーザーの不満に対応しています：
これらを改善すると、単なるスコア向上だけでなく実際の体感速度も良くなります。
実務的な目安として：
方向性として使い、まずは一番悪い指標を優先して改善してください。
変更前にベースラインを取ることから始めましょう：
デバイス、ネットワーク、テスト場所、正確なURLを記録し、1〜2点だけ変えて再テストしてください。
主な原因は通常次の通りです：
この順で対処すると、効率よく改善できます。
画像はページ上で最も大きなファイルになることが多く、ダウンロード時間とLCPに直接影響します。基本の4点に集中してください：
これらは低リスクで即効性があり、測定もしやすいです。
遅延読み込み（lazy loading）は、ファーストビュー外のコンテンツのダウンロードを遅らせることで初期読み込みを軽くしますが、使い方に注意が必要です。
基本ルール：
width と height を指定するか、固定アスペクト比のCSSを使う。重要なものはプリロードを検討しますが、やりすぎると帯域を奪って逆効果になります。
キャッシュは主にリピート訪問を速くします：
app.3f2a1c.js）を使う。正しく設定すれば再ダウンロードとサーバー負荷を大きく減らせます。
CDNは静的ファイルを訪問者に近いエッジサーバーから配ることでレイテンシを下げます。特に多地域からのアクセスやメディアが多いサイトで効果的です。
注意点：
CDNは万能ではないが、基本が整っていれば強い乗数効果を生みます。
壊さずに速度を改善するためのシンプルな順序：測定→画像→キャッシュ→JavaScriptの整理。
例の1週間プラン：
defer各ステップ後に同じ条件で再テストし、サイト操作で問題がないか確認してください。