経営者やプロジェクトリーダーが理解すべき「Web表示スピード」の価値

  • 2021年7月16日
  • Web表示スピードは、コアウエブバイタルの登場もあり、いまではすっかりUXの一つとして認知されるようになってきました。

    いままでは、エンジニアやIT担当者に任せていたカテゴリーかもしれませんが、これからは経営者やプロジェクトリーダーが「表示スピード対策」に理解とリーダーシップをとるべき時代です。

     

    そのためにWeb表示スピードを理解するための実用ガイドをまとめてみました。

      • ページが遅くなる原因は何ですか?
      • 表示スピードはどのように測定されますか?
      • さまざまな指標(メトリック)の意味は?
      • パーセンタイルの理解と使用方法
      • 関係者に表示スピードの価値を伝える方法

    ページが遅くなる原因は何ですか?

    知っておくべき重要な用事用語について説明します。Web表示スピードは複合的な要素を持つため、これらの用語の理解が必要です。

    リクエスト数

    Webページは、個別のアセットで構成されています。画像、フォント、JavaScript、CSS、ピクセルなどなど、これらはリッチなエクスペリエンスを提供するための機能を果たしますが、これらをまとめた途端に「とんでもなく遅延が発生してしまう」という事態となってしまいます。

    Steve Soudersが唱えた黄金律今でも普遍です。レンダリング時間の80〜90%はフロントエンドで費やされ、その大半はネットワークで送信されるリクエスト数です。サイトを最適化するなら、まずリクエスト数をできるだけ減らすことから始めましょう。

    コード

    フロントエンド・エンジニアが学ぶべきベストプラクティスはたくさんあります。しかし、最適化の王道としては下記の3つです。

    • JavaScriptによるブロックの改善
    • 「クリティカルパス」やレンダリングブロックの改善
    • アセットをプリロードする、またはスクリプトを非同期にしてロードする

    このほか推奨事項は、コンサルタントによるアドバイスやLighthouseやSpeedCurveのような計測ツールも役にたちます。

    多くの場合、フロントエンドが原因ですが、開始時のレンダリング時間が長くなったり、最初の読み込み時間が増加となる数値が表れた場合は、バックエンド側にも目を向けましょう。

    画像・イメージ

    画像最適化は、表示スピードを大幅に向上させる手法の1つです。画像圧縮技術は進化し続けています。帯域幅を最小限に抑えながら豊富な機能を提供する新しいフォーマットも登場しています。ただし、これらの形式はブラウザ固有のものであるため、実際の作業が複雑になります。

    自社管理か外部管理かにかかわらず、画像作製のワークフローをルール化しておくことは大切です。特に、大規模な製品カタログを扱うサイトや、ユーザー生成コンテンツが多いサイトでは、その傾向が顕著です。

    ただし、画像最適化による表示スピード向上は、すべての指標(メトリック)に反映されるわけではありません。しかし、帯域幅が不十分であったり、データプランが制限されているユーザーにとってはありがたいことです。画像に関するパフォーマンス予算(パフォーマンスバジェットは、期間ではなくサイズとリクエスト数で設定するようにしてください。

    ネットワーク

    インターネットには、一貫性はありません。A地点からB地点に到達する仕組みは、回線を介するビット送信の複雑さを考えると驚くばかりです。

    Akamai、Fastly、Cloudflare、Cloudfrontなどのコンテンツ・デリバリー・ネットワーク(CDN)の採用は、表示スピードに大きな影響を与えます。CDNは、以前はバックエンドにその影響が表れていいましたが、最近は、アセット(画像、静的コンテンツ)をはじめ、Edgeサーバーを利用した高度な最適化では、フロントエンド側にも大きな影響を与える可能性があります。しかし、CDN導入は改善ばかりではなく、場合により悪化させることもありますから注意してください。

    サードパーティ

    あらゆる場所で問題を起こします。

    サードパーティタグとは、リッチコンテンツやリコメンドやリサーチサービス、広告配信、SNSなどの自社ドメイン外の機能のことです。

    サードパーティへの不満は、サードパーティが自社のコントロール範囲外にあるとされることが多いからです。サードパーティが表示スピードに影響を与える場合、タグを削除したり、キルスイッチを入れる以外に、処理速度を上げる方法はありません。

    とはいえ、あなたが事業責任者である場合、コントロール範囲外のものにしがちです。サードパーティタグに責任を負わせ、それらを維持するための戦略を立てることもできます。

    たとえば、これです。

    ベンダー担当者と協力するか、責任者である関係者と協力して、サードパーティに「パフォーマンス予算」を設定するようにします。またベンダー担当者と実行できるタグ(パフォーマンス)予算を作成してもいいでしょう。

    マーケティング部門が、新しい画像を追加する必要がある場合は、それを強制的に置き換えます。サードパーティを監査し、ゴーストスクリプトを排除します。

    新しいサードパーティを許可する前に、検証プロセスをおこない、表示スピードの基本ガイドラインを満たすことを確認します。私のお気に入りはNic Jansmaが提供している3rdParty.ioです。

    表示スピード問題の原因が何であれ、問題に取り組む際には「チームとしてのアプローチをする」ことが重要です。誰か1人が原因でパフォーマンスが低下しているということはありません。また、1人のユーザーまたはグループがその分野のオーナーとなったとしても、ほかのユーザーとは関係なく解決できるということも稀です。表示スピード改善はチームスポーツなのです。

    Web表示スピードはどう計測されますか?

    主に2つの方法があります。どちらもユーザーがサイトにアクセスした際に、ブラウザがどう反応するかを測定します。

    シンセティック(合成)モニタリング

    シンセティック=合成テストであり、本物ではありません。シンセティック・モニタリングとは、基本的に指示したこと(「Xの場所からXブラウザでホームページにアクセスしてください」)を実行し、表示スピードデータを積極的に収集するボットのことです。

    シンセティックの良さは、そのアクションが実行されたときに何が起こったか?についてのデータ収集ができます。

    これには以下が含まれます。

    • 各リクエストの詳細を示すウォーターフォールチャート
    • レンダリング体験を視覚化するためのフィルムストリップやビデオ
    • アプリケーションの構成を見る際に、ベースライン

    シンセティックは、速度に大きな影響を与えるリクエスト(画像、JavaScript、CSS)の数やサイズを調べるときなど、時間経過に伴う状況分析に最適です

    ただし、シンセティック・モニタリングには、エンドユーザーという要素が欠けています。そこでRUMが注目されます。

    リアルユーザモニタリング(RUM)

    RUM(Real User Monitoring)とは、実際のエンドユーザーがブラウザを訪れ、そこで計測される表示スピード分析です。

    プロジェクトマネジャーとして、すでに自社システムを外部ベンダーによって構築することに注力していることとします。膨大な数のお客様と話し、フィードバックを得て、それらを次のシステム要件に反映させるのです。こうしたプロセスの中で、ロードマップを作成したり、システム仕様やワークフローを作成するときに、チーム全体で広く理解されることが必要です。

    これが、RUMが必要な理由です。リアルユーザー。リアルな体験。RUMは、Web表示スピードを理解するための基礎であり、Web表示スピードを関係者に伝える際の重要な情報源となります。RUMがなければ、表示スピードを仕様要件として効果的に盛り込むことはできません。

    とはいえ、これは難しい問題です。いまの時代、RUMをプランの中に組み入れないのは、表示スピードに関する不正行為と言えます。

    さまざまな指標(メトリック)の意味は?

    シンセティックでもRUMでも、各テストは数多くのパフォーマンス指標を取得します。どのパフォーマンス指標に注目すべきかは、長期にわたる大変な道のりでした。その傾向は「すべてを測定しつくす」から「ユニコーン指標は注力」に変わっています。いまはその中間です。しかし「どの指標(メトリック)を重視すべきか」は、いまだに苛立たしい問題です。

    メトリック(指標)は無数にありますが、すべてを理解する必要はありません。表示スピードを始めたばかりの方は、ユーザーのエクスペリエンスに最も近い指標に焦点を当ててください。これに正面から取り組んだTammyの素晴らしいガイドがあります。

    ここ数ヶ月、プロジェクトマネジャーとの会話はCore Web Vitalsに集中しています。SEOの改善やGoogle Consoleに表示される数字にプレッシャーを感じているのであれば、これらの指標について理解しておきたいところです。幸いなことに、コアウエブバイタルについては多くの資料がありますので、ご覧ください。

    • コアウェブバイタルの追跡
    • Cumulative Layout Shift(CLS)の理解
    • First Input Delay(FID)の重要性とは?
    • Core Web Vitalsについてわかっていること(Simon Hearne著)

    パーセンタイルの理解とその使用方法

    さまざまなメトリック(指標)を理解した後は、各指標に対して、パーセンタイルを適用する方法を学び、実際のユーザーのいくつかのグループが、どのようにサイト体験しているかを理解することが重要です。

    これはヒストグラムです。

    ヒストグラムは、サイトを訪れた際に様々な経験をしたユーザーの分布を表します。

    表示スピードは分布であり、ひとつの数値ではありません。また一度だけ計測されるものでもありません。ヒストグラムは経験の連続性を表し、表示スピードの形とそれにどのように影響を与えたかを考えることができます。速くなると左に、遅くなると右にシフトします。

    数字で語る必要性

    数字で説明する必要があります。パーセンタイルは、0~100の母集団のセグメントを表します。統計学者でなくても、次のように考えてください。

    50パーセンタイル (中央値) :50パーセンタイル (中央値) を使うと、理解しやすく、コミュニケーションしやすくなります。必要に応じて、平均値と呼ぶこともできます。

    75パーセンタイルCore Web Vitalsなどの一部の一般的な指標では、75パーセンタイルがレポートに使用されます。

    95パーセンタイル:サイトがすでにほとんどのユーザーにとってかなり高速である場合は、ロングテールの高速化に注力することができます。ユーザーの5%は大したことがないように聞こえるかもしれませんが、月に1000万人の訪問者があるとすれば、そのうち50万人が本当にひどい体験をしているということになります。

    どのパーセンタイルに注目すべきかについては、それぞれにメリットがあり、間違った答えはありません。ただし、人口を表すために算術平均(従来の平均値)を使って母集団を表現している場合は除きます。この種の分布では、従来の平均値はあまりうまく機能しません。

    関係者にWeb表示スピードを伝える方法

    プロジェクトマネジャーが直面する最大の課題の1つが「関係者にWeb表示スピードを伝える方法」です。私たちは何年もこの課題に取り組んできましたが、まだ解決していません。ここでは、コミュニケーションについて、いくつかの考え方をご紹介します。

    オーディエンスを知る

    新しい概念ではありません。機能横断的な仕事をする際には、新しい用語やコンセプトを導入して経営者と議論することになります。

    シンプルであること

    多くの情報で相手を混乱させないようにしましょう。表示スピードをKPIを中心にレポートを作成しているのであれば、それは素晴らしいことです。また、ユニコーン指標で調整ができているのならばそれもいいでしょう。ただし、あまり飾りすぎないようにしましょう。

    パーセンタイルのような用語は使わず、2つの数字のセットを提示するのは避けましょう。プロジェクトマネジャーが陥りがちな間違いの1つに、RUM指標とシンセティック指標の両方を伝えようとすることです。これはダメです。

    繰り返しですが、可能な限りRUMを使用してください。シンセティックデータでは、ページウェイトやリクエスト数など、そのエリアを強調したり、サイト上のサードパーティの数を示したりすることができます。つまりシンセティックデータがRUMデータをうまく補完してくれることになります。

    表示スピードのイメージを描く

    シンセティックの出番はここからです。表示スピードに疎いステークホルダーに説明するとき、フィルムストリップやビデオを使ってポイントを説明すると、非常に効果的です。またチームの素晴らしい仕事ぶりをアピールするのにも、動画でビフォー・アフターを見せるのが一番です。

    ベンチマークする

    もうひとつ便利なのが、ベンチマークです。チームは勝つことが好きで、負けることが嫌いです。ベンチマークを利用して自社サイトと競合サイトを比較することは非常に効果的です。これは、Core Web Vitalsの管理に関しても当てはまります。競合他社の半数が自社よりもLCPタイムが速かった場合、SEOの検索結果にどのような影響があるでしょうか?

    難しいかもしれませんが、自社が最下位であろうと競争相手が最下位であろうといつでも変化します。ベンチマークは、自分自身を向上させるため、あるいは他者を理解し学ぶために活用しましょう。ベンチマークを使用する方法については、「Industry Page Speed Benchmarks」をご覧ください

    サマリーを読む

    サマリーを読むことで時間を有効に活用することができるでしょう。プロジェクトマネジャーとして触れるあらゆるトピックと同様に、いつでも深く掘り下げることができます。

     


    ※この記事はSpeedCurve社の英文情報を元に、内容を分かりやすく編集、翻訳した記事です。

    Copyright © 2021 SpeedCurve Limited. All Rights Reserved.

>サイトが重い、ファーストビューが速く表示されないこんなお悩み、ご相談ください。

サイトが重い、ファーストビューが速く表示されないこんなお悩み、ご相談ください。