読み込み直さない画面切り替えの速さをChromeが測れるようになった

つくば市のホームページ制作会社

サイトの表示速度を測る指標として、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のように、通常の遷移でもアプリらしい見せ方ができる手段が増えており、境目は少しずつ曖昧になっています。

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

タブに添えた閉じるボタンを読み上げに伝えるARIAの新しい属性

つくば市のホームページ制作会社

Chromeの安定版151が7月28日に公開された。大型の目玉機能というより細かい追加が並ぶ回だったが、そのなかにaria-actionsという属性が入っていて、これは現場の作り方に素直に馴染みそうだと感じた。ある要素に付き添っている別の操作ボタンの存在を、スクリーンリーダーなどの支援技術に伝えるための指定である。Chromeのリリースノートによると、W3CのARIA仕様に沿った形で実装されたとされている。

想定されている典型例は、タブの見出しに小さく付いている閉じるボタンだ。マウスで操作していれば見えているので迷わないが、キーボードと読み上げでたどっている人には、そのタブに閉じる手段が添えられていること自体が伝わりにくい。メールの一覧行に並ぶアーカイブや削除のボタン、カード型のリストに乗った編集ボタンなども同じ構図になる。主となる要素と、その脇に置かれた操作との関係を機械が読み取る手がかりがなく、支援技術の側から見つけづらいことは、以前から課題として挙げられていた部分だ。近くにボタンが置いてあることは、画面上の距離では明らかでも、読み上げの順番のなかでは伝わらない。結果として、タブ移動を重ねて偶然行き当たるまで存在に気づけない、という状態が起きていた。

既存のマークアップを壊さずに足せる

使い方は他のARIA属性と似ていて、主となる要素から、関連するボタンのidを指すだけでよい。属性を足しても見た目やクリックの挙動は変わらず、対応していないブラウザは単に無視する。既存のコンポーネントに後から付け足す形で試せるので、導入の判断はしやすい。開発者ツール側でも、他のid参照型のARIA属性と同じように、参照先がどの要素を指しているかを確認できるようになっている。W3C側の仕様もほぼ固まっており、Firefoxはすでに対応済み、WebKitは試作の段階と伝えられている。ChromeはまずWindows、Mac、Linuxのデスクトップで有効になり、モバイル向けは後続になるとのことだ。

もっとも、属性を書けばすぐ読み上げが変わるという話ではない。支援技術の側がこの関係をどう利用者に案内するかは、各社の実装がこれから揃っていく段階にある。ただMicrosoftのUI部品群を手がけるチームが早い時期の取り込みに前向きだと伝えられており、部品ライブラリ経由で静かに広まっていく類の機能ではありそうだ。自前でタブやリストのUIを組んでいるなら、仕様の様子を眺めておく価値はある。

中小企業のサイトでも、同じ形はあちこちにある。予約フォームの入力欄に添えたクリアボタン、実績一覧のカードに置いた詳細ボタン、通知バーの右端にある閉じる印。どれも見えている人には自明で、見えていない人には気づきにくい。ARIAは足しすぎるとかえって読み上げを濁らせるので万能ではないが、これまで説明のしようがなかった関係を素直に書ける手段が増えたのは、地味ながらありがたい変化だと思う。

地域ごとの週の始まりや暦をブラウザ標準で引ける仕組み

つくば市のホームページ制作会社

日付まわりの表示は、サイトを作っていればどこかで必ず触ることになります。予約フォームのカレンダー、記事の投稿日、営業日の一覧。一見どれも単純ですが、対象の地域が変わると前提そのものが変わります。週の始まりは日曜なのか月曜なのか、週末はどの曜日にあたるのか、どの暦を併記するのか。こうした知識は、これまでブラウザの外から持ってくるしかありませんでした。

2026年7月、JavaScriptの国際化機能であるIntl.Localeに加わった一連のメソッドが、主要ブラウザすべてで使える状態になりました。web.devの月次まとめによると、Firefox 153が対応したことで、Baselineの「新しく利用可能」に入ったとされています。地味な機能ですが、カレンダー部品を自作したことがある人ほど、ありがたみが分かる種類の追加です。

これまでは辞書を自前で抱えていた

「この地域では週が月曜から始まる」といった知識は、CLDRという国際的なデータベースにまとめられています。ただ、ブラウザからその中身を直接引く手段が長らくなく、カレンダーの見た目を自分で組む場合は、データの一部を写し取ったライブラリを読み込むのが普通でした。週の初日を表す値ひとつのために、数十キロバイトの追加読み込みが発生することも珍しくありません。

