知っておくべき CSS パフォーマンス最適化の 8 つのヒント

この記事では、CSS のパフォーマンスを最適化するための 8 つのヒントを紹介します。一定の参考値があるので、困っている友達が参考になれば幸いです。

Web サイトにとってパフォーマンスが重要であることは誰もが知っています。CSS は、ページのレンダリングとコンテンツのプレゼンテーションの重要な部分として、Web サイト全体のユーザーの最初のエクスペリエンスに影響を与えます。したがって、それに伴うパフォーマンスの最適化は無視できません。

私たちは、プロジェクトが完了したときにのみパフォーマンスの最適化を検討することがよくあります。多くの場合、プロジェクトの終了まで延期されるか、重大なパフォーマンスの問題が明らかになった場合でも、ほとんどの人がこのことを深く理解していると思います。

著者は、この状況を回避するには、まずパフォーマンスの最適化に関連する作業に注目し、それを製品の設計と開発全体に組み込む必要があると考えています。 2 つ目は、パフォーマンスに関連する内容を理解し、プロジェクトの開発プロセス中にパフォーマンスの最適化を自然に実行できるようにすることです。最後に、そして最も重要なことですが、今すぐ最適化を開始してください。

Qiwu Weekly が以前推奨した記事「Web パフォーマンス最適化マップをあげます」1 を読むことをお勧めします。これは、何を行う必要があるのか​​、何を行う必要があるのか​​を理解するのに役立ちます。パフォーマンスの最適化には問題を考慮する必要があります。全体的な概念
。
この記事では、CSS のパフォーマンス最適化に関するテクニックを実践的なものと推奨的なものの 2 つのカテゴリーに分けて、合計 8 つのヒントとともに詳しく紹介します。実践的なテクニックはプロジェクトにすぐに適用でき、パフォーマンスを大幅に向上させることができます。これらは著者も頻繁に使用するものであり、全員ができるだけ早くプロジェクトで実践することをお勧めします。提案されたテクニックの中には、パフォーマンスに大きな影響を与えないものや、誰もが使用できるわけではないものもありますので、ここでは取り上げませんが、読者はそれぞれの状況に基づいてそれらについて学ぶことができます。 (学習ビデオ共有: css ビデオ チュートリアル)

正式に開始する前に、全員がブラウザ 2 の動作原理をある程度理解する必要があります。それが必要な友人は、最初に簡単に理解することができます。 。

最初の画面の主要な CSS から始めて、4 つの実践的な最適化テクニックを見てみましょう。

1. インラインの最初の画面の重要な CSS

