タグ: パフォーマンス

web.devが10月2日に公開した9月分のウェブプラットフォーム新機能まとめに、地味ながら気になる項目がありました。Safari 27が、Service Workerの「Static Routing API」に対応したという話です。Chromeでは版123から使えていた機能で、これでSafariとChrome系の両方で動くようになりました。表示速度に関わる仕組みなので、少し掘り下げて紹介します。

Service Workerが抱えていた待ち時間

Service Workerは、ページとネットワークの間に入って通信を仲介するスクリプトです。オフライン表示やキャッシュの制御に使われ、WordPressでもPWA化やキャッシュ系のプラグインを通じて、知らないうちに組み込まれているサイトがあります。

ただ、Service Workerを置くと、そのサイトへのリクエストはいったんService Workerのfetchイベントを通るのが基本です。Service Workerが止まっている状態なら、まず起動させてから処理を始めることになります。結果として、キャッシュから返すだけ、あるいはそのままネットワークへ流すだけのリクエストでも、Service Workerの起動を待つ時間が生じていました。

Chrome for Developersの解説によると、Static Routing APIはこの部分を解消するためのものです。どのパスをどこから取得するかをあらかじめ宣言しておくことで、ブラウザはキャッシュやネットワークから取るだけのためにService Workerを動かさずに済むとされています。web.devの記事でも、起動を待たずに取得できることでページ遷移の速度が上がると説明されています。

インストール時に道筋を登録しておく

使い方は、Service Workerのinstallイベントの中で event.addRoutes() を呼び、振り分けのルールを渡すだけです。ルールは「条件」と「取得元」の組み合わせで書きます。

条件には、URLの形(urlPattern)、リクエストのメソッド、モード、取得先の種類、Service Workerが起動中かどうか、を指定できます。複数の条件を書いた場合は、すべてを満たしたときだけそのルールが使われます。取得元は、ネットワーク、キャッシュ、従来どおりのfetchイベント、ネットワークとfetchイベントを競わせる方式、の中から選びます。名前を指定して特定のキャッシュストレージを使うこともできます。

たとえば、フォームへのPOST送信はService Workerを通さず、そのままネットワークへ送る、という指定は次のように書けます。

addEventListener('install', (event) => {
  event.addRoutes({
    condition: {
      urlPattern: "/form/*",
      requestMethod: "post"
    },
    source: "network"
  });
});

画像の拡張子を条件にして特定のキャッシュから返す、記事ページはService Workerが起動中のときだけfetchイベントに回す、といった書き分けも解説の例に挙がっています。なお、試験提供の段階では registerRouter() という一度しか呼べないメソッドでしたが、利用者の意見を受けて今の addRoutes() に変わったそうです。Chromeの開発者ツールでは、Applicationパネルに登録済みのルールが表示され、Networkパネルでもルールに一致したリクエストを見分けられます。

制作現場で押さえておきたいこと

web.devの対応表を見ると、ChromeとEdgeは版123から、Safariは今回の27から対応していますが、Firefoxはまだ未対応です。対応していないブラウザでは従来どおりfetchイベントで処理されるだけなので、ルールを追加しても表示が壊れるわけではありません。速くなる環境が増えた、と受け止めるのが妥当なところです。

中小企業のサイトで直接この記述を書く場面はそう多くないかもしれません。それでも、Service Workerを使っているサイトを引き継いだときや、キャッシュ系のプラグインを選ぶときに、こうした振り分けに対応しているかどうかは一つの見どころになります。特にお問い合わせフォームや管理画面への通信のように、キャッシュを挟む意味がないリクエストを素通しにできるのは、速度だけでなく不具合の切り分けの面でも助かります。

Service Workerは入れると速くなる一方で、仲介が増えるぶんの負担もある、という両面を持つ仕組みでした。その負担を宣言ひとつで減らせる手段が主要なブラウザにそろってきたので、手元のサイトでService Workerが何を受け持っているのか、一度確かめてみる良い機会だと思います。