Intl自体はかなり前からあり、Intl.DateTimeFormatを使えば日付を地域の書式に整えることはできました。ただしそれは整形済みの文字列が返ってくるだけで、UIを自分で組み立てるために必要な素の情報、たとえば曜日を並べる順番の起点までは取り出せません。今回埋まったのは、ちょうどこの隙間にあたる部分です。

Intl.Localeから引けるようになった情報

書き方は素直で、ロケールを表すオブジェクトを作ってメソッドを呼ぶだけです。new Intl.Locale("ja-JP").getWeekInfo() のように書くと、週の始まりの曜日、週末にあたる曜日、その年の最初の週とみなすための最小日数がまとめて返ってきます。曜日は1が月曜、7が日曜という決まりになっています。

同じ要領で、その地域で使われる暦の一覧を返す getCalendars()、時刻を12時間制と24時間制のどちらで扱うかを返す getHourCycles()、文字を左から右に並べるか右から左に並べるかを返す getTextInfo()、地域に結び付いたタイムゾーンの一覧を返す getTimeZones() が用意されています。ほかに数字の表記体系や並べ替えの規則を返すものもあり、いずれも MDNのIntl.Localeのページに一覧があります。

返ってくるのは配列や小さなオブジェクトなので、そのまま画面に出すというより、自分のUIの初期値として使う性格のものです。

日本語のサイトで効いてくる場面

日本のロケールで getCalendars() を呼ぶと、グレゴリオ暦と和暦の識別子が返ってきます。行政関連の書類を扱うサイトや、年号の併記が求められる申込フォームでは、この結果を起点にIntl.DateTimeFormatへ和暦を指定する、という流れが自然に組めます。和暦を出すかどうかを地域の慣習として扱えるので、判定を自前のif文で書き分けずに済みます。

週の始まりも実務的です。日本語圏では日曜始まり、英国では月曜始まりというように、カレンダーの見た目は地域で割れます。多言語対応のサイトで同じカレンダー部品を使い回すとき、対応表を自分で抱えなくてよくなるのは負担が減るところです。予約カレンダーや営業日の表示は、中小企業のサイトでも決して珍しい要素ではありません。

使う前に確認しておきたいところ

Baselineの「新しく利用可能」は、主要ブラウザの最新版で動くという意味であって、少し前の端末まで含めて安全という意味ではありません。企業サイトの訪問者には更新の止まった端末も混ざりますから、メソッドがあるかどうかを確かめて、無ければ従来どおりの既定値を使う、という組み方が現実的です。値が取れなくても表示が壊れないようにしておけば十分です。

もう一点、以前の実装ではメソッドではなくプロパティとして提供されていた時期があります。古い解説記事のコードをそのまま持ってくると動かないことがあるので、参照する情報の新しさには注意しておきたいところです。

外部ライブラリに頼っていた小さな機能が標準側に移ると、依存パッケージがひとつ減り、更新の手間もその分軽くなります。派手さはありませんが、次にカレンダーまわりを触る機会があれば、置き換えられる部分がないか見ておく価値はありそうです。

日本語を含むメールアドレスへの対応が次期WordPressで見送られた

つくば市のホームページ制作会社

WordPressの次のバージョンにあたる7.1のベータ3が7月22日に公開された。71件を超える修正が入った通常のベータ更新だが、告知の中に少し珍しい一文が混ざっていた。いったんコアに取り込まれていた、アルファベット以外の文字を含むメールアドレスへの対応が、7.1には入らないことになったという内容だ。

対象になっていたのは、@より前のローカル部分に日本語や各国の文字が入ったアドレスである。ドメイン側はPunycodeという変換の仕組みで以前から扱えていたが、ローカル部分は長く対象外で、WordPressの検証関数が不正なアドレスとして弾いていた。今回の変更では、データベースの文字コードがutf8mb4であればis_email()やsanitize_email()が非ASCIIのアドレスを受け付けるようになり、アドレスをローカル部とドメイン部に分けて扱えるWP_Email_Addressというクラスも加わっていた。元になったチケットが立てられたのは2015年で、11年越しで前に進んだ案件でもある。

取り込んだあとで外すという判断

その機能が、コアにマージされてから6週間ほどで外された。挙げられている理由は、Unicodeを受け入れることで確認しなければならない範囲が一気に広がることと、それに伴うセキュリティ面の影響だ。Unicodeには見た目がほとんど区別できない別の文字が数多くあり、ログイン用のアカウントや通知メールの宛先が絡む場所では、取り違えやなりすましの入口になりうる。公式の告知では、開発はコミュニティプラグインとして続け、互換性やセキュリティ、データの扱いをより広くテストしていくとされている。

