クリティカルCSSとは？Shopifyでの効果・実装方法・注意点を公式情報から整理

Shopifyの表示速度を調べると、「レンダリングを妨げるリソース」や「クリティカルCSS」という言葉が出てきます。CSSの読み込み方を見直すことで、ブラウザがページを表示するまでの待ち時間を短縮できるためです。

ただし、クリティカルCSSは、すべてのCSSを非同期で読み込む方法ではありません。初期表示に必要なCSSまで遅らせると、スタイルが適用されていない画面が一瞬表示されるFlash of Unstyled Content（FOUC）や、読み込み後のレイアウトシフトが発生します。また、LCPの原因が画像やJavaScript、サーバー応答にある場合は、CSSだけを変更しても原因は解消しません。

この記事では、2026年8月30日時点のShopify、Chrome、web.devの公式資料をもとに、クリティカルCSSの仕組み、LCPへ効果が出る条件、Shopifyテーマでの対応方法、アプリを使う前に確認したい点を整理します。特定のストアでの検証結果ではなく、実装を判断するための調査結果としてまとめています。

先に結論：初期表示のCSSは残し、画面外のCSSだけを遅らせる

クリティカルCSS対応の要点は、次の3つです。

1. ファーストビューの表示に必要なCSSは、同期的に読み込む
2. スクロール後に使うCSSだけを、計測結果に基づいて遅らせる
3. FCPやLCPだけでなく、CLSと実際の見た目も変更前後で比較する

Shopifyの公式ガイドは、初期表示に使うCSSを同期的に読み込み、非同期読み込みは画面外のセクションへ限定するよう案内しています。Chromeも、初期表示に必要な小さなCSSはインライン化し、不要なリクエストを遅らせる方法を示す一方、CSSのインライン化は不具合を伴う高度な施策であり、多くのサイトでは必須ではないと説明しています。

つまり、PageSpeed Insightsの指摘を消すこと自体が目的ではありません。表示を妨げているCSSを特定し、初期表示を崩さずに読み込み経路を短くできる場合に実施する施策です。

クリティカルCSSとは

クリティカルCSSとは、ページを開いた直後の表示領域を正しく描画するために必要な、最小限のCSSです。ヘッダー、ファーストビューの見出しや画像、最初に表示されるボタンなどのスタイルが該当します。

通常の<link rel="stylesheet">で読み込むCSSは、ブラウザがファイルを取得して解析するまで描画を止めます。これは、スタイルが適用される前の画面を表示しないためのブラウザ本来の動作です。CSSが大きい場合や、複数のCSSファイルが直列に読み込まれる場合は、FCPやLCPが遅れる要因になります。

この待ち時間を減らす方法として、次のような実装があります。

• 初期表示に必要な少量のCSSをHTMLの<style>内へ直接記述する
• 初期表示用のCSSファイルを小さく分け、通常どおり同期的に読み込む
• 画面外のセクションにしか使わないCSSを非同期で読み込む
• ページやセクションごとに、配信するCSS自体を減らす

クリティカルCSSと「CSSのインライン化」は同じ意味ではありません。インライン化は実装手段の一つであり、Shopifyではテーマの構成に合わせて、必要なCSSを同期読み込みのまま残し、不要なCSSを分離する方法も選べます。

参考：Render-blocking requests｜Chrome for Developers

クリティカルCSSがLCP改善につながる条件

LCPは、ページを開いてから、表示領域内で最も大きい画像やテキストが描画されるまでの時間です。web.devでは、良好なLCPの基準を、モバイルとデスクトップに分けたページ読み込みの75パーセンタイルで2.5秒以内としています。

FCPは最初のテキストや画像などが表示されるまでの時間、CLSは読み込み中に発生したレイアウトのずれを表す指標です。クリティカルCSSを評価するときは、LCPだけでなく、初期表示の速さと表示の安定性も確認します。

CSSの最適化が効果を持つのは、HTMLが届いたあと、レンダリングを妨げるCSSによって最初の描画やLCP要素の表示が待たされている場合です。

一方、web.devのLCP改善ガイドでは、LCPを次の4段階に分けて原因を確認しています。

Shopifyも、TTFB、FCP、LCPの間隔から原因を絞り込む方法を案内しています。TTFBは速いのにFCPが遅い場合は、theme.liquid内のCSSや同期JavaScript、アプリが追加したタグなどを確認します。FCPは速くLCPだけが遅い場合は、LCP画像の遅延読み込み、CSS背景画像、JavaScriptによる描画、カルーセルやフェードインなどが主な確認対象です。

参考：Debugging performance with metric gaps｜Shopify

実装前に確認する5つの項目

クリティカルCSSを追加する前に、どの処理が表示を遅らせているかを確認します。

1. 実ユーザーのFCP・LCP・CLS

Shopify管理画面のWeb Performance Dashboardや、PageSpeed Insightsで参照できるChrome UX Report（CrUX）を使い、実際のユーザー環境で問題が出ているページとデバイスを確認します。

