フレームワークのJavascriptレベルで実装されたDOMレンダリングの最適化のリスト

2009年10月以来、音楽を検索して聴くためのアプリケーションを開発しています。 私は、ユーザーとインターフェース間の迅速な相互作用の可能性を整理するよう努めており、相互作用を加速する手段の1つとして、迅速にページをレンダリングするためのさまざまな方法を使用しています。



システムレベルのアプリケーションで私が実装したメソッドに精通することを提案します。

• DOMツリーを再構築する代わりにCSSとクラススイッチングを使用する
• 要素サンプルのユビキタスキャッシュ（ $（ 'div.active_part span.highlighter'） ）、アトミック変更操作（DOMツリーの大きなセクションを再作成する代わりに、一般的な再描画の代わりに）
• 状態変更の書き込み中にDOM読み取りを最小限に抑える
• 要素のサイズと配置のキャッシュ（他の変更がある場合にこれらの値を読み取るときの不必要な計算から節約します。ツリーの多くの部分を変更しながら読み取ると、生産性に悪影響があります）
• DOMで行うために必要な変更の正確で、長期的でない蓄積
• コレクション全体をDOMからデタッチして再アタッチ（およびリスト全体を再描画）する代わりに、一度に変更コレクションの一部をアタッチします（たとえば、3つの新しい要素がリストの中央に挿入される場合、 createDocumentFragment ）。
• プログレッシブ非同期レンダリング：わずかな詳細で画像がすぐに描画され、その後、より詳細に表示
• ノードのクローニング（パターニングの一部として）
• DOMテンプレートの解析結果のキャッシュのキャッシュと使用

「一度にコレクションを変更する部分を添付する...」というタイトルの部分の画像

DOMツリーを再構築する代わりにCSSとクラススイッチングを使用する

原則として、視覚部分の最大値がCSSに転送され、クラスを切り替えることで表示が変更されます（たとえば、要素を非表示にするだけでノードを削除/作成する代わりに、クラス.hidden {display：none}を切り替える）。 同時に、この原則を使用すると、ドキュメント内の過度の数のDOMノードでブラウザを過負荷にしないようにすることができます。





この例では、完全なリストを表示するために、ノードの1つは単にwant_more_songsクラスを切り替えます

ノードサンプルのユビキタスキャッシュ、アトミックな変更

アトミックな変更とは、DOM構造の新しい大きな部分を完全に作り直し、再解析して構築するのではなく、既存のDOMの特定の部分を変更するという原則を意味します。 さらに、構造の変更は、可能な限り具体的な状態の変更に関連付けられています。 クラスを変更する必要がある場合は、 $（ '。Target_node'）。AddClass（ 'active'） 、テキストの場合は$（ '。Target_node'）。Text（ 'place an order'）を使用して変更します。 同じことがDOMの属性やその他の部分にも当てはまります。



これらは最初の最適化であり、私が使用した最初の原則の1つです（これに関連して、特にunderscorejs.templateのスタイルのテンプレートエンジンを拒否しました）。 モデルの状態を変更するときにビュー全体を再描画するのではなく、一部のみを変更することになります。 彼らによると、 .innerHTML （またはjquery（...）。Html（） ）を使用するべきではなく、ノードサンプル（セレクター）もキャッシュする必要があります。 一部を変更する必要がある場合は、毎回選択するのではなく、キャッシュから目的のノードを取得します。

これらの2つのことはこのように整理されています：コードはMVCに従って分割され、モデルが状態を変更すると、変更に関する情報がビューに送信され、変更された状態に関連付けられた機能がビューでトリガーされます。 この関数は、サンプルのキャッシュを使用します。

たとえば、モデルには次の状態がありました。

{ artist: "The Killers", track: null }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードでそれらを変更しました：

 track_model.updateState('track', "When You Were Young");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