日本の制作現場への直接の影響は、いまのところ小さい。国内で非ASCIIのメールアドレスを実際に運用している取引先はほとんど見かけないし、7.1に入らないのであれば当面の挙動も変わらない。気に留めておきたいのは、問い合わせフォームや会員登録の入力チェックを自前の正規表現で書いているサイトのほうだ。将来コア側が受け入れる文字の範囲が広がったとき、フォーム側だけが古い基準で弾き続ける、という食い違いが起きうる。プラグインとして先に試せる形になるのであれば、その前に手元で挙動を確かめておける。

もうひとつ、この話が示しているのは、メールアドレスの扱いがWordPress単体で完結しないことだ。仮にコア側が受け付けても、その先の送信サーバーやメール配信サービス、受け取る側のメールソフトがそろって対応していなければ、通知が届かないという形で問題が出る。ウェブ側だけを新しい仕様に合わせても意味がない領域で、慎重に進める判断そのものは理解しやすい。

11年動かなかった機能が入り、6週間で外れる。読んでいて印象に残るのはむしろ判断の速さのほうで、世界中のサイトが乗っている土台に何を入れるかという線引きが、機能の完成度とは別の基準で引かれていることがよく分かる。7.1そのものは8月19日の公開予定で、こちらは通常どおりの日程で進んでいる。

カメラとマイクの許可をブラウザに任せるHTMLの新要素

つくば市のホームページ制作会社

ウェブサイトでカメラやマイクを使う場面は、ここ数年で少しずつ増えてきました。オンライン相談の入口、動画で送るお問い合わせ、現場のスタッフが撮影してそのまま投稿する仕組みなど、業種を問わず出てきます。その手前に必ず挟まるのが、ブラウザが表示する「カメラの使用を許可しますか」という確認です。

Chrome 151が2026年7月28日に公開され、この確認の出し方そのものを見直す新しいHTML要素、usermedia要素が使えるようになりました。JavaScriptから許可を求めるのではなく、ブラウザが仲立ちする部品を押してもらう形に変わります。

スクリプトから許可を求める方式のつまずき

これまでカメラやマイクを使うには、JavaScriptでgetUserMediaという命令を呼び、その瞬間にブラウザが許可の確認を出す形が標準でした。書き方としては素直ですが、実際の現場では困りごとがついて回ります。

ひとつは、確認が出るタイミングを利用者が予想しにくいことです。ページを開いた直後に何の脈絡もなく確認が出れば、多くの人はとりあえず拒否します。もうひとつは、拒否したあとの復帰が難しいことです。いったん拒否すると次からは確認すら出ず、ブラウザの設定画面を自力で開いて権限を戻す必要があります。制作側からは、その設定画面への案内文を書き添えるくらいしか打つ手がありませんでした。

迷惑な確認を減らすため、ブラウザ側が自動的に確認を抑え込む挙動も広がっています。まっとうに作ったページが、その網に引っかかって何も起きないという事故も起こり得ます。

ボタンを包むだけの書き方

usermedia要素は、押してもらうボタンをこの要素で包むだけで使えます。中に置いたボタンの見た目はこれまでどおり自由に整えられ、押されたあとの段取りをブラウザが引き受けます。

結果の受け取りは、要素が発火する3種類の出来事を見張る形です。許可されたときのstream、失敗したときのerror、利用者が確認を閉じたときのcancelの3つで、映像や音声の本体はstreamから受け取ります。解像度やエコー除去といった希望は、押される前にsetConstraintsで指定しておきます。従来の書き方で必要だった成功と失敗の分岐や状態管理のコードは、かなり減らせます。

目に見えて変わるのは、確認が出る条件です。従来はスクリプトの都合で確認を出せましたが、この要素ではブラウザが用意した部品が実際に押されるまで確認は出ません。裏を返せば、勝手なタイミングで確認を出す作りが成立しなくなるということでもあり、利用者側から見た予測しやすさは上がります。

拒否されたあとに戻ってこられるかどうか

この要素の効き目がはっきり出ているのが、一度拒否されたあとの復帰です。Chromeの開発者向け情報によると、試験導入に参加したCiscoの計測では、従来の方式で復帰できた人がおよそ1割だったのに対し、新しい要素では6割を超えたとされています。Zoomでは撮影や録音の失敗が約47パーセント減り、Google Meetでは「マイクが動かない」という申告が約17パーセント減ったという数字も挙がっています。

理由は単純で、利用者が自分でボタンを押したという事実をブラウザが確実に把握できるからです。押した本人の意思がはっきりしているぶん、ブラウザは自動的な抑制を回さずに済み、拒否済みの状態からその場で復帰させる専用の流れを出せます。設定画面まで手順を案内しなくてよくなるのは、問い合わせ対応の手間という面でも小さくありません。

今すぐ全面的に置き換えるものではない

現時点で動くのはChrome 151以降で、他のブラウザはこれからです。仕様はW3Cのメディアキャプチャ拡張仕様に載っており、将来はカメラ用、マイク用といった用途別の要素も検討されています。

