スピードテストのソースコードで速度が遅く見える原因と改善方法

スピードテストのソースコードで起きる問題とは

スピードテストは、一定量のデータを測定サーバーと送受信し、通信にかかった時間から下り速度、上り速度、Ping、遅延などを算出します。ソースコードの設計が実際の利用環境に合っていないと、光回線の契約内容やプロバイダーの混雑だけでは説明できない結果になることがあります。

たとえば、測定値が毎回大きく変わる、下りだけ極端に遅い、ブラウザーを変えると結果が変わる、実際の動画視聴やファイル転送より低い数値になるといった現象が代表的です。まず測定ロジックと利用環境を分けて確認することが重要です。

原因1：測定サーバーの距離や混雑

ソースコードが固定の測定サーバーだけを使っていると、利用者からサーバーまでの距離や経路の混雑が結果に反映されます。海外や遠距離のサーバーを選ぶ構成では、Pingや遅延が大きくなり、特に小さなデータを使った測定で速度が安定しにくくなります。

判断するには、複数の地域や事業者が提供する測定サーバーで比較します。特定のサーバーだけ遅い場合は、回線全体ではなく経路またはサーバー側の負荷が疑われます。近いサーバーを自動選択し、初回の応答時間や継続的なエラー率も確認できるようにすると改善しやすくなります。

原因2：データ量や測定時間が不足している

転送するデータ量が少なすぎると、DNS検索、TLS接続、HTTPリクエスト、ブラウザーの処理時間が測定値に大きく影響します。反対に、データ量が多すぎると、モバイル回線や通信制限のある環境で利用者の負担が増えます。

判断方法は、データサイズや測定時間を変えて結果を比較することです。短時間だけ極端に低い場合は、接続確立の時間を速度計算に含めている可能性があります。最初のウォームアップ通信を別扱いにし、一定時間または一定量の転送後に平均速度を計算すると、瞬間的な変動を抑えられます。

原因3：通信の並列数が環境に合っていない

スピードテストでは、複数の通信を同時に実行して帯域を使い切る方式がよく使われます。しかし並列数が少ないと高速な光回線でも下り速度が伸びず、逆に多すぎるとルーター、ブラウザー、サーバーに負荷がかかり、遅延や再送が増えることがあります。

判断するには、並列数を段階的に変え、速度とPingの両方を記録します。並列数を増やしたときに速度が上がらず遅延だけ増える場合は、設定が過剰です。低速回線から高速な光回線まで対応するには、固定値だけでなく、短い試験転送で適切な並列数を選ぶ設計が有効です。

原因4：ブラウザーとJavaScriptの制約

ブラウザー上のスピードテストは、JavaScriptの実行性能、メモリー使用量、タブのバックグラウンド制御、セキュリティポリシーの影響を受けます。端末の負荷が高い状態や省電力モードでは、通信速度ではなく処理の遅さが測定結果に含まれることがあります。

判断するには、同じ回線で別のブラウザーや別端末を使って比較します。特定のブラウザーだけ結果が低い場合は、開発者ツールでJavaScriptエラー、FetchやXHRの失敗、処理時間を確認します。測定処理を細かく分割し、不要な画面更新を減らし、転送済みバイト数を正確に数えることで影響を抑えられます。

原因5：HTTP方式、CORS、キャッシュの設定

測定用ファイルがブラウザーや中間キャッシュから返されると、インターネット経由の通信速度を正しく測れません。また、CORS設定の不備、HTTPとHTTPSの混在、プロキシによる圧縮やバッファリングがあると、通信が失敗したり実際とは異なる転送時間になったりします。

判断時には、レスポンスヘッダー、キャッシュの有無、Content-Length、転送サイズ、HTTPステータスを確認します。測定データにはキャッシュ回避用のクエリを付け、サーバー側で適切なCORSとHTTPSを設定します。ただし、キャッシュ回避用のパラメーターを増やしすぎるとサーバー負荷が高まるため、利用回数とログを管理してください。

原因6：Wi-Fi、ルーター、端末側の影響

ソースコードが正常でも、Wi-Fiの電波干渉、ルーターの処理能力、接続端末の性能によって測定値は変わります。2.4GHz帯の混雑、ルーターからの距離、他の端末による通信、VPNやセキュリティソフトが下り速度や上り速度を抑えることがあります。

判断するには、同じ測定コードを有線LANとWi-Fiで実行し、さらに複数の端末で比較します。有線では安定してWi-Fiだけ遅い場合は、ソースコードより無線環境の確認が先です。ルーターの近くで測定する、5GHz帯や対応するWi-Fi規格を試す、バックグラウンド通信を止めるといった方法で切り分けできます。

原因7：速度とPingの計算方法が不正確

速度は一般に、転送したビット数を経過時間で割って算出します。バイトとビットの変換を誤る、ミリ秒と秒を混同する、開始時刻と終了時刻の取得位置が不適切であると、下りと上りの数値が大きくずれます。Pingも、複数回の応答時間から平均だけを出すと、一時的な遅延を見落とすことがあります。

判断するには、転送サイズ、開始時刻、終了時刻、失敗回数、再送回数をログに出し、手計算した値と照合します。速度の単位をMbpsやMB/sのどちらで表示するか明示し、Pingは最小値、中央値、最大値を分けて記録すると通信品質を判断しやすくなります。

原因を切り分ける確認手順

1. 測定条件を固定する。同じ端末、同じ接続方式、同じ時間帯で複数回測定します。
2. 有線とWi-Fiを比較する。差が大きい場合はルーターや無線環境を確認します。
3. サーバーを変更する。特定サーバーだけ低いか、すべて低いかを確認します。
4. 並列数とデータ量を確認する。設定変更で速度と遅延がどう変わるかを記録します。
5. 開発者ツールで通信を見る。接続時間、転送時間、ステータス、キャッシュ、エラーを調べます。
6. 別の測定サービスと比較する。同じ条件で傾向が一致するかを確認します。

ソースコードと測定環境の改善ポイント

• 利用者に近い測定サーバーを複数用意し、応答時間などから選択する。
• ウォームアップ、下り、上り、Pingの測定を分離して結果を表示する。
• 固定の並列数ではなく、回線速度や端末性能に応じて調整する。
• キャッシュ、CORS、HTTPS、圧縮、プロキシの影響を確認する。
• 速度だけでなく、遅延、ジッター、失敗率、再送もログに保存する。
• 測定前にVPN、バックグラウンド通信、省電力設定などの注意事項を表示する。

スピードテストのソースコードを評価するときは、表示された数値だけでなく、測定サーバー、転送方式、データ量、並列数、ブラウザー、ネットワーク環境を一緒に確認する必要があります。原因を一つずつ分離すれば、回線やプロバイダーの問題と、測定処理の問題を区別しやすくなります。