表示速度の指標として広く使われている Core Web Vitals には、長いあいだ埋まらない空白があった。JavaScript で画面の中身だけを差し替えるタイプのサイトでは、アドレスバーの URL が変わっても「新しいページを読み込んだ」とは扱われず、最初の読み込み時に測った数値がそのまま残り続けていた。その空白を埋める仕組みが Chrome に入り、解析サービス側の対応もこの夏から動き出している。

操作とURLと描画がそろった瞬間を区切りとみなす

Chrome の開発者向け資料では、この仕組みは「ソフトナビゲーション」と呼ばれている。何をもって画面の切り替わりとみなすかについて、ユーザーの操作が起点になっていること、ユーザーから見える形で URL が変わること、その操作の結果として実際に描画が起きること、という三つの条件が示された。この三つがそろったときにはじめて、ブラウザは新しい時間の起点を置く。

これが長らく難しかった理由も、あわせて説明されている。web.dev の解説によると、画面の一部だけを差し替える作りには標準的な型がなく、URL を更新するタイミングも、中身を読み込む順序も、サイトごとにばらばらだという。ちょっとした表示状態の変化でも URL を書き換えるサイトがある一方、まとまった単位でしか書き換えないサイトもある。この差を無視して一律に数え始めると、かえって実態から離れた数字になってしまう。だからこそ、フレームワークの違いに左右されない共通の線引きが必要だった。

二種類の記録が時系列に追加された

実装は Chrome 151 に入り、既定で有効になっている。パフォーマンスの時系列に、soft-navigation と interaction-contentful-paint という二種類の記録が追加された。前者は操作をきっかけにした同一文書内の履歴変化を報告し、そこから先の計測を最初の URL ではなく現在の画面に結びつける。後者は、操作によって書き換えられた部分に新しく描かれた内容を報告するもので、非同期の読み込みをまたいだ待ち時間も追える。

この二つがあると、切り替え後の画面についても LCP や INP、CLS を区切って測れるようになる。ただし細かい扱いには注意点が多い。同じ画像を出し続けている箇所は再描画されないため LCP の対象から外れ、通常の読み込みと切り替え後とで最大要素が変わることがある。最初のバイトが返るまでの時間にあたる TTFB は、切り替え時には便宜的にゼロとして扱うのが現在の推奨だ。こうした処理を自前で書かずに済むよう、公式の計測ライブラリ web-vitals は v6.0.0 でこの仕組みに対応している。

解析サービス側の数字が動くことがある

ブラウザが対応しても、実際に数値を見るのは解析サービスの画面だ。そちらの動きも出てきている。Cloudflare は 8 月 21 日に Web Analytics の計測改善を告知し、その変更履歴では 9 月 4 日に展開が完了したとしている。従来の全画面遷移に加えて、新しい API が使える環境での切り替えと、使えない環境で履歴の書き換えから推測した切り替えを、それぞれ別の種類として記録するようになった。後者では LCP は取れないが、ほかの指標は取得できるという。

注意したいのは、告知のなかで、ページビューや訪問の集計値、そして LCP の数値が変動しうると明記されている点だ。サイトの作りによって振れ幅は変わる。数字が動いたときにサイト側の不調を疑う前に、計測方法が変わったのではないかと一度立ち止まれるかどうかで、無駄な調査時間はかなり変わってくる。

手元のサイトで気にしておきたいこと

中小企業のサイトの多くは、ページごとに読み込み直す普通の作りなので、この話が直接効いてくる場面は限られる。とはいえ、商品の絞り込み、予約や見積もりの入力画面、地図や一覧の切り替えなど、部分的に画面を差し替えている箇所は珍しくない。そこがどれくらい待たされているかは、これまで数字として残りにくかった部分だ。