対応しているかどうかは、HTMLUserMediaElementという名前がブラウザ側に存在するかで判定できます。対応していないブラウザでは要素の中に書いた内容がそのまま表示されるので、中に従来のgetUserMediaを呼ぶボタンを置いておけば、ひとつの記述で両方の環境をまかなえます。新規に組むならこの入れ子の形から始めておくと、対応ブラウザが増えたときに書き直さずに済みます。

カメラやマイクを扱うページは、動くかどうかが問い合わせ件数に直結します。実装の難しさよりも、拒否したまま戻れなくなった利用者をどう救うかが実際の課題だった現場は多いはずで、そこにブラウザ側から手が入ったという意味で、頭の片隅に置いておく価値のある変化です。

Safariの新しい版で使えるようになるフォームと表示まわりの指定

つくば市のホームページ制作会社

Safariの次の版のベータが公開され、58件の新機能と525件の修正が入るとされています。WebKitの発表を読むと、目新しい機能を数多く並べるというより、既存の機能の細かい挙動を揃える作業に重心が置かれているのが分かります。

とはいえ、制作の現場ですぐ効きそうな追加もいくつか含まれています。中小企業のサイトでも出番がありそうなものを、順に並べてみます。

セレクト要素の見た目を組み直せるようになる

フォームのセレクトボックスは、ブラウザごとに見た目が違ううえ、選択肢の並びに手を入れられない部分が長く残っていました。デザインに合わせたい場合、select要素を捨ててdivとJavaScriptで作り直すのが定番の回避策です。

今回のベータではappearance: base-selectに対応し、本来の要素のまま見た目だけを組み直せるようになります。キーボード操作や読み上げ、フォーム送信の挙動は標準のまま残るので、作り直したときに抜けがちな部分を自前で用意しなくて済みます。問い合わせフォームのように、崩れると直接損をする箇所ほど恩恵が大きいところです。

遅れて読み込まれた要素で読む位置がずれない

記事を読んでいる途中で、画面の上のほうにある画像や埋め込みが遅れて表示され、本文が下に押し出される。よくある不快な挙動です。スクロールアンカリングは、こうしたときに表示位置を自動で補正して、読んでいた行を保ちます。

他のブラウザではすでに動いていた機能なので、Safariが加わることで挙動の差が縮みます。ただし、画像に幅と高さを書いておくといった基本の対策が不要になるわけではありません。ブラウザ側の補正はあくまで最後の受け皿と考えておくのが安全です。

見出しをまとめて指定できる疑似クラス

:headingは、h1からh6までをまとめて指す疑似クラスです。これまではセレクタに六つ並べて書くのが普通で、余白や行間を揃えたいだけの場面では冗長でした。

書く量が減るだけの小さな追加に見えますが、見出しの階層が増えたり減ったりする構成では、書き漏らしを防ぐ意味もあります。ブログのように書き手が複数いるサイトでは、想定していなかった深さの見出しが入ることも珍しくありません。

余白まで含めて幅を伸ばすstretchという値

幅や高さの指定にstretchという値が使えるようになります。親の中で余白の分まで含めて伸ばす指定で、これまでcalcを使って余白を引いて調整していた場面を素直に書けます。

あわせてrevert-ruleというキーワードも入りました。そのルールが当たる前の状態まで戻す指定で、後から足したCSSが積み重なって入り組んだサイトの調整に向きます。どちらも派手さはありませんが、既存サイトに手を入れる仕事では出番がありそうです。

画像のsizes属性をブラウザに計算させる

遅延読み込みを指定した画像で、sizes属性にautoと書けるようになります。実際のレイアウト幅をブラウザが測り、srcsetに並べた候補から適したものを選びます。

これまでは画面幅ごとの表示幅を自分で書き並べる必要があり、レイアウトを変えるたびに書き直す手間がありました。書いた値が実際のレイアウトと食い違うと、必要以上に大きい画像を読み込んでしまいます。手作業の当て推量が減るのは、表示速度の面でも助かります。

同じ時期に出たChromeの新しい安定版には、矢印キーでの項目移動を属性の指定だけで有効にできるfocusgroupが入っています。片方は新しい書き方を先に出し、片方は既存の機能の足並みを揃える。方向は違いますが、どちらも自前のスクリプトで埋めていた部分を標準側に寄せる動きです。実務では、対応が片方だけの機能はしばらく補助的に添える程度にとどめ、両方に入ったものから本番へ回すのが無難だと思います。

JavaScriptで組んでいた部品がHTML側に移りつつある

つくば市のホームページ制作会社

