TailwindCSSをCDNで使ってはいけない理由と、正しい導入方法

「とりあえず動くものをすぐ見たい」——そんなときに便利なのが、<script src="https://cdn.tailwindcss.com"></script>を1行貼るだけで使えるTailwind CSSのCDN版です。ビルド環境を用意する手間もなく、HTMLファイル1枚あれば今すぐ試せる手軽さは、正直かなり魅力的です。

学習中や検証中にお世話になった人も多いはずです。ところがこのCDN版、そのまま本番サイトに使ってしまうと「思ったより重い」「なんだか表示がちらつく」といった悩みにぶつかることがあります。この記事では、なぜTailwind CSSのCDN版が重くなりやすいのか、その仕組みと見落としがちな注意点を整理し、実務ではどう使い分ければいいのか、Tailwind以外の選択肢も含めて解説します。

そもそもTailwind CSSのCDN版は、何をしているのか

Tailwind CSSは本来、HTMLやJSXなどのファイルをスキャンして「実際に使われているクラス名」だけを集め、それに対応するCSSだけを1つの静的ファイルとして書き出す仕組みを前提にしています。ビルド時にこの処理を済ませておくことで、本番環境ではただの軽量なCSSファイルを読み込むだけで済むわけです。

一方でCDN版(cdn.tailwindcss.comや@tailwindcss/browserなど)は、この「スキャンしてCSSを生成する」処理そのものを、ビルド時ではなくブラウザ側でリアルタイムに実行します。つまり、ページを開いた人のブラウザの中で、その都度コンパイラが動いているということです。

「コンパイルされないから重い」の正体

「コンパイルされないから不要な定義がいっぱい詰まっている」というイメージは、決して間違いではありません。古いバージョンのCDN配布では、あらかじめ全ユーティリティクラスを含んだ巨大なCSSファイルをそのまま配信するタイプのものもあり、実際に使っていないスタイル定義まで丸ごとダウンロードさせることになっていました。

ただし現行のCDN版(Play CDN)は少し事情が違います。今は「全部入りの巨大CSS」ではなく、ブラウザ上でその場でクラス名をスキャンしてCSSを組み立てるJITコンパイラ自体を、JavaScriptとして丸ごと配信する方式になっています。つまり「重い」の中身が、単なる不要なCSS定義から、コンパイラ本体を動かす処理コストへと変わってきているわけです。

実際にCDN版を本番環境で読み込むと、ブラウザの開発者ツールのコンソールに「本番環境では使わないように」という趣旨の警告メッセージが表示されます。「知らないうちに本番でCDN版を使い続けていた」という状況は、意外とよくある落とし穴です。

見落としがちな3つの落とし穴

「重い」以外にも、CDN版を本番で使う際にはいくつか見落としがちなポイントがあります。ここを知らずに使ってしまうと、あとで「あれ、なんか変」という困りごとにつながります。

• ⚠️表示直後に一瞬スタイルが当たっていない状態(いわゆるFOUC)が発生しうる。JavaScriptの読み込みとコンパイルが終わるまでの間、スタイルなしの見た目がユーザーに見えてしまうことがあります。
• ⚠️ページ読み込み後にJavaScriptで動的に追加した要素は、再スキャンが必要になる場合があり、想定通りスタイルが当たらないことがある。
• ⚠️独自の設定ファイルやプラグイン、細かいカスタマイズ、キャッシュを効かせた配信の最適化など、本番運用で重宝する機能に制限がある。

「便利だから」と気軽に導入したはずが、こういった細かいところで足元をすくわれるのは、正直ちょっと悔しいですよね。ですが、これは裏を返せば「CDN版の役割を正しく理解して使い分ければ問題ない」ということでもあります。

こうして並べてみると、CDN版とビルド版はそもそも「得意な場面」が違うだけだと分かります。どちらが優れているという話ではなく、適材適所です。

結論：本番ではどう導入すればいいのか

本番環境でTailwind CSSを使うなら、基本の選択肢は次の2つです。どちらも「実際に使っているクラスだけを含んだCSSファイル」を、あらかじめビルドしておくという考え方は共通しています。

方法1:Tailwind CLIでビルドする

Node.jsが動く環境であれば、もっともシンプルな方法です。

npm install -D tailwindcss
npx tailwindcss init

作成された設定ファイルで、どのファイルをスキャン対象にするかを指定したうえで、次のようにビルドコマンドを実行します。

npx tailwindcss -i ./src/input.css -o ./dist/output.css --minify

このoutput.cssを本番ページから読み込めば、実際に使っているクラスだけを含んだ軽量なCSSファイルを配信できます。コマンド名やオプションはTailwindのバージョンによって変わることがあるため、導入時は必ず公式ドキュメントで最新の手順を確認してください。

方法2:PostCSSプラグインとして組み込む

すでにビルドツール(Vite、webpackなど)を使っているプロジェクトであれば、PostCSSプラグインとして組み込むのが自然です。多くの場合、Next.js・Astro・Nuxtなどのフレームワークには公式のインテグレーション手順が用意されているので、それに沿って導入すると設定がスムーズです。

Tailwind CSS以外での考え方・対応

ここまでTailwind CSSを例に説明してきましたが、実はこれ、Tailwind固有の問題ではありません。CSSフレームワークをCDNで手軽に読み込むこと自体に、共通するトレードオフがあるのです。

たとえば従来型のCDN配布のCSSフレームワークも、使っていないコンポーネントのスタイルまで含めて、まとめて配信されるタイプが少なくありません。UnoCSSのようなAtomic CSS系のツールでも、CDN版はあくまで検証用という位置づけで、本番運用ではビルドツールを介した導入が推奨されている点はTailwindと同じ考え方です。

自前でCSSを書く場合の考え方としては、次のような選択肢があります。

• CSS Modulesやコンポーネント単位のスタイル管理で、実際に使う画面のスタイルだけを読み込む構成にする
• CSSカスタムプロパティ(CSS変数)でデザイントークンを管理し、必要な分だけ定義を増やしていく
• ページごとに読み込むCSSを分割し、全ページ共通の巨大なCSSファイル1本に頼りすぎない

大事なのは、「まずは動かして試す段階」と「本番向けにきちんと最適化する段階」を分けて考える、という設計の姿勢そのものです。この考え方さえ押さえておけば、Tailwind CSS以外のツールを使うときにも、同じ視点で判断できるようになります。

まとめ

Tailwind CSSのCDN版が重くなりやすいのは、単に「コンパイルされていないから」だけでなく、ブラウザ上でリアルタイムにスタイルを生成する仕組みそのものに理由があります。公式ドキュメントも本番利用を推奨しておらず、表示のちらつきやカスタマイズの制限など、見落としがちな注意点も存在します。

とはいえ、CDN版が「悪」というわけではなく、学習や検証には向いた選択肢です。本番サイトを公開するタイミングでは、Tailwind CLIやPostCSSプラグインとしてビルドする方法に切り替え、実際に使っているクラスだけを含んだ軽量なCSSを配信することを検討してみてください。まずはご自身のプロジェクトで、今どちらの方式を使っているかを一度確認するところから始めてみましょう。