クリティカルCSSが解くべき問題かを判断する
監査ラベルではなく証拠から始めてください。優先ページのコールドキャッシュ読み込みを代表的なモバイルとデスクトッププロファイルで計測します。ウォーターフォールとトレースを確認してください：スタイルシートが初回コンテンツを遅らせており、その影響が十分に重要ですか？DevToolsのCoverageはあるセッションで使われたCSSを示すだけで、すべてのルートや状態を表すわけではありません。
まずはメンテナンス負荷が低い作業を試してください：未使用ルールの削除、出力の最小化と圧縮、ルートごとのCSSを必要な箇所でのみ読み込むこと、そして平易なCSSの@import連鎖を避けること。web.devは抽出と遅延を高度な技術と呼んでいます。
計測で初回描画の遅延がCSSに結び付くこと、コールド訪問が重要であること、そして初期レイアウトを維持できること。
サーバー遅延、画像、フォント、JavaScript、あるいは既に小さなスタイルシートがボトルネックである場合、インラインCSSは効果が薄いでしょう。
初期ビューポートをテストマトリクスとして定義する
初期ビューポート（いわゆる above the fold）は、スクロール前に訪問者が目にする領域です。普遍的な高さはなく、デバイス、ズーム、言語、クッキー、コンテンツのバリアントにより変わります。1つのデスクトップスクリーンショットでは電話端末や翻訳された見出しを見落とします。
名前付きプロファイルを使ってください。狭いレイアウトと広いレイアウト、主要なブレークポイント、ログイン状態の違い、ページ上部に現れる同意バナー、プロモーション、メンテナンス告知、検証エラーなどを含めます。
テンプレート、ビューポート、ロケール、認証、同意、ページ上部のバリアントを記録して、セットを生成・テストします。
素早いスクロール、メニュー、フォームフォーカスをテストしてください。遅延されたルールのコントロールがフルCSS適用前に現れるなら安全ではありません。
ソース・オブ・トゥルースから小さなセットを抽出する
本番ビルドからクリティカルCSSを生成してください。抽出はビューポートで使われたルールを特定できますが、条件付きルール、ダイナミックなルール、トランジションはレビューが必要です。コンポーネントやマークアップが進化するので、二重に手でデザインシステムをコピーしてテンプレートに置くべきではありません。
出力は生成・バージョン管理され、ソースのCSSが権威であり続けるようにします。最初に必要な状態のルールだけをインライン化してください。大きなインラインブロックはHTMLを遅くし、外部CSSのキャッシュから再利用できなくなります。改善を判断する前にコールドとウォームのナビゲーションを比較してください。
圧縮されたインラインバイト数、残りのスタイルシートバイト数、重複ルールを追跡します。ブロッキングリクエストが一つ減っても必ずしも純増利ではありません。
抽出が空、インラインサイズ予算を超過、あるいはレビュー済み基準から予期せず変化したときにビルドでフラグを立てます。
残りのCSSを安全に読み込み、ポリシー制約を尊重する
残りのスタイルシートは、下位コンテンツや後続の状態が完全に見える前に到着している必要があります。一般的なパターンは、CSSを一旦 preload または style として要求し、読み込み完了後にスタイルシートに切り替える方法で、JavaScriptが無い場合のフォールバックも用意します。preloadはリソースを早く要求しますが、CSSを適用しません。不完全なセットは視覚的な再スタイル（フラッシュ）を引き起こします。
インラインの onload ハンドラを使う前に Content Security Policy（CSP）を確認してください。web.dev はポリシーがインラインonloadを禁止する可能性があると指摘しており、互換性のあるローダーか別の設計を使ってください。JavaScript無効での挙動もテストしてください。メディアクエリ付きのファイルは印刷など正当な条件付きスタイルに役立ちます。問い合わせに一致しないメディアはレンダーブロッキングしませんが、ダウンロードされる場合があります。
JavaScriptを無効にした訪問者でも完全なCSSが提供され、優先ジャーニーを完了できることを検証してください。
初回ビューポートで遅れるフォントや画像は別に調査してください。クリティカルCSSはそれらのフェッチ挙動を修正しません。
視覚的・機能的・キャッシュ回帰をテストする
命名された各ビューポートとページ上部の状態で視覚比較を行ってください。無スタイルのテキスト、重なり、ナビゲーションの隠れ、フォーカス指標の欠落、レイアウトシフト、遅延CSS適用時のスナップをチェックします。キーボード操作、タッチ経路、エラー、素早いスクロールを含めて操作を確認してください。遅延されたルールでコントロールが使えなくなるなら、そのルールはクリティカルパスに含めるか、デザインを変更する必要があります。
コールドとウォームの両方でテストしてください。コールドテストはCSS待ちを取り除いたときの描画改善を示し、ウォームテストは繰り返しのインラインバイトコストを示します。キャッシュされた古いHTMLとデプロイ後の再訪も確認してください。互換性のある資産を保持し、キャッシュされたHTMLがそれらを要求する可能性があるため、フィンガープリント済みスタイルシートURLを上書きしないでください。
まず first content と main visible content を比較し、トレースを使って得られた改善または回帰を説明します。
フォーカス、コントラスト、モーションの嗜好、ズーム、読みやすい順序を含めてください。表示が速くなっただけでは、インターフェースがアクセシブルであるとは言えません。
可逆的な配信機能として運用する
パイプラインに担当者を割り当て、入力、アーティファクト、テンプレート、テストプロファイル、インラインサイズ上限を文書化してください。CSS、マークアップ、コンポーネントライブラリ、機能フラグ、あるいはページ上部に影響するサードパーティが変更されるたびにテストを実行します。Coverageはレビューを導くツールですが、1回の記録であるルールがあらゆる場所で安全であると証明することはできません。
可能なら可逆的な設定でリリースしてください。既知の良好なスタイルシートパス、アーティファクトのバージョン、ビルド識別子、復旧方法を記録します。回帰が現れたら、まず互換性のある配信を復元し、その後で見落とした状態を診断してください。SIUはこのワークフローを使って主要パスの安定化を行い、顧客影響が広がる前に対処します。
新しいバナー、同意フロー、ロケール、ブレークポイント、アカウントレイアウトは再生成とテストを必要とします。
互換性のある生成にテンプレートと配信設定を戻してください。公開済みのイミュータブルURLを参照する古いドキュメントを壊さないこと。