現時点で対応しているのは Chromium 系のブラウザだけで、検索まわりで参照される実測データにいつ反映されるかも、まだ示されていない。順位のために慌てて何かを変える話ではない。それでも、開発者ツールの計測画面ではすでに切り替えの区切りが見えるようになっている。自社サイトで JavaScript による画面の差し替えを使っているなら、その部分の待ち時間を一度自分の目で確かめておくと、次に改善に手をつけるときの判断材料になる。

自分の作業機では軽快に動くのに、お客様の手元ではもたつく。制作の現場では何度も出会う話です。8月25日に安定版が公開されたChrome 152に、この端末ごとの差を扱うための小さな仕組みが入りました。CPU Performance APIと呼ばれるもので、閲覧している端末の処理性能の目安を、ごく粗い段階の数値としてJavaScriptから読み取れます。

使い方はそっけないほど簡単で、navigator.cpuPerformance を参照すると小さな整数が返ってきます。値が大きいほど性能の高い端末、という意味づけです。Chromeの開発者向けブログでは、描画の作り込みを加減する、重い計算を減らす、裏で走らせる処理の量を調整するといった使い方が挙げられています。

これまでは自前で測るしかなかった

仕様草案によると、端末の性能に応じて中身を出し分けたいという要望は以前からあり、実現しているアプリは自前でベンチマーク相当の処理を走らせるか、ウェブには開かれていない内部的な機能に頼っていたとされています。性能を測るために端末に余計な仕事をさせるのは、順序が逆さまな感じもします。提案の目的のひとつは、この無駄をなくすことだと書かれています。

考え方としては、以前からある端末メモリ量の取得と似ています。細かい実測値ではなく、あらかじめ用意された区分のどれに当てはまるかだけを返す。navigator に読み取り専用の値をひとつ足すという形も同じ流儀です。

段階の分け方と、身元の割り出しへの配慮

返る値は1から4までの4段階で、判定できなかった場合は0です。基本の分け方は、OSが報告するコア数をもとにした素朴なもので、1コアなら1、2から4コアなら2、5から10コアなら3、それ以上なら4と決まっています。そのうえで、特定のCPUがコア数から想像される性能と大きく違うと分かっている場合に限り、ブラウザ側が段階を上下に1つずらしてよいことになっています。

おもしろいのは、この区分を将来にわたって動かさないと決めている点です。もっと高性能な端末が出てきたら、既存の端末を格下げするのではなく5段目を足す。同じ端末なら、混雑していても電池が減っていても、いつでも同じ値を返す。古い端末で古いアプリを開いたときの見え方が、時間が経っても変わらないようにするための約束事です。

もうひとつの軸が、閲覧者の身元を割り出されにくくすることです。CPUの製造元や型番、コア数をそのまま渡せば、端末を特定する手がかりが増えてしまいます。そのため仕様では、それぞれの段階に既存のCPU機種の1割以上、実際に使われている端末の1割以上が入るくらいの粗さを保つべきだとしています。利用できるのはHTTPS接続の場面に限られます。

参考値として付き合う

気に留めておきたいのは、この値が絶対的な事実ではないことです。Chromeでは閲覧者自身が設定画面から報告される段階を上書きでき、組織のパソコンでは管理者が方針で指定することもできます。値はあくまで判断の材料であって、これを根拠に機能を完全に閉ざす作りにすると、上書きした人が困ることになります。

他のブラウザの姿勢も、現時点では表明されていません。提案文書でChromeは前向きとされている一方、Edge、Firefox、Safariは公開の意見なしと記されています。当面はChromeだけで読める値だと考え、取得できないときや0が返ったときにどう振る舞うかを先に決めておく必要があります。仕様の例では、判定できなかった端末は高性能側と同じ扱いにしています。

加えて、この値が示すのは端末の地力であって、いまその端末が忙しいかどうかではありません。今この瞬間の混み具合を見たい場合は、別途用意されているCompute Pressure APIと組み合わせる想定です。読み込み時に演出を出すかどうかを決め、その後の負荷を見ながら止めたり戻したりする、という二段構えの例が示されています。