ウェブ制作の現場で長く続いてきた作業のひとつが、ブラウザに足りない機能をJavaScriptで補うことでした。開閉するパネル、画面全体に出るダイアログ、装飾された選択メニュー。本来はただの部品なのに、ライブラリを読み込み、初期化のコードを書き、キーボード操作や読み上げの面倒まで見て、数年後の保守で頭を抱える。制作に関わっていれば、たいてい心当たりのある流れだと思います。

ここ数年、その前提が少しずつ変わってきています。7月28日に安定版が出たChromeの最新版の変更点を眺めると、方向がかなりはっきり見えます。カメラとマイクの扱い、Shadow DOMの組み立て、画面切り替えの計測。どれもこれまではJavaScriptの領分だったものが、HTMLの要素や属性、あるいはブラウザ標準の計測項目として整理されつつあります。今回はこの流れを、直近のブラウザ各社の動きと並べて眺めてみます。

カメラとマイクの入口がHTMLの要素になる

目を引くのは usermedia という新しい要素です。ブラウザが用意した操作部品として画面に置かれ、そこからカメラやマイクの利用が始まります。Chromeの開発者向けブログによると、利用者の意図をはっきりさせた上で許可を求め、映像や音声のストリームを受け取るところまでを、この要素が受け持つとされています。

従来はJavaScriptから取得用の関数を呼ぶと、いきなりブラウザの許可ダイアログが出る作りでした。押した覚えのないタイミングで「カメラを使いますか」と聞かれれば、多くの人はまず拒否します。そして一度拒否されると、設定から手で戻してもらうしかない。許可の取りこぼしは技術の問題ではなく導線の設計の問題で、その導線をブラウザ側に寄せるという判断は理にかなっています。

使いどころとしては、オンライン相談の受付ページ、採用ページで応募者に短い動画を録ってもらう仕組み、業務用の写真アップロードなどが考えられます。ただし現時点ではChromeだけの機能なので、これ抜きでも成立する作りにした上で、対応ブラウザでは体験が良くなる、という積み方が現実的です。

影の中の差し込み口も属性で書ける

同じ版では、template 要素に shadowrootslotassignment という属性が加わりました。Shadow DOMの中で、どの中身をどの差し込み口に入れるかを手動で割り当てる指定です。これまでは JavaScript から Shadow DOM を作るときにオプションで渡すしかなく、スクリプトが動くまで組み立てが完了しませんでした。

地味な変更に見えますが、意味は小さくありません。サーバー側が吐き出したHTMLだけで部品が完成するなら、最初の表示が崩れて後から整うという、あの落ち着かない一瞬が減ります。PHPでHTMLを組み立てるWordPressのような環境とも相性が良く、ブロックやテーマの作り込みで恩恵を受ける場面はありそうです。

見た目の調整からスクリプトが抜けていく

この半年ほどの各ブラウザの更新を並べると、同じ傾向がもっと広い範囲で起きていることが分かります。グリッドやフレックスの隙間に線を引く指定、箱の幅に合わせて文字の大きさを自動調整する指定、入力欄が中身の量に応じて伸縮する指定。最後のものはFirefoxが対応したことで、主要なブラウザエンジンすべてで使える状態になりました。矢印キーでの移動先をまとめて宣言できる属性も加わっています。

どれも、かつては手で書いていた処理です。文字幅を測って収まるまで縮めるコード、入力のたびに高さを再計算するコード、キーボード操作を自前で組み立てるコード。案件ごとにコピーして、少しずつ挙動が違う状態で増えていく類のものでした。それが数行のCSSや属性ひとつに置き換わるなら、書く量が減るだけでなく、動作の説明もしやすくなります。

制作者側の実利は、たぶん「新しい表現ができる」よりも「消せるコードが増える」ところにあります。納品後に触る人が読む量が減るのは、それ自体が品質です。

足並みがそろわない例もある

とはいえ、宣言的に書ける方向へ一直線に進んでいるわけではありません。分かりやすい例が、選択メニューの見た目を自由に整えられる仕組みです。Chromeでは去年のうちに安定版に入り、Safariは開発者向けの先行版で確認できる段階、Firefoxは試験版でフラグを立てて試す段階。MDNの解説でも、広く使われるブラウザの一部で動かないため安定して使える状態には達していない、という位置づけになっています。

ブラウザごとの歩幅の違いも、この7月にそのまま表れました。Chromeが新しい要素を入れた前日にはSafariの更新版が出ていますが、こちらはWebAssemblyまわりの小さな追加と、CSSや通信の不具合修正が中心です。文字の大きさの単位が拡大表示でずれる問題や、要素の配置指定が意図した位置に戻らない問題が直されています。新機能を並べる回もあれば、土台を固める回もある、というだけの話ですが、対応状況を「だいたい揃った」で済ませられない理由ではあります。

