HTMLでサイトの表示速度を改善方法する方法！読み込みが遅くなる要因は？

HTMLでサイトの表示速度を改善方法する方法！読み込みが遅くなる要因は？

「サーバーは速いのにページが重い」「PageSpeed Insightsのスコアが低い」と感じるなら、原因はHTML・CSS・JavaScriptの書き方やリソースの読み込み設計にある可能性が高いです。

改善の第一歩は、どの要因が足を引っ張っているかを正確に見極めること。

むやみに施策を打つ前に、原因を5つのカテゴリに分けて整理しましょう。

HTMLで表示速度が遅くなる要因は？

Webページの表示速度が遅いとき、サーバーの応答速度（TTFB）だけでなく、ブラウザがHTMLを受け取ってから画面に描画するまでのプロセス（クリティカルレンダリングパス）に問題があるケースが大半です。

主な要因は以下の4点に集約されます。

改善の第一歩は、どの要因が足を引っ張っているかを正確に見極めること。

むやみに施策を打つ前に、原因をカテゴリに分けて整理しましょう。

レンダリングブロックの発生

ブラウザはHTMLを上から順に読み込みますが、<link rel="stylesheet">や通常の<script>タグに遭遇すると、そのリソースの読み込みと実行が完了するまでHTMLの解析（パース）を中断します。

これを「レンダリングブロック」と呼びます。

特に<head>内に大量のCSSや同期的なJavaScriptがあると、画面は真っ白なまま待機状態となり、First Contentful Paint (FCP) や Largest Contentful Paint (LCP) の悪化に直結します。

リクエストが増えすぎる（ネットワーク待ちが増える）

HTML自体が軽量でも、そこから呼び出される外部リソース（画像、CSS、JS、フォント）が多すぎると、ブラウザの同時接続数制限に引っかかり、ダウンロード待ち（キューイング）が発生します。

HTTP/2で多重化が可能になったとはいえ、物理的な帯域幅やレイテンシの影響は無視できません。

HTML構造（DOM）が重い

HTMLタグのネストが深すぎたり、要素数が多すぎたりすると、ブラウザがスタイル計算（Style Calculation）やレイアウト計算（Layout/Reflow）を行う際の負荷が増大します。

GoogleのLighthouseでは「Avoid an excessive DOM size」という警告があり、DOMノード数は1,500未満が推奨されています。

DOMが巨大だと、スクロール時の再描画やJavaScriptによるDOM操作も遅くなります。

画像・埋め込みがHTML側で遅くなっている

画像のファイルサイズが大きいことはもちろん問題ですが、HTMLの記述方法自体もパフォーマンスに影響します。

width / height 属性の欠如はレイアウトシフト（CLS）を引き起こし、不適切なタイミングでの読み込み（loading属性の誤用）は初期表示を遅らせます。

フォント起因（表示が遅い／ガタつく）

Webフォントの読み込み中はテキストが表示されない（FOIT: Flash of Invisible Text）か、代替フォントで表示されてから切り替わる（FOUT: Flash of Unstyled Text）現象が起きます。

これにより、ユーザーは「文字が出ない」「画面がチラつく」と感じ、体感速度が低下します。

DevToolsのパフォーマンスで「遅い処理」を可視化する

改善を始める前に、DevToolsを使って「何がボトルネックになっているか」を特定します。

闇雲な軽量化ではなく、数値に基づいた改善が必要です。

まずはDevToolsで計測を行う

まず、分析対象のページをChromeのシークレットモードで開きます。

シークレットモードを使うことで、拡張機能やキャッシュの影響を排除し、より正確なトレースが取れます。

次に、右クリックから「検証」を選ぶか、F12キーを押してDevToolsを起動します。

DevToolsが開いたら「パフォーマンス」タブ（下記画像の赤枠部分）を選択します。

タブが見当たらない場合は、コマンドメニュー（Mac: Cmd+Shift+P / Windows・Linux: Ctrl+Shift+P）を開き、「Performance」と入力して該当パネルを呼び出してください。