パフォーマンスの最適化には重要な指標があります - 最初の効果的な描画 ( First Meaningful Paint (FMP for short) は、ページの主要なコンテンツが画面に表示される時間を指します。この指標は、ユーザーがページを表示するまでに待機する必要がある時間に影響し、インライン クリティカル CSS (Critical CSS、最初の画面ではクリティカル CSS と呼ぶこともできます) によってこの時間を短縮できます。

誰もが、リンク タグを介して外部 CSS ファイルを参照することに慣れているはずです。ただし、知っておく必要があるのは、CSS を HTML ドキュメントに直接インライン化すると、CSS のダウンロードが高速になるということです。外部 CSS ファイルを使用する場合は、HTML 文書をダウンロードした後に参照する CSS ファイルを把握してダウンロードする必要があります。したがって、 インライン CSS は、HTML のダウンロードが完了した後にレンダリングできるため、ブラウザーがページのレンダリングを より早く開始できるようになります。

インライン CSS はページレンダリングの開始時間を早めることができるため、すべての CSS をインライン化できますか?答えは明らかに「ノー」です。この方法は、より大きな CSS ファイルをインライン展開するのには適していません。初期輻輳ウィンドウ 3 (TCP 関連の概念、通常は 14.6kB、圧縮サイズ) には制限があるため、インライン CSS 後のファイルがこの制限を超える場合、システムはサーバーとブラウザの間でさらにラウンドを行う必要があります。トリップしても、ページのレンダリング時間は短縮されません。したがって、スクロールせずに見えるコンテンツ を HTML にレンダリングするために必要な重要な CSS のみを インライン化する必要があります。

最初の画面のインライン キー CSS がパフォーマンスを最適化できることがわかったので、次のステップは最初の画面のキー CSS を決定する方法です。明らかに、どのコンテンツがスクロールせずに見える部分の重要な CSS であるかを手動で判断する必要はありません。 Github には、最初の画面に属する主要なスタイルを抽出できる Critical CSS4 というプロジェクトがあり、これを参照して独自のビルド ツールで使用することができます。もちろん、正確性を確保するために、抽出されたコンテンツが欠落していないかどうかを個人的に確認することが最善です。

ただし、インライン CSS には欠点があり、インライン後の CSS はキャッシュされず、毎回再ダウンロードされることになります。ただし、前述したように、インラインファイルのサイズを 14.6kb 以内に制御すれば、大きな問題はないと思われます。

以上、キーCSSをインライン化する必要がある理由とインライン化方法を紹介しましたが、残りのCSSはどうすればよいのでしょうか？外部 CSS を使用して残りの CSS を導入し、非同期でロードするだけでなくキャッシュを有効にすることをお勧めします。

2. CSS

CSS の非同期読み込みによりレンダリングがブロックされます。CSS ファイルのリクエスト、ダウンロード、解析が完了するまで、ブラウザーは処理されたコンテンツをレンダリングしません。 。必要な CSS が読み込まれる前にブラウザーがページのレンダリングを開始しないようにするために、このブロックが必要になる場合があります。最初の画面の主要な CSS がインライン化された後は、残りの CSS コンテンツのレンダリングをブロックする必要がなくなり、外部 CSS を使用して非同期に読み込むことができます。

それでは、CSS の非同期読み込みを実装するにはどうすればよいでしょうか?ブラウザによる CSS
の非同期読み込みを実装するには 4 つの方法があります。
最初の方法は、JavaScript を使用してスタイル シートのリンク要素を動的に作成し、それを DOM に挿入する方法です。

// 创建link标签
const myCSS = document.createElement( "link" );
myCSS.rel = "stylesheet";
myCSS.href = "mystyles.css";
// 插入到header的最后位置
document.head.insertBefore( myCSS, document.head.childNodes[ document.head.childNodes.length - 1 ].nextSibling );

2 番目の方法は、link 要素の media 属性を、ユーザーのブラウザが一致しないメディア タイプ (またはメディア クエリ) (media= など) に設定することです。 "print"、または完全に存在しないタイプ media="noexist" であっても。ブラウザの場合、スタイル シートが現在のメディア タイプに適していない場合、その優先順位は低くなり、ページのレンダリングをブロックせずにダウンロードされます。

もちろん、これは CSS の非同期読み込みを実現するためだけです。ブラウザが CSS の解析を開始できるように、ファイルの読み込み後に media の値を screen または all に設定することを忘れないでください。

<link rel="stylesheet" href="mystyles.css" media="noexist" onload="this.media=&#39;all&#39;">

2 番目の方法と同様に、rel 属性を通じてリンク要素を代替のオプションのスタイル シートとしてマークすることもできます。これにより、ブラウザによる非同期読み込みも実現できます。また、ロードが完了したら、rel を元に戻すことを忘れないでください。

<link rel="alternate stylesheet" href="mystyles.css" onload="this.rel=&#39;stylesheet&#39;">

上記の 3 つの方法は比較的古いものです。現在、Web 標準 rel="preload"5 は、CSS のようなリソースを含むリソースを非同期で読み込む方法を示しています。

<link rel="preload" href="mystyles.css" as="style" onload="this.rel=&#39;stylesheet&#39;">

as は必須であることに注意してください。 as 属性を無視するか、間違った as 属性を使用すると、プリロードが XHR リクエストと同等になります。ブラウザはどのコンテンツがロードされているかを認識しないため、そのようなリソースのロード優先度は非常に低くなります。 as のオプションの値は、上記の標準ドキュメントを参照できます。

rel="preload" の使用法は上の 2 つと変わらないようです。どちらも特定の属性を変更して、ブラウザーが CSS ファイルを非同期で読み込みますが、読み込みが完了するまで解析しないようにします。変更が復元され、解析が開始されます。

しかし、実際にはこれらの間には非常に重要な違いがあります。つまり、プリロードを使用すると、一致しないメディア メソッドを使用するよりも早く CSS の読み込みを開始できるということです。したがって、この標準のサポートはまだ完全ではありませんが、この方法を優先的に使用することをお勧めします。
この標準は現在標準の候補であり、ブラウザーが徐々にサポートすることになると思います。各ブラウザのサポート状況は下図のとおりです。

3. ファイル圧縮

パフォーマンスを最適化するときに考えられる最も簡単で最も一般的に使用される方法の 1 つはファイル圧縮であり、このソリューションは多くの場合効果的です。
ファイルのサイズはブラウザの読み込み速度に直接影響します。これは、ネットワークが貧弱な場合に特に顕著です。 CSS の圧縮にはすでに慣れていると思いますが、Webpack、gulp/grunt、rollup などの構築ツールも CSS 圧縮機能をサポートしています。圧縮ファイルを大幅に縮小できるため、ブラウザの読み込み時間を大幅に短縮できます。

4. 不要な CSS を削除します

ファイル圧縮によりファイル サイズを削減できます。ただし、CSS ファイルの圧縮では通常、無駄なスペースが削除されるだけなので、CSS ファイルの圧縮率が制限されます。 CSSを合理化する他の方法はありますか?答えは明らかに「はい」です。圧縮ファイルが依然として予想サイズを超えている場合は、コード内の不要な CSS を見つけて削除することができます。

一般に、役に立たない CSS コードには 2 つのタイプがあります。1 つは、異なる要素またはその他の状況で繰り返されるコードであり、もう 1 つはページ全体で効果を発揮しない CSS コードです。前者については、コードを記述するときに、重複を減らすために可能な限りパブリック クラスを抽出する必要があります。後者については、複数の開発者がコードをメンテナンスしていく過程で必ず使われなくなったCSSコードが生成されますが、もちろん一人で書いた場合にもこの問題は発生する可能性があります。これらの役に立たない CSS コードは、ブラウザのダウンロード量を増加させるだけでなく、ブラウザの解析時間も増加させ、パフォーマンスを大幅に低下させます。したがって、これらの無駄なコードを見つけて削除する必要があります。

もちろん、これらの役に立たない CSS を手動で削除するのは非常に非効率です。これは、Uncss7 ライブラリを利用して行うことができます。 Uncss を使用すると、スタイル シートから不要な CSS を削除でき、複数ファイルと JavaScript を挿入した CSS がサポートされます。

実践的な 4 つの最適化手法についてはすでに説明しましたが、ここでは、推奨される 4 つの手法を紹介します。

1. セレクターを選択的に使用する

CSS セレクターのマッチングは右から左に実行されることをほとんどの友人は知っているはずです。この戦略は、種類によってパフォーマンスの違いもあります。セレクターの。 #markdown-content-h3 と比較すると、 #markdown .content h3 を使用するとブラウザがレンダー ツリーを生成するのに明らかに時間がかかります。後者では、まず DOM 内のすべての h3 要素を検索し、次に .content ではない祖先要素をフィルターで除外し、最後に #markdown ではない .content の祖先をフィルターで除外する必要があるためです。想像してみてください。ページ上のネスト レベルや要素が増えると、マッチングにかかる​​時間コストは当然高くなります。

ただし、最新のブラウザではこの点で多くの最適化が行われており、異なるセレクター間のパフォーマンスの違いは明らかではないか、非常に小さい場合さえあります。さらに、異なるブラウザーの異なるセレクターのパフォーマンスは完全に均一ではなく、CSS を記述するときにすべてのブラウザーを考慮することは不可能です。これら 2 つの理由を考慮すると、セレクターを使用する場合は次の点だけを覚えておく必要があり、残りは完全に好みに基づいて問題ありません。

• シンプルさを保ち、ネストされすぎた過度に複雑なセレクターは使用しないでください。

• ワイルドカードと属性セレクターは効率が最も低く、最も一致する要素を必要とするため、使用は避けてください。

• h3#markdown-content などの要素タグを変更するためにクラス セレクターと ID セレクターを使用しないでください。これは不必要であり、効率が低下します。

• 速度を追求するために、可読性と保守性を放棄しないでください。

上記の点についてまだ疑問がある場合は、次の CSS 方法論 (BEM9、OOCSS10、SUIT11、SMACSS12、ITCSS13、Enduring CSS14 など) のいずれかを選択することをお勧めします。 )をCSSの記述仕様として記載します。統一された方法論を使用すると、全員が統一されたスタイルを形成し、名前の競合を減らし、上記の問題を回避するのに役立ちます。つまり、多くの利点があります。まだ使用したことがない場合は、すぐに使用を開始してください。