ブラウザ間の差を埋める取り組みとしては、Apple、Google、Igalia、Microsoft、Mozillaが共同で進めるInterop(相互運用性)のプロジェクトがあります。今年の重点領域は二十近く挙げられており、テストの通過率がダッシュボードで公開されているので、気になる機能の足並みを自分で確かめられます。営業資料に「最新の書き方に対応」と書く前に、こういう一次情報で裏を取る癖をつけておくと安全です。

体感速度の測り方も追いついてきた

もうひとつ、Chromeの最新版には計測まわりの追加があります。画面を読み込み直さずに表示を切り替える作りで、その切り替えを一区切りとして扱い、操作をきっかけに描かれた主要な内容が出るまでを測れるようになりました。

これは長く空いていた穴です。表示速度の指標は最初の一画面に強い一方、その後の画面遷移は測りにくく、「最初は速いのに使い始めると重い」という感想を数字で示せませんでした。予約フォーム、商品の絞り込み、地図の切り替えなど、中小企業のサイトでも読み込みを挟まず描き替える作りは増えています。改善の順番を決めるときに、体感に近い数字が手元にあるかどうかは大きな差になります。

もっとも、指標が増えれば追う手間も増えます。全部を見るのではなく、その画面で一番使われる操作をひとつ決めて、その前後だけ測るくらいでも十分に判断材料になります。

どこから取り入れるか

実務での見極めは、三つに分けて考えると迷いません。まず、主要なブラウザすべてで使える状態になったものは、素直に置き換えの候補にできます。入力欄の伸縮や要素同士を結びつける配置指定はこの段階です。次に、特定のブラウザだけで動くものは、無くても成立する上乗せとして扱う。カメラの新しい要素は今のところここに入ります。最後に、置き換えによって読み込んでいるライブラリやプラグインを一つ減らせるかどうかを見る。減らせるなら優先度は上がります。

この最後の観点が、長く運用するサイトでは一番効きます。数年前に選んだライブラリの更新が止まり、依存関係の警告だけが増えていくという話は珍しくありません。ブラウザに入った機能は簡単には消えないので、同じことができるなら標準の側に寄せておくほうが、後々の手間は少なくて済みます。

新機能の一覧を追いかけるのは楽しい作業ですが、実利という意味では逆向きの棚卸しのほうが効くのかもしれません。いま抱えているJavaScriptのうち、どれがすでにHTMLやCSSで書けるようになっているのか。手元の案件をひとつ開いて、読み込んでいるファイルを上から見ていくだけでも、消せる候補はいくつか見つかるはずです。

ふりがなが隣の文字に重なるのを抑えるCSSの新しい指定

つくば市のホームページ制作会社

日本語のページを組んでいると、ふりがな、つまりルビの扱いで地味に手を取られることがある。難読の地名や人名に読みを添えたい、子ども向けや自治体のページで漢字に読みを振りたい、といった要望は今も普通に出てくる。HTMLにはもともと ruby 要素があり、<ruby>石動<rt>いするぎ</rt></ruby> のように書けば親字の上に読みが乗る。ところが実際に組んでみると、読みのほうが親字より長いときの見え方がブラウザまかせになりがちで、そこを細かく指定する手段が長らく足りていなかった。Chromeのベータ版に入った新しいCSSプロパティは、その足りなかった部分をひとつ埋めるものになっている。

ルビは日本語サイトの地味な難所

ルビの厄介さは、親字と読みの長さが一致しないところにある。二文字の漢字に四文字の読みを振れば、読みの側が横にあふれる。ブラウザはこのあふれた分を隣の文字の上に少しはみ出させて表示することが多い。行がむやみに間延びしないので、組版としてはむしろ自然な処理だ。

問題は、そのはみ出しが常に望ましいとは限らないことだった。隣にリンクや強調が続いていると読みが重なって見えづらくなる。狭いカラムや表のセルの中では、はみ出しのせいで折り返し位置が予想と変わる。逆にはみ出しを一切許さないと、親字と読みの幅を揃えるために文字間が広がり、本文の中でその部分だけ間延びして見える。どちらを選ぶかは文脈次第で、これまではCSSからその判断を伝える標準的な手段がなかった。制作側は文字サイズを下げる、ルビを画像にする、そもそもルビをあきらめるといった回り道をしてきた。

はみ出しの許し方を選べるruby-overhang

Chrome 151のベータで加わったのが ruby-overhang というプロパティで、ルビが隣にはみ出すことを許すかどうかを書き手が指定できる。初期値は auto で、これは従来どおりブラウザの判断ではみ出しを許す振る舞いにあたる。隣にも別のルビが並んでいる場合など、重なると読めなくなる状況では自動的にはみ出さない、といった配慮も仕様に含まれている。

