LPの表示速度がCVRに影響する？表示速度を改善する11の方法を徹底解説！

皆さんこんにちは。クロスバズでLPのコーディングをしている、けんてぃーです。 

突然ですがLPを運用していてこんな悩みをお持ちではないでしょうか？ 
「CVRがなかなか伸びない…」「何故か離脱率が高い…」

それはLPの表示速度によるものかもしれません。

どんなに素晴らしいLPでも、表示速度が遅くては離脱に繋がってしまう恐れがあります。
非常に勿体無いですよね。

この記事を読めば表示速度を改善する手立てが見つかるはずです。
表示速度を改善して、LPの効果を最大限発揮させましょう！

なぜLPの表示速度は重要なのか？表示速度がLPの成果を大きく左右する

皆さんこういう思いをしたことはないですか？
Webサイトを開いた時に「なかなかページが表示されない…別のページ見よう」と。

私もそのような経験がたくさんあります。ページがなかなか表示されないと別のサイトへと移動してしまいますよね。

LPの表示速度が遅いと表示を待ちきれずにユーザーは離脱してしまいます。また、離脱されるだけでなく広告やSEOにも影響を及ぼします。詳しく見ていきましょう。

離脱率・CVRに影響する

先程もお話したようにLPの表示速度が遅いとユーザーは離脱しやすくなってしまいます。

