BtoB SaaSのLPで表示速度をどう作るか｜先に整えること

なお、TimeValue株式会社では、広告運用・クリエイティブ制作・LP改善・データ分析・AI導入までを一括で引き受けるWebマーケティング支援「KAIZEN」を提供しています。

現在、オンラインの無料マーケティング診断を毎月10社限定で実施中です。いまの数字を見ながら、どこから直すのが早いかを一緒に整理します。

今月の無料診断は残り4社です

無料マーケ診断を申し込む

広告からLPまで、まとめて見ます。オンラインで30分から対応しています。

BtoB SaaSのLPは広告を出す前に表示速度を整えるべきですか

BtoB SaaSのLPでは、広告開始前に表示速度を確認しておく必要があります。
理由は、広告運用を始めたあとでは、広告側の問題とLP側の問題を切り分けにくくなるためです。

たとえば広告のクリック率は悪くないのに、LP到達後のフォーム遷移率が低い場合があります。
このとき、訴求が弱いのか、フォームの入力負荷が高いのか、ページ表示が遅くて離脱されているのかを同時に調べることになります。

広告開始前に表示速度を一定水準まで整えておけば、広告開始後は訴求やターゲティング、フォーム内容といった別の要因を検証しやすくなります。

広告費を増やすほど表示速度の問題も拡大します

表示速度の問題は、広告費が小さいうちは見過ごされやすいです。
月数万円程度のテストでは、数件のCV差が偶然なのか速度の影響なのか判断しづらいためです。

一方で、月100万円、300万円と広告費を増やした場合、LP到達者数も増えます。
仮の値として、広告クリック後のLP到達者が月5,000人いて、表示速度による離脱が5パーセント発生しているとします。
この場合、250人がLPの内容を十分に見る前に離脱している計算です。

広告単価を下げる施策に時間を使いながら、ページ側で同程度の損失を放置している状態になる可能性があります。

完璧な高速化を待って広告を止める必要はありません

広告開始前に表示速度を整えるといっても、すべての改善を完了させる必要はありません。
高速化には、画像圧縮のように短時間で直せるものと、CMSやフロントエンド構成まで変更しなければならないものがあります。

広告開始前に優先するのは、ユーザーが明らかに待たされる原因です。
ファーストビューの大容量動画、巨大な画像、不要な外部タグ、読み込みを止める外部スクリプトなどが該当します。

構造変更を伴う改善は、広告を開始したあとに継続して進めても問題ありません。
広告配信前には、直す費用と広告で失う費用を比較して、優先順位を決めます。

広告開始前に確認する表示速度の優先順位

BtoB SaaSのLPはなぜ表示速度が遅くなりやすいのですか

BtoB SaaSのLPが重くなりやすい原因は、デザインそのものよりも、ページに載せる機能の多さにあります。

SaaSでは、単純な商品画像と購入ボタンだけで説明を完結させることが難しいです。
サービス画面、導入イメージ、機能説明、利用企業向けの情報、資料請求、デモ予約など、多くの情報を一つのLPに集約することがあります。

さらにマーケティング施策が増えるほど、計測用のタグや外部ツールも増えていきます。

公開時より半年後のほうが遅くなりやすいです

LP制作時には問題がなくても、運用開始後に徐々に遅くなるケースがあります。

広告用の計測タグを追加します。
アクセス解析用のタグを追加します。
ヒートマップを追加します。
チャットツールを追加します。
フォーム改善ツールを追加します。

それぞれの追加は単体では小さく見えます。
しかし、外部サーバーへの通信やJavaScriptの実行が積み重なることで、表示開始や操作可能になるまでの時間に影響します。

特にBtoB SaaSでは、マーケティング担当者ごとに異なるツールを導入し、誰も全体を把握していない状態になりやすいです。

見た目がシンプルでも軽いとは限りません

LPを見たときに画像が少ないからといって、必ずしも軽いとは限りません。

ユーザーからは見えないところで、多数の外部スクリプトが動いていることがあります。
タグ管理ツールの中に複数のタグが設定され、その一部がすでに使われていないケースもあります。