もうひとつの値が spaces で、はみ出してよい相手を空白と約物、つまり句読点やかっこの類に限る。隣が普通の文字なら、はみ出さずにその手前で止まる。Chromeの説明によれば none は spaces の別名として扱われ、はみ出しを完全に禁じた結果として不自然な隙間ができるのを避ける形になっている。この none の解釈は資料によって記述が揃っていない段階なので、実際の見え方は手元で確かめておきたいところだ。

書き方そのものは短い。読みが隣の文字に重なると困る箇所に ruby-overhang: spaces; を当てるだけで、あとはブラウザが処理してくれる。JavaScriptで文字幅を測って調整する、といった作業はいらない。

位置や揃え方を決める指定との組み合わせ

ルビまわりのCSSは、これが最初というわけではない。読みを親字の上に置くか下に置くかを決める ruby-position、親字に対して読みをどう割り付けるかを決める ruby-align は以前から使える。縦書きで読みを右側に出したい、読みを親字の幅いっぱいに散らしたい、といった調整はこれらが受け持つ。

今回の指定は、そこに「隣との境界をどう扱うか」という軸を足すものだと考えるとわかりやすい。位置と揃え方を決めたうえで、あふれた分を外に出してよいかどうかを別に決められる。組み合わせると、たとえば見出しの中のルビははみ出しを許して行の高さを保ち、本文の狭い箇所でははみ出しを止める、といった使い分けができる。

現時点で試すときの構え

ruby-overhang は主要ブラウザすべてに揃った状態ではなく、Baselineの対象にもなっていない。Chromeでもまだ安定版ではなくベータの段階にある。今すぐ本番の見た目を左右する前提で組むものではない、というのが正直なところだ。

とはいえ、対応していないブラウザではこの指定が無視されるだけで、ルビ自体は従来どおり表示される。壊れるのではなく、これまでの見え方に戻るだけなので、段階的に足していける類の機能になる。ルビを多用しているページがあるなら、対応済みのブラウザで spaces を当てたときにどう変わるかを一度見ておくと、将来の判断が早くなる。

中小企業のサイトでルビが主役になる場面は多くないが、社名や商品名の読み、地域名、業界特有の用語など、読みを添えたい単語は意外とある。読みを振ると崩れるから避ける、という選択をしてきた現場ほど、こうした指定が揃ってきたことの意味は大きい。日本語の組版に関わる指定がウェブ標準の側で少しずつ整っていくのは、地味だが歓迎したい流れだ。

SNSや動画の投稿の検索での見え方をSearch Consoleで追える

つくば市のホームページ制作会社

Googleが今月、Search Consoleに「プラットフォームプロパティ」という新しい種類のプロパティを追加したと公式ブログで発表した。InstagramやTikTok、X、YouTubeに投稿したコンテンツが、Google検索やDiscoverでどのように表示され、どんな検索語句から人が来ているのかを、Search Consoleの画面の中で確認できるようになるというもの。すぐに全員が使えるわけではなく、数週間かけて段階的に開放されると案内されている。

これまでのSearch Consoleは、ドメインやURLの所有権を確認したうえで使うツールだった。自分で管理していないSNS上の投稿は、検索結果に出ていたとしても計測する手段がなく、実質的に見えない領域として残っていた。今回のプラットフォームプロパティは、サイトを持っていなくてもアカウントを連携するだけで登録できる点が従来と大きく違う。プロパティを追加する操作自体は既存の流れと同じで、追加画面から対象のサービスを選び、連携を承認していく形になる。

用意されているレポート

見られるのはパフォーマンスとインサイトの二種類のレポートとされている。パフォーマンスのほうは、クリック数や表示回数といったおなじみの数字に加えて、どの投稿とどの検索語句が実際の流入につながっているかを絞り込んで確認できる。インサイトのほうは、直近の傾向や反応の良かった投稿、検索から自分のアカウントがどう見つけられているかを大づかみに把握するための画面という位置づけになっている。ウェブサイトのプロパティで見慣れている画面構成にかなり近いので、普段からSearch Consoleを開いている人なら戸惑うところは少なそうだ。サイトを持たずに発信している人にも数字が届くようにしたい、という意図が説明されている。

気をつけたいのは、ここに出てくるのはあくまでGoogle検索とDiscover経由の数字で、各サービスのアプリの中で見られた分は含まれないという点。SNSの管理画面が出す数字とは母数がまったく違うので、単純に足したり、どちらが正しいかを比べたりするような使い方には向かない。あくまで検索という入口からの流入を見るための道具として、別枠で扱うのが無難だと思う。連携そのものも各サービスの認証を通す形になるので、誰のアカウントを誰が繋ぐのか、社内で運用担当が分かれている場合は先に決めておいたほうがあとで混乱しない。

