タグ: Google

サイトの速さの話をするとき、話題はどうしてもページ全体の評価に寄っていきます。表示速度の指標が良いか悪いか、という会話は、1枚のページを丸ごと1つの数字にまとめた見方です。ただ、実際に手を動かしていて困るのは、もっと部分的なところではないでしょうか。商品の価格や在庫の表示だけが後から差し替わる、同意バナーが本文より遅れて覆いかぶさる、問い合わせフォームの中身だけがしばらく空白のまま残る。ページ全体としては速いのに、利用者が待っているその一角だけが遅い、という状況です。

この「部品ごとにいつ見えたのか」をブラウザ側で数えてもらう仕組みが、試験提供の段階に入りました。Container Timingと呼ばれるもので、Bloombergが提案し、Igaliaの手でChromiumに実装されたものです。Chromeの開発者向けブログでは、Chrome 148からオリジントライアル、つまり本番のサイトで期間限定で試せる段階に入ったことが案内されています。

ページ全体の指標では届かない場所

いま広く使われている表示速度の指標は、いずれもページを単位にしています。最初に何かが描画された時点、いちばん大きな内容が描画された時点。どちらも利用者の体感を大づかみに表すには便利ですが、面積が大きいことと、その部品が大事であることは別の話です。

商品ページを思い浮かべると、写真、価格と在庫、レビュー、おすすめ商品、決済のウィジェット、同意バナー、外部のチャットといった部品が同居しています。サーバー側で組み立てられるものもあれば、読み込み後にブラウザ側で描かれるもの、外部との通信を待ってから出てくるものもあります。この中で最大の面積を占めるのはたいてい写真ですが、購入の判断を止めているのは価格や在庫の表示だったりします。

さらに、いちばん大きな内容の描画時間は、利用者が操作した時点で計測が打ち切られます。気にしている部品がスクロールやクリックのあとに現れるなら、その部品は指標に載らないまま終わります。実際の訪問者から集めた計測データを扱っている事業者の記事では、同じページ、同じ機種でもこの数値は訪問者ごとに揺れる、と説明されています。画面の広さの違いもありますが、操作で計測が止まることも理由の1つです。

囲んで名前をつけるだけの計測

Container Timingのやることは、拍子抜けするほど単純です。測りたいひとかたまりの外側の要素に containertiming という属性を書き、値として自分でつけた名前を入れる。それだけです。

あとは PerformanceObserver で container という種類の記録を購読すると、その内側に内容が描かれるたびに通知が届きます。届く記録には、自分でつけた名前、最初に描画された時刻、最新の描画の時刻、これまでに描かれた面積の合計、最後に描画のきっかけになった要素などが入っています。描画がコンポジタに渡された時刻と、画面に出た時刻を分けて受け取ることもできます。

逆に、数に入れたくない部分には containertiming-ignore という属性を書きます。同意バナーの中のボタン、読み込み中の骨組み表示、装飾目的の要素、計測のために差し込んだ表示など、数えると面積が水増しされてしまうものを外せます。囲みの中に大きな別部品がある場合、これを外しておくとDOMをたどる処理も軽くなる、という副次的な効きもあるようです。

要素単位の計測と何が違うのか

これまでも elementtiming という属性で、個々の要素の描画時刻を測ることはできました。ただ、これは1つの要素につき1回きりの合図です。ウィジェット全体がいつ揃ったのかを知りたければ、中身の要素すべてに印をつけて回る必要があり、しかも後から差し込まれる要素には印がついていません。自社で書いていない部品には、そもそも手を入れられません。

提案の説明文書では、この不足を埋めるために書かれたJavaScriptの補助実装が引き合いに出されています。描画が始まる前にすべての子要素へ印をつけ、DOMの変化を監視して新しく入ってきた要素にも印をつけ、描かれた矩形を自前で管理する。動きはするものの、そのために描画をせき止めることになり、計測したい速さを計測が損なうという本末転倒に近い形になっていました。この補助実装は現在保守を終えており、正確な値が必要ならブラウザ側の実装を使うよう案内されています。

もう1つの違いは、記録が一度で終わらないことです。ひとかたまりの中身は、文字が先に出て、画像が後から届き、遅れて読み込まれるアイコンがさらに後から乗る、という順に埋まっていきます。そのため記録は候補として複数回届き、どの時点をその部品の揃った時刻と見なすかは書き手が決めます。面積の増加が止まったところを採る、最初の1件だけを採る、利用者の操作が起きるまでを採る。そうした選び方が想定されています。

