ローエンドデバイス向けにCore Web Vitalsを最適化する

ローエンドデバイス向けにCore Web Vitalsを最適化する

Core Web Vitalsは、サイト品質の客観的なベンチマークの一部であるべきだ。しかし実際にはそうではない！これらの指標は、ユーザーが使用するデバイスと密接に結びついている。ハイエンドの製品やサービスを販売する企業であれば、その顧客は高速なスマートフォン、デスクトップ、そして信頼性の高い回線を所有している傾向がある。
それとは対照的に、コストを重視する買い物客や新興市場をターゲットにする企業を考えてみよう。彼らのオーディエンスは、古いスマートフォン、貧弱なプロセッサ、または劣悪なネットワーク条件に依存している。
最新のiPhoneでのテストを軽々とクリアする同じウェブサイトが、ミッドレンジのAndroidや低帯域幅の接続環境にある国々では、許容範囲内で読み込むことさえ困難になる。

最終レビュー: 2026年3月、Arjen Karelによる

数字が物語る真実

2025 Web Almanacによると、モバイルオリジンのうちCore Web Vitalsに合格しているのはわずか48%であり、デスクトップの56%と比較して低い。最も大きな格差はINPに見られる。デスクトップオリジンは97%が合格しているのに対し、モバイルではわずか77%にとどまっている。この20パーセントポイントの差は、ほぼすべてAndroidデバイスの遅いCPUによって引き起こされている。

モバイルにおけるTotal Blocking Timeの中央値は1,916ミリ秒である。デスクトップはどうだろうか？ 92ミリ秒だ。これは20対1の比率である。あなたのMacBookでスクリプトが問題なく動作するとしても、低価格のスマートフォンでは絶対に正常には動作しない。

Alex Russellの調査によると、実際に使用されているデバイスの約30%はローエンド（4コア以下、4GB RAM以下）である。これらのデバイスのシングルコア性能は、最新のiPhoneよりも最大9倍遅い。CoreDashのRUMデータでは、ローエンドデバイス向けに最適化されたサイトはモバイルページロードの62%でCore Web Vitalsに合格するのに対し、ハイエンドハードウェアのみでテストされたサイトではわずか41%にとどまることがわかっている。

ステップ1: クライアント機能スコア(Client Capability Score)を生成する

訪問者がハイエンドデバイスを使用しているか、ローエンドデバイスを使用しているかを評価するために、ブラウザ内で直接クライアント機能スコアを計算できる。このスコアは0（極めて制限されている）から100（トップクラスのハードウェア）の範囲である。実際のところ、40を下回るスコアのデバイスはすべてpoor(貧弱)と分類すべきである。

以下の関数は、実際のRUMおよびGoogleのCore Web Vitalsデータと強い相関を持つハードウェアおよびネットワーク指標を使用して、クライアント機能スコアを計算する。スコアが高いほど、デバイスがより少ないリソース制約で高速なページパフォーマンスを提供する能力が高いことを示している。

function getClientCapabilityScore() {
  const mem = navigator.deviceMemory || 4;
  let cpu = navigator.hardwareConcurrency || 4;
  cpu = Math.min(cpu, 8);

  let net = 4;
  if (navigator.connection) {
    const { effectiveType, rtt = 300 } = navigator.connection;
    const map = { 'slow-2g': 1, '2g': 2, '3g': 3, '4g': 4, '5g': 5 };
    net = map[effectiveType] || 4;
    if (rtt > 500) net = Math.max(net - 3, 1);
    else if (rtt > 300) net = Math.max(net - 2, 1);
    else if (rtt < 150) net = Math.min(net + 1, 5);
  }

  const score = mem + cpu * 0.5 + net * 2;
  return Math.min(100, Math.round(score * 5));
}

getClientCapabilityScore();

Core Web Vitalsのヒント: これらの最適化はすべてのユーザーに役立つ。しかし、低速な接続を利用している人やメモリが限られたデバイスを使用している人にとっては、その重要性ははるかに高まる。最適化を怠った場合の欠点がより早く現れるからだ。
画像のダウンロードを例にとってみよう。通常の接続では、画像はLargest Contentful Paintにかかる時間の約10%を占めるのが一般的だ。これが低速な接続になると、容易に2倍に跳ね上がる可能性がある。そのため、ほとんどのユーザーに対しては画像最適化をリストの最上位には置かないが、低帯域幅やメモリに制約のある訪問者に対応する場合は、瞬時に最優先事項となる。

QUICと0-RTTでHTTP/3を有効にする

サーバーから遠く離れている訪問者や低速なネットワークに囚われている訪問者は、高いラウンドトリップタイム(RTT)に直面する。HTTP/3は、QUICおよび0-RTTとともに、初期接続速度を直接的に向上させる。これはすべての訪問者にとって重要な最適化だが、低帯域幅の訪問者にとっては特に極めて重要である。Cloudflare Radarによると、HTTP/3は現在、世界のウェブトラフィックの21%を処理している。Cloudflareを使用している場合は、CloudflareダッシュボードでHTTP/3を有効にすることができる。

• より高速な接続セットアップ: QUICは、トランスポートと暗号化のハンドシェイクを1つに統合する。0-RTTはさらに一歩進み、リピーターはハンドシェイクを完全にスキップしてデータを即座に送信できる。
• 再訪問ユーザーのレイテンシ低減: 0-RTTにより、クライアントは一時停止することなくセッションを再開し、リクエストを送信できる。数百ミリ秒の節約は、遠方やモバイルのユーザーにとって特に価値がある。
• 長距離での耐障害性: HTTP/3 (UDP上) は、TCPのヘッドオブラインブロッキングを回避する。QUICは、パケットロスや不安定なネットワークをより優雅に処理する。これは、大陸間通信や不安定なモバイル接続において真の違いをもたらす。

