CSS 2本をGzip・Brotliで比較。約17KBが3.6〜4.3KBになった

検証条件

• dist/_astro内の.cssファイル二本を対象
• ファイル名はビルド時ハッシュを含むため計測時の名称を記録
• GzipとBrotliはHTML記事と同じNode.js zlibを使用
• ルール数は開き波括弧の件数であり厳密なCSS AST集計ではない

計測結果

大きさが近くても圧縮率は異なった

二本の未圧縮容量は1,719bytes差でしたが、Brotli後は102bytes差になりました。宣言やセレクタの繰り返し方によって圧縮効率が変わるため、元容量だけでは転送量を判断できません。

メディア側は概算231ルール、作品側は158ルールでした。ルール数が多いメディア側の方がBrotli後は小さく、単純な本数やルール数だけで重さを評価できない結果です。

共通化は可読性とキャッシュを優先する

似た宣言を無理に一行へ詰めても、圧縮後の差は小さくなる場合があります。保守しやすいセレクタを保ち、完全に同じ役割の宣言だけをまとめます。

作品用の暗いUIとメディア用の明るいUIは責務が異なるため、現時点では別CSSを維持します。閲覧しない側のCSSを読み込ませない方が重要です。

ルール数と転送量が比例しなかった理由

メディア側は231ルール、作品側は158ルールですが、Brotli後の差は約100bytesです。メディア側には似た色、余白、文字指定が多く、繰り返しが圧縮されやすい構造になっています。

ルール数を減らすためだけに異なる画面のCSSを統合すると、読まないスタイルまで配信する可能性があります。今回は作品とメディアを分け、各ページが必要なCSSだけを使う構成を優先しました。

この検証で確かめたかったこと

今回の出発点は「CSS 2本をGzip・Brotliで比較。約17KBが3.6〜4.3KBになったで扱う値を、現在のサイトと公開ファイルから再現できる形で確認できるか」という疑問です。Web制作の記事では推奨値だけが独り歩きしやすく、条件が異なる結果を並べても判断材料になりません。そこで対象を当サイトの実ファイルへ限定し、変更した項目と固定した項目を分けました。数値が小さいか大きいかを競うのではなく、現在の構成で次の作業を決められるかを目的にしています。

想定している読者は、CSS・素材を自分のサイトでも具体的に点検したい人です。完成済みの大規模サイトではなく、少数の記事や画像から始める個人サイトでも追試できるよう、特別な計測サービスを前提にしていません。結果だけを持ち帰るのではなく、対象の選び方、単位、除外した要素まで確認すると、自分の環境との差を整理しやすくなります。

一次情報として残したもの

「CSS 2本をGzip・Brotliで比較。約17KBが3.6〜4.3KBになった」で明示した対象をビルド済みHTML、CSS、画像、設定ファイルから読み取り、dist/_astro内の.cssファイル二本を対象という条件を変えずに記録したことを記録の中心にしました。記事内の表は、その記録から必要な値だけを転記しています。一般的な解説を先に置いて数字を当てはめるのではなく、先に対象ファイルを決め、取得できた値から考察を書く順序です。元データと公開本文の数字が食い違わないよう、単位はbyte、px、件数など測定時の形式をできるだけ保ちました。

「CSS 2本をGzip・Brotliで比較。約17KBが3.6〜4.3KBになった」の計測日は2026年6月10日です。Astro 5で静的出力した時点のファイルを対象としているため、素材やテンプレートを変更すれば値も変わります。この記事は永続的な基準値ではなく、CSS・素材の状態を残したスナップショットです。再測定で結論が変わる場合は、更新日と変更理由を追記します。

結果を読むときの注意

「CSS 2本をGzip・Brotliで比較。約17KBが3.6〜4.3KBになった」は当サイト一件の測定であり、別のCSS・素材環境へ同じ数値をそのまま一般化できないという限界があります。一つの指標だけで「速い」「使いやすい」「正しい」と断定しないことが重要です。たとえば容量が小さくても表示が崩れれば採用できず、規格上の目安を満たしても実際の操作が難しい場合があります。表の値は判断の入口であり、最終的な利用体験の代わりではありません。

このCSS・素材検証で差が出なかった場合も、作業の優先度を下げる根拠になります。反対に大きな差が出た場合は、「CSS 2本をGzip・Brotliで比較。約17KBが3.6〜4.3KBになった」で明示した対象をビルド済みHTML、CSS、画像、設定ファイルから読み取り、dist/_astro内の.cssファイル二本を対象という条件を変えずに記録したという記録へ戻り、条件の混入や数え方を再確認します。都合のよい値だけを採用せず、対象、式、除外項目を本文へ残すのはそのためです。