中小企業のサイト運営という視点で見ると、これは「SNSは検索とは別のもの」という前提を少し見直す材料になりそうだ。店名やサービス名で検索したときに、自社サイトより先にSNSの投稿が並んでいるケースは珍しくない。どの投稿がどの語句で拾われているのかが分かれば、サイト側でどんな情報を厚くすべきかの判断もしやすくなる。連携できるアカウントを運用しているなら、自分のところに機能が届いたタイミングで一度のぞいてみる価値はあると思う。

ホバーや押したときの見た目をコードなしで整えるWordPressの新機能

つくば市のホームページ制作会社

ボタンにマウスを載せたら色が変わる、リンクにキーボードのフォーカスが当たったら枠線が出る。ウェブサイトではごく当たり前の動きですが、WordPressのブロックエディタでこれを整えようとすると、これまでは追加CSSの欄にセレクタを書き足すか、テーマのスタイルシートを直接触るしかありませんでした。次のバージョンで、ここに標準の指定方法が入ります。

7月15日に公開された7.1のベータ1の告知では、ブロックが操作にどう反応するかを、サイト全体の設定と個々のブロックの両方で共通のコントロールから指定できるようになる、と説明されています。派手さはありませんが、制作側と運用側の分担にじわじわ効いてくる種類の変更です。正式リリースは8月19日、WordCamp USに合わせた日程が示されています。

これまでは追加CSS頼みだった領域

ホバーやフォーカスといった状態ごとの見た目は、CSSでは擬似クラス(:hover、:focus、:active)で書く領域です。ブロックエディタのサイドバーには色やタイポグラフィの入り口はあっても、状態別の入り口はありませんでした。結果として、テーマが用意した見た目をそのまま受け入れるか、追加CSSで上書きするかの二択になります。

後者はセレクタの書き分けが面倒でした。サイト全体のボタンをまとめて変えるのは比較的簡単でも、あるページの一つのボタンだけ挙動を変えたいとなると、そのブロックに固有のクラスを振り、そのクラス向けの記述を足すことになります。運用担当の方が触れる範囲ではなく、結局は制作会社への小さな依頼として積み上がっていく部分でした。

この標準化はGutenbergのリポジトリで数年前から要望が出ていたもので、ようやく本体に入る形になります。

全体にも一つのブロックにも当てられる

今回の仕組みで押さえておきたいのは、適用範囲が二段構えになっている点です。グローバルスタイル側で指定すればサイト全体のボタンの反応が揃い、個別のブロック側で指定すればその一つだけが別の反応になります。テーマの土台は崩さないまま、例外だけを局所的に作れるということです。

もう一つ、フォーカス時の見た目を編集画面から扱えるようになる意味は小さくありません。キーボードだけでサイトを操作する人にとって、今どこにいるかを示す枠線は迷子にならないための唯一の手がかりです。装飾を優先してこの表示を消してしまう実装は今も見かけますが、逆に言えば、消すのではなく背景色に対して見やすい色に調整するという判断を、コードを触らない担当者でもできるようになります。

対応するブロックはまず限られる

期待しすぎないほうがよい部分もあります。ベータの段階で状態指定に対応しているのはボタンとナビゲーションリンクなど、対象はまだ絞られています。すべてのブロックに広がるのはこの先の版で、本体側でも段階的に範囲を広げていく方針が示されています。

また、テーマ開発の側ではtheme.jsonから擬似要素を扱えるようにする整備も並行して進んでいます。編集画面のコントロールとテーマの定義ファイル、両方から状態のスタイルを扱えるようにしていく流れの一部と見ておくと、位置づけを取り違えずに済みます。開発者向けの月次まとめでも、この周辺は7.1の柱の一つとして扱われています。

更新前に確認しておきたいところ

実務で気をつけたいのは、既存サイトで追加CSSを使ってホバーの見た目を上書きしている場合です。新しいコントロールから指定した内容と、これまで書いてきた記述が重なると、どちらが勝つかは書き方次第になります。更新のタイミングで、追加CSSにどんな状態指定が残っているかを一度洗い出しておくと、後から原因を探す手間が減ります。

本番にいきなり当てるのではなく、複製した検証環境で主要なページを一通り見てから、というのはこの種の更新では毎回変わらない手順です。ボタンとナビゲーションが対象である以上、影響が出るとしたら問い合わせ導線やグローバルメニューという、サイトの中でも動いてほしくない場所になります。

小さな見た目の調整を運用側で完結できる範囲が広がるのは、更新を続けていくサイトにとっては地味に効きます。制作時に決めた見た目を固定するのではなく、運用しながら少しずつ手を入れられる状態にしておく。ブロックエディタが年々進んでいる方向は、おおむねそこに向いているように見えます。