デザイナーの好みよりも積極的に画像を圧縮する

高解像度の画像は、特にGPUの展開能力が限られているデバイスにおいて、LCPを停滞させる。2025 Web Almanacによると、モバイルのホームページの中央値では911KBの画像が読み込まれている。これはページ全体のウェイトの42%に相当する。9 MbpsのP75ダウンリンクを持つ低価格のデバイスでは、これらの画像がクリティカルなリソースと直接競合してしまう。

美観に屈するのではなく、よりサイズが小さく、視覚的に許容できる画像を目指すべきだ。WebPやAVIFも役立つが、遅延読み込み(lazy-loading)やレスポンシブなサイズでの提供の方がさらに重要である。

明確なルールとして、ローエンドデバイスのヒーロー画像は100KB未満に抑えること。もしデザイナーが反対するなら、それ以上反論する前に、同じサイトを100ユーロのAndroidスマートフォンでテストしてもらうべきだ。

厳密に必要なものだけにCSSを削ぎ落とす

スタイルに関しては、唯一のルールがある。それは大掃除(clean house)だ。未使用のセレクタを削除し、詳細度を下げ、冗長なルールをまとめること。

オーバーライドを最小限に抑えた、予測可能で一貫性のあるレイアウトに焦点を当てる。複雑なコンポーネント固有のスタイルよりも、少数のユーティリティクラスのセットを使用する。これは、ブラウザのCSSOM構築と開発者のメンテナンス性の両方に役立つ。

アバブ・ザ・フォールド（スクロールせずに見える範囲）のコンテンツについては、絶対に必要不可欠なものだけをインライン化する。残りは遅延読み込みにするが、分割は最小限かつ明確に保つ。Critical CSS Generatorを出発点として使用できるが、最高の結果を得るには、クリティカルCSSを手動で、かつ外科手術のように正確に定義することだ。

スクリプトに対しては容赦なく対処する

モバイルのTBTの中央値が1,916ミリ秒（2025 Web Almanacによると前年比58%増）であることを考えると、ローエンドデバイスにおいてJavaScriptは最大の問題である。低価格デバイスのP75ネットワーク速度は、100msのRTTで約9 Mbpsのダウンリンクである。配信するJavaScriptのすべてのキロバイトは、あなたがテストに使用しているスマートフォンよりも9倍遅いCPUで解析され、実行される。

• レンダリングをブロックするスクリプトをなくす: 必須ではないすべてのスクリプトが非ブロッキングであることを確認する。<script>タグにはasyncまたはdefer属性を使用すること。スクリプトが初期のページロードやユーザーインタラクションに不可欠でない場合、同期的であってはならない。遅延テクニックの完全な概要については、JavaScriptを遅延させる16の方法を参照のこと。
• 非クリティカルなスクリプトをスケジュールする: 前もって必要とされないスクリプトはスケジュールされるべきだ。ブラウザがアイドル状態のときにスクリプトを発火させるには、requestIdleCallbackを使用する。これにより、クリティカルなレンダリングパスを妨げることなく、重いタスクをオフロードできる。
• クライアント機能スコアを使用してスクリプトを選択的に読み込む: スコアを利用して何を読み込むかを決定する。ローエンドデバイスでは、スクリプトの数を減らし、より軽量な代替手段を選択する。ユーザーのメモリが限られているか、古いCPUを使用している場合は、重いスクリプトの読み込みにリソースを無駄にしてはならない。ハイエンドデバイスでは見栄えがするかもしれないが、ローエンドデバイスではイライラさせるような虚栄心の強い機能よりも、パフォーマンスを優先すべきだ。

システムフォントを使用するか、少なくとも重いカスタムフォントを避ける

カスタムフォントの読み込みは、レイテンシを追加し、レイアウトをガタつかせる。メモリが限られているデバイスでは、不必要にRAMへの圧力を高める可能性もある。2025 Web Almanacによると、88%のサイトが少なくとも1つのWebフォントを読み込んでいるが、それらをプリロードしているのはわずか12%である。パフォーマンスにとって最良のオプションであるfont-display: optionalを使用しているサイトはわずか0.4%にすぎない。

システムフォントはより高速にレンダリングされ、ユーザーの設定を尊重し、レイアウトシフトを軽減する。もしブランディングでカスタムタイポグラフィが必須の場合は、積極的にサブセット化を行い、フォントを遅く読み込むようにする。配信を制御できるように、フォントをセルフホストすることも検討すべきだ。

合成テストだけでなく、実際のハードウェアで監視する

合成テストツール（LighthouseやWebPageTestなど）はスロットリングをシミュレートするが、熱、実際の負荷下でのスロットリング、ガベージコレクションによる一時停止、ストレージのボトルネックなど、ローエンドハードウェアのすべての癖を模倣するわけではない。PageSpeed Insightsが2024年12月にCPUスロットリングを4倍から1.2倍に変更したことに留意してほしい。これにより、ラボスコアは実際の低価格デバイスのパフォーマンスをさらに反映しにくくなっている。

安価なAndroidスマートフォンを購入して、自分のサイトを閲覧してみよう。もしそれを定期的に行うことに耐えられないのであれば、CoreDashのようなRUMツールを使用し、デバイスクラスごとにデータをセグメント化すること。もしP75のLCPがiPhone 15では問題ないのに、Xiaomi Redmi 9でひどい状態であるなら、誰のために最適化しているのかを正直に見直す時だ。