中小企業のサイトで、この値をすぐに使う場面はそう多くないはずです。ただ、同じページでも端末によって体験がまるで違うという前提は、値を読むかどうかとは関係なく効いてきます。凝った動きを見せ場にするなら、それが動かない端末でも内容が伝わるか。制作側が握っているのは結局そこで、こうしたAPIはその判断を少しだけ具体的にしてくれる道具だと考えています。

一度入れた外部ライブラリを、あとから見直すことはあまりない。動いているし、テストも通っているし、あえて触る理由がない。ただ、その間にもブラウザ側は動いていて、いま package.json に並んでいるもののうち何割かは、すでにブラウザが自前で持っている機能と重なっている。Smashing Magazine に出た依存関係の棚卸しの記事が、その重なりを具体的な数字で示していて面白かった。

入れたきりの依存が積み上がっていく

記事によると、中規模のJavaScriptアプリでは、圧縮後でおよそ60KBから90KB分の依存が、いまやブラウザ側で代替できる範囲に入っているという。日付や数値の書式、HTTP通信、モーダル、ツールチップ、オブジェクトの複製、配列のグループ化。数年前までは確かに穴だった領域が、順に埋まってきた結果だ。

それでもライブラリが残り続けるのは、怠慢だからではないと筆者は書いている。セキュリティの観点で npm audit は回していても、「このライブラリは今もブラウザにできないことをやっているのか」という問いを立てる機会が、そもそも運用の中に組み込まれていない。だから入れたまま何年も過ぎる。複数サイトの保守を抱えている制作の現場だと、この感覚は身に覚えがあるのではないかと思う。

Baselineという安全度の目盛り

棚卸しの物差しとして使われているのが Baseline だ。WebDX Community Group による指標で、ある機能が主要ブラウザ(Chrome、Edge、Firefox、Safari)でどこまで安全に使えるかを三段階で示す。全エンジンには載っていない「限定的な利用可能性」、出そろった直後の「新しく利用可能」、出そろってから30か月が経った「広く利用可能」という並びになっている。

この30か月の差が、棚卸しでは効いてくる。広く利用可能なものは、基本的に今日そのまま置き換えを検討できる。新しく利用可能な段階のものは、自分のサイトの訪問者層を確かめてから決める話になる。状態は webstatus.dev や、MDN の各機能ページに付いているバッジで引ける。

消す前に通しておきたい三つの問い

「ブラウザができるようになった」と読んで、すぐ削り始めないほうがいい、というのが記事の立場だ。紙の上では無料に見える置き換えが、一部の利用者の環境を静かに壊すことがあるし、気づかずに頼っていた機能を落とすこともある。そこで、削る前に三つ確認する。

ひとつめは、代替となる機能が自分の利用者にとって安全かどうか。一般論としてのBaselineではなく、アクセス解析や browserslist の設定と突き合わせて判断する。社内向けの管理画面と、古い端末からの流入が長く続く一般向けサイトでは、答えが変わる。

ふたつめは、置き換えの費用。ブラウザ側の対応が足りずポリフィルを足すことになり、それが外したライブラリより重ければ、容量は増えている。

みっつめは、ブラウザの機能が実際の使い方をカバーしているか。ライブラリは見た目の似た標準機能より多くの仕事をしていることが多い。記事が挙げているのが axios で、fetch に置き換えると、404や500で拒否されない、共通処理を差し込むインターセプタがない、自動再試行がない、アップロードの進捗が取れない、といった差が出る。実際にどこまで使っているかを見てから決める、という順番になる。

置き換えが効きやすいのは書式と画面部品まわり