ヒント: CSS セレクターはなぜ右から左に一致するのでしょうか?

CSS 内のセレクターがさらに多くなると一致しなくなるため、パフォーマンスの問題を考慮する場合、考慮する必要があるのは、セレクターが一致しない場合に効率を向上させる方法です。右から左に一致させることでこの目的を達成することができ、この戦略により、一致しない場合の CSS セレクターの効率を高めることができます。このように考えると、マッチング中にパフォーマンスをより多く消費するのは理にかなっています。

2. 高価なプロパティの使用を削減する

ブラウザが画面を描画するときに、ブラウザの操作や計算を必要とするすべてのプロパティは相対的に必要になります。もっと。ページの再描画が発生すると、ブラウザのレンダリング パフォーマンスが低下します。したがって、CSS を記述するときは、box-shadow/border-radius/filter/transparency/:nth-child などの高価なプロパティの使用を減らすように努める必要があります。

もちろん、これは誰もがこれらの属性を使用すべきではないという意味ではありません。これらは私たちが頻繁に使用する属性であるはずだからです。私がこのことを申し上げる理由は、このことを皆さんに理解していただくためです。選択肢が 2 つある場合、高価な属性がない方を優先するか、高価な属性が少ない方を優先するかを毎回選択すると、無意識のうちに Web サイトのパフォーマンスが向上します。

