レンタルサーバー
速度比較18社
【2026年】

2026年の結論：一番速い会社を先に決めない

速度比較で最初にすべきことは、18社を1位から並べることではありません。訪問者地域、サイトの種類、予算、運用体制から候補を減らし、その候補だけを同じサイトで測ります。以下は速度順位ではなく、再測定を始めるための用途別候補です。

法人サイトではXServerビジネスも候補です。速度だけでなく、移行、問い合わせ、復旧、担当者が迷わず操作できるかまで含め、通常のエックスサーバーやマネージドサービスと比較してください。

レンタルサーバーの速度はどこで決まる？

「サーバーが遅い」と感じても、遅延の発生場所は一つではありません。TTFBはリクエスト開始から最初の1バイトを受け取るまでの時間ですが、その中にはリダイレクト、DNS、接続、TLS、CDN、オリジンサーバーの処理などが影響します。さらにHTMLを受け取った後は、画像、CSS、JavaScript、フォント、広告タグがLCPやINPを左右します。

Core Web Vitalsは75パーセンタイルで判定します。平均値や最高スコアではなく、モバイルとデスクトップを分け、少なくとも75%の訪問で良好基準を満たすかを確認します。

旧TTFB18社を証拠監査：なぜ順位に使えないのか

次の値は旧記事に掲載されていた記録です。削除すると過去記事の検証経緯を追えなくなるため残しますが、共通の日時・地点・URL・試行回数・プラン・キャッシュ条件・生ログがないため、2026年の性能順位や契約判断には使用しません。

30msと440msの差が見えても、そのまま約15倍速いとは言えません。CDNキャッシュされた静的ページと、遠距離から測ったWordPress動的ページが混ざっていれば、比較対象そのものが異なります。

旧値から統計量を再計算することもできません。1回の値なのか複数回の平均なのか、コールドかウォームか、どのURLかが分からないためです。今後の比較ではCSVまたはJSONの生値、レスポンスヘッダー、測定日時を保存します。

旧記事で保存した測定画面・サービス画像を見る

比較前に固定する10の測定条件

サービス名以外の条件を揃えなければ、差がサーバー由来なのか、サイトやネットワーク由来なのか判断できません。測定前に次の10項目を1枚の測定票へ記録します。

再現できる速度測定を行う6ステップ

測定値を増やすこと自体が目的ではありません。「同じ手順を別の担当者が実行しても、近い結論に到達できること」を目標にします。

1. 用途と運用条件で候補を2〜3社へ絞る

   訪問者地域、月額上限、WordPress、メール、バックアップ、電話・チャット、移行支援を必須・希望・不要に分けます。

2. 本番に近い複製サイトを作る

   軽い初期テーマではなく、実際に使う画像、記事量、プラグイン、フォームを入れます。個人情報や本番キーはコピーしません。

3. コールドとウォームを分ける

   キャッシュ削除直後の初回と、キャッシュが温まった再訪を別の測定群にします。CDN HIT/MISSもレスポンスヘッダーで確認します。

4. 各条件を最低5回、できれば10回測る

   1回目だけ、最小値だけを採用しません。エラーや外れ値も消さず、除外する場合は理由を残します。

5. 時間帯を変え、中央値と遅い側を比較する

   共有サーバーは混雑の影響を受けます。朝・昼・夜で測り、中央値、75パーセンタイル、最大付近を確認します。

6. 表示・管理・復旧を一つの評価表で採点する

   TTFBだけでなく、LCP・INP・CLS、管理画面、バックアップ復元、問い合わせ、移行、更新費を同時に評価します。

curlでTTFBを反復記録する例

次の例はDNS、接続、TLS、TTFB、総時間をCSV形式で10回記録します。キャッシュを消す処理は含まれないため、コールド測定では各サービスのキャッシュ削除機能を別途使い、レスポンスヘッダーも保存してください。