ブラウザの内側でどう数えているか

実装を担当したIgaliaの技術記事では、既存の仕組みを組み替えて作った経緯が説明されています。Blinkの描画処理には、いちばん大きな内容の描画時間や要素単位の計測のために、文字と画像の描画を検出する部分がすでにあります。新しく描画の追跡を作るのではなく、そこで拾った情報を集約する道を足した、という説明です。

DOMが組み立てられる段階で、containertiming が書かれた要素とその子孫には内部的な目印が立てられます。containertiming-ignore があれば、そこで目印の伝播が止まります。おかげで描画が起きたときに、それが計測対象かどうかを即座に判断でき、対象でない場合の負担はほとんど生じません。対象だった場合は、描かれた要素からDOMを上にたどり、印のついた祖先へ報告が上がっていきます。

面積の集計には、描かれた矩形を重複なく足し合わせる領域計算が使われています。Skiaの領域オブジェクトを流用して、新しい描画のたびに既存の領域との和を取る形です。面積が増えない描画は記録として送られないので、通知の数も抑えられます。計測そのものが重くなっては意味がない、という割り切りが、この辺りの設計に表れているように見えます。

現時点の制約もはっきり書かれています。追跡できるのは文字と画像の描画で、動画やcanvas、SVGはまだ対象外です。Shadow DOMの扱いも初版では見送られており、要素単位の計測での方針が固まってからの検討とされています。深い階層を上にたどる処理の重さも、今後の最適化課題として挙げられています。

どこに印をつけると意味があるか

あらゆる部品に印をつけて回るのは、おそらく得策ではありません。実際の訪問者から計測データを集めている事業者の記事では、利用者の目に入り、かつ商売として意味のある部分から始めるのがよい、という考え方が示されています。売上や離脱に効く場所、先に進めなくなる場所、遅いと苦情の原因になる場所です。

具体例として挙がっているのは、冒頭の主役となる領域、商品のバリエーション選択、購入内容の確認、検索結果の一覧、同意バナー、外部から読み込まれるウィジェットあたりです。とくに同意バナーは、外部の仕組みがブラウザ側で組み立てることが多く、画像も見出しも持たない作りだと要素単位の計測では捉えにくいという事情があります。画面を覆って操作を止めるものなのに、既存の指標には載りにくいわけです。

地方の中小企業のサイトに置き換えるなら、規模は小さくても構図は同じです。トップの主役画像、料金表、予約や問い合わせのフォーム、地図の埋め込み、外部のカレンダー。このうちどれかが遅れて出てくることに心当たりがあるなら、名前をつけて測ってみる価値があります。名前は人間が読んで分かるもので、かつ商品IDのように変動する値は避けるべきだ、とも助言されています。集計したときに散らばってしまうからです。

注意したい点もいくつかあります。印は描画より前に存在していなければならず、後からJavaScriptで属性を足すと、それまでの描画は取りこぼされます。画面の外にある部分は記録されず、後からスクロールして見えても新しい記録が出るとは限らないので、表示領域に入ったかどうかを知る仕組みの代わりにはなりません。読み込み中の骨組み表示を囲みの中に入れたままにすると、その骨組みも描画として数えられます。最終的な中身の側に印をつけ直すか、骨組みを除外するか、集め方を調整するかの判断が要ります。

試験提供という段階の受け止め方

オリジントライアルはChrome 148から始まり、153までの期間が示されています。手元で試すだけなら実験的なウェブプラットフォーム機能の設定を有効にすれば足りますが、実際の訪問者から値を集めたい場合は、サイトごとに発行されるトークンをページに埋め込む必要があります。

このトークンの置き方には、先行して試した事業者がつまずいた落とし穴が紹介されています。ふつうは、機能を使うJavaScriptより前にトークンが読まれていれば動きます。ところがContainer Timingでは、属性そのものも試験提供の対象です。つまりブラウザが最初の containertiming 属性に出くわす前にトークンが読まれている必要があり、計測用スクリプトを描画の妨げにならない形で読み込んでいると間に合いません。結局、サイト側で自分のトークンを登録してもらって初めて値が集まり始めた、という顛末が書かれています。

