CSS解析では、スタイルの量や使われ方、セレクターの詳細度などを調べます。レポートの「未使用」は、検査した状態で使われなかったという意味です。メニューを開いたときや画面幅を変えたときに必要なルールまで、すぐに削除しないでください。
最初にページと操作を決める
共通ヘッダーを持つページ、商品一覧、入力フォームなど、異なるスタイルを使うページを選びます。初期表示だけでなく、メニューを開く、入力エラーを表示する、タブを切り替えるといった操作も整理してください。修正前後では同じ画面幅と操作で確認します。
MiltenのCSS解析で公開ページを確認し、対象のスタイルシートと指摘を記録します。解析がカバーしていない状態は、手動確認の項目として残します。
未使用の割合だけで削除を決めない
説明用の例として、初期表示では閉じているメニューを考えます。メニュー内のスタイルが最初の表示で使われなくても、開いた状態では必要になることがあります。実際に操作してから、不要なルールかを判断します。
Chrome DevToolsのCoverageのドキュメントでは、ページを操作しながらCSSとJavaScriptの使用状況を記録する方法を説明しています。特定の記録で未使用だったことと、サイト全体で不要であることを区別してください。
削除候補を決めたら、どのファイルやビルド処理がそのCSSを出力しているかを調べます。圧縮済みファイルを直接書き換えるより、生成元を修正し、再ビルドした結果を確認する方が変更を管理しやすくなります。
重複と詳細度を整理する
同じ宣言が繰り返されていても、適用条件が同じとは限りません。メディアクエリ、状態、カスケードの順序を確認します。ルールを統合したら、元と同じ要素に同じスタイルが適用されるかを調べてください。
別の説明用の例として、ボタンの色を変えるために !important を追加し続けるケースがあります。先に競合するルールと詳細度を確認します。MDNの詳細度の説明を参照し、意図した優先関係をソースコードで表現します。
見た目と操作を公開後に確認する
変更後は、対象URLを再解析します。ファイルサイズだけでなく、ボタン、フォーム、開閉するメニューの動作を確認してください。モバイル端末と大きな画面の両方で、文字の折り返しやフォーカス表示も調べます。
色や余白の共通値を整理したい場合はDesign Tokens、表示の不具合がHTMLに関係する場合はHTMLの確認手順を使えます。
未使用CSSが減れば表示も必ず速くなりますか？
速度は読み込み順、ファイルの転送、JavaScriptなどにも影響されます。表示速度の検査で同じ条件を使って確認し、実際に何が変わったかを調べます。
自動解析だけで完了できますか？
利用者が操作する状態や画面幅を含めて確認する必要があります。レポートの対象と、手動で確認した範囲を分けて記録してください。
公開ページのCSSを解析する。修正前の条件と指摘を残してから作業を始めましょう。