実ユーザーのデータは改善対象を決めるために使い、Chrome DevTools、Lighthouse、WebPageTestなどのラボデータは原因の調査と変更前後の比較に使います。Shopifyも、実ユーザーのデータで問題を見つけ、ラボデータで原因を調べ、公開後に実ユーザーのデータで効果を確認する流れを推奨しています。

参考：Lab vs. field data｜Shopify

2. LCPとして計測されている要素

LCP要素が画像なら、loading="lazy"が付いていないか、HTMLから早い段階で発見できるか、表示サイズに対して画像が大きすぎないかを確認します。LCP画像にはfetchpriority="high"を指定できますが、優先度の高いリソースを増やしすぎると互いに競合するため、対象は主要な画像へ限定します。

LCP要素がテキストなら、Webフォントやレンダリングを妨げるCSS、JavaScriptで内容を非表示にしていないかを確認します。

3. 初期描画を妨げているCSS

Chrome DevToolsのPerformanceパネルにある「Render-blocking requests」で、初期描画を待たせているファイルを確認します。Coverageでは、ページ読み込み時に使用されたCSSと未使用のCSSを調べられます。

未使用率が高いという理由だけでファイル全体を遅らせるのではなく、その中にヘッダーやファーストビューで使うスタイルが含まれていないかを確認します。

4. テーマとアプリが追加しているCSS

テーマのCSSだけでなく、Shopifyアプリがストアフロントへ追加したCSSやJavaScriptも確認します。テーマ側で読み込み順を変更できないリソースもあるため、使っていないアプリやアプリブロックを先に整理した方が、変更範囲を小さくできます。

参考：Remove or optimize apps causing render-blocking issues｜Shopify

5. CSSファイルの数と役割

大きなCSSを分割しても、同じページから多数のCSSファイルを読み込めば、解析やスタイル再計算の負担が増えます。共通スタイル、初期表示のスタイル、特定セクションだけのスタイルを整理し、同じファイルをコンポーネントごとに重複して読み込まない構成にします。

Shopifyテーマでの対応方法

{% stylesheet %}によるCSSの自動サブセットを活用する

2026年4月以降、Shopifyは、セクション、ブロック、スニペット内の{% stylesheet %}タグに書かれたCSSを、ページのレンダーツリーに応じて自動的に絞り込んで配信しています。表示していないセクションのCSSを全ページへ送らずに済むため、コンポーネントごとにCSSを管理しているテーマでは、まずこの仕組みを活用できます。

ただし、assetsフォルダ内のCSSをstylesheet_tagで読み込む場合や、通常の<style>、{% style %}内のCSSはサブセットの対象外です。また、あるセクションで定義したクラスを無関係な別のセクションから使う構成では、必要なCSSが配信されないことがあります。shopify theme checkのValidScopedCSSClassで依存関係を確認できます。

参考：Stylesheet content subsetting｜Shopify

画面外のセクションだけCSSを非同期で読み込む

assets内のCSSをセクション単位で読み込む場合は、Shopifyが案内するsection.indexを使い、画面上部と画面外で読み込み方を分けられます。

{% unless section.index > 3 %}
  {{ 'section.css' | asset_url | stylesheet_tag }}
{% else %}
  <link
    rel="stylesheet"
    href="{{ 'section.css' | asset_url }}"
    media="print"
    onload="this.media='all'"
  >
  <noscript>{{ 'section.css' | asset_url | stylesheet_tag }}</noscript>
{% endunless %}

この例では、上から3つまでのセクションと、section.indexを取得できない場面ではCSSを同期的に読み込み、4つ目以降はmedia="print"で優先度を下げます。読み込み完了後にmediaをallへ変え、通常のスタイルとして適用します。JavaScriptを利用できない環境に備え、noscriptも残します。

「3セクション」は公式コード例で使われている目安です。ヘッダーの高さ、各セクションの大きさ、端末の表示領域によって、スクロール前に見える範囲は変わります。対象テーマをモバイルとデスクトップで確認し、初期表示に入る可能性があるセクションは同期読み込みにします。

クリティカルCSSをインライン化する

初期表示に必要なCSSが少なく、外部CSSのリクエストが明確なボトルネックになっている場合は、必要なルールを<head>内へインライン化できます。外部ファイルの取得を待たずに描画できますが、HTMLのサイズが増え、同じCSSをページごとに再送することになります。

レスポンシブ表示、テーマ設定、言語、告知バーの有無などによってファーストビューの構成が変わるShopifyでは、抽出したCSSがすべての状態をカバーしているか確認が必要です。インラインCSSと元のCSSを二重に管理すると更新漏れも起きるため、生成や更新の手順まで含めて設計します。

なお、ShopifyはCSSとJavaScriptを自動的に圧縮して配信します。圧縮は転送量を減らす仕組みであり、初期表示に必要なCSSを選ぶクリティカルCSSとは目的が異なります。

参考：The Shopify platform｜Shopify

Shopifyアプリで対応する場合の判断基準

2026年8月30日時点で、Shopify App Storeの説明にクリティカルCSS対応を明記しているアプリとして、次の例を確認できます。

表はApp Store上の機能説明を整理したもので、導入による改善値を示すものではありません。テーマ構成、アプリ、コンテンツ、ユーザーの端末によってボトルネックが異なり、アプリの説明だけではLCPの改善効果を判断できません。