また、表示されている画像が1枚でも、元データが必要以上に大きい場合があります。
小さく表示している画像でも、ブラウザ側で数千ピクセルの画像を読み込んでいれば通信量は減りません。

BtoB SaaSのLPでは、デザインレビューとは別に、読み込んでいるファイルと外部通信を確認する工程を持つ必要があります。

動画やアニメーションはどこまでLPに使ってよいですか

BtoB SaaSでは、文章だけで機能を説明するより、管理画面や操作方法を動画で見せたほうが理解されやすいことがあります。

そのため、動画自体を避ける必要はありません。
問題になるのは、動画をどこに置き、いつ読み込むかです。

ファーストビューの背景動画は特に確認します

ファーストビューに動画を置くと、LPの印象を作りやすくなります。
一方で、ページを開いた直後から大きな動画ファイルを読み込めば、モバイル回線では負荷が高くなります。

BtoB SaaSでは、背景動画として抽象的な演出を流していても、それがサービス理解に直接つながっていないケースがあります。

その場合、広告流入のLPでは静止画に変更し、サービス紹介ページでは動画を残す方法があります。
LPとコーポレートサイトを同じ演出にする必要はありません。

操作デモ動画はクリック後に読み込む方法もあります

サービス画面の操作動画など、検討者にとって価値がある動画は残す意味があります。

ただし、ページを開いた瞬間に動画本体まで読み込む必要はありません。
最初はサムネイルだけを表示し、ユーザーが再生操作をしたあとに動画を読み込む設計もできます。

これにより、動画を見ない訪問者まで同じ通信量を負担する状態を避けられます。

アニメーションも同じです。
すべての見出しや画像を動かすのではなく、内容理解を助ける場所だけに絞ります。

LPの目的は演出を見せることではなく、サービスを理解し、資料請求や問い合わせなどの次の行動に進んでもらうことです。

計測タグやチャットツールはどのように整理すればよいですか

BtoB SaaSのLPでは、表示速度改善のために画像を圧縮しても、外部ツールの読み込みが増え続ければ効果が相殺されます。

特に見直したいのが、計測タグ、ヒートマップ、チャット、ABテスト、フォーム補助などの外部ツールです。

タグは導入目的ではなく現在の利用状況で判断します

以前は必要だったタグでも、現在はレポートで使っていない場合があります。

広告媒体を停止したのに計測タグだけ残っていることもあります。
過去のABテストで使ったスクリプトが残るケースもあります。

削除判断では、誰が入れたのかより、現在誰が使っているのかを確認します。

広告担当者が使っているのか、営業側が使っているのか、サイト改善担当者が使っているのかを整理します。
利用者がいなければ削除候補です。

チャットツールは全ページで必要とは限りません

BtoB SaaSでは、チャットツールを導入して問い合わせ機会を増やすことがあります。

ただし、チャットを全訪問者に即時表示する必要があるかは別の問題です。

たとえば資料請求が主なCVで、チャット経由の商談がほとんど発生していない場合があります。
その状態で重いチャットスクリプトを全ユーザーに読み込ませる意味は限定的です。

チャット経由の成果があるなら、削除ではなく読み込みタイミングを見直します。
一定時間後やスクロール後に起動する方法なども検討できます。

外部ツールを残すか判断するときの確認項目

フォーム埋め込みが遅い場合はどこを確認すればよいですか

BtoB SaaSのLPでは、問い合わせフォームや資料請求フォームを外部のシステムから埋め込むことがあります。

この構成では、LP自体のHTMLや画像が軽くても、フォーム部分の読み込みだけが遅いことがあります。

広告流入では、この違いが成果に直接影響します。
ユーザーがCTAを押したあとにフォームが表示されるまで待たされれば、入力前に離脱される可能性があるためです。

LP表示とフォーム表示を別々に測ります

LPを開いた直後の表示が速くても、CTAを押したあとにフォームが数秒間空白になる場合があります。

