Modern Web Guidance を入れて、ブログに直すところがあるか測った

Chrome チームが公開している Modern Web Guidance を、Claude Code にユーザーレベルで入れた。入れたあと、このブログに直すところがあるかを PageSpeed Insights で測ってみた。入れた手順と、測った結果を記録しておく。

Modern Web Guidance とは

Modern Web Guidance は AI コーディングエージェント向けのスキル集だ。Web 開発のベストプラクティスと、ブラウザの対応状況のデータをまとめたもので、Chrome for Developers が公開している。対象のユースケースは 100 件を超える。

作られた理由は AI エージェントの書くコードにある。公式のページによると、AI エージェントは古い書き方を選びやすい。新しい機能を知らないこともあるし、プロジェクトがどのブラウザまで対応すべきかも考えない。たとえば <dialog> 要素で済むモーダルを、JavaScript で自作してしまう。

導入すると、エージェントは作業の前に Modern Web Guidance の CLI を呼び出し、作業に合うガイドを探して読む。ガイドを探すのが search、本文を取り出すのが retrieve だ。導入する前に、自分で試すこともできる。

npx modern-web-guidance@latest search "animate a dialog modal backdrop"
npx modern-web-guidance@latest retrieve "animate-to-from-top-layer"

ガイドは AI が読む前提で書かれていて、解説記事というより指示書に近い。たとえば「Light-Dismiss a Dialog」（背景のクリックでダイアログを閉じる）のガイドには、推奨する実装のコード、守るべきルール、未対応のブラウザ向けの代わりの実装が載っている。ルールは MANDATORY / DO / DO NOT の形で書かれている。

公式のページによると、ガイドを使った場合は使わない場合より、評価のスコアが平均 37 ポイント高かった。ただし、これは Chrome チーム自身による初期の結果で、ページにも「結果は異なる場合がある」と注記がある。

ユーザーレベルで導入した

このブログに限らず、どのプロジェクトでも使いたかったので、ユーザーレベルで入れることにした。Claude Code のプラグインとして入れる方法もあるが、公式が推奨している次のコマンドを使った。こちらは自動更新にも対応している。

npx modern-web-guidance@latest install

本体は ~/.agents/skills/modern-web-guidance に置かれ、Claude Code はこれを ~/.claude/skills/modern-web-guidance というリンク経由で読み込む。~/.agents/skills/ は Codex や Cursor、Cline なども見に行く場所なので、それらのエージェントからも使える。

インストールの途中で、3 つのサービスによるセキュリティの評価が表示された。Gen は「Safe」、Snyk は「Low Risk」で、Socket だけ警告が 1 件出ていた。

利用データの送信を止める

Modern Web Guidance は匿名の利用データを Google に送る。送りたくなかったので、~/.zshrc に次の 1 行を足した。

export DISABLE_TELEMETRY=1

Baseline はデフォルトのまま

Modern Web Guidance は Baseline という基準で「どのくらい新しい機能まで使うか」を決める。何も指定しなければ Widely available、つまり主要なブラウザすべてで使えるようになってから 30 か月以上たった機能だけを使う。新しめの機能も使いたい場合は、CLAUDE.md や AGENTS.md に「This project's Baseline target is Baseline 2024.」のように書く。

今回はデフォルトのままにした。

Modern Web Guidance に直してもらうところはあるか

Modern Web Guidance は AI が書く Web のコードの質を上げるためのスキル集だ。せっかく入れたので、このブログに直してもらうところがあるかを確かめたくなった。そこで、表示の速さやユーザー補助を採点してくれる PageSpeed Insights で測ってみた。

何も直していないのに、トップページはモバイルでもデスクトップでも 4 項目すべて 100 だった。エージェントによるブラウジングも 3/3 だった。

記事ページ（前回の記事）も測った。モバイルではトップページと同じく 4 項目すべて 100 だった。デスクトップでは、パフォーマンスだけ 1 回目が 100、2 回目が 97 とぶれた。ほかの 3 項目は 100 で、エージェントによるブラウジングはどちらも 3/3 だった。

アクセスがまだ少ないので、実際のユーザーの環境のデータはどのページも「データがありません」だった。

残っていた改善点

点数には影響しない「診断」の欄に、次の 3 つが出ていた。

• 使っていない JavaScript が 107 KiB ある
• 使っていない CSS が 30 KiB ある
• メインスレッドの処理に 2.7 秒かかっている

使っていない JavaScript の正体は背景のアニメーションに使っている Three.js だった。Three.js の本体は圧縮前で 743 KB、gzip 後でも 185 KB あり、このサイトの JavaScript の中で群を抜いて大きい。それなのに、背景でやっているのは「点を描く」「線を描く」「少し傾ける」の 3 つだけだ。

Three.js は、ブラウザが手の空いたときに読み込むようにしてある。ただ、PageSpeed Insights の計測中にこの読み込みが始まると、JavaScript の解析と WebGL の初期化がメインスレッドの処理に入る。97 点になったのは、おそらくこの処理が計測の時間内に入ったためだ。

使っていない CSS の正体は日本語フォントの定義だった。Noto Sans JP を文字の範囲ごとに分けて読み込むために、@font-face が 124 個並んでいる。フォントのファイル自体はページで使う文字の分しか読み込まれない。Lighthouse が「使われていない定義」として数えているだけなので、こちらはそのままにした。

おわりに

Three.js はブログを少しリッチにしたくて入れたものだ。ただ、今は背景にしか使っておらず、やっていることも点と線と傾きだけだ。これならブラウザ標準の Canvas 2D でも描けそうなので、書き直すかどうかを検討している。

Modern Web Guidance を入れてはみたものの、このブログには直してもらうところがほとんど残っていなかった。点数はもう満点に近く、技術面でこれ以上の差はつけにくい。差をつけるなら、あとは記事の中身だ。個人開発の話も仕事の話も書きたいが、まずは FlutterKaigi の話を、記憶が鮮明なうちに早く書かないと（笑）。