Google PageSpeedはしばしば CSS配信を最適化する を提案します。次のようにすべてのCSSをインライン化することで、ネットワークの往復を減らすことができました。
<style type="text/css">
@{
var bootstrap = File.ReadAllText(Server.MapPath("bootstrap.min.css"));
var bootstrapTheme = File.ReadAllText(Server.MapPath("theme.min.css"));
var fontAwesome = File.ReadAllText(Server.MapPath("font-awesome.min.css"));
var bigfont = File.ReadAllText(Server.MapPath("bigfont.min.css"));
var bigfontPrint = File.ReadAllText(Server.MapPath("bigfont-print.min.css"));
}
@Html.Raw(bootstrap)
@Html.Raw(bootstrapTheme)
@Html.Raw(fontAwesome)
@Html.Raw(bigfont)
@Html.Raw(bigfontPrint)
</style>
これはページの読み込みが遅いという問題に対する妥当な解決策のようで、PageSpeedスコアが88から95に増えました。
とりあえずコードスタイルを別にして、このようにすべてのCSSをインライン化しないことの技術的な理由があるとすれば、どのようなものでしょうか。
すべてのCSSをインライン化すると、キャッシュできないため、1つのページの読み込みごとに必要なCSSがすべて含まれます。また、大きなライブラリを使用している場合は、帯域幅を大量に浪費する可能性があります。たとえば、Bootstrapは約120kです。共有したGoogleリンクは次のように指定しています(強調は私のものです):
外部CSSリソースが小さい場合、インライン化と呼ばれるHTMLドキュメントに直接それらを挿入できます。
そのため、単一のページの読み込みは速くなる可能性がありますが、全体的に遅くなる可能性があります。
個人的に私はそうすることを避けます。ただし、できることの1つは、すべてのCSSを単一の要求にバンドルすることです(MVCを使用しているため、比較的簡単です)。CSSと、ブラウザは再度要求する必要はありません。
このテクニックの意図された使用例について誰も言及していません。これは、CSSの100%をロードすることは絶対にありません。むしろ、この手法は、ユーザーがthinkページをより速くロードできるようにすることを目的としています。
ページの読み込みを高速化することについて説明する場合、実際の目標は、一般にページの読み込みを高速に見せることです。ユーザーエクスペリエンスの観点からは、これは実際にロードにかかる時間を短縮することよりもはるかに重要です。人間がとにかく速くそれを解析することができないので、ページ全体がロードするのに500msかかるかどうかは問題ではありません。重要なのは、ページが読み込まれたように見える速さです。
したがって、この手法の適切な使用法は、ページを適切にレンダリングするために絶対に不可欠なCSSを即座にロードすることです。つまり、画像を適切なサイズにし、物事を正しくフロートにし、Facebook SDKがビジネスを終了する間、ページコンテンツがページを飛び回る恐ろしい外観を回避するCSSルールがいくつかあります。そのコードは、マークアップが読み込まれると同時に存在する必要があります。解決策:その重要なCSSをインライン化します。
ただし、CSSのすべてをインライン化しないでください。それでもcssが非同期的に読み込まれているコンテンツのみをスタイルする場合、後で読み込まれる別の100kbが存在する可能性があります。ただし、25ミリ秒後に正しい形式でなければならないページ構造がある場合は、そのCSSをインライン化する必要があります。
PageSpeedの提案を誤解しました。推奨事項は、小さなCSSファイルです。
外部CSSリソースが小さい場合は、インライン化と呼ばれるHTMLドキュメントに直接挿入できます。 [...] CSSファイルが大きい場合、CSSを完全にインライン化すると、PageSpeed Insightsが、ページのスクロールせずに見える部分が[可視コンテンツの優先順位付け]で大きすぎることを警告することがあります。
実際、この記事では後で、大規模なCSSファイルに対するバランスのとれたアプローチを提案しています。重要なCSSをインライン化し、残りのCSSファイルを遅延ロードします。
大きなCSSファイル*をインライン化した後でPageSpeedが適切なスコアを与えたとしても、それは悪い考えかもしれません。
インラインCSSファイルは、ページ間で<style>...</style>
タグを複製することを意味します。つまり、後続のページビューまたは繰り返しページビューに冗長データを提供します。冗長データは帯域幅を消費し、ダウンロード時間を増加させます。
個別のCSSファイルと強力なキャッシングヘッダーにより、冗長性を排除できます。キャッシングヘッダーは、最初のページビューでCSSファイルをキャッシュし、後続のページビューまたは繰り返しページビューで再利用するようにブラウザーに指示します。
インラインCSSファイルは、ページ上の「実際の」コンテンツの割合を減らします。インラインCSSファイルでは、CSSをコンテンツの上に挿入する必要がありますが、私たちのほとんどは、実際のコンテンツを上部のHTMLの近くに配置するよう努めています。
インラインCSSは、JavaScriptや画像などの他のリソースをダウンロードする前に、ブラウザーに追加のバイトをダウンロードさせます。
HTMLページが動的に生成される場合、ほとんどの場合、非圧縮で提供されます。一部のサーバー(IISなど)およびソフトウェア(Wordpressなど)では、動的コンテンツの圧縮が可能ですが、静的コンテンツ(CSSファイルなど)の圧縮と比較して、より多くのCPU +メモリが必要です。これは、CSSを別のファイルに保存する必要があるもう1つの理由です。
上記の理由により、1ページのWebサイトであっても、CSSを結合、縮小、圧縮、およびキャッシュし、別のファイルに保存します。
* インラインスタイル と混同しないでください
コメントには長すぎます。そこで私が働いている場所では、 Content Security Policy ヘッダーディレクティブ(具体的にはstyle-src
)インラインCSSの使用を明示的に禁止します。この場合にインラインCSSを使用しない理由は、動的に作成されたページのCSSインジェクションのリスクを最小限に抑えることです。 OWASPには、エクスプロイトサンプルを含むこのトピックに関する詳細情報があります: https://www.owasp.org/index.php/Testing_for_CSS_Injection_(OTG-CLIENT-005) 。静的コンテンツのみがブラウザーに提供される場合、リスクはありません。