記事はライブラリを一個ずつではなく、かたまりで見ていく。いちばん取りやすいのが国際化まわりで、相対時間、数値や通貨の書式、複数形、配列を文章に連結する処理は、ブラウザの Intl 系で大半が置き換えられる。この一群でおよそ14KBという計算だ。ただし継続時間の書式は主要エンジンに出そろったのが2025年3月で、広く利用可能になるのは2027年の見込みとされている。

もうひとつ大きいのが画面部品で、こちらはツールチップやポップオーバーのライブラリまで含めて合計およそ24KB。このうちモーダル用のライブラリ、フォーカスを閉じ込める処理、背景のスクロールを止める処理が、dialog要素とCSSの一行にまとまる。showModal で開けば、フォーカスが中に移り、背後が操作できなくなり、Escapeで閉じ、閉じたあとは元の要素にフォーカスが戻る。重なり順もブラウザが面倒を見るので、z-index と格闘しなくてよくなる。手書きの実装より結果的に読み上げ環境への配慮が行き届く、という指摘もうなずける。

通信まわりも同じ見方ができる。よく使われるHTTPクライアントは圧縮後で17KBから19KBほどあり、単純な取得や送信であれば fetch と中断用の仕組みで足りる。タイムアウトも標準の指定で書ける。ここは前述のみっつめの問いが効く場所で、共通処理や再試行に頼っているなら、外した分を自分で書き直すことになる。

配列やオブジェクトの操作も、グループ化や深い複製、集合の和や積は標準側に入った。一方で debounce と throttle には今も標準の代わりがないので、そこは残す。全部捨てるという話ではなく、ブラウザがすでに持っている部分を二重に配らない、という整理だ。

今は手放さないという判断も同じ枠組みから出る

この記事の良いところは、置き換えない例をきちんと入れているところだ。JavaScriptの日付処理を置き換える Temporal は、2026年3月に仕様策定の最終段階に達し、Firefox と Chrome には載ったが、Safari の安定版にはまだ来ていない。全ブラウザで使うにはポリフィルが要る。

そこで数字を並べると、軽量な日付ライブラリが圧縮後3KB程度なのに対し、公式のポリフィルは44KB前後ある。今すぐ乗り換えると容量は減るどころか増える。三つの問いに通すと、機能の良さでは勝っていても、利用者の範囲と費用で落ちる。だから今は現状維持で、Safari が対応してBaselineに入った時点でもう一度見る。判断を「保留」として記録しておける枠組みは、実務では地味に効く。

ブラウザ側の受け皿は今も増えている

置き換え先が増え続けているのも事実で、Chrome 150では、矢印キーでの移動やフォーカス位置の記憶を属性の指定だけで賄える focusgroup が入った。従来は tabindex を書き換える手書きのスクリプトで実現していた部分だ。文字を枠幅に合わせて拡縮する text-fit や、border-image の回り道なしでグラデーションの枠線を描ける background-clip の新しい値も同じ流れにある。

続く Chrome 151 のベータでは、コンポーネントの内側にある要素を aria-labelledby などから参照できる仕組みや、複合的な部品の中の補助的な操作を支援技術に伝える aria-actions が挙がっている。手書きのJavaScriptで補っていた振る舞いが、少しずつ宣言的な記述に移っていく。

中小企業向けのサイトだと、そもそも巨大な依存を抱えていないことも多い。それでも、テーマやプラグインが読み込んでいるものを一度数えてみる価値はある。四半期に一度、本番に出ている依存だけを並べ、それぞれが実際のビルドでどれだけ容量を占めているかを解析ツールで測り、代わりになる機能のBaselineの状態を確かめる。そのうえで先ほどの三つの問いに通し、いま標準になっているものを返していく。それだけで表示は軽くなり、更新を追いかける対象も減る。まずは一つの分野だけ選んで手元の設定ファイルを開いてみる、という始め方が現実的だと思う。

サイトの表示速度を測る指標として、Core Web Vitalsはすっかり定着しました。ところが、この指標には長らく穴があると言われてきました。ページを読み込み直さずに中身だけを差し替える作りのサイトでは、最初の一回しか計測されないという問題です。Chromeの最新版で、この部分をブラウザ側で測る仕組みが正式に使えるようになりました。