printf "run,dns,connect,tls,ttfb,total,http_code\n"
for i in $(seq 1 10); do
  curl -sS -o /dev/null \
    -w "$i,%{time_namelookup},%{time_connect},%{time_appconnect},%{time_starttransfer},%{time_total},%{http_code}\n" \
    "https://example.com/target-page/"
done

curlのTTFBとPSIの値が違っても異常とは限りません。測定地点、端末、ネットワーク、リダイレクト、キャッシュ、ツールの集計範囲が異なります。異なるツールの値を同じ列で平均しないでください。

最終評価は3群に分ける

PageSpeed Insightsを正しく読む

PageSpeed Insightsには、実ユーザーのフィールドデータと、制御された環境でのラボデータが表示されます。両者は対象期間と環境が異なるため、数値が一致しないことは珍しくありません。

フィールドデータは過去28日間の実利用を集計

CrUXのフィールドデータは、実際のChromeユーザーの体験を集計した28日間のローリングデータです。1日前の変更がすぐ全面反映されるわけではなく、URL単位のデータが不足するとオリジン単位だけが表示される場合があります。

ラボデータは改善箇所を再現しやすい

Lighthouseのラボ計測は、同じ条件で再実行しやすく、開発中の回帰検知や原因調査に向いています。一方、単一の端末・回線を模擬するため、地域や端末性能が多様な実利用全体は表しません。

INPは実操作が必要。ラボではTBTを補助にする

INPは実際のユーザー操作から測る指標です。自動実行のLighthouseだけでは同じ方法でINPを測れないため、ラボではTotal Blocking Timeを補助指標として使い、公開後はCrUXや自社RUMでINPを確認します。

速度だけで契約すると失敗する6つの条件

表示が数十ミリ秒速くても、復元できない、更新費を払えない、メールが移行できない、担当者が操作できないサーバーは、事業サイトにとって速い選択とは言えません。

サーバーを乗り換えるべきサイン

遅いと感じた瞬間に移転するのではなく、まず原因を切り分けます。次の状態が複数当てはまり、改善しても解消しない場合は、テスト環境を作って移転候補を比較する価値があります。

• 複数時間帯でTTFBの遅い側が継続し、キャッシュを使ってもLCPへ影響している
• CPU・メモリ・同時実行数などの制限に頻繁に達し、上位プランでも改善余地が小さい
• WordPress管理画面、検索、フォーム、決済などキャッシュできない処理が遅い
• アクセス増でエラーが出るが、リソース状況やログを確認できない
• バックアップ復元が難しい、保持期間が足りない、復旧テストができない
• サポート範囲、更新費、管理画面が現在の運用体制に合わなくなった

サーバー以外が原因なら、移転前に直した方が安全です。未圧縮画像、重いスライダー、広告タグ、不要なプラグイン、JavaScript、フォント、レイアウトシフトが主因の場合、移転後も問題が残ります。

2026年7月に確認した公式情報

速度指標はGoogle・Chromeの一次情報、サービス機能は各社の公式ページで確認しました。料金やキャンペーンは変わりやすいため、本文では固定的なランキング材料にせず、申込み直前に公式画面で再確認する前提としています。

• web.dev：Core Web Vitals（LCP・INP・CLSと75パーセンタイル）
• web.dev：TTFBの測定、0.8秒の粗い目安、フィールドとラボの違い
• Google：PageSpeed Insightsのフィールドデータとラボデータ
• Chrome for Developers：CrUX各ツールと28日間ローリングデータ
• エックスサーバー：現行の主な機能
• wpX Speed：WordPress専用環境、NVMe、オートスケール
• Kinsta：データセンター所在地（東京・大阪を含む）
• Hostinger：現行Webホスティングプランと機能
• ConoHa WING：現行機能と速度計測条件
• mixhost：LiteSpeed Cache、バックアップ、現行サービス情報
• スターサーバー：新規受付終了と後継スターレンタルサーバーの案内

レンタルサーバー速度比較のよくある質問