フロントエンドで速度測定コードが正しく動かない原因と改善方法

フロントエンドの速度測定で起きる主な現象

ブラウザー上で実行する速度測定コードでは、実際の回線速度より低い値が表示されたり、測定結果が毎回大きく変わったりすることがあります。下り速度だけが遅い、上り速度が途中で止まる、Pingや遅延が異常に高いといった症状も一般的です。

速度測定は、単にファイルをダウンロードして時間を計るだけでは正確になりません。測定対象のサーバー、通信方式、ブラウザーの処理能力、同時通信、キャッシュ、ネットワーク環境をまとめて確認する必要があります。

原因1：測定対象のファイルが小さすぎる

測定用ファイルの容量が小さいと、通信速度ではなく接続開始やTLS確立にかかる時間の影響が大きくなります。特に高速な光回線では、数百KB程度のファイルでは転送が終わる前に測定誤差が生じ、実際より低い下り速度が表示されます。

判断するには、異なる容量のファイルで測定結果を比較します。小さなファイルだけ遅く、大きなファイルで数値が安定する場合は、測定データ量が不足しています。複数サイズのファイルを使い、最初の接続時間と転送時間を分けて記録すると原因を確認しやすくなります。

原因2：キャッシュや同時通信が測定値を歪めている

ブラウザーやCDNに測定ファイルがキャッシュされていると、ネットワーク経由ではなく端末内から読み込まれ、速度が異常に高く表示されることがあります。反対に、測定中に動画再生、クラウド同期、OS更新などが動作すると、実際の回線帯域が分散して速度が低下します。

URLに毎回異なるクエリを付けるキャッシュバスターを利用し、レスポンスヘッダーも確認してください。測定前に不要な通信を停止し、同じ条件で複数回測定します。キャッシュ無効化だけでなく、サーバー側のCDNキャッシュ設定も確認することが重要です。

原因3：測定サーバーの場所や混雑が異なる

速度測定コードが遠距離のサーバーや混雑した共有サーバーへ接続している場合、利用者の光回線が十分速くても結果は低くなります。プロバイダーの経路、海外サーバーまでの距離、時間帯ごとのトラフィックによって、下り・上り速度とPingは変化します。

複数地域の測定サーバーを使い、同じ端末と回線で結果を比較します。近いサーバーだけ速い場合は経路やサーバー混雑が疑われ、すべて遅い場合は端末や宅内ネットワークも確認します。NTT、ドコモ、au、ソフトバンクなどの回線利用時も、契約名だけでなく接続先と経路を基準に判断してください。

原因4：HTTP設定やCORSの問題で正しく測れない

フロントエンドから別ドメインの測定サーバーへアクセスする場合、CORS設定が不足するとリクエストがブロックされます。また、リダイレクト、圧縮、認証、プロキシによって、測定対象のデータが意図せず変換されることがあります。

ブラウザーの開発者ツールで、リクエストのステータス、転送サイズ、実際のレスポンスサイズ、Timingの各項目を確認してください。測定用エンドポイントでは、CORSの許可範囲、Cache-Control、Content-Encoding、Content-Lengthを明確に設定します。HTTPSページからHTTPへ接続する混在コンテンツは避ける必要があります。

原因5：JavaScriptの実装方法が端末性能に影響している

速度測定コードがメインスレッドで大量の計算やDOM更新を行うと、通信が速くても表示や計測処理が遅延します。1回の大きなリクエストだけでなく、細かいチャンクを頻繁に処理する実装でも、スマートフォンのCPUやメモリー使用量がボトルネックになります。

測定中の画面更新は一定間隔に制限し、毎回の受信イベントでレイアウトを変更しないようにします。必要に応じてWeb Workerを使い、経過時間はDate.nowより高精度なperformance.nowで計測します。処理時間とネットワーク転送時間を分けて記録すると、端末性能による遅延を見つけられます。

原因6：Wi-Fiやルーターが通信のボトルネックになっている

Wi-Fi接続では、電波干渉、距離、壁、周辺機器、周波数帯の混雑によって速度が変動します。ルーターの処理能力や古い無線規格も影響し、同じ光回線でも有線接続とWi-Fi接続で下り・上り速度に大きな差が出ます。

まず端末をルーターへ有線接続して測定し、Wi-Fiの結果と比較します。有線だけ安定する場合は、5GHz帯の利用、ルーターの設置場所変更、ファームウェア更新、不要な同時接続の停止を試します。Pingが高い場合は電波品質だけでなく、ルーターの負荷やバッファリングも確認してください。

原因7：測定回数が少なく統計的に不安定である

速度は一定ではなく、接続開始直後の遅延、TCPの輻輳制御、時間帯、他の利用者の通信によって変化します。1回だけの測定結果を回線の代表値とすると、偶然の低速または高速を判断してしまいます。

同じ条件で複数回測定し、平均値だけでなく中央値、最小値、最大値も表示します。初回接続の影響を避けるため、ウォームアップ測定を別に行う方法も有効です。下り、上り、Ping、遅延は別々の指標として保存し、単一の速度スコアだけで評価しないようにします。

フロントエンド速度測定コードの確認手順

1. 開発者ツールを確認する：NetworkタブでDNS、接続、TLS、待機、転送の時間を分けて確認します。
2. キャッシュを除外する：測定URLに一意の値を付け、キャッシュヒットとネットワーク転送を区別します。
3. 測定サーバーを変える：近隣、国内、別事業者など複数のエンドポイントで比較します。
4. 接続方式を変える：有線、5GHz Wi-Fi、2.4GHz Wi-Fiを同じ端末で測定します。
5. 複数回の結果を保存する：平均値と中央値に加え、Pingと遅延のばらつきも記録します。

簡易的な実装では、performance.nowで測定開始時刻と終了時刻を取得し、転送したバイト数を経過時間で割ってビット毎秒へ変換します。ただし、レスポンスの圧縮やキャッシュがあると実際の通信量と一致しないため、測定用エンドポイントでは圧縮とキャッシュの扱いを統一してください。

測定精度を高める最適化方法

• 十分な容量の測定データを用意し、短時間で終わる測定を避ける。
• 複数の測定サーバーを用意し、利用者に近い経路を選択する。
• キャッシュバスターと適切なCache-Controlを設定する。
• 測定中のDOM更新を減らし、必要に応じてWeb Workerを利用する。
• 速度だけでなくPing、遅延、ジッター、パケットロスも記録する。
• 有線とWi-Fiを分け、ルーターやプロバイダー側の問題を切り分ける。

ブラウザーだけで実装する速度測定は、利用者の端末やネットワーク環境の影響を受けます。サービスの品質を比較する目的なら、速度測定サービスなどで同じ条件を確認し、フロントエンドの結果と照合すると判断の精度を高められます。