パネルが表示されたら、左上の ●（Record）ボタン（画像の黄色部分）を押して記録を開始します。

記録中にページをリロードするか、「遅い」と感じる操作（スクロール・クリック・フォーム操作など）を実際に行ってください。

操作が終わったら「停止」ボタン（画像の青枠部分）を押して記録を終了すると、トレース結果がパネルに描画されます。

「どこが遅いか」当たりをつける

パネル上部の概要部分を見てください。（下記画像の赤枠部分）

グラフが跳ね上がっている箇所（CPUスパイク）や、赤いバーが表示されている箇所が処理落ちしているタイミングです。

問題のある時間帯をドラッグして範囲選択し、詳細を分析します。

メインスレッドの詰まりを特定する（Mainでロングタスクを見る）

「メイン」トラックを展開すると、メインスレッドで行われた処理（HTML解析、JS実行、レイアウト、ペイント）が時系列で表示されます。

※下記画像の青枠部分でメインが確認できます。

タスクの右上に赤い三角マークが付いているものは「ロングタスク（50ms以上かかる処理）」です。

これらがユーザーの入力反応を遅らせ（INP悪化）、描画をブロックしています。

「原因の関数/処理」を特定する（ボトムアップ/呼び出しツリー）

下部のタブを切り替えて詳細を確認します。

ボトムアップについては「合計時間」でソートし、処理時間を食いつぶしている具体的な関数を特定します。

合計時間順にソートをかけると読み込みに時間のかかってる順に要素が並ぶので原因を特定しやすいです。

呼び出しツリーについては、どの親処理からその重い処理が呼び出されたか、階層構造を追跡します。

ボトムアップの部分で「怪しい関数」を見つけたあと、Call Treeで「どこから呼ばれているか」を辿ることで、根本的な修正箇所を特定できます。

HTMLで効く改善①：レンダリングを止めない

ここからは具体的な改善策です。

最も効果が大きいのは、ブラウザのHTML解析を邪魔するリソース（CSS/JS）の制御です。

<script>の最適化（defer / asyncの使い分け）

通常の<script>タグはHTMLを読み下す途中でブラウザの解析処理を完全停止させ、JSのダウンロードと実行が終わるまで描画が進みません。

JavaScriptはデフォルトでHTML解析を中断します。

一方、defer・asyncを付与するとJSのダウンロードをHTMLの読み込みを止めずに並列して行えるようになります。

これにより、ブラウザが描画に専念できる時間が増え、FCPやLCPの短縮に直結します。

具体的には、下記の画像のようにdeferまたは async属性を付与して非同期読み込みに切り替えます。

ソース例でご紹介すると下記のようになります。

deferの場合

<script src="dummy1.js" defer></script>

asyncの場合

<script src="dummy1.js" async></script>

deferとasyncの使い分け方

下記のような使い分けをするといいでしょう。

使用条件

defer/async

この判断の意図

スクリプトはDOM操作をする場合

defer

DOMができる前に動くと事故りやすいので、解析後に実行させる

他のスクリプトに依存する場合（例：jQuery前提、順序が重要）

defer

deferは複数スクリプトでも順序を保ちやすい

計測タグ・広告など 完全に独立している場合

async

独立なら“読み込み次第すぐ実行”でブロックを避けやすい

下記には注意

defer属性をつけているのに、コード内でdocument.writeを使っている場合（無視されるかエラーになる）。

jQueryプラグインなどをasyncで読み込み、本体より先に実行されてエラーになる場合（順序保証がないため）。

CSSやJSのインライン化の実施内部

外部CSSファイルはHTMLの解析と描画をブロックするリソースです。

ブラウザはCSSのダウンロードが完了するまで画面を描画できないため、外部ファイルの数や通信遅延がそのまま「白い画面の待ち時間」に直結します。

この問題に対する施策が、ファーストビューに必要な最小限のCSSだけを<style>タグとしてHTML内に直接埋め込む「クリティカルCSSのインライン化」です。