逆に、フォーム自体は速くても、LP上部の画像やJavaScriptが重く、フォームまで到達する前に離脱している場合もあります。

そのため、表示速度の確認では、最初のページ表示だけを見ません。

LPを開きます。
CTAまで移動します。
フォームを開きます。
入力を開始します。

実際のユーザー行動に沿って、どの地点で待ち時間が発生しているかを確認します。

埋め込み方法を変えられるか確認します

外部フォームを利用している場合、マーケティング担当者だけでは改善できないことがあります。

制作会社側で読み込み順序を変えられることもあります。
フォーム提供側の設定で不要な機能を減らせることもあります。

また、LPに直接フォームを埋め込む以外に、フォーム専用ページへ遷移させる設計も考えられます。

どちらが良いかは、表示速度だけでは決まりません。
フォーム到達率、入力完了率、計測のしやすさも含めて判断します。

BtoB SaaSでは、LP制作担当者とフォーム管理担当者が別になっているケースがあるため、問題の所在を分けて確認することが欠かせません。

画像の重さはBtoB SaaSのLPでどこから直せばよいですか

BtoB SaaSのLPでは、商品写真よりも管理画面のキャプチャや機能図を多く掲載する傾向があります。

この画像が意外に重くなります。

画面キャプチャは作成時の解像度が高いまま使われることがあります。
デザインデータから書き出した画像も、必要以上に大きなサイズで納品されることがあります。

表示サイズと元画像サイズを比較します

たとえばLP上では横600ピクセル程度で表示しているのに、元画像が横3,000ピクセル以上あるケースがあります。

ブラウザ上では小さく見えていても、大きなファイルを読み込んだあとに縮小表示しているだけなら通信量は大きいままです。

まず、LPで実際に必要な表示サイズを確認します。
そのうえで画像を書き出し直し、適切に圧縮します。

画像形式も確認しますが、形式変更だけで解決したと考えないほうが安全です。
元画像の解像度や品質設定が適切でなければ、形式を変えても十分に軽くならない場合があります。

ファーストビューから先に直します

ページ下部にある画像より、ページを開いた直後に読み込む画像を優先します。

広告から訪問したユーザーは、最初の画面が表示される前にはサービス内容を判断できません。
そのため、ファーストビューの画像が重い状態は優先して修正します。

サービス画面のキャプチャが何十枚もある場合は、画面外の画像を最初からすべて読み込まない設計も検討します。

ユーザーがスクロールして近づいた段階で読み込めば、初期表示の負担を下げられます。

画像最適化では、すべての画像を同じ基準で一括処理するより、初期表示に影響する順番で対応したほうが広告開始前の改善として効率的です。

表示速度はデスクトップだけ確認すれば十分ですか

BtoB SaaSでは、業務中にパソコンで比較検討されるイメージが強いため、LP確認もデスクトップ中心になりやすいです。

しかし広告接触と最終的な検討が同じ端末で行われるとは限りません。

移動中にスマートフォンで広告を見る人もいます。
SNSや動画経由で初めてサービスを知る人もいます。

広告管理画面でモバイル流入が発生しているなら、モバイルでの表示速度は無視できません。

社内Wi-Fiだけで確認しないようにします

制作会社や社内の確認では、高速なWi-Fi環境でLPを見ることが多いです。

その環境では問題なく見えていても、モバイル回線では画像や動画の読み込みが目立つ場合があります。

確認するときは、スマートフォンの実機でもページを開きます。
広告クリック後と同じようにLPを開き、フォームに到達し、入力開始まで進みます。

単にページが開くかではなく、ユーザーが途中で待たされる場所がないかを見ます。

数値と体感を両方確認します

速度改善では測定ツールの数字だけを追いかけると、ユーザー体験とズレることがあります。

数値上の評価が多少低くても、見出しやCTAが早く表示され、操作できる状態なら広告配信を開始できる場合があります。

反対に、総合スコアが悪くなくても、CTAを押したあとのフォーム表示だけ極端に遅いことがあります。