実際に、読み込み時間が1秒から10秒になると直帰する確率が123%増加するというGoogle/SOASTAの調査データがあります。(出典：Think with Google「New Industry Benchmarks for Mobile Page Speed」）

逆に、表示速度が0.1秒改善しただけでCVRが小売は+8.4%・旅行は+10.1%改善したというデータも存在しています。（出典：web.dev ケーススタディ）

わずかな速度改善でも数値が大きく動く可能性があるとは驚きですよね。

このように、LPの表示速度はCVRを大きく左右しうる要因の一つと言えます。

※上記調査は複数の指標が改善した場合などの条件も含むため、必ずしも「0.1秒改善すれば必ず改善する」というものではありませんが、速度改善が成果に効きうることを示すデータと言えます。

SEO（検索順位）に影響する

またLPの表示速度はSEOにも影響を及ぼします。

SEOにおいては、LPのコンテンツだけではなく、LPの表示速度も検索順位に影響してきます。

2021年から、Google検索のランキング要素に表示速度を含むユーザー体験の指標「Core Web Vitals（ページエクスペリエンス）」が組み込まれています。

表示速度を含むページエクスペリエンスは、Google検索のランキングで考慮される要素の一つです。

ただし、検索順位はコンテンツの有用性や検索意図との一致など、他の多くの要素も含めて総合的に判断されます。速度だけで大きく順位が決まるわけではない点には注意しましょう。
（出典：Google検索セントラル「Core Web Vitals と Google 検索の検索結果について」）

広告評価や広告ランクに影響する

LPの表示速度の遅さは、SEOに留まらず広告にも影響してきます。 

具体的には表示速度の遅いLPはクリック単価が上がったり、広告の掲載順位が下がったりすることがあります。

なぜこのような事が起きるのかというと、広告のクリック単価や掲載順位は「広告ランク」という評価で決まるからです（※1）。

そしてこの広告ランクを左右する要素のひとつに「ランディングページの利便性」が含まれています(※2)。

ここでいうランディングページの利便性とは、表示速度や使いやすさといったユーザー体験の良し悪しのことです。

まとめると、
表示速度が遅い→「ランディングページの利便性」の評価が下がる→広告品質が下がる→広告ランクが下がる
といった流れでクリック単価が上がったり掲載順位が下がってしまう恐れがあるので広告運用しているサイトは特に要注意です。

なお、Google広告には管理画面で確認できる「品質スコア」というものがありますが、こちらはあくまで広告を改善をするための目安となり、実際の評価に使われるスコアではありません。（※3）。
実際の評価は、ユーザーが検索した瞬間にその都度判定されています。品質スコアはあくまで参考、と捉えておきましょう。

※1出典：Google広告ヘルプ「広告ランクについて」
※2出典：Google広告ヘルプ「ランディング ページの利便性を把握する」
※3出典：Google広告ヘルプ「検索キャンペーンの品質スコアについて」

まずは自社LPの表示速度を計測してみよう。計測方法と数値の見方を解説

ここまで、LPの表示速度がどう影響してくるかをお話してきました。

LPの表示速度が遅いとCVRやSEO、広告までにも影響を及ぼすということがわかったかと思います。 

ここですぐ改善と行きたいのですが、その前に今のLPがどれくらいの表示速度なのか計測してみましょう。計測することで何が悪いのか、そして改善すべき箇所が見えてきます。 

また、実際に改善されたかが体感ではなく、数値で確認できるので、施策を行う前に必ず計測しておきましょう。 次は計測の仕方とその見方を解説します。

PageSpeed Insightsで計測する

まずはじめに、LPの表示速度は「PageSpeed Insights」というサイトを使って計測することができます。

PageSpeed Insightsを開くと以下のような画面が表示されます。

上部の「ウェブページのURLを入力」に計測したいサイトのURLを入れて「分析」を押してみましょう。

すると下記のような画面が出てきます。

まずURLの下に「携帯電話」「デスクトップ」とあります。
PageSpeed Insightsの計測結果は「携帯電話」と「デスクトップ」とで異なってきます。

そのため計測したいサイトはどちらをターゲットにしているか、適した方の数値を確認することをおすすめします。

もちろん余裕があればどちらも改善したほうが良いですが、時間がないと言う方はターゲットに合わせて改善をしていきましょう。

様々な数値が出てきていますが、詳しい数値の説明は次で行います。

また、検証ツール(デベロッパーツール)でも表示速度を計測することができます。

1. サイト内で右クリック
2. 検証（デベロッパーツール）を開く
3. 上部のタブから「Lighthouse」を選択（「要素（Element）」や「コンソール（console）があるタブの右側にあります）
4. 計測したいデバイスを選択し、右上の「ページ読み込みを分析」をクリック

上部タブにある「Lighthouse」をクリックすると以下のような画面が出てきます。

「Lighthouse」の画面を開けたら測定したいデバイスを選択し、右上にある「ページ読み込みを分析」を押すと、表示速度を計測できます。

その他、「モード」や「カテゴリ」などがありますが、「モード」はデフォルトの「ナビゲーション」、「カテゴリ」はすべてチェックが入った状態で問題ありません。

「PageSpeed Insights」、「Lighthouse」はどちらも表示速度を計測できますが、「PageSpeed Insights」は公開中のURLが対象で、条件を満たせば実際にそのページを訪れたユーザーの数値も確認できます。

一方で「Lighthouse」は開発途中（ローカル環境）でも使え、こちらは自分のPC・ブラウザ上でのテスト計測になります。

そのため、公開されているURLであれば「PageSpeed Insights」、開発途中で計測したいという場合は「Lighthouse」という使い分けが良いと思います。

実際に計測することができたら、数値を見ていきましょう。

見るべき指標と数値

先程の計測結果で出てきた数値の説明と、どこを見るべきかを解説します。

「PageSpeed Insights」では英語の指標が沢山出てきますが、それぞれ以下のような意味を持っています。

まず大枠をつかむなら、PageSpeed Insights下部の「パフォーマンスの問題を診断する（0〜100点）」を見ましょう。
「パフォーマンスの問題を診断する」は「Lighthouse」によるテスト計測結果で、LCPやCLS、TBTなど複数の指標を元に算出される総合評価です。

検証ツールで計測できる「Lighthouse」と同じものです。

「Lighthouse」では主に以下の4項目が0点〜100点で診断されます。

• パフォーマンス 
• ユーザー補助
• おすすめの方法
• SEO

それぞれ以下の要素を評価をしています。

LPの表示速度に焦点を当てるのであれば、このうち「パフォーマンス」の数値を確認すれば大丈夫です。

理想の表示速度・目標スコアの目安は？

計測が完了すると、実際にどのくらいの数値が良いの？と思われるかと思います。 目指すべきスコアは以下の数値を参考にして下さい。

「Lighthouse」の数値については、90以上が「良好」／50〜89が「改善が必要」／49以下が「低い」が目安です。
（出典：Chrome for Developers「Lighthouse のパフォーマンス スコアリング」）

LPの表示速度を改善する方法は？効果の高い施策から順に解説

ここまで、LPの表示速度の重要さ、計測方法と数値の見方を解説してきました。
では、その計測結果を元に実際に施策を行っていきましょう。

効果の高い順に解説をしますが、計測結果を元にピンポイントで行うことも大切になってきますので、自社のサイトの課題に合わせて施策を行っていきましょう。

最優先で確認すべき4つの項目

まず最優先で確認すべき4つを紹介します。

• FV / LCP要素の最適化
• 画像の最適化（圧縮・WebP化・リサイズ）
• 画像や動画・iframeの遅延読み込み
• JavaScriptの読み込み制御（defer/async・レンダリングブロック解消）

こちらはどのサイトでも必ずと言ってよいほど行なうものになってきます。
 何からやったらいいかわからない…という方はまずここだけでも良いので確認してみましょう。

1.FV / LCP要素の最適化

1つめはFV / LCP要素の最適化です。（FV=ファーストビュー。LCP（Largest Contentful Paint）とは、Webページの初期表示において、画面内で最も大きなコンテンツが表示されるまでの時間を示す指標のことです。）

LCPは、初期表示の画面内で最も大きく表示される画像やテキストブロックが表示されるまでの時間を指します。LPではFVのメインビジュアルがLCP要素になることが多いです。

例えばページ全体を早くしても、この最初の大きなコンテンツの表示速度が遅ければユーザーからは何も見えず、離脱に繋がってしまいます。

では実際にどう最適化を行なうかというと、FVのメインビジュアルが 「<img> 」で実装されている場合は、以下のように指定します。

改善前

<img
  src="assets/img/fv.webp"
  alt=""
/>

改善後

<img
  src="assets/img/fv.webp"
  alt=""
  loading="eager"
  decoding="async"
  fetchpriority="high"
/>

ここでは3つコードを追加しました。

• loading=”eager”
• decoding=”async”
• fetchpriority=”high”

それぞれ詳しく解説します。

「loading=”eager”」 は画像をすぐに読み込むための指定です。FVのメインビジュアルのように、初期表示で必要な画像には適しています。

「decoding=”async”」は画像を表示するための準備を、ページの描画と同時に行うようにする指定です。画像の処理でページの表示が止まりにくくなるため、表示速度の向上が期待できます。

「fetchpriority=”high”」 は、指定した画像を優先的に取得するようブラウザに伝える指定です。LCP要素になりやすいFVのメインビジュアルなどの特に重要な画像に指定します。

なお 「fetchpriority=”high”」 はLCP候補となる画像（多くの場合FVのメインビジュアル1枚）に付けるのが効果的です。

FV内のすべての画像に付けてしまうと優先度の差がつかず効果が薄れるとされているので、付けるのは最も大きく目立つ1枚に絞りましょう。 
参考：web.dev「Largest Contentful Paint（LCP）を最適化する」

また、状況によってはプリロード指定も有効です。
プリロードとは、初期表示に必要な画像などをブラウザに早めに読み込ませるための指定です。

特にCSSの背景画像や、JSなどであとから差し込まれる場合は、ブラウザが画像を見つけるのが遅くなることがあります。

そのような場合に、<head>内で以下のように指定をすると、画像を早めに読み込ませることができます。

<link
  rel="preload"
  as="image"
  href="assets/img/fv.webp"（早く読み込ませたい画像）
  type="image/webp"（webpの部分は指定する画像の拡張子に合わせて変更して下さい。）
  fetchpriority="high"
/>

このようなコードを<head>内に記述することによって指定された画像は優先的に読み込まれ、最初に開いた際に表示されやすくなります。

逆に、通常の 「<img>」 でページの早い位置に書かれている画像なら、「fetchpriority=”high”」を付けるだけで十分なこともあります。

2.画像の最適化（圧縮・WebP/AVIF化・リサイズ）

LPの表示速度を速めるために、次に行うべき施策は画像の最適化です。画像の最適化とは画像の圧縮、WebP化、リサイズのことを主に指します。

ここでは画像の圧縮、WebP/AVIF化、リサイズのやり方と、それぞれの注意点を解説します。

画像の圧縮

まず画像の圧縮です。圧縮にはいくつか方法がありますが、お手軽なのはブラウザ上で使えるツールです。代表的なのが「TinyPNG」で、画像をドラッグ＆ドロップするだけで圧縮してくれます。

ただ無料版だと一度に圧縮できるのは20枚まで、1枚あたり5MBまでといった制限があります。枚数が多いときは何回かに分けて使う形になります。

同じくブラウザで使える「Squoosh」というものもあり、こちらは圧縮の強さを見た目で確認しながら調整できるので、画質にこだわりたいときはおすすめです。

枚数が多い・毎回手作業は嫌だという場合は、アプリを入れてしまうのも手です。Macなら「ImageOptim」が定番で、フォルダにまとめて放り込むと一括で圧縮してくれます。

画像を圧縮する際の注意点としては、圧縮をしすぎると画質が劣化してしまいますので適度に調節しましょう。

画像のWebP、AVIF化

次に画像のWebP/AVIF化です。 WebPは、JPEGやPNGよりも軽量にできることが多く、PNGの透過も保持できる次世代画像フォーマットです。

注意点としては、WebPは古いブラウザだと対応していないことがあります。現在は主要なブラウザで広く対応しているので、通常の用途であれば問題なく使えます。

WebP化するには「サルワカWebツール」などのサイトを使うと良いでしょう。

さらに圧縮効率を重視する場合は、AVIFという選択肢もあります。
AVIFはWebPと同様に、JPEGやPNGよりも軽量にできることが多く、WebPと同じような画質でも容量を小さく出来る場合があります。

注意点としては、WebPに比べ画像編集ソフトなどでは対応していないものもあり、WebPに比べると扱いづらいといったことがあります。

画質や圧縮率にこだわりたい場合はAVIFを使い、汎用性や扱いやすさを重視したい場合はWebP、という使い分けがおすすめです。

AVIF化は圧縮のときにも記載した「Squoosh」などで行なうことができます。

画像のリサイズ

最後に画像のリサイズです。

例えば100pxで表示させるものに対して、1000pxの画像を用意する必要はありません。画像サイズが大きくなればなるほど容量も増えてしまうので、画像サイズが最適かどうか確認しましょう。

目安としては、Retina（高解像度ディスプレイ）対応も考えて、表示サイズの2倍程度までを基準にし、必要に応じて端末に合った画像を出し分けるのが理想です。

表示サイズの2倍程度を大きく超えると容量だけ増えて画質のメリットはほぼ無くなります。

ただ画像の内容によっても最適なサイズは変わるので、その場合は画質や容量との相談になります。

3.画像や動画・iframeの遅延読み込み

LPの表示速度を改善するうえで、 画像や動画の遅延読み込みも有効です。 

遅延読み込みとは、FVなどの初期表示で見えていない画像やiframe※の読み込みを後回しにできる仕組みです。

遅延読み込みをすることによって、ページを開いた際の読み込み時間を短縮し、FVなど初期の表示速度の改善が見込めます。

※iframeとは別のWebページを自分のページに埋め込む際に使用するHTMLタグです。Youtubeの動画やGoogleマップなどを埋め込みたいときに使えます。

方法としては「<img>」や「<iframe>」に「 loading=”lazy”」を追加して下さい。

<img
  src="assets/img/example.webp"
  alt=""
  loading="lazy"
/>

「loading=”lazy”」は画像（img）とiframeで広く使えます。動画（videoタグ）もブラウザによっては「loading=”lazy”」 を使えますが、確実に制御したい場合は 「preload=”none”」 を指定する、ポスター画像を設定する、スクロール時に埋め込むなど、別の対応を併用するのが安全です。

ただし注意点があり、「 loading=”lazy”」は遅延読み込みなので、FVなど最初に表示されるコンテンツにつけてしまうとLCPの悪化につながる可能性があります。 あくまでも最初は見えない画像やiframe コンテンツに「 loading=”lazy”」を追加しましょう。

4.JavaScriptの読み込み制御（defer/async・レンダリングブロック解消）

JavaScript（JS）は、読み込みや実行の間ページの表示を止めてしまうことがあり、これをレンダリングブロックと言います。

ブラウザはHTMLを上から順に読んでいくのですが、その途中でJSがあると一度読むのを止めてJSを処理します。その間はページが表示されないので、JSが多いと表示速度が遅くなってしまいます。

レンダリングブロックを防ぐ方法の一つが「defer」と「async」です。外部JS(別ファイルのJS)の「<script>」 タグに指定することで、HTMLの読み込みを止めにくくできます。

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

「defer」は「HTMLを全て読み終わってから順番に実行する」、「async」 は「読み込めたものから順不同で実行する」という違いがあります。 

基本的には表示を優先したいので、まずは 「defer」 を付けておけば大きく間違うことはありません。ただ、JSの実行する順番が関係するものは 「async」 だと挙動が崩れることがあるのでそこだけ注意が必要です。

計測結果によってやるべき項目

続いて、LPの表示速度の改善のために、必要に応じて改善するべき施策を紹介します。

• Webフォントを見直す
• キャッシュの最適化
• 画像にwidth/height指定

上記については絶対にやるべきもの、というものではなく計測結果を元にピンポイントで行うべき施策です。

5.Webフォントを見直す

LPに使用されていないフォントが読み込まれていませんか？
例えば、HTMLのlinkタグ、CSSの@import、@font-faceなどで不要なフォントを読み込んでいると、その分だけ通信が増えて表示速度に影響を及ぼす可能性があります。

そのため、読み込むフォントは実際に使用しているものだけに限定することをおすすめします。

PageSpeed Insights に「使用していないフォントを削除」などの指摘が出ていたら、不要なフォントが読み込まれていないか確認しましょう。

6.キャッシュの最適化

キャッシュとは一度開いたページの画像やCSS・JSを、ブラウザに一時的に保存しておく仕組みのことです。

一時的に保存しておけば、次に同じページを開いたときに毎回ダウンロードし直さずに済むので、2回目以降の表示が速くなります。

設定はサーバー側で「このファイルは◯日間は保存しておいてよい」と期限を指定する形になります。画像やCSSなど、頻繁には変わらないファイルほど長めに設定しておくと効果的です。

ただキャッシュの設定はサーバーの設定ファイル（.htaccessなど）を触る必要が出てくるので、不安があれば専門の方に任せたほうが安全かと思います。

計測結果（PageSpeed Insights）に「効率的なキャッシュ ポリシーで静的アセットを配信する」という指摘が出ていたらキャッシュの設定を見直してみましょう。

7.画像にwidth/height指定

画像にwidth/heightを指定しないと、レイアウトシフト（CLS）と言って、スクロールしていった際に、レイアウトが崩れてしまうことがあります。レイアウト崩れを防ぐために、画像にはwidth/height指定を指定しましょう。

width/heightの指定は、LPの表示速度を直接早くする施策ではありませんが、ページの見やすさや使いやすさを改善する重要な施策です。

特に「loading=”lazy”」で画像を遅延読み込みをする場合は、widthとheightもあわせて指定しておくことをおすすめします。
画像の表示スペースをあらかじめ確保できるため、画像が後から読み込まれた際のレイアウト崩れを防ぎやすくなります。

PageSpeed Insights に「画像のwidth/height未指定」などと出ている場合は、画像にwidth/heightを指定することをおすすめします。

余裕があれば見直したい項目

最後に紹介する施策は少し設定が難しく、専門知識を要する項目です。

• テキストの圧縮（Brotli / gzip）
• 不要なCSSやJSを削除
• CDNを活用する
• サーバー応答（TTFB）の改善

この4項目は無理に全てを対応する必要はありません。サーバー設定や、コードを大きく変更するため、必要に応じてエンジニアや制作会社に相談しつつ進めましょう。

8.テキスト圧縮（Brotli / gzip）

HTMLやCSS、JSといったテキストのファイルは、サーバーからブラウザに送る前に圧縮しておくことができます。その圧縮の方式が「gzip」や「Brotli」です。
zipで圧縮してから送って、受け取った側で解凍する、というイメージです。

ファイルの容量が小さくなる分、転送にかかる時間が短くなるので表示が速くなります。

Brotliのほうがgzipより圧縮率は高いですが、まずはどちらかが有効になっていれば十分です。

テキスト圧縮もサーバー側の設定になるので、有効になっているか分からない場合は、計測結果（PageSpeed Insights）に「テキスト圧縮の有効化」という指摘が出ていないか確認してみましょう。

9.不要なCSSやJSを削除

CSSやJSの容量もLPの表示速度に影響してきます。そのため、使用していないCSSやJSは削除をすることをおすすめします。

ただ、そのコードが本当に使われていないか確認せず削除してしまうと、意図しない挙動になってしまう恐れがあるのでしっかり確認しましょう。

PageSpeed Insights に「使用していない JavaScript の削減」「使用していない CSS の削減」と出ている場合は、不要なCSSやJSを削除することをおすすめします。

10.CDNを活用する

CDNは、世界中に配置されたサーバーの中から、ユーザーに一番近い場所のサーバーが画像などを配信してくれる仕組みです。 

通常はWebサイトを置いているサーバー1か所から、ユーザーのブラウザへ画像や、CSS、JSなどのデータを届けますが、距離が遠いほど時間がかかってしまいます。

CDNを使うと近いサーバーから届くので、その分速くなるというわけです。アクセスが集中したときにサーバーの負荷を分散できるというメリットもあります。

画像や動画など重たいファイルが多いLPほど効果が出やすいですが、導入にはサービスの契約や設定が必要になるので、ここは専門の方と相談しながら進めるのがおすすめです。

CDNはPageSpeed Insights に直接の指摘項目はありませんが、TTFB（サーバー応答）が遅い・画像や動画が多い・全国や海外からアクセスがあるLPで効きやすいので、当てはまる場合は検討してみましょう。

11.サーバー応答（TTFB）の改善

TTFB（Time to First Byte）は、ブラウザがリクエストを送ってから、サーバーが最初のデータを返し始めるまでの時間のことです。

ここが遅いと何をしても最初の一歩が遅くなってしまいます。 
原因はさまざまで、サーバーの性能不足だったり、ページを表示するたびに重たい処理が走っていたりといったことが考えられます。

対策としては、サーバーのプランを見直す、先ほどのキャッシュを効かせる、CMSなら不要なプラグインを減らす、などがあります。

ただ原因の特定にはある程度専門の知識が必要になるので、計測結果でTTFBが目立って遅い場合は、サーバー周りに詳しい方に見てもらうのが確実です。

【実例】最優先項目4つを実際に試してみた

ここまで様々な施策を紹介してきましたが、実際どれくらい効果があるの？と気になった方も多いと思います。

そこで自社で運用しているLPを使用して、最優先項目の4つを順番に試しスコアがどう変わったのか計測してみました。 

ここで言う「スコア」とは、「Lighthouse」による計測結果のことです。
「Lighthouse」の数値については、90以上が「良好」／50〜89が「改善が必要」／49以下が「低い」が目安となっており、スコアが高い=表示速度が速いということになります。
（出典：Chrome for Developers「Lighthouse のパフォーマンス スコアリング」）。

検証環境、前提は以下の通りです。

• デスクトップの数値を計測（今回のLPはPCファーストのため）
• 画像85個、動画1つが入った約16000pxのLP
• ツール：Lighthouse（今回はテストのため開発環境で計測）

※計測のブレを少なくするため5回計測を行いその平均値を取っています。
また、表示速度のパフォーマンスの値に焦点を当てていますのでご了承下さい。

改善前のスコア

まず何も施策を行っていない段階のスコアです。

5回計測した結果は「40、53、41、41、40」で平均にすると43点でした。

実際に試した施策

ここから、「1. FV / LCP要素の最適化」、「2.画像の最適化（圧縮・WebP/AVIF化・リサイズ）」、「3.画像や動画・iframeの遅延読み込み」、「4.JSの読み込み制御（defer/async）」を順番に行いながら、その都度5回計測しました。平均スコアの推移がこちらです。 

• 改善前（なし）：約43点
• 1. FV / LCP要素の最適化：約60点（+17）
• 2. 画像の最適化（圧縮・WebP化・リサイズ）：約64点（+4）
• 3. 画像や動画・iframeの遅延読み込み：約67点（+3）
• 4. JSの読み込み制御（defer/async）：約68点（+1）

各段階の計測画面はこちらです。

1.FV/LCP最適化後

2.画像の最適化後

3.遅延読み込み後

4.JS読み込み制御後

一番効果が大きかったのは「FV / LCP要素の最適化」でした。
このことから、FV内のLCP要素を早く表示させることがスコア改善にとってとても重要だとわかります。

次に効果が大きかったのは「画像の最適化」でした。画像が多く使われていることから、画像の施策も大きく効いた形です。

また、体感ですが「FV / LCP要素の最適化」と「画像の最適化」を行ったあとは目に見えるほど、ページの読み込み速度が上がったと実感しました。

反対に「JSの読み込み制御（defer/async）」ではほぼ数値が変わりませんでした。
今回テストしたサイトが、JSをあまり使用していないものだったためかと思われます。JSが多いサイトなどであれば効果が変わってくるかと思いますので、最初の計測でどこに問題があるのか把握しておくことが大事ですね。

改善後のスコア

まとめるとパフォーマンスのスコアが約43点だったものが、4つの施策を行うことによって約68点まで上げることができました。

今回行った4つの施策については、コードを大きく触ることはなく、画像の最適化や少しのコード記述をおこなっただけでパフォーマンスのスコアを大きく改善できました。

目安の90点には届かなかったものの、25点アップと大きく改善されたのではないでしょうか。

このスコアアップは、そのままLPの表示速度が上がったことを意味します。

さらに90点以上を目指す場合は、画像の出し分けや未使用のCSS/JSの削減、Webフォントの改善、外部タグの整理、テキスト圧縮やサーバーの設定など、より踏み込んだ施策が必要になってきます。

どこまで自分で試せて、どこからプロに任せるか

ここまで11個の施策を紹介してきましたが、「どこまで自分でやれるんだろう？」と感じた方もいるかと思います。

ここでは専門的な知識がない方でも取り組みやすい施策と、専門家に任せたほうが安全なものに分けて整理します。自社LPでどこまで手をつけるかの参考にしてみてください。

誰でも取り組みやすい施策

比較的簡単にでき、コードの修正も軽微な施策は以下の通りです。

• 画像の最適化（圧縮・WebP/AVIF化・リサイズ）
• 画像にwidth / heightの指定
• 画像や動画・iframeの遅延読み込み
• FV / LCP要素の最適化
• Webフォントの見直し

まずLPの表示速度を改善する際に試すべきは画像の圧縮やWebP/AVIF化、リサイズです。画像に関するものはコードを触らずに対応できることが多く、画像が多いLPでは表示速度を改善するうえでかなり効果的です。

また、「画像へのwidth / heightの指定」や「画像やiframeへのloading=”lazy”」の指定、「FV / LCP要素の最適化」「Webフォントの見直し」については、比較的軽いコードの追加、修正で対応できます。

ただし、「FV / LCP要素の最適化」についてはLCP要素が画像なのか、CSSの背景なのか、テキストなのかによって対応が変わってくるため、不安があれば専門の方に相談するのが安心です。

コードやサーバの設定が必要なもの

一方で、コードやサーバーの設定が複雑で、専門的な知識を有するものは以下の通りです。

• JavaScriptの読み込み制御（defer / async）
• キャッシュの最適化
• テキスト圧縮（Brotli / gzip）
• 不要なCSSやJavaScriptの削除
• CDNを活用する
• サーバー応答（TTFB）の改善

このあたりは一つ間違えるとサイトの表示が崩れたり、動かなくなってしまうこともあります。設定する箇所もわかりにくかったりするので、無理に自分で進めず専門の方に任せるのが安全です。

画像まわりや軽いコード修正は自分でやってみて、それ以外は相談するといったぐらいがちょうどよい線引きかと思います。

まとめ：LPの状態に合った施策で表示速度を改善しよう

LPの表示速度を改善するために様々な施策を紹介してきましたが、ここまでの中で一番大事なことは、それぞれのLPに合った施策を行うということです。

サーバー設定などは環境によってはLPの表示速度が逆に遅くなってしまうということも考えられるため、計測結果を元に必要なものだけ改善しましょう。 

LPに合った施策を行うことでLPの効果を最大限発揮させましょう。

バズLPでは競合調査からセールスストーリーの設計・デザイン・コーディングまで一貫して制作をしています。「速度を改善してもCVRが伸びない」「この際、根本からLPを作り直したい」という段階のご相談も歓迎です。

無料でご相談いただけますので、ぜひお気軽にお問い合わせください！

なんか、凄いバズLPの詳細はこちら