ガイド

ウェブサイトを速くする方法:実践的なチェックリスト

ウェブサイトを速くするには、まずPageSpeed Insightsで計測し、そこで示される最大の原因を直します。通常は、大きすぎる画像、多すぎるJavaScript、重いフォント、サードパーティのスクリプトです。目指すべきはGoogleのCore Web Vitalsの「良好」の目標です。メインのコンテンツが2.5秒以内に表示され、タップへの反応が200ミリ秒以内で、レイアウトがほとんど動かないことです。多くのサイトは、作り直すのではなく、いくつかの変更でこの目標に到達します。

何かを変える前に計測する

推測は時間の無駄になります。ほとんどの人には、次の2つの無料ツールで十分です。

  • PageSpeed Insights(pagespeed.web.dev):公開されているURLを貼り付けます。十分なアクセスがあるサイトなら、実際のChromeユーザーから得たフィールドデータと、シミュレートされた読み込みによるラボデータ、そして具体的な問題のリストが表示されます。
  • Chrome開発者ツールのLighthouse:同じラボテストを、開けるあらゆるページ(プレビューを含む)で実行できます。モバイルモードでテストしましょう。問題が表れるのは、遅いネットワークのスマートフォンだからです。

重要な数値は、GoogleのCore Web Vitalsです。2026年9月時点で、web.devにあるGoogleのドキュメントでは、ページ読み込みの75パーセンタイルで測定した次の「良好」のしきい値が示されています。

指標測定内容良好
Largest Contentful Paint(LCP)メインのコンテンツ(ヒーロー画像、見出し)がどれくらい早く表示されるか2.5秒以内
Interaction to Next Paint(INP)クリック、タップ、入力にページがどれくらい早く反応するか200ミリ秒以内
Cumulative Layout Shift(CLS)読み込み中にレイアウトがどれくらい動くか0.1以下

INPは、2024年に古いFirst Input Delayの指標に取って代わりました。ツールがまだFIDを報告しているなら、それは古いものです。

最初の数値を書き留めておきましょう。修正のたびに再テストすれば、何が効いたかが分かります。

時間がどこでかかっているか:選択肢とトレードオフ

よくある原因にはそれぞれ修正方法があり、それぞれにコストがあります。上にあるものから始めましょう。最も簡単で、最も一般的なものです。

原因一般的な修正トレードオフ
大きな画像表示サイズにリサイズし、圧縮し、WebPやAVIFを使う圧縮しすぎると、画質がわずかに落ちる
画像の読み込み順が間違っている画面の下に見える画像は遅延読み込みし、ヒーロー画像は優先度を高くするヒーロー画像を遅延読み込みしなければ、影響はない
JavaScriptが多すぎるページごとにコードを分割し、使われていないライブラリを削除する多少のリファクタリングが必要
クライアント側のみのレンダリング公開ページを事前レンダリングするか、サーバーでレンダリングするビルドやサーバーの設定が増える
ウェブフォントファミリーとウェイトを減らし、メインのフォントをプリロードし、font-display: swapを使う文字デザインの多様性が減る
サードパーティのスクリプト使っていないものを削除し、残りはページの後で読み込むウィジェットやトラッカーを失う
サーバーの応答が遅いキャッシュ、CDN、コンテンツページ向けの静的ホスティングキャッシュの無効化を考える必要がある

画像

画像は最もよくある問題で、最も直しやすいものです。表示幅800ピクセルで表示される4,000ピクセルの写真は、訪問者が見る量の5倍をダウンロードさせることになります。

  • 表示されるサイズで画像を配信し、スマートフォンとデスクトップに合わせたsrcsetのレスポンシブなサイズを指定します。
  • 最新のフォーマット(WebPまたはAVIF)と適切な圧縮を使います。
  • すべての画像にwidthとheightを設定し、ブラウザがスペースを確保できるようにします。これだけで、ほとんどのレイアウトのずれが直ります。
  • 画面の下に見える画像は、loading="lazy"で遅延読み込みします。
  • ページ上部のメイン画像は、決して遅延読み込みしないでください。 GoogleのLCPのガイドラインは、この点を明確に述べています。LCP画像を遅延読み込みすると、必ずそれが遅れます。代わりにfetchpriority="high"を設定してください。

JavaScript

