ページのレンダリングの詳細な分析_html/css_WEB-ITnose

基本的なレンダリング プロセス

ユーザーが要求したリソースがブラウザのネットワーク層を介してレンダリング エンジンに到達すると、レンダリング作業が開始されます。通常、各レンダリング ドキュメントは 8K データ ブロックを超えません。基本的なレンダリング プロセスは次のとおりです。

ステップ 1: レンダリング エンジンはまず HTML ドキュメントを解析し、DOM ツリーに変換します。インライン、外部、埋め込みのいずれであるかに関係なく、導入された CSS スタイルが解析され、DOM ツリーのレンダリングに使用される別のツリー (レンダー ツリー) がレンダリングされます。レンダー ツリーには、 color 、 size 、およびその他の表示属性が含まれます。

ステップ 3: 次に、レンダリング ツリーの各ノードでレイアウト処理を実行して、画面上の表示位置を決定します。レンダリング ツリーを作成し、前の章で説明した UI バックエンド レイヤーを使用して各ノードを描画します。

上記の手順は段階的なプロセスであり、ユーザー エクスペリエンスを向上させるために、レンダリング エンジンはできるだけ早く結果をエンド ユーザーに表示しようとします。すべての HTML が解析されるまで待機せずに、レンダー ツリーを作成してレイアウトします。ネットワーク層から文書コンテンツを取得しながら、受信した部分コンテンツを最初に表示します。

レンダリング エンジンが異なれば、レンダリング プロセスも異なります

上記では、レンダリング エンジンの一般的な処理フローを紹介しているだけです。具体的な手順は、一般的な Webkit と gecko を例に挙げます。

最初は、Webkit の詳細なレンダリング プロセスです:

Firefox などのブラウザの gecko レンダリング プロセス:

上の 2 つの図からわかるように、2 つは異なる「専門用語」を使用していますが、この図からわかるように、2 つのレンダリング プロセスは非常に似ています。だからこそ、特定のプロセスを分離することができます。

では、効率的な CSS コードを記述するにはどうすればよいでしょうか?この質問の前に、コードの非効率的な記述方法を見てみましょう:

a. ワイルドカードを使用する

body * {...}hide-scrollbars * {...}

b. タグをキーセレクターとして使用する

ul li a {...} #footer h3 {...} * html #atticPromo ul li a {...}

c. :hover 疑似を追加する-class を非接続タグに追加すると、IE7 および IE8 では厳密な doctype を使用するページが非常に遅くなります。

そうです

なぜ効率的にならないのですか?

まず、ブラウザが HTML コードを解析するプロセスを理解します。つまり、dom ツリーを構築し、ページに表示される各要素がこの dom ツリーに作成されます。新しい要素が DOM ツリーに追加されるたびに、ブラウザは CSS エンジンを通じて CSS スタイル シートを検索し、要素に一致するスタイル ルールを見つけて要素に適用します。 CSS エンジンはスタイル シートを検索し、各ルールを右から左に照合します。

プロセスを理解すると、CSS コードは次の 2 つの側面から最適化できることがわかります。

1. 定義されている CSS スタイル ルールは少ないほど良いため、CSS ファイル内の不要なスタイル定義をすぐに削除します。各ルールのセレクターの記述方法を最適化し、このルールを現在の要素に適用する必要があるかどうかを CSS エンジンに一目で知らせるようにして、エンジンが不必要な迂回を回避できるようにします。

最適化の提案:

a、ワイルドカードの使用を避けます。

b、ルールが現在の要素に適用されるかどうかを CSS エンジンに迅速に識別させます。使用する ID またはクラス セレクターを増やし、タグ セレクターを減らします。余計なことをする場合は、id と class または label と class を連続して記述してください。

d、不要な祖先要素を削除するために子孫セレクターを使用しないようにしてください。子孫セレクターを置き換えるためにクラス セレクターを使用することを検討してください。回避 :hover 疑似クラスを接続されていないタグに追加します。

次に、次の点に注意する必要があります:

まず、CSS 式の使用を避けてください

CSS 式は、ページのパフォーマンスに重大な影響を与えるため、IE ブラウザーでのみ機能します。Microsoft は、IE8 以降の使用を推奨していません。 : ウィンドウのサイズ変更イベント、マウスの移動などのイベントがトリガーされるたびに、CSS 式が再計算されます。

2 番目に、CSS ファイルをページの上部に配置します

外部スタイル シートまたはインライン スタイル シートを本文部分に配置すると、ページのレンダリングの速度に影響します。これは、ブラウザはスタイルをすべて変更した後のみページの他のコンテンツのダウンロードを続けるためです。シートがダウンロードされました。さらに、インライン スタイル シート (c9ccee2e6ea535a969eb3f532ad9fe89 内に配置されたスタイル) により、ページが再レンダリングされたり、ページ内の特定の要素が表示または非表示になったりする可能性があります。インライン スタイル シートは使用しないことをお勧めします。

3 番目に、ページ画像のサイズを指定します

ページ画像のサイズを指定します。これは、画像の実際のサイズに準拠する必要があります (サイズを指定して画像を拡大縮小しないでください)。これにより、ページ構造効果の変更を回避できます。サイズの変更によって引き起こされるため、ページのレンダリングが高速化されます。

4、ページのヘッダーにドキュメントのエンコーディングを指定します

HTML ドキュメントは、ドキュメントのエンコード情報を含むデータ ストリームでネットワーク上に送信されます。ページのエンコード情報は通常、HTTP 応答のヘッダー情報またはドキュメント内の HTML マークアップで指定されます。クライアント ブラウザは、ページ エンコーディングを決定した後でのみページを正しくレンダリングできます。そのため、ほとんどのブラウザ (IE6、IE7、および IE8 を除く) は、ページを描画する前、または JavaScript コードの検索を実行する前に、一定のバイト数のデータをバッファします。ブラウザごとに事前バッファされるバイト数は異なります。ブラウザは、設定された量の事前バッファされたデータを受信した後にページのエンコード情報を見つけられなかった場合、この時点でページのエンコード情報が再度取得された場合、各ブラウザによって指定されたデフォルトのエンコードに従ってページのレンダリングを開始します。 、現在使用されているエンコーディングと同じではありません。一貫性がない場合は、ページ全体を再レンダリングする必要があり、場合によってはデータを再取得する必要があります。したがって、サイズが 1KB を超えるページ (さまざまなブラウザーでのテストによると、事前バッファリングされるデータの最大量は 1KB です) については、できるだけ早くエンコード情報を示す必要があります。