集めた数値の読み方にも工夫が要ります。ある部品の描画時刻をそのまま見ると、ページ全体の遅れを丸ごとかぶった値になります。たとえば表示の切り替えのために本文全体を数秒隠す仕掛けが入っていれば、その裏で待たされた部品の時刻もそろって遅くなる。それをその部品のせいだと読むのは無理があります。そのため、最初に何かが描画された時刻を引いて差分で見る、という扱い方が採られています。ページが出始めてから、その部品が出るまでに何秒余計にかかったのか。こちらのほうが、直す場所を決めるには役に立ちます。

仕様はまだ動く可能性があり、項目名や細かい挙動が変わることも十分あります。集めた値も、当面は長く追いかける指標ではなく、早い段階の観測データとして扱うのが無難でしょう。それでもこの手の話は、標準になってから慌てて追いかけるより、試験提供のうちに1つか2つ印をつけて眺めておくほうが、広く使えるようになったときの動きが速くなります。属性を書き足すだけで始められるのは、入り口としてはかなり低いほうだと思います。

ブラウザの新しい版が届く間隔が、この秋から短くなる。GoogleはChromeの安定版を4週間ごとに出してきたが、9月から2週間ごとに切り替える。ほぼ同じ時期に、MozillaもFirefoxで同じ方向の変更を試す。新機能が増えるという話とは少し性格が違って、これはサイトを作って納品したあとの面倒の見方、つまり段取りのほうに関わる変更だと思う。

Chromeは九月から二週間ごとに

Chrome for Developersの告知によると、新しい間隔での最初の安定版はChrome 153で、公開は2026年9月8日。ベータ版は各安定版の3週間前に出る。対象はデスクトップに限らずAndroidとiOSも含まれ、すべてのプラットフォームで同じ間隔になる。

変わらない部分もある。企業の管理者や、Chromiumを自社製品に組み込んで使う側に向けたExtended Stableは、これまでどおり8週間ごとのまま。DevとCanaryにも変更はない。更新の回数が増える代わりに、1回あたりに入る変更の幅は小さくなる。Googleはその点を、利用者への影響を抑えられて、公開後に問題を追いかけるときも切り分けがしやすくなる理由として挙げている。

切り替えの前後では、開発の締め切りにあたるブランチの日程も前倒しになる。告知には移行期の日程表が添えられていて、どの版がいつ枝分かれしていつ公開されるかが並べてある。個別の機能がどの版に入る予定かを追いたい場合は、Chromiumのダッシュボードや Chrome Status のロードマップで日付を確認できる。

Firefoxも同じ時期に間隔を詰める

Mozillaの開発者向けメーリングリストでは、Sylvestre Ledru氏が、Firefoxのデスクトップ版とAndroid版を9月から4週間間隔ではなく2週間間隔にすると告知している。最初の対象はFirefox 155で、公開予定は9月1日。これまでの日程なら出せなかったタイミングだ。

ただしMozillaはこれを実験と位置づけている。恒久的な変更と決め打ちせず、実際に走らせてみた結果を見ながら必要に応じて調整するという書き方をしている。開発者に倍の速さで働くことを求めるものではなく、準備できていない仕事を急がせるつもりもない、機能は必要なだけ時間をかけてよい、という説明も添えられている。頻度を上げる狙いは、出せる状態になったものが利用者に届くまでの待ち時間を減らすところにある。

四週間ごとで出る最後のChrome 152

現行の間隔で出る最後の版がChrome 152になる。ベータの告知を見ると、CSS側では音声や動画の状態に応じて見た目を変えられる擬似クラスが増えている。再生中や一時停止中、読み込み待ち、消音といった状態を :playing や :paused のような形で書き分けられる。自前の再生ボタンを作るときに、状態の受け渡しをJavaScriptで持たずに済む場面がありそうだ。

ほかにも、既存の色を参照して透明度だけを変えられる相対的な指定や、入力欄の自動修正の効き方を制御する autocorrect 属性が入る。どれも派手な機能ではないが、実務でよく書いていた小さな回り道を減らす種類の変更が並んでいる。こうした細かい追加が、これからは半分の間隔で積み上がっていくことになる。

保守の段取りをどこで区切るか

頻度が上がって困るのは、たいてい機能そのものではなく、こちら側の段取りのほうだ。よくあるのが、保守の説明や見積書に「最新版のChromeとFirefoxで表示確認」と書いてあるだけで、いつ確認するかは決めていないというケース。間隔が半分になると、確認の回数を増やすのか、こちらで区切りを決めてまとめて棚卸しするのかを先に決めておかないと、追いつけていない感覚だけが残ってしまう。