条件は次のようになりました。

 { artist: "The Killers", track: "When You Were Young" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

トラックフィールドの状態が変更されました。これらの変更をモデルからビューに送信しました。





アニメーション、3フレーム。 モデルのトラックの状態を変更します。2つのビューが変更に即座に応答します



Viewでは、特定の状態の変更に応答してDOMの変更を生成する機能がアクティブになります。この場合、次のコードが機能します。

 'stch-track': function(new_state, old_state){ this.container .find('.song-track-name') .text(new_state) .toggleClass('hidden', !new_state); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（ 'stch-' + state_nameの形式のメソッドの名前に注意を払います。この場合は'stch-track' ）;

そのため、特定の変更はDOMの特定の部分に関連付けられています



ここで、キャッシュに注意しましょう。 変更するたびに選択する場合（ this.container.find（ '。Song-track-name'） ）、これはパフォーマンスに悪影響を与えるため、毎回選択しないように、すぐに次のコードに変更します。

 'stch-track': function(new_state, old_state){ if (!this.track_name_node){ this.track_name_node = this.container.find('.song-track-name'); //            } this.track_name_node.text(new_state).toggleClass('hidden', !new_state); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（ アトミックな変更の原則に従って、コードを書き始めたばかりのときにサンプルをキャッシュしました ）



後で、テンプレートエンジンの作成と使用を開始したとき、手動モードでDOMを変更する必要がある場合のために、ディレクティブ（<span pv-anchor = "track_name_con" class = "song-track-name"> </ span >） 、ノードをリポジトリにキャッシュする必要があることを示します。手動でアクセスするため、（ 毎回命令コードthis.container.find（ '。song-track-name'）を書く代わりに）。 したがって、次のような変更に対する反応を書き換えることができます。

 'stch-track': function(new_state, old_state){ this.tpl.ancs['track_name_con'].text(new_state).toggleClass('hidden', !new_state); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このような単純な変更（テキストまたはクラス、または他の属性が状態に依存する場合）は通常、他のディレクティブによって記述され、 pv-anchorディレクティブは、より複雑な変更（たとえば、他のノードの場所やサイズに影響する）、複雑な相互作用中のイベントのハングに使用されますまた、DOMが手動で変更されるその他の場合。

状態変更の書き込み中にDOM読み取りを最小限に抑える

ブラウザは、DOMへのすべての変更が行われた後にレンダリングを試みます。 ただし、いくつかのプロパティを読み取ろうとすると、彼はもっと早くすべてを計算する必要があります。 したがって、DOMの読み取りはできる限り少なくし、それが機能しない場合は、読み取り結果を（可能であれば）キャッシュします。





現在、高速で比較的便利なテンプレートエンジンがあります。たとえば、 angularjsおよびFacebook Reactのテンプレートエンジンです。 旅の最初の頃、​​これらの単純なことをする便利なテンプレートツールの存在に気づかなかったので（当時は存在していましたか？）、私はそれらを使用しませんでした。

MVCの原理に従って分割されたアプリケーションのコードが進化したとき、テンプレートエンジンはまだなかったため、変更に対するすべての反応を手動で説明しました（上記の例で説明）。



その後、 angularjsの人気が急速に高まっているため、テンプレートエンジンに注意を向けました。これは、アトミックな変更の原則にも準拠しています（データバインディングもありました）。 しかし、私にとっての関心はむしろ原理であり、それによると、状態の変化は要素の特性に結びついています。 これは、htmlドキュメントで追加の属性を宣言することで発生します。



式の解析を担当するコードと、属性自体を介した日付バインディングの宣言メソッドを、 angularjsから取得しました 。 この接続の記述方法により、HTMLコードが機能し、ブラウザーが作業の最も難しい部分（HTML解析）を実行し、結果を再利用できます（.cloneNode（）メソッドを使用したクローン作成を使用） 。



例：

 <div class="user_tag_page usual_page" pv-class="lula_page usual_page {{!vmp_show && 'hidden'}}" ></div>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、pv-classディレクティブが使用されています。 その値に応じて、要素には常にlula_pageのクラスがあります。また、モデルにvmp_show状態がない場合、要素には別のクラス（「非表示」）が必要です。 vmp_showの状態が変化すると、テンプレートエンジンは自動的に.classNameを上書きしますが、テンプレートエンジンが使用されない場合、 classNameは上書きされず、その値は最初に記述したものと同じになります-class = "user_tag_page normal_page"



この方法は、便利で解析の最適化を可能にするだけでなく、DOMの変更に関連するパフォーマンスの最適化の可能性も提供します。 たとえば、要素クラスが変更されると、パフォーマンスの最適化が実装されます。 jQuery（ノード）.addClass（ 'sample-class'）メソッドは、要素にそのようなクラスがあるかどうかを確認することを知っているかもしれません。 書き込みの前に、（少なくともclassList APIが表示されるまで）追加の​​読み取りを行います。 しかし、以来 テンプレートエンジンでは、モデルの現在の状態にあるクラスの完全なセットとクラスのセットを知っています（たとえば、「 lula_page通常のページ非表示 」）、すぐにこれを行うことができます。

 node.className = "lula_page usual_page hidden";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり classNameの以前の値を読み取る必要はありませんでした。状態が変更された場合にのみ変更し、依存する状態のリスト全体とクラス値が正確に何であるかを知っているからです。



モデルの状態と対応するDOM構造がわかれば、このDOMをまったく読む必要はありません（他のパーツのサイズに依存しない場合を除く）。



ただし、特に読み取りクラスの場合、説明した原則ではパフォーマンスがまったく向上しない場合があります（少なくとも、最新のブラウザーは、 classNameの完全な値を提供するためにサイズや場所を計算する必要がないことを理解する必要があります）テンプレートエンジンから受け取るボーナス。



ただし、最新の現在リリースされているjqueryバージョン（2014年1月24日、1.11、2.1）のリリースに関連するレコードでは、開発者は 、クラスが変更されたときに追加のレイアウト変更トリガーを修正したことを報告しました （「レイアウトの強制を減らす」の見出しを参照）。 つまり それは重要であり、非常に深刻です。 Chrome開発者もこの問題に取り組んでいます。

キャッシュ要素のサイズとレイアウト

要素のサイズまたは配置を読み取ると、他のすべての変更が早期に計算されます。これは最適化に適した場所です。 これが可能な場合には、キャッシュを使用します。



たとえば、再生と読み込みの現在の進行状況を表示するノードの幅を設定するには、幅のパーセンテージ値ではなく、ピクセル値を使用します。





通常幅のプログレスバーファイル





ファイルのリストを展開した幅の進行状況バー





異なるウィンドウ幅の幅プログレスバー







計算するには、親要素の幅を知る必要があります。 親要素の幅は、画面の幅と、見つかったファイルのリストの完全または単一の表示とは異なる場合があります。



この場合、幅は他のパラメーターに依存しません。 同じ幅とリスト表示モードでは、ノードの幅は常に同じになります。 リポジトリにアクセスするときに、キーの一部として幅に影響する可能性のある状態を使用します。

 this.getBoxDemension(this.getProgressWidth, 'progress_c-width', window_width, !!p_wmss);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メソッドの最初のパラメーター（ getProgressWidth ）は、ストアにこのキーの値がない場合にgetBoxDemensionメソッド自体が呼び出す関数です。

他のすべてのパラメーターは、単に文字列に追加されます。 この場合、 行のp_wmssは「false」または「true」になります （1つのファイルまたはリスト全体が表示されます）。 その結果、キーはprogress_c-width-1372-falseのようになります 。



ウィンドウまたは表示モードの幅を変更すると、新しいキーの新しい幅が計算され（ストアにない場合）、この幅に依存する部分が自動的に再描画されます。



実際、キーにさらに2行が追加されます-これは親ビュー内のこのビューのスロット-スロット位置の名前です（フレームワークの用語では、この位置名をビューに自動的に割り当てます）。同じことが内部の親ビューにも当てはまります。親ビュー。 これは、同じビューが異なる場所で使用される場合に使用されるため、計算されたサイズは、たとえば、ファイルリストの画面幅や表示モードだけでなく、ビューが使用される場所にも依存します。



さらに、レポートの一部で、Googleの従業員Paul Lewisがこれについて語っているビデオを見ることができます。 同じテーマに関するPaul LewisとPaul Irishの共同記事も参照してください。 その記事からのレンダリングに何らかの形で影響するプロパティのリスト 。

DOMで行うために必要な変更の正確で、長期的でない蓄積

フレームワークは、異なる状態に依存し、この状態が更新されると変化するモデル状態のビューに送信される前に、パッケージ内のすべての状態のコレクションを実装します。 ただし、このモデルのみであり、アプリケーション全体ではありません。



モデル状態を更新すると、それに依存する他のすべてのモデル状態も自動的に更新され、変更が1つの大きなパッケージに収集されてビューに送信され、1回の反復でレンダリングが行われます。 変更の計算は、このモデルに新しい変更が表示されなくなるまで行われます。 送信は、このモデルの状態を計算することによってのみ遅延されます（それ以上は行われません）。 これらのモデルの他のモデル（たとえば、更新されたモデル）に依存する状態の変化は、更新されたモデルがビューに変更を送信した後にのみ計算されます。



したがって、状態変化の蓄積が実現され、あまり長くドラッグされない。



複数の状態を手動で更新するときに1回の反復でレンダリングするには、次の方法を使用します。

 .updateManyStates({ artist: 'artist_224', title: 'radnomd title 014' })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのような2つのステップを実行する代わりに：

 updateState('artist', 'artist_224')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 updateState('title', 'radnomd title 014')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

将来的には、この原則に加えて、requestAnimationFrameを使用して、テンプレートエンジンの側で直接書き込みの変更を蓄積することを称賛します。

コレクション全体をDOMからデタッチして再アタッチする代わりに、コレクションを一度に変更する部分（ createDocumentFragment ）を特定の場所（ after 、 before ）にアタッチする

リストを変更しても、リストは再描画されません。

リストを変更すると、リストアイテムに関連付けられたDOMパーツは再作成されません。

リストを変更するとき、リストのDOM要素の新しいシーケンスは、ドキュメントから完全にデタッチするのではなく、必要に応じてデタッチして、変更された（または新しい）要素を厳密に定義された場所にアタッチすることによって確立されます。

添付するリストアイテムに対応するDOMは個別に添付されませんが、要素が次々に移動する場合はcreateDocumentFragmentで添付されます 。 要素はdocumentDrafmentに目的の順序で添付され、その後documentDrafmentは 、 after 、 beforeまたはappendメソッドを使用して、ドキュメントの目的の場所に添付されます 。



したがって、DOMのリストを変更すると、最も必要で最小限の変更のみが発生します。





このリストで最後の要素が強調表示されたリスト（コンソールのグローバル変数$ 0は選択され強調表示された要素、$ 1、$ 2、$ 3は以前に選択された要素です）





多数の新しいコンポジションがリストに追加されましたが、以前に選択されたコンポジション（リストが変更された）の表示を担当する要素はまったく同じノードのままです。







さらに、John Rezigのブログからエントリの翻訳を読むことができます。

プログレッシブ非同期レンダリング：わずかな詳細で画像がすぐに描画され、その後さらに詳細が表示されます

必要に応じて、要素を互いに入れ子にした大きな構造を描画します（単純なものでも入​​れ子部分として実装されることが最も多い）。必要に応じてリストを描画するなど、最初の反復のフレームワークは構造の最上部にモデルのビューを描画します。 このイテレーション内には、さらに2つの要素があります。視覚的な次元を定義するまさにその基礎が描かれ、次に詳細が描かれます（このモデルに直接関係し、状態の変化に対する反応）。 次の反復で、フレームワークはネストされたモデルを描画し、これはネストが終了するまで続きます。 すべての反復は分離されており、レンダリングにたとえば200ミリ秒以上かかる場合（将来的にはrequestAnimationFrameに置き換える予定です）、 setTimeoutを使用して解放できます。これにより、インターフェイスがブロックされず、ブラウザーが既に存在するものを描画できるようになります。 ユーザーにとって、インターフェースは徐々に変化します。 単純な方法とは対照的に、長い一時停止の後（ブラウザがクリックに応答せず、同じものを表示する間）、ブラウザが画像を劇的に変更するときに、いくつかの変更が発生していることがわかります。



これはプログレッシブjpegに似ているか、ゲームエンジンを思い出させます。 エンジンにリソースが不足し、画像が最初に低品質（フィルター処理されていないテクスチャ、低ポリゴンモデルなど）で表示され、その後画像が改善する場合があります。

アニメーション、2フレーム。 プログレッシブレンダリング：最初にスクランブル、次に詳細。 デバッグモードでのみ、瞬間をキャプチャし、最初の部分をキャプチャすることが可能でした。これにより、調光が表示されます。

ノードのクローニング

ビューのDOM構造の取得は、おおよそ次のとおりです。ブラウザー自体のHTMLパーサーがHTMLを1回解析し（最も難しい作業を実行します。これはページ全体の読み込み中に事前に行われます）、必要に応じて、結果はDOM API（ .cloneNode（） ） テンプレートのインスタンスは、テンプレートツリーのDOMのクローンを作成することで作成され、その後、このノードに関連付けられたディレクティブが読み取られて解析されます。

DOMテンプレートの解析結果のキャッシュのキャッシュと使用

ノードを複製した後、ディレクティブを検索するために属性を再度読み込む必要はありません（ノードの複製時にサービスデータはコピーされません）。また、より効率的にメモリを使用し、よりまれにトリガーするために、ディレクティブによって作成されたオブジェクトを再利用します（後でテンプレートエンジンで使用するため） garbadgeコレクターでは、元のノードからクローンノードにサービスデータをすばやくコピーできるソリューションが見つかりました。



これは次のように発生します。テンプレートDOM構造が解析され、解析されます。 ディレクティブを持つ要素のすべてのノードは、リポジトリに格納され、将来使用できるディレクティブの一意のセットに対応する一意の値を持つpvprsdプロパティに設定されます。 必要なすべての要素にプロパティセットが設定され、ルートから始まると、構造が配列に展開されます。 テンプレート構造はルートから複製され、このインスタンスも複製されます。 インスタンスは、ルートから同様の方法でさらに配列に分解されます。 このようなクローン作成と折りたたみにより、同じインデックスの下のアレイが正確に同じノードを持つようになります。 その後、配列を通常通りパスすると、最初の配列の要素からインスタンス配列の要素にpvprsdがコピーされます。

 var getAll = function(node) { var result = []; var iteration_list = [ node ]; var i = 0; while( iteration_list.length ){ var cur_node = iteration_list.shift(); if ( cur_node.nodeType != 1 ){ continue; } for ( i = 0; i < cur_node.childNodes.length; i++ ) { iteration_list.push( cur_node.childNodes[i] ); } result.push( cur_node ); } return result; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 var cloned = this.onode.cloneNode(true); var all_onodes = getAll(this.onode); var all_cnodes = getAll(cloned);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに

システムレベルでアプリケーションに実装した最適化方法について説明しました。 これにより、毎回同じ最適化をプログラムすることはできませんが、いくつかのルールに従って、結果として生産性の高いコードを作成できます。 もちろん、私は他の方法を使用し、プロファイリングを使用しますが、これは特定のケースで発生し、余分な時間がかかります。



システムレベルで他にどのような最適化を実装できるかを知りたいと思います。 たとえば、この例で手動で行われるように、iframe / object要素に基づいて視覚的に引き裂かれた領域の自動作成： http : //fb.html5isready.com





アプリケーションの視覚的表現の一部はオブジェクト要素内にあります







私はそのような方法を実装していませんが、テンプレート、そのインスタンス、スタイル、動作状態の変更が任意の基準に基づいて自動的に作成されたiframeに該当する場合、これを自動モードで実装するのが現実的だと思います。



あなたが知っているシステムレベルでの最適化技術の他の実装について教えてください（ そのようなまたはそのような ）。 または、どこかでそのような最適化のアイデアを表明した（ 例 ）、または共有する準備ができていれば、あなたのアイデアについて。