広告開始判断では、測定値と実際の操作を組み合わせます。

BtoB SaaSのLPで確認するモバイル操作

表示速度の改善は社内と制作会社でどう分担すればよいですか

BtoB SaaSのLPで表示速度を改善するとき、技術的な作業だけを制作会社へ依頼しても進まないことがあります。

理由は、制作会社だけでは削除してよい機能を判断できないためです。

計測タグを削除してよいのか、動画を静止画にしてよいのか、チャットを遅延表示してよいのかは、マーケティング上の判断です。

制作会社は技術的に削除できても、事業側の意図までは決められません。

社内は何を残すかを決めます

社内で最初に整理するのは、LPに必要な機能です。

動画が商談前の理解促進に必要なのかを確認します。
チャットから商談が発生しているかを確認します。
ヒートマップを現在も分析に使っているかを確認します。
広告タグがすべて現役なのかを確認します。

これらの判断は、制作会社ではなく事業会社側が持ちます。

マーケティング担当者だけで分からない場合は、広告担当、営業担当、サイト担当で確認します。

制作会社には原因と対応方法を分けて聞きます

制作会社へは、単に速くしてくださいと依頼しないほうが進めやすいです。

ファーストビューが遅い原因は何かを確認します。
どのファイルや外部通信が影響しているかを確認します。
改善方法ごとの工数を確認します。
デザインや計測への影響も確認します。

たとえば動画を削除すれば速くなるとしても、サービス理解への影響があります。
読み込み方法を変更するだけで同程度の改善ができるなら、そちらを選べます。

技術的な選択肢を出してもらい、事業側が優先順位を決める進め方が適しています。

担当者を決めないと再び遅くなります

一度LPを高速化しても、その後タグやツールを自由に追加すれば再び重くなります。

そのため、公開後の管理ルールも必要です。

新しいタグを追加するときに誰が確認するのかを決めます。
新しい外部ツールを導入するときに速度影響を確認する担当者を決めます。

表示速度改善を一度きりの制作作業にせず、LP運用のルールとして扱うことが必要です。

広告費をかける前に表示速度はどこまで直せばよいですか

表示速度改善には終わりがありません。

画像をさらに軽くできます。
コードもさらに整理できます。
外部サービスの読み込み方法も改善できます。

そのため、広告を始める前にどこまで直すかという線引きが必要です。

判断基準は、技術的に理想的かではなく、広告費を使って集客してよい状態かです。

ユーザーが待たされる問題を先に消します

広告開始前に優先して直すのは、ユーザーが明確に感じる遅さです。

LPを開いても数秒間内容が分からない状態は優先度が高いです。
CTAを押しても反応が分からない状態も優先度が高いです。
フォームがなかなか表示されない状態も優先度が高いです。

これらはCVに近い行動を直接妨げます。

一方で、技術測定上の小さな改善を何週間も続け、広告開始を延期する必要はありません。

改善工数と広告損失を比較します

仮の値として、制作会社への改善費用が20万円かかるとします。

一方で月200万円の広告を配信し、速度によって数パーセントのユーザーが余計に離脱していると考えられるなら、先に改善する価値があります。

逆に、改修に数か月かかる大規模なシステム変更しか方法がなく、現在のLPでもユーザー操作上の大きな問題がないのであれば、広告を開始しながら改修を進める判断もできます。

表示速度の改善費だけを見るのではなく、広告費と機会損失を合わせて考えます。

広告開始後も速度を変更履歴に残します

広告配信後にLPの速度改善を行った場合、その日付を広告運用側でも記録します。

CVRが改善したときに、広告クリエイティブの影響なのか、LPの表示改善によるものなのかを判断しやすくするためです。

タグ削除、画像軽量化、動画変更、フォーム変更などは、広告成果へ影響する可能性があります。

BtoB SaaSのLPでは、広告運用とサイト改善を別々の仕事として管理すると、原因の切り分けが難しくなります。

広告開始前に最低限の速度を整え、開始後は流入データを見ながら改善する進め方が現実的です。

よくある質問

まとめ