一度入れた外部ライブラリを、あとから見直すことはあまりない。動いているし、テストも通っているし、あえて触る理由がない。ただ、その間にもブラウザ側は動いていて、いま 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の状態を確かめる。そのうえで先ほどの三つの問いに通し、いま標準になっているものを返していく。それだけで表示は軽くなり、更新を追いかける対象も減る。まずは一つの分野だけ選んで手元の設定ファイルを開いてみる、という始め方が現実的だと思う。
