サイトのページが表示されるまでの速度が遅いとサイトへの流入数(率)やコンバージョン数(率)が低下すると一般的には言われています。そのためサイトの表示速度を改善することは、コンバージョン数の増加にもつながっていくと言っても過言ではないです。
サイトの表示速度はGoogleが提供しているPageSpeed Insightを使うことで確認することができます。PageSpeed Insightを使ってサイトの表示速度に対するパフォーマンスを確認し、改善を行なっていくフローを紹介いたします。
ページ表示速度とトラフィック・コンバージョンの関係性
ページの表示速度が落ちることで、数値が悪化する事例や逆にページの表示速度が上がることで好転する事例もあります。ページ表示速度がビジネスに及ぼす影響を想像することは難しいかもしれないですが、誰もが知っている有名ブランドもページ表示速度との影響度に注目をしています。
数値が悪化した事例
ページの表示が100ミリ秒(0.1秒)遅くなるごとに売上が1%減 (Amazon)
Slides from my talk at Stanford
ページの表示が500ミリ秒(0.5秒)遅くなると検索数が20%減 (Google)
Slides from my talk at Stanford
ページ表示速度が1秒から3秒になると直帰率が32%増加。6秒になると106%増加。10秒まで遅くなると123%まで増加する。また表示が3秒以上かかるモバイルページからは53%のユーザーが離脱している (Google)
Find Out How You Stack Up to New Industry Benchmarks for Mobile Page Speed
数値が好転した事例
表示速度が10％上がると、約1％の売上増が見込め、35％上昇すると5％もの売上アップにつながる (eBay)
Measuring Real User Experience with Site Speed Gauge
ページの読み込み時間を1秒短縮することでトラフィックが2％増加し、ページの読み込み時間が100ミリ秒減少するごとに1％のコンバージョンが増加した (Walmart)
5 Reasons Visitors Leave Your Website
ページ表示時間を2.2秒改善したところ、年間でFirefoxのダウンロードが6千万回増加 (Mozilla)
Firefox & Page Load Speed – Part II
待ち時間が 40% 減少し、SEO トラフィックが 15% 増加し、サインアップへのコンバージョン率が 15% 増加した (Pinterest)
Driving user growth with performance improvements
ページ表示速度の改善手順
ページの表示速度を改善するにあたって、まず初めに行うことは現状のサイトパフォーマンスを把握することです。ページ表示速度を評価してくれるツールに「PageSpeed Insight」があり、無料で利用することができます。
PageSpeed Insightを使ったパフォーマンスの把握
ページの表示速度を改善するにあたって、まず初めに行うことは現状のサイトパフォーマンスを把握することです。ページ表示速度を評価してくれるツールに「PageSpeed Insight」があり、無料で利用することができます。
PageSpeed Insightの指標
PageSpeed Insightで表示されるスコアは「core web vitals(コアウェブバイタル)」を始めとする実際のユーザー環境で評価された指標と現状のパフォーマンスでの問題点を指摘してくれるレポートの大きく2つに別れます。実際のユーザー環境で評価されたレポートは過去28日間で評価を行っているのに対し、現状のパフォーマンスでの問題点を指摘してくれるレポートはリアルタイムでの検証になるため用途によって指標を使い分けるのがベストです。
実際のユーザー環境での評価
Google 検索でページ エクスペリエンスが優れていると評価されるための重要なシグナルの1つに「core web vitals(コアウェブバイタル)」があります。実際のユーザー環境で評価された指標の中に入っている「LCP」「FID」「CLS」という3つの要素から構成されています。またこの3つの指標以外にも「FCP」「INP」「TTFB」があり、全部で6つの指標で構成されています。各指標に対して合格点が設けられており、評価対象の総ページロード数のうち75パーセンタイルが合格点に達していれば、そのページはGoogleが設定する基準をクリアしたことになります。
| 項目 | しきい値 | 内容 |
|---|---|---|
| LCP (Largest Contentful Paint) | 良好：2.5秒以下 改善が必要：2.5秒～4秒 不良：4秒超 | 最も大きなテキストまたは画像が画面に描画されるまでにかかった時間 |
| FID (First Input Delay) | 良好：100ミリ秒以下 改善が必要：100ミリ秒～300ミリ秒 不良：300ミリ秒超 | ユーザーが最初にページを操作したときからブラウザが実際にイベント ハンドラーの処理を開始するまでにかかった時間 |
| CLS (Cumulative Layout Shift) | 良好：0.1以下 改善が必要：0.1～0.25 不良：0.25超 | ビューポート内の視覚要素がどのくらい移動しているか(レイアウトが変化したか)を測定する指標 |
| FCP (First Contentful Paint) | 良好：1.8秒以下 改善が必要：1.8秒～3秒 不良：3秒超 | 最初にコンテンツが描画されるまでにかかった時間 |
| INP (Interaction to Next Paint) | 良好：200ミリ秒以下 改善が必要：200ミリ秒～500ミリ秒 不良：500ミリ秒超 | ページで行われたすべてのクリック、タップ、およびキーボード操作から応答までが最も長いものをINP 値として選択 |
| TTFB (Time to First Byte) | 良好：0.8秒以下 改善が必要：0.8秒～1.8秒 不良：1.8秒超 | リソースの要求から応答の最初のバイトが到着し始めるまでの時間 |
パーフォーマンスの問題を診断
ページの表示速度のパフォーマンスは100点満点で表示され、それを構成する要素が全部で6項目あります。単純に各項目に対して6等分されているわけでは無く、各項目に対して点数の配分が異なります。最も点数の配分が高い項目はTBTであり全体の30%も占めています。一方で最も点数の配分が少ない項目はSIとTTLで10%となります。
| 項目 | 配分 | 内容 |
|---|---|---|
| FCP (First Contentful Paint) | 10% | 最初にコンテンツが描画されるまでにかかった時間 |
| SI (Speed Index) | 10% | ページのコンテンツが読み込まれて画面に表示されるまでの時間 |
| LCP (Large Contentful Paint) | 25% | 最も大きなテキストまたは画像が画面に描画されるまでにかかった時間 |
| TTI (Time to Interactive) | 10% | ページが完全に操作可能になるのに要する時間 |
| TBT (Time Blocking Time) | 30% | タスクの処理時間が 50 ミリ秒を上回った場合の、コンテンツの初回描画から操作可能になるまでの合計時間 (ユーザーの入力がブロックされている合計時間) FCPからTTLまでの間の時間になるため、この時間の差が大きければブロック時間が長くなる |
| CLS (Cumulative Layout Shift) | 15% | ビューポート内の視覚要素がどのくらい移動しているか(レイアウトが変化したか)を測定する指標 |
データの把握はページ × デバイス × 競合の3軸で掛け合わせる
PageSpeed Insightのパフォーマンスはページ単位で取得することが可能です。また取得したページはモバイル(携帯電話)とデスクトップの2種類でデータが取得できます。自社の各ページに対して、データを取得することでパフォーマンスの悪いページを抽出することが可能になります。
また、ページのURLを入力するだけでページの表示速度のパフォーマンスを把握することができるため、競合のパフォーマンスを把握することも可能です。自社と同等の競合ページのパフォーマンスを把握することで、競合と比べて自社のページのパフォーマンスが高いのか低いのか把握することが可能になります。把握した際に競合よりパフォーマンスが低い場合は、ページの構成を改善するヒントが競合ページに潜んでいるかもしれません。
分析対象ページの選定
注力ページなど自社コンテンツで重要度の高いページを選定する。
競合ページの選定
選定した自社の注力ページ(分析対象ページ)と同等の意味合いを持つ競合のページをピックアップする。
対象ページのパフォーマンスデータの抽出
分析対象として選定した自社・競合のページのパフォーマンスデータを抽出する。抽出するデータは、総合点数のパフォーマンスと「PageSpeed Insightの指標」に記載したパフォーマンスを構成している6つの指標データ。
PageSpeed Insight API
検索窓にパフォーマンスを把握したいページのURLを入力することで、そのページのパフォーマンスを100点満点で表示できますが、1ページ単位でかつ1回1回入力をしなければ行けないため、複数のページを定期的に観測するのは非常に大変です。しかしPageSpeed InsightはAPIを提供しており、そのAPIを活用することで定点観測がしやすくなります。
目標のパフォーマンスを達成するための改善シミュレーション
現状が把握できたら、現状のパフォーマンスからどれくらい改善したいか、パフォーマンスをいくつにしたいか整理します。整理ができたらそのパフォーマンスを達成するのに各項目の数値をどう改善しないといけないかシミュレーションを行います。
目標のパフォーマンスの整理
ページの表示速度を改善していくにあたってまずは目標値を決めます。ここで注意したいことは決して100点を目指しに行かなくて良いということです。目的はあくまでページの表示速度を改善してストレスのないユーザー体験を提供することです。
では何点を目指せば良いかというと、決して決まったラインはありませんが85点以上を目指すことをおススメします。またパフォーマンスバジェットという考え方を取り入れると良いでしょう。パフォーマンスバジェットはそのページでどれだけのデータ転送を許容するかというラインになります。そのラインを超えないページ設計や運用が必要になります。パフォーマンスバジェットは特に決まったラインはありませんが、web.devにて公開されている方法が参考になるため、ここではそちらを参考にパフォーマンスバジェットを決める手順を紹介いたします。
重要なページの特定
ユーザーのトラフィックが多いページや商品のランディングページなど該当のサイトにて重要なページを選定する
ユーザーエクスペリエンスの実績を把握する
PageSpeed Insightで計測したFCPとTTIを確認する
競合のFCPとTTIの数値も取得し、自社の数値を比較する
パフォーマンスバジェットを決める
ユーザーは応答時間が20%変わると応答時間の違いを感じます。そのため競合として選定したサイトの中で1番高速なページよりも20%高速で設定することで、ユーザー体験をより良いものにできるでしょう。もし最初から競合含め1番速いページより20%も高速にすることにハードルを感じる場合は、自社の今の速度より20%速い速度を初期目標、競合より20%速い速度を長期目標に設定してください。
目標到達までのシミュレーションを実施
目標のパフォーマンスが決まったら、現状の状態からそこに辿り着くためにどの項目を改善していくべきか整理していきます。
改善シミュレーションを行う際に「Lighthouse Scoring Calculator」という非常に便利なツールがあります。こちらのツールでは、どの指標をどれだけ変更したらパフォーマンスに影響を与えるかをシミュレーションすることができます。各指標に対してパフォーマンスに影響を与える度合いが異なるため、影響度が大きい指標から改善できないかを検討していくことがおすすめです。
PageSpeed Insightには各指標に対して「改善できる項目」として改善したことにより、短縮できる推定時間が出てきます。改善シミュレーションをする際にそのシミュレーション数値が現実的なのかどうか、照らし合わせることでシミュレーション数値にも現実味が帯びてきます。
改善案の実行
現状のパフォーマンスと目標とすべきパフォーマンスが決まったら、その乖離分を埋めるための改善案を検討・実行します。ページの表示速度を改善する方法は「不要ファイルの削除」「ファイルの圧縮」「ファイルの変換」「サーバーレスポンスの最適化」の大きく分けて4種類になります。
不要ファイルの削除
当初は必要でも運用していく中で不要になってしまったファイルはいくつか存在します。そういったファイルはページ上、必要ないにも関わらずページの表示速度を落としてしまっている要因となっているため、ページに読み込まないように設定します。
| 使用しないファイルのリソースの除外 | ・使用していないCSSやJavaScriptファイルを削除 |
ファイルの圧縮
画像やプログラムファイルなどファイルを圧縮することで読み込む容量を削減する方法があります。読み込む容量が少なくなれば、ページをレンダリングするまでにかかる時間も圧縮することが可能になります。
| レンダリングを妨げるリソースの除外 | ・画像のサイズ・容量の調整 ・CSSやJavaScriptファイルなどをインライン化し容量を圧縮する ・画像、CSSやJavaScriptファイルの読み込みを遅らせる |
| リクエスト数を少なく、転送サイズを小さく維持する | ・呼び出す外部リソースの数調整 |
| ウェブフォント読み込み中のテキスト表示 | ・ウェブフォントが読み込まれるまでは、ブラウザフォントを表示 |
| テキスト圧縮の有効化 | ・GZIP圧縮の使用 |
ファイルの変換
読み込むファイルの形式を変換することで容量を圧縮することができ、結果読み込むファイルの容量を削減しページ表示速度の改善につながります。
| 効率的な画像フォーマットへの変換 | ・次世代フォーマットでの画像の配信 ・アニメーションコンテンツにビデオを使用 |
サーバーレスポンスの最適化
ページに必要なリソースをやり取りするサーバーからのレスポンス速度を早めることで、結果ページの表示速度の改善を行います。
| サーバーの応答時間の減少 | ・質の高いWebホスティングプロバイダーの選択 ・コンテンツデリバリーネットワーク(CDN)の利用 ・ブラウザキャッシュの実装 |
| サーバーへのリクエスト数を最小限に抑え込む | ・必須ドメインの事前接続 ・キーリクエストのプリロード |
| 複数のリダイレクト回避 | ・不要なリダイレクト処理の削除 |
ページ運用
改善案の実行を通してページの表示速度を改善することと同じくらい改善後の運用は重要です。改善後に運用ルールを決めずにページの運用を行なっていると、またページの表示速度は悪化してしまい再度改善を行うといった負のループに陥ってしまいます。改善後もページの表示速度を悪化させないためには運用ルールを設計しておく必要があります。
パフォーマンスバジェットの運用
ページのパフォーマンスを良く保つために、そのページでどれだけのリソースを読み込んで良いかの上限ライン(バジェット)を決めます。その決めたラインに収まるように運用を行っていきます。バジェットはページ内に読み込まれるコンテンツの種類毎に整理します。
| 項目 | バジェット |
|---|---|
| HTML | 10KB |
| 画像 | 30KB |
| CSS | 10KB |
| JS | 100KB |
| フォント | 20KB |
| 合計 | 170KB |
3Gの遅い回線でもストレスなくページが表示できるようにweb.devが推奨している合計170KBに収まる内訳になっています。しかしページによって画像が多いページやJSプログラムが多く必要なページなど様々なため、170KBに収まるために配分は個々に合わせて設定して大丈夫です。
まとめ
ページの表示速度はユーザー体験に直結するため、トラフィックやCVなどビジネス指標に大きく影響を及ぼしてきます。
ページの表示速度を最適化していくことが重要ですが、そのためにはページのパフォーマンスを把握して目標とすべきパフォーマンスに改善を行なっていくステップが必要になります。また改善後はより良いユーザー体験を行なってもらうために運用設計もしっかりと整備する必要があります。
ページ表示速度を改善して、より良いユーザー体験を提供できるページを作る一助になれば幸いです。