AIで作られた多くのサイトは、シングルページアプリ(SPA)です。ブラウザがJavaScriptのバンドルをダウンロードしてから、ページを描画します。バンドルが大きいほど、白い画面が長く続きます。修正方法は、手間の少ない順に次のとおりです。

  1. 使っていないものを削除する。 依存関係の一覧を依頼し、一度追加されて忘れられたライブラリを削除します。例えば、1つの日付のために日付ライブラリを使っている、5つのアイコンのために大きなアイコンパックを入れている、といったものです。
  2. ルートごとに分割する。 管理ダッシュボードのコードは、ホームページではなく、誰かがそれを開いたときにだけ読み込みます。
  3. 公開ページを事前レンダリングする。 実際のHTMLとして配信されるマーケティングページは、JavaScriptが実行される前に表示されます。これは検索エンジンにも役立ちます。AIで作ったウェブサイトのSEOをご覧ください。

INPが遅いのは、通常、1つの長いタスクがページをブロックしているからです。例えば、キーを押すたびに巨大なリストを絞り込んでいる、あるいはセルが1つ変わるたびにテーブル全体を再描画している、などです。Chrome開発者ツールのパフォーマンスパネルで、どれかを確認できます。

フォント

フォントのファミリーとウェイトは、それぞれが別のファイルです。通常、2つのファミリーと3〜4つのウェイトで十分です。画面の上部で使われるフォントはプリロードし、テキストがすぐに表示されるようにfont-display: swapを使いましょう。外部のフォントサービスが訪問者にとって遅い場合は、フォントを自分でホストしてください。

サードパーティのスクリプト

チャットウィジェット、アクセス解析、ヒートマップ、広告のピクセル、埋め込み動画、ソーシャルフィードは、いずれも他のサーバーからコードを読み込みます。どれも小さく見えますが、合わせるとページで最も遅い部分になることが多いです。実際に見ているものだけを残しましょう。残りは、ページが操作可能になった後で読み込みます。重い埋め込み(YouTubeプレーヤー、地図など)は、クリックしたときに本物を読み込む軽量なプレビューに置き換えてください。

サーバーの応答

Time to First Byte(TTFB)、つまりサーバーが応答を開始するまでの時間は、他のすべての指標の土台になります。CDN(訪問者の近くにあるサーバーのネットワーク。CDNとは何かをご覧ください)から配信される静的ページは、ほぼどこでも速いです。リクエストごとにサーバーが組み立てるページは、そのサーバーとデータベースに依存します。繰り返しの処理をキャッシュし、遅いクエリにデータベースのインデックスを追加するのが、一般的な修正です。

効果のあるプロンプト

具体的に伝えましょう。ページ、指標、制約を名指しします。PageSpeed Insightsの結果があれば、それも貼り付けてください。

PageSpeed Insightsでは、モバイルのホームページのLCPが4.8秒と報告されています。LCPの要素はヒーロー画像です。ヒーロー画像をリサイズしてWebPに変換し、レスポンシブなサイズを配信し、widthとheightを設定して、fetchpriority="high"を付け、遅延読み込みされないようにしてください。画面の下にあるすべての画像は遅延読み込みしてください。デザインは変えないでください。

このアプリの依存関係を監査してください。各パッケージ、それを使っている箇所、バンドルに追加されているおおよその量を一覧にしてください。使われていないものを削除し、/adminと/settingsのルートを、訪問されたときにだけ読み込まれる別々のチャンクに分割してください。

/productsの検索ボックスの反応が鈍く感じます。フィルターにデバウンスを入れ、キーを押すたびにリスト全体を再描画しないようにしてください。リストが200件を超える場合は、ページ分割または仮想化してください。

ステップごとの手順

  1. 公開されているページをテストする。 PageSpeed Insightsでモバイルを選択します。LCP、INP、CLSと、表示された上位3つの問題をメモします。
  2. まず画像を直す。 サイズ、フォーマット、寸法、画面の下の画像の遅延読み込み、ヒーロー画像の優先度です。
  3. 使っていないサードパーティのスクリプトを減らし、残りは後で読み込むようにします。
  4. フォントを、デザインに必要なものに絞ります。
  5. JavaScriptを小さくします。 使っていないパッケージを削除し、ルートごとに分割します。
  6. 公開ページがまだクライアント側でレンダリングされていて、LCPが遅い場合は事前レンダリングします。
  7. サーバーを確認します。 キャッシュ、データベースのインデックス、めったに変わらないコンテンツの静的ホスティングです。
  8. 再公開して、再テストします。 PageSpeed Insightsのフィールドデータは、実際の訪問が増えるにつれて数週間かけて更新されます。そのため、初期の結果はラボデータで判断してください。