実際の制作でどう判断したか

この結果を受け、当サイトでは「今回の結果をCSS・素材の公開前チェックへ組み込み、変更時には同じ手順で差分を確認する」と判断しました。数値を掲載するだけではサイト改善につながらないため、CSS、画像の書き出し、記事テンプレート、公開前チェックのいずれかへ反映します。採用理由を文章にしておくと、後から別の設定へ変えるときにも、以前の判断を検証できます。

ただし「今回の結果をCSS・素材の公開前チェックへ組み込み、変更時には同じ手順で差分を確認する」という判断を全ページへ一律適用するわけではありません。今回の対象と、トップ、記事、固定ページでは利用目的が異なります。「CSS 2本をGzip・Brotliで比較。約17KBが3.6〜4.3KBになった」は当サイト一件の測定であり、別のCSS・素材環境へ同じ数値をそのまま一般化できないという限界もあるため、共通ルールを作ったうえで例外の理由を残す方が、数値だけを守るより保守しやすいと考えています。

同じ確認を再現する手順

再検証するときは、dist/_astro内の.cssファイル二本を対象という対象条件と、ファイル名はビルド時ハッシュを含むため計測時の名称を記録を固定して同じ確認を行うのが基本手順です。最初に対象ファイルを複製するかビルド結果を保存し、変更前の値を残します。次に一度に変更する条件を絞り、同じ単位で変更後を取得します。最後に差分を計算し、画面上の見え方や操作も確認します。複数の変更を同時に入れると、どの変更が結果へ効いたのか分からなくなります。

自分のサイトで「CSS 2本をGzip・Brotliで比較。約17KBが3.6〜4.3KBになった」と同じ確認を行っても、同じ数字になる必要はありません。重要なのは、dist/_astro内の.cssファイル二本を対象という対象条件と、ファイル名はビルド時ハッシュを含むため計測時の名称を記録を固定して同じ確認を行うという条件を変更前後で揃えることです。OS、ツールの版、画面幅、対象URLなど結果へ影響する情報を残せば、数値が異なっても比較可能な一次記録になります。

次に確認する項目

今回扱わなかった要素は、「CSS 2本をGzip・Brotliで比較。約17KBが3.6〜4.3KBになった」は当サイト一件の測定であり、別のCSS・素材環境へ同じ数値をそのまま一般化できないという点です。次回は対象を広げるのではなく、この不足を一つずつ切り分けます。ファイル容量の次に表示時間、寸法の次に実機操作というように、異なる種類の指標を組み合わせると、単独の数値による誤解を減らせます。

「CSS 2本をGzip・Brotliで比較。約17KBが3.6〜4.3KBになった」を再現できないという連絡や数値の指摘が届いた場合は、「CSS 2本をGzip・Brotliで比較。約17KBが3.6〜4.3KBになった」で明示した対象をビルド済みHTML、CSS、画像、設定ファイルから読み取り、dist/_astro内の.cssファイル二本を対象という条件を変えずに記録したという一次記録と本文を照合します。結論へ影響する修正では更新日を変更し、何が変わったかを残します。CSS・素材の記事を完成品として固定せず、サイトの変更とともに追試できる記録として維持します。

CSS・素材記事の公開前チェック

CSS・素材の記事では、個別の結果に加えて「装飾の容量と描画負荷を抑えながら、サイト固有の見た目を維持できるか」を公開前の共通確認点にしています。今回の表だけが良好でも、関連する画面やファイルへ悪影響があれば採用しません。変更前の状態を残し、記事で扱った指標と実際の利用場面を往復して確認します。

このチェックは「CSS 2本をGzip・Brotliで比較。約17KBが3.6〜4.3KBになった」の文字数を増やすためではなく、測定から公開判断までの抜けを減らすために使います。ファイル容量と描画処理を分けて考える、共通化で責務が混ざらないか見る、低性能端末でスクロールを確認するを確認し、自動検査だけでは判断できない箇所を画面と文章で読み直します。読者が追試できない説明なら、数値が基準内でも公開しません。

CSS・素材の記事を更新するときは、結論だけを新しい値へ置き換えず、検証条件、表、本文の参照値、タイトル、descriptionを順番に照合します。以前の手順を再現できなくなった場合は、「CSS 2本をGzip・Brotliで比較。約17KBが3.6〜4.3KBになった」は当サイト一件の測定であり、別のCSS・素材環境へ同じ数値をそのまま一般化できないという制約がどう変わったかも記録します。どの変更で結果が動いたかを追える状態を優先します。

• ファイル容量と描画処理を分けて考える
• 共通化で責務が混ざらないか見る
• 低性能端末でスクロールを確認する