計測していないと、Before/Afterの比較ができないので、プロジェクトが成功したかどうかが分かりません。
計測していないWeb高速化サービスは、評価そのものができないので、ベンダーに有利で、御社に不利になります。

これらのツールは4G回線や光回線をエミュレートして計測しています。
レイテンシが150ms、下りが1.638Mbpsで、5Gが普及している日本の通信環境と大きく異なります。
そして、エミュレートなので、通信経路も異なりますから、実際の顧客が体験している表示速度ではありません。

またGoogle PageSpeed Insightsが高得点だから表示が高速というわけではありません。
ファイル容量を削減すると高得点になります。
しかし、日本のインターネット環境でのWebの遅延はファイル容量が原因ではなく、計算時間の遅延が原因です。

Google PageSpeed InsightsやLighthouseを評価に使うWeb高速化サービスは、ページ容量で評価されるため、ベンダーに有利で、御社に不利になります。

GoogleのCrUXの調査手法を確認されたでしょうか?
全てのChromeユーザのデータが使われているわけでなく、以下のような条件があります。
従って、データはバイアス(偏り)が入っており、それを補正する必要があります。

1. 閲覧履歴の同期を許可
2. Sync パスフレーズを設定していない
3. 使用統計のレポートを有効にしている
4. データの送信に成功した(これはGoogleのページには書かれていません)

データの送信に失敗する原因は、以下の3つです。

• 御社のサイトが著しく遅延、もしくはサードパーティが遅延して、データを送信できない
• 御社のWebページがエラーになって、データ送信に必要なデータが送信できない
• Googleにデータを送信する際に、通信の問題、データ受信サーバの遅延があった場合に、そのデータを受信できない

Google CrUXを評価に使うWeb高速化サービスは、遅い数値やエラーは記録されないため、ベンダーに有利で、御社に不利になります。

RUM(Real User Monitoring)は以下の場合にデータを取得できません。

• 御社のサイトが著しく遅延、もしくはサードパーティが遅延して、データを送信できない
• 御社のWebページがエラーになって、データ送信に必要なデータが送信できない
• 集計サーバにデータを送信する際に、通信の問題、データ受信サーバの遅延があった場合に、そのデータを受信できない

RUMを評価に使うWeb高速化サービスは、遅い数値やエラーは記録されないため、ベンダーに有利で、御社に不利になります。

WebPageTestは、弊社が代理店として販売しているCatchpointの無料サービスですが、参考として計測するには使えますが、実際のビジネスで使うには不向きです。

• AWSなどのクラウドサーバ上にシステムがあり、そこから回線のスループットをシミュレートして計測しているので、実際の現地のスピードではない
• ネットワーク経路が異なるので、実際のユーザがどのような体験をしているかが分からない
  (高速道路の混雑状況で例えると、湾岸高速道路が渋滞していないから、東名高速道路も渋滞していないと主張するようなものです)
• テストをしたその時点での観測値なので、それ以外の時間の表示速度を保証できない

WebPageTestを評価に使うWeb高速化サービスは、実際のユーザが使っている回線ではないですし、時間の推移による表示速度の変化を捉えられないので、ベンダーに有利で、御社に不利になります。

WebPageTestと同様に、AWS上で稼働しているサーバから計測したデータは、実際のユーザが体験する表示速度を保証できません。
東京の市場だけを重視しており、他の地方の市場は放棄するというのであれば、構わないでしょう。

• AWSにお客様がいるわけではないので、実際のユーザがどのような体験をしているかが分からない
• 5Gの計測ができない
• 地方都市の実際のネットワーク経路を使った計測ではないので、地方都市での表示速度が分からない

AWS上に計測サーバがあるSynthetic Monitoringを使うWeb高速化サービスは、実際の顧客が使っている回線ではなく、地方の表示速度も分からないので、ベンダーに有利で、御社に不利になります。

御社サーバまでのインターネット上のルーティング情報の監視。
特に海外に置いてあるサーバやクラウドサービスなどと連携している場合に、BGPのルーティング情報が変わったり、通信ができない事態の発生を捉えないと、正しく分析できないです。

各主要都市から御社サーバまでの経路状況の計測・監視。
通信回線については、100Mbpsのようなスループットばかり注目されますが、これは高速道路に例えると車線数です。
車線数がどんなに多くても、混雑すると時速が遅く渋滞するように、通信回線もレイテンシの方が重要です。

レイテンシの数値が、そのまま、DNS、TCP 3way handshakes、SSLの鍵交換、ファイルのダウンロード時間のベースとなります。
レイテンシの数値より高速にならないので、現在のインターネット回線の「時速」を知るのは、正しい高速化に欠かせません。

ドメイン名からIPアドレスを探すDNSの応答速度を組織単位・回線単位で計測・監視。
DNSは、ルートDNSのレスポンス、co.jpのDNSなど、レベル別にレスポンス時間が異なります。
またCDNを利用していると、CNAME Chain(CNAMEが複数連鎖する状態)になっていて、どのDNSで遅延しているかを把握する必要があります。

御社のWebページの主要動線を計測・監視。
特に、ログイン後のページや、ショッピングカートといった動的な生成ページは、計測するためには、実際に遷移する必要があります。
ユーザが遷移しているページをなぞるように、ページ遷移して計測すると、顧客体験を正確にトータルで把握できるようになります。

1ページだけで成り立っているページの計測・監視。
ランディングページやトップページなど、ページ遷移は伴わない、もしくは1ページだけの表示速度を知りたい場合に使います。

御社のWebシステムで連携しているAPIがあれば、その応答速度を計測・監視。
特にバックエンド側で、APIを使った疎結合なシステムを構築している場合には、Enterpriseノードという計測機器を設置して、APIのレスポンスタイムを計測します。
Enterpriseノードは、オンプレミスでも、クラウドでも、どちらでも展開可能です。

APIのレスポンスタイムは100ms以下が望ましいです。