現実的なのは、毎回は追いかけないと割り切ることだと思う。ベータ版で先に触れる期間は変わらず用意されているので、自分たちが関わるサイトで実際に使っている仕組みに関係する変更だけを拾い、それ以外は通常の保守の周期でまとめて見る。手の数が限られている小規模な制作現場ほど、この線引きを最初にしておく効果は大きい。

頻度が上がることには直接の利点もある。修正が手元に届くまでの待ち時間が短くなることだ。深刻な脆弱性の修正を定期便とは別に配る仕組みは以前からあるが、通常の不具合や表示の食い違いも、これまでより早く解消されるようになる。閲覧する側の環境が新しくなる速度が上がるという意味では、作る側にとって悪い話ではない。

もうひとつ、版番号を条件にした分岐や、対応範囲を版番号で書いた文書は、これから急速に古びていく。番号ではなく、その機能が使えるかどうかで判断する書き方に寄せておいたほうが、あとで書き換える手間は少なくて済む。ブラウザ側が速く動くようになるほど、こちら側は番号から距離を置いたほうが楽になる。

ページの中から外へ出ていく通信の宛先を、サイト側があらかじめ決めておく。そんな仕組みがChromeのベータ版に入った。Connection Allowlistsと呼ばれる機能で、少し前の版からオリジントライアルとして試験提供されていたものが、次の安定版で正式に出荷される段階へ進んだ。出荷予告によれば、デスクトップとAndroid、WebViewを対象に、利用者側で特別な設定をしなくても有効になるとされている。

使い方はHTTPのレスポンスヘッダー1本だ。Connection-Allowlist というヘッダーに、通信を許可するURLのパターンを並べて返す。ブラウザは接続を張る前に宛先を照らし合わせ、リストに載っていない相手には接続しない。自分自身のオリジンを含めたいときは response-origin という書き方が用意されている。対象になるのはfetchによるサブリソース取得だけでなく、画面遷移やリダイレクト、prefetchやpreconnectといった先読み系の指定、さらにWebSocketやWebTransport、WebRTCまで広い。文書だけでなく、Worker類にも適用できるとされている。

考え方としてはコンテンツセキュリティポリシー(CSP)の connect-src に近いが、CSPが読み込み元を用途ごとに細かく書き分けるのに対して、こちらは許可する宛先の一覧を一箇所にまとめ、接続を確立する手前でまとめて判定する。狙いとしてわかりやすいのは、外部から読み込んでいるスクリプトが何らかの理由で書き換えられ、フォームに入力された内容を見知らぬ宛先へ送り出してしまうような事故だろう。そうした通信を、ブラウザ自身が門番となって止める位置づけになる。

いきなり遮断せずに様子を見られる

現場的にありがたいのは、記録だけを取るモードが最初から用意されている点だ。Connection-Allowlist-Report-Only というヘッダーを使うと、実際の通信は止めないまま、リストから外れた宛先をReporting API経由で受け取れる。開発者ツール側の対応も入っているとされ、稼働中のサイトにいきなり適用して決済や地図が動かなくなる、という事態を避けながら、自分のサイトがどこへ通信しているのかを棚卸しできる。

一方で、現時点で実装を表明しているのはChromiumの系列だけだ。Firefoxはヘッダーの書式をめぐって意見の相違があり議論中、Safariは公式な立場をまだ示していないとされている。守りをこれ一本に預けるのではなく、これまで通りCSPを整えたうえで、対応するブラウザでは壁がもう一枚立つ、と考えるのが現実的だろう。中小企業のサイトでも、アクセス解析のタグ、チャットの窓口、フォーム、外部サービスの埋め込みと、気づけば通信先は増えていく。まずはレポート専用のモードで一度眺めてみると、思っていたより多くの宛先が並ぶかもしれない。

2026年3月にGoogleが実施したCore Web Vitalsの大幅な改定が、ウェブ制作現場に大きな変化をもたらしています。従来の評価基準から厳格化された新しい閾値への転換により、多くのサイトが新たな対応を迫られる事態となりました。LCPの「良好」基準が2.0秒を超えるサイトでは平均2〜4ポジションの順位低下が報告されるなど、その影響は検索結果にも如実に現れています。

今回の変更は単なる数値の調整ではありません。Googleがより厳格な基準を設定し、モバイル優先の評価を強化した背景には、ユーザー体験への根本的な考え方の変化があります。この新しい動きがどのような意味を持つのか、制作現場ではどう対応すべきなのかを整理してみましょう。