3. リフローと再描画を最適化する

Web サイトの使用中、特定の操作によりスタイルが変更されるため、ブラウザーはこれらの変更を検出する必要があります。レンダリングの一部はパフォーマンスが高くなります。 FPS が 60 であれば、ユーザーは Web サイトを快適に使用できることは誰もが知っています。これは、各レンダリングに関連するすべての操作を 16.67 ミリ秒以内に完了する必要があることを意味するため、よりコストのかかる操作を最小限に抑える必要があります。

3.1 リフローの削減

リフローにより、ブラウザはドキュメント全体を再計算し、レンダリング ツリーを再構築します。このプロセスにより、ブラウザのレンダリング速度が低下します。以下に示すように、再スケジュールをトリガーする操作は多数あり、これらの操作を頻繁にトリガーすることは避ける必要があります。

• フォント サイズとフォント ファミリーを変更する

• 要素の内側と外側のマージンを変更する

• JS を介して CSS クラスを変更します

• JS を介して DOM 要素の位置関連の属性 (幅/高さ/左など) を取得します

• CSS 疑似クラス Activate

• スクロール バーをスクロールするか、ウィンドウ サイズを変更します

さらに、次のこともできます。また、どのプロパティが CSS Trigger15 を通じてリフローと再描画をトリガーするかをクエリします。

一部の CSS プロパティはリフロー パフォーマンスが優れていることに言及する価値があります。たとえば、Flex を使用すると、inline-block や float を使用する場合よりもリフローが高速になるため、レイアウト時に Flex を優先できます。

3.2 不必要な再描画を回避する

要素の外観 (色、背景、可視性、その他の属性など) が変更されると、再描画がトリガーされます。 Webサイトを利用していく上で、再描画は避けられません。ただし、ブラウザーはこれを最適化し、複数のリフロー操作と再描画操作を 1 回の実行にマージします。ただし、ページのスクロール時にトリガーされる hover イベントなど、不必要な再描画を避ける必要があります。スクロール時に hover イベントを無効にすると、ページがよりスムーズにスクロールされます。

さらに、CSS でアニメーション関連のコードを記述することが多くなり、ユーザー エクスペリエンスを向上させるためにアニメーションを使用することに慣れています。アニメーションを作成する場合は、再描画や再配置のトリガーを減らすために、上記の内容も参照する必要があります。また、ハードウェア アクセラレーション 16 と will-change17 によってアニメーションのパフォーマンスも向上します。この記事では詳しく紹介しませんが、興味のある方はリンクをクリックしてご覧ください。

最後に、ユーザーのデバイスは想像ほど優れていない可能性があり、少なくとも開発マシンほど優れていない可能性があることに注意してください。 Chrome の開発者ツールを使用して CPU の速度を下げ、関連テストを実施できます。

モバイル側でアクセスする必要がある場合は、モバイルのパフォーマンスが低下するため、速度制限を低く設定することをお勧めします。側が悪い場合が多いです。

4. @import を使用しないでください

最後に、CSS の導入に @import を使用しないでください。誰もが @import を使用することはほとんどないと思います。

@import の使用は主に次の 2 つの理由により推奨されません。

まず、@import を使用して CSS を導入すると、ブラウザの並列ダウンロードに影響します。 @import を使用して参照される CSS ファイルは、その CSS ファイルを参照する CSS ファイルがダウンロードされた後に、ダウンロードして解析する必要がある別の CSS ファイルがあることのみを認識し、それをダウンロードし、解析、レンダー ツリーの構築などを開始します。ダウンロード後の一連の操作です。その結果、ブラウザは必要なスタイル ファイルを並行してダウンロードできなくなります。

第 2 に、複数の @import により、ダウンロードの順序が乱れます。 IE では、@import によりリソース ファイルのダウンロード順序が乱れます。つまり、@import の後にリストされている js ファイルが @import より前にダウンロードされ、@import 自体の並列ダウンロードが中断され、さらには破壊されます。

したがって、この方法は使用せず、リンク タグを使用してください。

プログラミング関連の知識について詳しくは、プログラミング教育をご覧ください。 ！

以上が知っておくべき CSS パフォーマンス最適化の 8 つのヒントの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。