よくある間違い

  • 速いノートパソコンでしかテストしない。 訪問者は、中程度のスマートフォンや不安定なモバイル通信を使っています。モバイルモードでテストしてください。
  • 完璧な100点を追いかける。 ラボのスコアは目安にすぎません。Core Web Vitalsが良好な範囲に入ったら、コンテンツと使いやすさの方が、最後の数点よりも重要です。
  • ヒーロー画像を含め、すべてを遅延読み込みする。 それではLCPが悪化します。
  • 速度のためのプラグインやライブラリを追加する。 重さを取り除く方が、それを管理するためのコードを追加するよりも、ほぼ常に効果的です。
  • ライブサイトではなく、プレビューを最適化する。 開発用のプレビューは、最適化されていないビルドで動きます。公開されたURLを計測してください。
  • 速度を一度だけ直す。 新しいウィジェット、画像、機能はどれも重さを増やします。大きな変更の後は再テストしてください。

速度のチェックリスト

  • モバイルでLCP ≤ 2.5秒、INP ≤ 200ミリ秒、CLS ≤ 0.1
  • 画像はリサイズ・圧縮され、最新のフォーマットで、widthとheightがある
  • ヒーロー画像は遅延読み込みしない。画面の下の画像は遅延読み込みする
  • 使われていないJavaScriptライブラリがなく、重いルートは分割されている
  • フォントは2ファミリー以下で、メインのフォントはプリロードされている
  • 実際に使っているサードパーティのスクリプトだけがあり、後から読み込まれる
  • 公開ページは可能な限り事前レンダリングまたは静的になっている
  • 公開後にライブのURLで再テストした

速度とモバイルのレイアウトは密接に関係しています。ウェブサイトをモバイル対応にする方法をご覧ください。公開前の全体的な確認については、AIのプロトタイプを本番環境に移す方法で残りの部分を扱っています。

Mythexでの速度

Mythexでは、チャットで依頼するか、Proプランならコードエディタで、これらの変更を行います。プレビューは開発サーバーで動くため、公開されたURLを確認してください。静的なフロントエンドは、公開時に静的サイトとしてデプロイされ(静的ウェブサイト)、コンテンツページに適しています。サーバーを持つアプリはゼロにスケールします。アイドル時はスリープし、次の訪問で目を覚ますため、しばらく使われなかった後の最初のリクエストは遅くなります。また、接続されたデータベースは、5分間アイドルになるとスリープします(ホスティングの制限)。公開ページが最初の訪問のときだけ遅い場合、その原因である可能性が高いです。マーケティングページを静的に保つと役立ちます。変更後は再度公開し、ハードリフレッシュしてください。

よくある質問

ページの読み込み時間はどのくらいが良いですか?

GoogleのCore Web Vitalsが最も分かりやすい目安を示しています。メインのコンテンツは2.5秒以内に表示されるべきです(LCP)。ページは入力に200ミリ秒以内に反応するべきです(INP)。レイアウトのずれは0.1以下に抑えるべきです(CLS)。これらは実際の訪問の75パーセンタイルで測定されます。

サイトの速度はSEOに影響しますか?

少しは影響します。Googleは、Core Web Vitalsを含むページ体験のシグナルを使いますが、関連性のあるコンテンツの方がはるかに重要です。速度は訪問者への影響の方が大きく、遅いページは読まれる前に離脱されてしまいます。

PageSpeed Insightsのスコアが毎回違うのはなぜですか?

ラボのスコアは、1回のシミュレートされた読み込みから得られるため、ネットワークやサーバーの応答時間は実行ごとに変わります。何回か実行して傾向を見てください。また、実際のChromeユーザーから得られるフィールドデータのセクションをより重視してください。

多くのウェブサイトを遅くしている原因は何ですか?

通常は、大きすぎる画像、多すぎるJavaScript、ウェブフォント、チャットウィジェット、広告のピクセル、埋め込みなどのサードパーティのスクリプトです。サーバーの応答が遅い、またはコールドスタートするバックエンドが、それらすべてに上乗せされます。

Mythex · Pricing · AIでなんでも作ろう · ウェブサイト・アプリのテンプレート · Mythexを比較 · AIアプリ開発用語集 · AIアプリ開発の無料ツール · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)