「表示が遅い」と言われて画像を全部圧縮し、サーバーのプランも上げた。それでも体感が変わらない——という相談があります。数値上も、最初の表示までは速くなったのに、操作できるようになるまでの時間が縮んでいない。
このパターンでは、原因が画像でもサーバーでもないことがあります。ブラウザが自前でできるようになった処理を、いまも JavaScript のライブラリで肩代わりし続けている状態です。数年前に組んだサイトほど当てはまります。当時は必要だったコードが、必要なくなったまま配られ続けているだけだからです。
遅さの正体が画像でもサーバーでもないとき
表示速度の相談で最初に手をつけられるのは、たいてい画像とサーバーです。分かりやすく、効果も見えやすい。ただしこの2つは「最初の1枚が出るまで」に効くもので、その後の重さには効きません。
サイトを開いてから操作できるまでの間に何が起きているかを分けると、こうなります。
- 受け取る（ネットワーク） — 画像圧縮とサーバー増強が効くのはここ
- 読む（パース） — JavaScript のファイルサイズがそのまま時間になる
- 動かす（実行） — 読み込んだコードが実際に走る。端末の性能差がいちばん出る
3番目が重いサイトは、スマートフォンの実機で触ったときの「タップしても少し待たされる」感覚になって現れます。ここで効くのは圧縮ではなく、そもそも配るコードを減らすことです。指標としてどこを見るかはCore Web Vitals の読み方にまとめています。
「もう外せる依存」を見分ける基準
とはいえ「このライブラリはもう要らない」と判断するのは、担当者にとって怖い作業です。外した結果、特定のブラウザで壊れたら目も当てられません。
その判断のために使えるのが Baseline です。Baseline は、ある機能が主要ブラウザすべてで安定して使えるかどうかを単一のラベルにまとめた指標で、「対応表を横断して自分で読む」作業を不要にします。判断のしかた自体はWeb Platform Baseline 2026 でコーポレートサイトを設計するで扱っていますが、ここでの使い道はひとつに絞れます。
「このライブラリが解決していた問題は、いま Baseline に入っているか」 を1件ずつ確認する。入っていれば外せる候補、入っていなければ据え置き。それだけです。
外せる量は、実は数えられる
Smashing Magazine が2026年8月に公開した依存の棚卸し手順では、中規模のアプリケーションで gzip 後 60KB から 90KB 程度をプラットフォーム側に返せるとしています。たとえば lodash.clonedeep と lodash.groupby の2つを外すだけで gzip 後およそ 8KB という具体例が挙げられています（Smashing Magazine）。
置き換えの対象になりやすいのは、次のような領域です。
- ドロップダウン・ツールチップ・モーダル — 位置調整と重なり順のためにライブラリを入れていたもの。CSS アンカーポジショニングは2026年1月に Baseline Newly available になり、Popover API とあわせて素の機能で組めるようになっています
- 画面遷移のアニメーション — View Transition API で、ページ間・状態間の切り替えをブラウザ側に任せられます
- 日付・数値・通貨の書式 — 国際化のためのライブラリを丸ごと積んでいたもの
- 要素が画面に入ったかの判定 — スクロール監視の自前実装や専用ライブラリ
CSS 側でどこまで賄えるようになったかはモダンCSSのネイティブ機能で何が置き換わったかに一覧があります。カルーセルのように「JavaScript が必須だった」代表格ですら、CSS だけで組める形が出てきています。
外すと壊れるもの、壊れないもの
すべてを外せるわけではありません。判断を誤らないための線引きがあります。
壊れにくいのは、見た目と挙動が置き換え先とほぼ同じものです。日付の書式、配列操作、要素の可視判定のように、入力と出力が明確な処理は置き換えても影響範囲が読めます。テストで確認できる範囲に収まります。
注意が要るのは、アクセシビリティに関わる部分です。ライブラリ側がキーボード操作や読み上げの挙動まで面倒を見ていた場合、素の機能に置き換えると、その分を自前で作り直す必要が出ます。「同じ見た目になったから完了」で止めると、キーボードだけで操作しているユーザーが詰まります。
外すべきでないのは、業務ロジックが乗っているものです。フォームのバリデーションや決済まわりのように、動かなかったときの損失が大きい箇所は、パフォーマンスの数値のために触る対象ではありません。数十KBのために問い合わせフォームを壊すのは、どう考えても割に合いません。
つまり、外す順番は「効果の大きさ」ではなく「壊れたときの影響の小ささ」で決めます。効果が最大のものから手をつけると、いちばん怖い箇所から触ることになりがちです。
リニューアルまで待たなくてよい
依存の削減が良いのは、サイト全体を作り直さなくても着手できることです。1つのライブラリを外すのは、デザインの変更もコンテンツの移行も伴いません。効果は数値で出るので、続けるかどうかも判断できます。
進め方としては、まず「何がどれだけ乗っているか」の一覧を出してもらうところからです。制作会社に依頼する場合も、いきなり改修を頼むのではなく、現状の依存一覧と、それぞれが解決している問題を出してもらえば、外せる候補は自然に浮かびます。そこまで見えてから、どこまでやるかを決めれば十分です。
効果の確認も、専門的な計測環境は要りません。改修の前後で同じ端末・同じ回線条件で同じページを開き、操作できるようになるまでの体感と、ブラウザの計測結果を並べる。「速くなった気がする」ではなく数値が並んでいれば、次にどこを削るかの判断もできます。この繰り返しが成立するかどうかが、依存の削減を続けられるかの分かれ目になります。
逆に、この一覧が出てこない場合は注意が要ります。何が乗っているか把握していない状態で改修すると、外した副作用に気づくのが公開後になるためです。一覧が出せるかどうかは、そのまま引き継ぎのしやすさの指標にもなります。
次にやること
自社サイトをスマートフォンの実機で開き、最初の表示ではなく「タップして反応するまで」を見てください。 ここが遅いなら、画像圧縮とサーバー増強では改善しません。
そのうえで、制作を依頼した会社に「いま読み込んでいる JavaScript の一覧と、それぞれの用途」を出してもらってください。この一覧が出てこない、あるいは用途が説明できない項目があるなら、そこが最初に削れる場所です。
表示速度を理由にリニューアルを検討している場合、作り直さずに済むケースもあります。グリームハブではHP制作・リニューアルのご相談を承っており、現状の構成を見たうえで「作り直す必要があるのか」から整理します。要件によって最適な進め方は変わるため、個別にご相談ください。お問い合わせからどうぞ。
