Clever Geek Handbook

Webページのレンダリング：フロントエンド開発者が知っておくべきこと

親愛なるハブラビテス、私はあなたを歓迎します！ 今日は、Web開発におけるレンダリングの問題に焦点を当てたいと思います。 もちろん、このトピックに関する多くの記事が既に書かれていますが、私には思えたように、すべての情報はかなり断片的で断片的です。 少なくとも、頭の中の全体像を収集して理解するためには、多くの情報（主に英語）を分析する必要がありました。 そのため、記事で知識を形式化し、その結果をHabrコミュニティと共有することにしました。 この情報は、初心者のWeb開発者と経験豊富なWeb開発者の両方が知識を更新して構造化するのに役立つと思います。



明らかに、レイアウト、スタイル、およびスクリプトがレンダリングに直接関係するため、この方向はレイアウト/フロントエンド開発の段階で最適化できます。 これを行うには、適切な専門家が微妙な点を知っている必要があります。



この記事は、ブラウザーの仕組みを正確に伝えることを目的としたものではなく、むしろその一般原則を理解することを目的としていることに注意してください。 さらに、ブラウザエンジンごとに作業のアルゴリズムが大きく異なるため、1つの記事ですべてのニュアンスを網羅することはできません。



ブラウザがWebページを処理するプロセス



開始するには、ドキュメントを表示するときにブラウザのシーケンスを考慮してください。



  1. DOM（ドキュメントオブジェクトモデル）は、サーバーから受信したHTMLドキュメントから形成されます。
  2. スタイルが読み込まれて認識され、CSSOM（CSSオブジェクトモデル）が形成されます。
  3. DOMとCSSOMに基づいて、レンダリングツリーが形成されるか、レンダリングツリーは一連のレンダリングオブジェクトです（Webkitは「レンダラー」または「レンダーオブジェクト」という用語を使用し、Geckoは「フレーム」を使用します）。 レンダーツリーはDOM構造を複製しますが、非display:none;



    要素（たとえば、 <head>



    、またはスタイルdisplay:none;



    要素display:none;



    ）はここには含まれません。 また、テキストの各行は、レンダリングツリーで個別のレンダラーとして表されます。 各レンダリングオブジェクトには、対応するDOMオブジェクト（またはテキストブロック）、およびこのオブジェクトに対して計算されたスタイルが含まれます。 簡単に言えば、レンダーツリーはDOMの視覚的表現を表します。
  4. レンダーツリー要素ごとに、ページ上の位置が計算されます-レイアウトが発生します。 ブラウザはフローメソッドを使用します。ほとんどの場合、1つのパスですべての要素を配置できます（パステーブルにはさらに多くの要素が必要です）。
  5. 最後に、これらすべてがブラウザでレンダリングされます-ペイント。


ページとスクリプトのユーザーインタラクションのプロセスで変更されるため、上記の操作の一部を再実行する必要があります。



塗り直し



ページ上のサイズと位置に影響を与えない要素のスタイルを変更する場合（たとえば、 background-color



、 border-color



、 visibility



）、ブラウザは新しいスタイルを考慮して、それを再びレンダリングします-再描画（または再スタイル）が発生します。



リフロー



変更がドキュメントのコンテンツ、構造、要素の位置に影響する場合、リフロー（または再レイアウト）が発生します。 通常、このような変更の理由は次のとおりです。







ブラウザの最適化



ブラウザは、可能な場合、変更された要素内で再ペイントとリフローをローカライズします。 たとえば、絶対位置または固定位置の要素のサイズ変更は、要素自体とその子孫のみに影響し、静的に位置する要素の変更は、それに続くすべての要素のリフローを伴います。



もう1つの機能は、JavaScriptの実行中に、ブラウザーが行った変更をキャッシュし、コードブロックの完了時に1回のパスでそれらを適用することです。 たとえば、このコードの実行中に発生するリフローと再ペイントは1回のみです。 



 var $body = $('body'); $body.css('padding', '1px'); // reflow, repaint $body.css('color', 'red'); // repaint $body.css('margin', '2px'); // reflow, repaint //      1 reflow  repaint


ただし、上で説明したように、要素のプロパティにアクセスすると強制的なリフローが発生します。 つまり、上記のコードブロックで要素プロパティへの呼び出しを追加すると、余分なリフローが発生します。 



 var $body = $('body'); $body.css('padding', '1px'); $body.css('padding'); //   ,  reflow $body.css('color', 'red'); $body.css('margin', '2px');


その結果、1つではなく2つのリフローが発生します。 したがって、可能であれば、パフォーマンスを最適化するために、要素のプロパティへのアクセスを1か所にグループ化する必要があります（ JSBinのより詳細な例を参照 ）。



しかし、実際には、強制的なリフローなしではできない状況があります。 タスクがあるとします：最初にアニメーションなしで要素に同じプロパティを適用し（“ margin-left



”を取る）（ 100px



設定）、次に50px



への遷移を通してアニメーション化する必要があり50px



。 JSBinでこの例をすぐに見ることができますが、ここでも署名します。

最初に、遷移を持つクラスを作成しましょう。 



 .has-transition { -webkit-transition: margin-left 1s ease-out; -moz-transition: margin-left 1s ease-out; -o-transition: margin-left 1s ease-out; transition: margin-left 1s ease-out; }


次に、次のように計画を実装してみましょう。 



 var $targetElem = $('#targetElemId'); //  ,       "has-transition" //    transition $targetElem.removeClass('has-transition'); //  , ,  transition ,     $targetElem.css('margin-left', 100); //    transition   $targetElem.addClass('has-transition'); //   $targetElem.css('margin-left', 50);


このソリューションは、期待どおりに機能しません。 変更はキャッシュされ、コードブロックの最後にのみ適用されます。 強制的なリフローは私たちを助けます。その結果、コードは次の形式を取り、タスクを正確に実行します。 



 //    transition $(this).removeClass('has-transition'); //   $(this).css('margin-left', 100); //   reflow,         $(this)[0].offsetHeight; //  ,       //    transition   $(this).addClass('has-transition'); //   $(this).css('margin-left', 50);




最適化のヒント



この記事とクライアント側の最適化の問題に対処するHarbeに関する他の記事に基づいて、効果的なフロントエンドを作成するときに役立つ次のヒントを導き出すことができます。







問題のより詳細な調査については、次の記事を読むことをお勧めします。





すべての読者がこの記事から何か役に立つことを学んだことを願っています。 いずれにせよ-見てくれてありがとう！



UPD：CSSセレクターの処理効率に関する正しいコメントを寄せてくれたSelenIT2とpiumossoに感謝します。


More articles:


All Articles