Chromeの開発者向け資料によると、Soft Navigations APIと呼ばれるこの機能は、試験運用の期間を経て、2026年7月に公開された版から設定を切り替えずに利用できるようになりました。名前のとおり、ソフトナビゲーション、つまり読み込み直さない画面遷移を計測の対象にするものです。

これまで測れていなかった部分

従来のCore Web Vitalsは、ブラウザがURLを開いて新しい文書を読み込む、いわゆる通常の遷移を前提に設計されています。表示までの時間を示すLCP、レイアウトのずれを示すCLS、操作への反応を示すINPは、どれもそのページが開かれた時点を起点に集計されます。

JavaScriptで画面を組み立てる作りのサイトでは、二画面目以降はURLだけが書き換わり、文書の読み込みは起きません。ブラウザから見れば一枚のページがずっと開かれたままなので、二画面目の表示がどれだけ遅くても、最初の一枚の数字に埋もれてしまいます。逆に、最初の表示さえ速ければ全体が良好に見えてしまうこともありました。計測ツール側で独自に区切りを入れる回避策はありましたが、実装ごとに基準が違い、横に並べて比べられる数字にはなりにくい状態でした。

ブラウザはどこで区切りを判断するのか

新しい仕組みでは、ブラウザ自身が三つの条件をもとに画面の切り替わりを見分けます。利用者の操作がきっかけになっていること、利用者から見えるURLの変化を伴うこと、そしてその結果として実際に画面が描き直されること。この三つがそろったときに、ひとつの区切りとして扱われます。

あくまで推測にもとづく判定なので、公式の説明でも、サイトの作り方によっては拾いすぎたり拾いそこねたりすることがあると断っています。それでも、判定の基準がブラウザ側に統一されたこと自体に意味があります。計測ツールを乗り換えても、同じ考え方で区切られた数字が並ぶからです。

計測する側で増えたもの

開発者から見ると、パフォーマンス情報を受け取る仕組みに新しい種類の記録が追加された形になります。切り替わりそのものを表す記録と、切り替わったあとの主要な描画を表す記録が加わり、既存の各種タイミング情報にも何番目の遷移かを示す値が付くようになりました。これで、ひとつの記録がどの画面のものかを判別できます。

ただし、これらを直接扱うのはそれなりに骨が折れます。読み込み直さない遷移では最初の応答までの時間がゼロとして扱われるなど、通常の遷移とは数字の意味が変わる場面もあるためです。Googleが公開している計測用のライブラリweb-vitalsは、新しい版でこのあたりを内部で吸収するようになっており、URLの対応付けや数値のリセットを任せられます。自前で計測基盤を持っているところ以外は、ライブラリの更新に乗るほうが現実的でしょう。

今すぐ効いてくる話ではない

注意しておきたいのは、この計測結果が検索での評価にそのまま反映されるわけではない点です。実利用者のデータを集めたChrome User Experience Reportにも読み込み直さない遷移の分を加えることは目指されていますが、どのような形で反映されるかは未定とされています。対応もChromium系のブラウザに限られます。つまり現時点では、自分たちで測って改善に使うための道具という位置づけになります。

WordPressで作られた一般的な企業サイトのように、リンクを踏むたびにページを読み込み直す作りであれば、直接の影響はほとんどありません。関わってくるのは、予約や検索の絞り込み、会員向けの管理画面など、画面の一部だけを差し替える作りを取り入れている場合です。最近はView Transitionsのように、通常の遷移でもアプリらしい見せ方ができる手段が増えており、境目は少しずつ曖昧になっています。

数字が見えるようになると、これまで感覚で語られていた二画面目が重いという話を、根拠を持って共有できるようになります。制作側と運用側で改善の優先順位を決めるとき、この差は思ったより大きいはずです。