CSSの最適化アプローチ。インライン化、圧縮、そして削除

2020/8/27

CSSの最適化には、昔から大きく3つのアプローチがあります。

圧縮（minify）
使われていないCSSの削除
インライン化

この記事はもともと2020年に書いたもので、当時は「VS Codeの拡張機能で圧縮する」「オンラインツールに貼り付ける」といった手作業の方法を紹介していました。2026年現在、そのやり方はほぼ過去のものになったので、現状に合わせて全面的に書き直しました。

結論から言うと、今は3つともビルドツールとフレームワークがほぼ自動でやってくれます。手作業での最適化が必要な場面は限られていて、大事なのは「自分の環境で何が自動化されているか」を知っておくことです。

圧縮（minify）：ビルドツールが自動でやる時代

ViteやNext.js、Astroなど、現在主流のビルドツールは、本番ビルドでCSSを自動的に圧縮します。設定すら不要です。かつて紹介していたオンライン圧縮ツールやエディタ拡張の出番は、ビルド工程のない素のHTMLサイトくらいになりました。

ところで、圧縮でどれくらい小さくなるものなのか、Bootstrap 5.3.8のCSSで実測してみました。

bootstrap.css（元ファイル）     280,311 bytes（gzip後 33,860）
公式の bootstrap.min.css        232,111 bytes（gzip後 31,078）
Lightning CSS で圧縮            228,703 bytes（gzip後 30,728）
cssnano で圧縮                  230,447 bytes（gzip後 31,056）

ファイル単体では約18%小さくなりますが、gzip配信後の差は9%程度です。圧縮ツール同士の差（Lightning CSSとcssnano）に至っては誤差でした。サーバーがgzipやbrotliで配信しているなら、minifyの効果は「あるに越したことはない」程度。ツール選びで悩む時間がもったいないので、ビルドツールのデフォルトに任せれば十分です。

使われていないCSSの削除：フレームワーク側で解決された

2020年版では「BootstrapのようなCSSフレームワークを使うならPurgeCSSが事実上必須」と書きました。使われないユーティリティクラスが大量にファイルへ残るからです。

この問題は、フレームワーク側の進化でほぼ解決されました。Tailwind CSSはv3以降のJITエンジンで「実際に使ったクラスだけを生成する」方式になり、「削除」という工程そのものが不要になっています。

実例として、このブログはTailwind CSS（v4）で作っていますが、サイト全体のCSSは44KB、gzip配信後は約8KBです。Bootstrapをまるごと読み込むとgzip後でも30KB超あることを考えると、「あとから削除する」より「最初から作らない」方が圧倒的に効率的だと分かります。

古いプロジェクトでBootstrapなどを使い続けている場合は、今もPurgeCSSが選択肢になります。ただ、新規で作るなら「使った分だけ生成される」仕組みのフレームワークを選ぶ方が筋が良いと思います。

インライン化：これも自動化されている

最初に表示される画面に必要なCSSだけを<style>タグでHTMLに埋め込み、残りをあとから読み込む。いわゆるクリティカルCSSの考え方です。

これも現在は、フレームワークが面倒を見てくれる領域になりました。例えばAstroは、4KB未満のCSSをデフォルトで自動的にインライン化します（build.inlineStylesheets、デフォルト値はauto）。小さいCSSはHTTPリクエスト1回ぶん得をして、大きいCSSはキャッシュの効く外部ファイルのまま、という合理的な挙動です。

手動でクリティカルCSSを抽出する手法もありますが、管理の手間に対して効果が見合うケースは少なく、よほど表示速度がお金に直結する大規模サイトやLPでもない限り、フレームワークのデフォルトで十分です。

2020年にはこの3つはどれも「開発者が手を動かす作業」でしたが、2026年にはどれも「ツールの仕事」になりました。残った人間の仕事は、重いCSSを書かないことと、たまに計測して確認することくらいです。