LCP基準の厳格化が意味するもの

2026年3月のコアアップデートで、LCP（Largest Contentful Paint）の「良好」基準が2.5秒から2.0秒へと短縮されました。これまで「普通に使える」と考えられていた多くのサイトが、一夜にして改善の必要があるサイトに分類されることになります。

LCPが2.0秒から2.5秒の間にあるサイトは「改善が必要」扱いとなり、2.5秒を超えるサイトでは競合の激しいクエリで平均2〜4ポジションの順位低下が確認されています。この変更が持つインパクトは、単純にサイトが遅くなったということではなく、Googleが求める「快適なウェブ体験」の水準が大幅に引き上げられたことを示しています。

制作現場で特に注意すべきは、ウェブトラフィックの60%以上がモバイルデバイスから来る現在の状況です。Googleはモバイル性能を2026年により重視するようになり、デスクトップで最適化されていてもモバイルで劣るサイトは見過ごされなくなりました。つまり、従来の「デスクトップで問題ない」という感覚は通用しなくなったということです。

INPが中核指標に格上げされた意味

もう一つの重要な変更が、INP（Interaction to Next Paint）の扱いです。INPが補助的な指標から、LCPやCLSと同等の順位シグナルへと格上げされ、3月18日のSearch Central ブログ記事で正式発表されました。

INPが200msを超える「改善が必要」レンジにあるサイトでは、平均0.8ポジションの順位下落が測定されています。この数値は一見小さく感じるかもしれませんが、競合激戦区では決定的な差となりえます。

INPが重視される背景には、現代のウェブサイトがより動的でインタラクティブになったことがあります。INPはユーザーのクリック、タップ、キー入力から次の視覚更新までの遅延を捉え、ページのライフサイクル中のすべてのインタラクションを考慮して最悪ケースに近い値を報告します。つまり、「時々重い」サイトは確実に検出されるようになったということです。

モバイル優先評価の実際的な影響

2026年の変更で最も実務に影響するのは、モバイル性能への重点シフトかもしれません。Googleはモバイル使用量がデスクトップを上回る現実を反映し、2026年のWeb Vitalsではモバイル性能がより重要な順位シグナルとなり、レスポンシブデザイン、遅延読み込み、タッチフレンドリーUI、高速なモバイルレンダリングの影響が強化されました。

これまでデスクトップでの快適さを重視してきた企業サイトでも、根本的な見直しが必要になります。反応しないボタンや過度なレイアウトシフトなどのモバイル性能不足は、直帰率やセッション時間などのエンゲージメント指標に深刻な影響を与え、SEOの課題をさらに深刻化させるからです。

実際の対応では、モバイル最適化をウェブサイト開発プロセスの最優先事項とし、レスポンシブデザイン、リソース重い要素の削減、合理化されたモバイルナビゲーションが鍵となります。つまり、「デスクトップを作ってからモバイル対応」ではなく、「モバイルファーストで設計してからデスクトップに展開」という発想の転換が求められています。

制作現場での実践的対応策

新しい基準に対応するために、制作現場で実際に取り組むべき点を整理してみましょう。まず測定の観点では、Googleはラボデータではなく、28日間の実際のChromeユーザーからのフィールドデータを使って順位を決定し、75パーセンタイルで判断するため、訪問者の75%が良好な体験を得る必要があります。

LCP改善では、画像をWebP形式で200KB未満に圧縮し、幅と高さを追加し、画面外画像に遅延読み込みを適用し、LCP要素をプリロードすることが即効性のある対策です。INPについては、使用していないWordPressプラグインを削除（多くのサイトが30個以上のプラグインを実行し、半数が何もしていない状態）、JavaScriptを遅延実行し、サードパーティスクリプトを削減することが重要です。

長期的な視点では、Google Search ConsoleのCore Web Vitalsレポートを使った自動監視設定、指標が閾値を下回った際のアラート設定、ページ重量・JavaScriptサイズ・読み込み時間の許容限界を定義するパフォーマンス予算の確立、開発ワークフローでの予算遵守が欠かせません。

Core Web Vitalsを一度きりの修正ではなく継続的な実践として扱う機関やチームが、強固な検索可視性を維持している現実を踏まえると、この新基準への対応は一時的な作業ではなく、制作プロセスそのものの見直しと言えるでしょう。2026年の変更は確かに厳しいものですが、それだけユーザー体験への本質的な取り組みが求められる時代になったということでもあります。