外部リクエストを挟まずにスタイルを即座に適用できるため、ブラウザが最初の描画（FCP）を開始するまでの時間を短縮できます。

残りの全体CSSは非同期で後から読み込むことで、表示ブロックを回避しながらデザインの完全性も保ちます。

ソース例

<head>
  <!-- クリティカルCSSのみインライン化 -->
  <style>
    /* ファーストビューに最低限必要なスタイルのみ */
    body { margin: 0; font-family: sans-serif; }
    .header { height: 60px; background: #fff; }
    .hero-image { width: 100%; aspect-ratio: 16/9; }
  </style>
  
  <!-- 残りのCSSは非同期で読み込む -->
  <link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="styles.css"></noscript>
</head>

注意点としては、すべてをインライン化するとHTMLが肥大化し、ブラウザのキャッシュ機能も活かせなくなります。

「最初の1画面」に必要な分のCSSだけに留めてください。

手動抽出は困難なため、criticalやcrittersといったビルドツールの使用を推奨します。

HTMLで効く改善②：読み込み優先度を設計する

ブラウザに対して「このリソースは後で絶対に必要になるから、早めに準備して」と指示を出すことで、待機時間を削減します。

「preconnect（プリコネクト） 」「dns-prefetch（DNSプリフェッチ）」「preload（プリロード）」「prefetch（プリフェッチ）」といった読み込み方法があり、コンテンツによって読み込みの優先度を変えることができます。

ファーストビューの表示に必要なものは速く読み込ませる必要があり、ページ下部にあるコンテンツなどは優先度を下げて読み込ませるよう設計しましょう。

それぞれ、下記の比較表のように特徴があります。

読み込みの優先度を設計（preconnect / dns-prefetch / preload / prefetchの使い所）

属性

用途

タイミング

注意点

preconnect

DNS解決＋TCP/TLS接続

早期に接続確立

コストが高い。重要な外部ドメイン（CDNなど）に限定

dns-prefetch

DNS解決のみ

preconnectより軽い

preconnect非対応ブラウザへのフォールバックとして併記

preload

現在のページで使うリソース

高優先でDL

as属性必須。使わないと警告が出る

prefetch

次のページで使うリソース

アイドル時にDL

優先度は低い。遷移確率が高いページに使用

preconnect（プリコネクト）

ブラウザが外部ドメインへのリソースを取得するには 「DNS解決 → TCP接続 → TLSハンドシェイク」 の3ステップが必要で、条件によっては 100〜500ms以上かかる ことがあります。

preconnect はこれをまるごと先に済ませます。

利用ケース

preconnect（プリコネクト）は下記のようなケースでの使用がおすすめです。

外部ドメインのリソースを読み込むケースはプリコネクトを使うようにしましょう。

  1. Google Fonts / Adobe Fonts などのフォントCDN
  2. 画像CDN（URLは後で決まるが、接続先ドメインは確定している場合）
  3. 分析・広告など必ず呼ばれる外部ドメイン
  4. 動画ストリーミングの接続先

コード例

<!-- 基本形 -->
<link rel="preconnect" href="https://fonts.googleapis.com">

<!-- フォントなどcrossoriginが必要なもの（匿名モードで読み込まれるリソース） -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

dns-prefetch（DNSプリフェッチ）

preconnect より軽量（DNSルックアップのみ、TCPやTLSは行わない）。1回のDNS解決は通常 20〜120ms の短縮になります。

利用ケース

dns-prefetch（DNSプリフェッチ）は下記のようなケースでの使用がおすすめです。

  • preconnect を指定するほどではない第3〜n位の外部ドメイン
  • preconnect 非対応ブラウザへのフォールバック（セットで書くのが定番）

コード例

<!-- preconnect対応ブラウザ → preconnectが動く -->
<!-- 非対応ブラウザ → dns-prefetchにフォールバック -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://fonts.googleapis.com">

参考：dns-prefetchとは

preload（プリロード）

ブラウザは通常HTMLを上から読みながらリソースを発見しますが、CSS内のフォント・JS内の画像など、後から発見されるリソースは取得が遅れます。

preload でHTMLの <head> に書いておけば、発見タイミングを最速にできます。

利用ケース

preload（プリロード）は下記のようなケースでの使用がおすすめです。

  • LCPになる画像（ファーストビューのメインビジュアル）
  • CSSファイルの中から使われるWebフォント（FOUT回避）
  • Critical JS（最初の描画・操作に必要なスクリプト）

コード例

<!-- 画像（LCP画像に特に有効） -->
<link rel="preload" href="/images/hero.webp" as="image">

<!-- フォント（crossorigin必須！ないと2回ダウンロードされる） -->
<link rel="preload" href="/fonts/MyFont.woff2" as="font" type="font/woff2" crossorigin>

<!-- CSS -->
<link rel="preload" href="/css/critical.css" as="style">

参考：preloadとは

prefetch（プリフェッチ）

現在のページには関係なく、ユーザーが次に行きそうなページのリソースを低優先でキャッシュしておく仕組みです。

利用ケース

prefetch（プリフェッチ）は下記のようなケースでの使用がおすすめです。

  • 記事一覧ページ → 1位の記事詳細
  • ページネーションの「次のページ」
  • ログインページ → ダッシュボード（ログイン直後のLCP改善）

コード例

<!-- 次ページのHTML -->
<link rel="prefetch" href="/articles/next-page.html">

<!-- 次ページで使う画像 -->
<link rel="prefetch" href="/images/next-hero.webp">

フォント最適化（FOIT/FOUTをコントロールする）

Webフォントの最適化は「LCP改善」と「CLS防止」の両方に直結します。

対策しないと「フォントが遅れて表示→文字がガクッとズレる（CLS）」「テキストが長時間見えない（LCP悪化）」が同時に起きやすい問題です。

フォントで起きる問題（FOIT/FOUT）

FOIT（テキストが不可視）はフォント読み込み中にテキストが真っ白になる現象で、LCP・FCPを悪化させます。

FOUT（フォントの切り替えガタつき）はフォールバックフォントで先に表示し、Webフォント到着後に文字サイズ・幅が変わってレイアウトがズレる現象で、CLSを悪化させます。

問題の内容

影響する部分

FOUT

フォールバックフォントで先に表示→後からWebフォントに切り替わる（ガタつく）

CLS悪化

FOIT

フォントが来るまでテキストが完全に不可視（真っ白）

LCP/FCP悪化

どちらも未対策のデフォルト状態（font-display未指定）だと発生しやすく、Core Web Vitalsの複数指標を同時に下げる原因になります。

font-display（FOIT/FOUT をコントロールする CSS）

font-displayは@font-face 内に書くCSS記述子で、Webフォントが読み込まれるまでテキストをどう表示するかを制御します。

主な値は swap（すぐ代替フォントで表示→後から切替）と optional（100ms以内に来なければ今回は代替のまま）。

未指定だとFOIT・FOUT両方が発生しやすいため、必ず指定するのが基本です。

利用ケース

font-displayは下記のような値でコントロールすることができます。

値

どんなシーンで使うか

どんな動きをするか

auto

特に指定したくないとき（非推奨）

ブラウザが独自に判断する。挙動が不定で制御できないため基本的に使わない

block

ロゴ・アイコンフォントなど代替フォントでは成立しないデザイン

約3秒テキストを不可視にしてフォント到着を待つ。来たら切り替え。来なければ代替表示（FOIT発生）

swap

本文・見出しなど代替フォントでも読めるテキスト全般

約100ms後に代替フォントで即表示→Webフォントが来たら切り替え。常に読めるが文字幅変化でガタつく可能性あり（FOUT発生）

fallback

代替フォントと字形が近いフォントを使う場合

約100ms不可視→約3秒だけ代替表示→間に合えば切替、間に合わなければ今回はそのまま（次回キャッシュから適用）

optional

CLS（ガタつき）を絶対に防ぎたい場合

約100ms不可視→間に合わなければ今回は代替フォントのまま一切切り替えない。CLSがほぼゼロになる

コード例

/* 推奨：本文フォント（CLS防止優先） */
@font-face {
  font-family: "MyFont";
  src: url("/fonts/MyFont.woff2") format("woff2");
  font-display: optional;
}

/* 推奨：見出しフォント（代替と近い場合） */
@font-face {
  font-family: "HeadingFont";
  src: url("/fonts/HeadingFont.woff2") format("woff2");
  font-display: swap;
}

preload（フォントの発見を最速にする）

通常フォントは「HTML → CSS → @font-face → フォントDL」の順で発見されるため読み込みが遅れます。

preload を <head> に書くことでこの発見タイミングを最速に前倒しできます。

as="font" と crossorigin の2つは必須で、どちらか欠けるとフォントが2回ダウンロードされるなど意図しない挙動になります。

利用ケース

ケース

理由

LCP改善したいファーストビューの主要フォント

フォント発見が早まりテキストLCPが改善される

CSSファイルの中で定義されているWebフォント全般

CSS読み込み後にしか発見されないため preload で前倒しが有効

FOUT/FOIT を最小限にしたいフォント

早期取得により代替フォント表示の時間を短縮できる

セルフホストのフォントファイル

ファイルパスが確定しているため preload が使いやすい

Google Fonts など外部フォントのwoff2ファイルが固定URLの場合

URLが変わらなければ外部フォントにも適用可能

コード例

<head>
  <!-- as="font" と crossorigin は必須 -->
  <link rel="preload"
        href="/fonts/MyFont.woff2"
        as="font"
        type="font/woff2"
        crossorigin>
</head>

サブセット化（フォントファイルを軽くする）

フォントファイルから実際に使う文字だけを抽出して軽量化する手法です。

日本語フォントは未対策だと数MB〜10MB超になることがあります。

unicode-range でCSS側から読み込む文字範囲を絞るか、ビルド時にツールで切り出すことで転送量を大幅に削減でき、LCP改善に直結します。

利用ケース

ケース

推奨手法

理由

日本語フォントをWebフォントで使う

unicode-range / ツールでサブセット化

未対策だと数MB超になりLCPに直撃する

ロゴ・キャッチコピーなど固定の文字列にだけWebフォントを使う

Google Fonts text= API / ツール

使う文字が確定しているため極限まで軽量化できる

ラテン文字と日本語を文字種ごとに分けて管理したい

unicode-range

必要な文字セットだけ読み込みリクエストを最小化できる

ビルド環境がある（Next.js・Astro・Vite等）

subfont / glyphanger

自動でサブセットを生成し運用コストを下げられる

コード例（unicode-range で文字種を分けて読み込む）

/* 日本語のみ（必要な場合だけDL） */
@font-face {
  font-family: "MyFont";
  src: url("/fonts/MyFont-japanese.woff2") format("woff2");
  font-display: swap;
  unicode-range: U+3000-9FFF, U+FF00-FFEF;
}

HTMLで効く改善③：DOMを軽くする（HTML構造の最適化）

DOMが深い・要素数が多いと、ブラウザが行うStyle計算・Layout・Paintの処理コストが増大します。

特にJavaScriptでDOM操作をした際に再レイアウト（Reflow）が連鎖しやすく、メインスレッドが詰まってINPが悪化します。

またページ初期読み込み時のHTML解析コストも増えるため、LCP・FCPにも影響します。

Googleの目安はDOM要素数1,400以下と言われています。

下記に改善策を解説していきます。

不要wrapper削除

HTMLに意味なく積み重ねられた <div> などのwrapper要素は、DOMを深くしStyle計算・Layoutのコストを増やす原因になります。

削除してもデザインや機能に影響しない要素を取り除くことで、ブラウザの処理負荷を軽減できます。「とりあえずdivで囲む」実装の積み重ねがDOM肥大化の主な原因です。

削除できるwrapperの典型パターン

パターン

Before（削除前）

After（削除後）

1つしか子要素がないdiv

<div><p>テキスト</p></div>

<p>テキスト</p>

CSSのためだけに存在するdiv

<div class="wrap"><ul>...</ul></div>

CSSをulに直接当てる

意味のないネスト

<section><div><div><p>...</p></div></div></section>

<section><p>...</p></section>

Flexboxのためだけのdiv

<div class="flex"><div><span>...</span></div></div>

<div class="flex"><span>...</span></div>

「とりあえず<div>で囲む」実装の積み重ねが主な原因です。

中身が1つだけの<div>、CSSを当てるためだけに存在する<div>、Flexbox・Grid レイアウトのためだけに挟んだ<div>が代表例です。

これらは親要素に直接CSSを当てるか、セマンティックな要素（<p> <ul> <section> 等）に置き換えるだけで削除できます。

テーブル乱用の回避

<table> はブラウザが全セルのサイズを計算してからレイアウトを確定するため、CSS Flexbox・Gridより描画コストが高くなります。

「データの表形式表示」には適切ですが、ページレイアウト目的での使用はReflowを誘発しINP・LCPを悪化させます。

用途を「データ表示のみ」に限定するのが基本です。

NGパターンと代替手段

用途

テーブル乱用

代替手段

ページ全体のレイアウト

<table>で段組み

CSS Grid / Flexbox

横並びナビゲーション

<tr><td>で並べる

<ul> + display:flex

フォームの項目並べ

<table>で整列

CSS Grid / <dl>

画像とテキストの横並び

<td>で配置

Flexbox

データの表示

<table>

そのまま使う（正しい用途）

<table> をレイアウト目的で使うと、ブラウザが全セルのサイズを計算してから描画を確定するため処理が重くなります。

横並びレイアウト・ナビゲーション・フォーム整列はすべて CSS Flexbox・Grid で代替可能です。

「表形式のデータを見せる」用途のみ <table> を使い、それ以外は CSS レイアウトに置き換えるのが基本方針です。

HTMLで効く改善④：画像・iframe・サードパーティを制御する

画像・iframe・サードパーティスクリプトはHTMLの属性指定ひとつで速度が大きく変わる領域です。

loading="lazy" で不要な先読みを防ぎ、width/heightでCLSを防止し、fetchpriority="high" でLCP画像を最優先取得する。

この3つをセットで正しく実装するだけで LCP・CLS・INPを同時に改善できます。

loading="lazy"の活用

loading="lazy"は、ファーストビュー以外の画像・iframeをスクロールで画面に近づいたタイミングで読み込むHTML属性です。

属性1つ追加するだけで初期ロードの帯域消費を大幅に削減できます。

ただしLCP対象の画像に付けると致命的なLCP悪化を招くため、実装前にLCP要素の確認が必須です。

画像への適用例（ファーストビュー以外の画像に活用）

<!-- After：ファーストビュー以外はlazy -->
<img src="/images/photo.webp"
     alt="写真"
     width="800" height="400"
     loading="lazy">

iframeへの適用例（ファーストビュー以外のiframeに活用）

<!-- Google Maps -->
<iframe src="https://maps.google.com/..."
        loading="lazy"
        width="600"
        height="450">
</iframe>

参考：Lazy Loadとは

width/heightの活用

画像・iframeに width / height を指定しないと、ブラウザが読み込み完了までサイズを確定できず後からレイアウトがズレる（CLS悪化）原因になります。

数値を明示することでブラウザが事前にスペースを確保し、画像到着後のガタつきをゼロにできます。

CSSのaspect-ratioでも代替可能です。

width/height の指定確認チェック

下記のようなシーンではwidth/heightを指定あげましょう。

要素

指定方法

効果

<img>

width="800" height="400"

CLS防止・スペース事前確保

<iframe>

width="560" height="315"

同上

レスポンシブ画像

CSS aspect-ratio + height:auto

柔軟なサイズでもCLS防止

広告枠

枠サイズを固定指定

広告読み込み後のガタつき防止

fetchpriority="high"の活用

ブラウザが決めたリソース取得の優先度を high / low / auto で上書きできるHTML属性です。

LCP対象の画像にfetchpriority="high"を付けると、ブラウザが後回しにしていた取得を最優先に切り替えるためLCPに直接効きます。

付けるのはLCP画像の1枚だけが原則です。

fetchpriority="high"の適用例

<!-- LCP画像に高優先度を指定 -->
<img src="/images/hero.webp"
     alt="ヒーロー"
     width="1200" height="630"
     fetchpriority="high">

FAQ（よくある質問）

Q1：「HTMLを圧縮（minify）するとSEOに影響ある？」

A：SEOへの直接的な順位上昇効果はありませんが、ファイルサイズ削減による転送速度向上は微小なプラス要因です。

GooglebotはminifyされたHTMLも問題なくクロール・インデックスします。ビルドプロセスで自動化するのが一般的です。

Q2：「asyncとdeferはどっちが良い？」

A：基本はdeferを推奨します。DOM構築後に実行され、実行順序も保証されるため、依存関係のあるスクリプトでも安全です。asyncは、Googleアナリティクスのような「他の機能に依存せず、いつ実行されても良い」スクリプトに限定して使用します。

Q3：「WordPressでHTML表示速度を改善するには？」

A：プラグイン活用が近道です。①キャッシュ（WP Rocket, W3 Total Cache）、②リソース最適化（Autoptimize）、③画像圧縮（EWWW, Imagify）の3種を導入し、高速なサーバー環境（KUSANAGIなど）を選ぶことが重要です。テーマ自体が重い場合は変更も検討が必要です。

Q4：「LCP画像はlazyでいい？」

A：絶対NGです。LCP画像（ファーストビューで最も目立つ要素）を遅延読み込み（lazy）にすると、表示開始が遅れ、スコアが悪化します。LCP画像は通常のimgタグで、できればfetchpriority="high"を付与してください。

Q5：「改善したのにPSIが変わらないのはなぜ？」

A：いくつかの理由が考えられます。①PSIが過去のキャッシュを参照している、②フィールドデータ（CrUX）は28日間の集計値なので即座に反映されない、③サーバーの応答速度が不安定でボトルネックになっている、などです。DevToolsでのローカル計測も併用して変化を確認しましょう。

Q6：「Core Web Vitalsはランキング要因？」

A：はい、Googleの公式ランキング要因（ページエクスペリエンスシグナル）の一部です。ただし、最も重要なのは「コンテンツの質」であり、表示速度だけで低品質なコンテンツが上位に来ることはありません。「同程度の品質なら速い方が勝つ」という認識が適切です。

HTMLで表示速度を改善方法する方法まとめ

HTMLの表示速度改善は、魔法のような裏技があるわけではなく、「ブラウザのレンダリングプロセスを邪魔しない」「重要なリソースを最優先で届ける」という原則の積み重ねです。

まずはChrome DevToolsで現状のボトルネックを可視化し、deferの活用、画像の適切な属性設定、不要なDOM/CSS/JSの削減といった基本施策から着手してください。

ユーザーにとって快適な「サクサク動くサイト」は、結果として検索エンジンからの評価（SEO）にも繋がります。

記事を書いた人

井上寛生

井上寛生

LandingHub 執行役員 / 事業責任者 / 技術責任者

大学院では情報工学を専攻し、修了後に株式会社TeNへ新卒入社。当時は社内唯一のエンジニアながら、開発部門をゼロから立ち上げ、採用・育成を一手に担い、全員が未経験からスタートした精鋭エンジニアチームを組成。2021 年にはWEBサイト高速化プラットフォーム「LandingHub」を立ち上げ、プロダクトオーナー兼事業責任者として企画・開発・グロースを牽引。現在は執行役員として、会社の技術戦略と事業成長の双方をリードしている。
コラム一覧に戻る