アプリを導入する場合は、次の点を確認します。

• テーマへ追加・変更するファイルとコードを確認できるか
• アプリを無効化、または削除したときに元へ戻せるか
• テーマ更新後にクリティカルCSSを再生成する必要があるか
• 商品、コレクション、固定ページなど、テンプレートごとの差を扱えるか
• モバイルとデスクトップのファーストビューを正しく判定できるか
• 導入前後のFCP、LCP、CLSと画面の変化を比較できるか
• 既存の最適化アプリと同じ処理を重複していないか

PageSpeed Insightsのスコアだけでなく、FOUC、レイアウトシフト、テーマエディタでの表示、カートや検索などの機能も確認します。アプリによる自動化は、原因調査と変更後の検証を省略する仕組みではありません。

実装後はFCP・LCP・CLSをセットで確認する

CSSの非同期化はFCPやLCPを短縮しても、スタイルの適用が遅れてCLSを悪化させることがあります。Shopifyの公式ガイドでは、Dawnテーマで初期表示内のCSSを非同期化していた箇所を同期読み込みへ戻した結果、CLSが0.065からほぼ0まで、95％改善した例が紹介されています。

変更後は、次の順番で確認します。

1. 同じページ、端末、通信条件で複数回計測する
2. FCP、LCP、CLSの変更前後を比較する
3. Chrome DevToolsのフィルムストリップでFOUCと表示のずれを確認する
4. 商品、コレクション、固定ページなど主要テンプレートを確認する
5. 公開後にShopify Web Performance DashboardやCrUXの実ユーザーデータを確認する

ラボデータの1回のスコアだけで結論を出さず、複数回の中央値と、公開後に蓄積される実ユーザーのデータを使います。クリティカルCSS対応で数値が変わらない場合は、そのページのボトルネックがCSS以外にあると判断し、LCP画像、JavaScript、アプリ、サーバー応答の調査へ戻ります。

表示速度以外も含めた確認項目は、「AIコーディングで作ったWebサイトの品質チェックリスト」にまとめています。

クリティカルCSSより先に改善したいケース

次の状態では、CSSの抽出やインライン化よりも、原因へ直接対応する方が効果的です。

• LCP画像にloading="lazy"が指定されている
• LCP画像がJavaScript実行後に追加される
• LCP画像をCSSのbackground-imageで読み込んでいる
• ファーストビューをフェードインやカルーセルの初期化まで非表示にしている
• 使用していないアプリのCSSやJavaScriptが全ページで読み込まれている
• 同じCSSファイルをセクションやカードごとに重複して読み込んでいる
• TTFBが長く、HTMLが届くまでに時間がかかっている

LCPは複数の時間から構成されます。最も大きい遅延を特定してから施策を選ぶことで、必要のない複雑な実装を増やさずに済みます。

よくある質問

クリティカルCSSを導入すればLCPは必ず改善しますか？

レンダリングを妨げるCSSがLCPを遅らせている場合に効果があります。LCP画像の読み込み、JavaScript、TTFBなどが原因の場合は、その処理を改善します。実装前にLCP要素とネットワークの読み込み順を確認することが先です。

CSSはすべて非同期で読み込んだ方が速くなりますか？

初期表示に使うCSSは同期的に読み込みます。必要なCSSまで非同期化すると、スタイルがない状態の表示やレイアウトシフトが発生します。非同期化するのは、スクロール後に使うCSSなど、初期表示に不要な部分です。

ShopifyではクリティカルCSSを手動で作る必要がありますか？

すべてのテーマに必要な施策ではありません。{% stylesheet %}によるCSSの自動サブセット、不要なアプリの整理、LCP画像の読み込み改善で十分な場合もあります。初期描画を妨げるCSSが残り、変更前後を計測できる場合に、CSSの分割やインライン化を検討します。

PageSpeed Insightsの警告が消えれば対応完了ですか？

警告の解消だけでは判断できません。FCP、LCP、CLS、FOUC、主要機能の動作を確認し、公開後は実ユーザーのデータで効果を確認します。Chromeも、CSSのインライン化は不具合を招くことがあり、多くのサイトでは推奨値を満たすための必須施策ではないと説明しています。

まとめ

クリティカルCSSは、初期表示に必要なCSSを優先し、画面外のCSSを読み込み経路から外すための考え方です。Shopifyで対応する場合も、すべてのCSSを非同期化するのではなく、ファーストビューに使うCSSを同期的に読み込み、画面外のCSSだけを計測後に遅らせます。

実装前には、実ユーザーのFCP・LCP・CLS、LCP要素、レンダリングを妨げているCSS、アプリが追加したリソースを確認します。Shopifyの{% stylesheet %}による自動サブセットや、セクション単位のCSS管理で配信量を減らしたうえで、必要なページに限って非同期読み込みやインライン化を検討する順番が自然です。

クリティカルCSSは、LCPを改善するための選択肢の一つです。数値上の警告を消すことよりも、ボトルネックに合った施策を選び、表示の安定性を含めて変更前後を確認することが重要です。