今日はフロントエンドグラフィックレンダリングの最適化についてお話ししましょう。次回からwebglの研究を開始する可能性があるため、これまでに行ったH5を要約します。これはGERRY_BLOG、TiMiGerryでリリースされています。リンクはそのままにしてください。
静的リソース-写真
1.画像フォーマット
JPEG：まず、JPEG圧縮の全プロセスは、画像の色rgba（）を変換し、次に再サンプリングして高周波数と低周波数の色変換を区別して、DTAプロセスを実行し、次に高周波数の色を実行します。サンプリング結果を圧縮用に変換し、続いて量子化とエンコーディングを行い、最後に圧縮バージョンのJPEGを取得します。この画像の圧縮バージョンは元のデータ画像とは異なり、圧縮処理中に一部のデータが失われますが、これらの違いは人間の目では認識できません。そのため、圧縮後の全体的なブラウジングエクスペリエンスへの影響はありませんが、ページの静的リソース画像の容量も大幅に削減できるため、Webページの読み込み速度が向上します。
PNG：PNG画像は透明度をサポートする画像形式であり、その本質はカラーインデックスデータコレクションです。PNG8、PNG24、PNG32の3つの形式、つまり8ビット、24ビット、32ビットのインデックスがあります。PNGファイル形式には内部にカラーパレットがあります。PNG8を例にとると、PNGは256色+透明関数形式です。カラーパレットには256色、つまりピクセルの色があります。インデックスを作成するには、8ビットのデータ長が必要ですつまり、PNG8画像の色はこれらの256色でしか表示されないため、PNG8色はそれほど豊かではなく、欠点と利点があり、ファイルサイズもPNGファイル形式で最小のものです。
PNG24画像には2 ^ 24色が必要です。つまり、ピクセルの色はインデックスに24ビットを必要とするため、png24が色をインデックスするために必要なデータ長はpng8の3倍であり、透明度をサポートしていません。png32画像はpng24にあります透過機能の追加に基づいて、PNG画像の選択は画像の色によって異なります。画像の色がそれほど豊富でなく単純な場合は、PNG8画像の使用を検討できます。画像の色が非常に豊富な場合は、PNG24ビットまたはPNG32ビットの画像を選択して、画像リソースのサイズを縮小できます。PNG画像の各形式には若干の違いがあります。実際の開発では、使用する画像形式を決定する前に、現在のプロジェクトでファイルサイズ、画像形式、画質、画像サイズの重要性のバランスをとる必要があります。
JPEG：画像の圧縮率は比較的高く、背景画像として使用するのに適しています。また、先頭画像の場合は、大面積の背景の場合に適しています。
PNG：この形式は透明度をサポートします。この形式の画像は互換性が良好です。透明にする必要がある一部の背景またはポップアップレイヤーに使用されます。または、以下の場合、エクスペリエンス品質を追求し、PNG画像を使用してページ全体を開発する必要があります。
SVG：もう1つはSVGベクターグラフィックです。この形式の最大の利点は、歪みや細かさなしに拡大および縮小できることです。同時に、ファイルは比較的小さく、画像形式がコードに埋め込まれています。可能であれば、可能であればそのような形式を使用してくださいもちろん、写真はアイコンやボタンなどの単純なビジネスシナリオでのみ使用できます。
2番目に、画像処理
CSSスプライト：現在のところ、画像の並べ替えの方法としてはまだ一般的ですが、大小の画像を1つの大きな画像にマージし、画像の配置を使用して対応する画像を表示することで、ページを削減できます。ページの読み込み速度を上げるリクエスト。しかし、大きな画像が合成されるため、多くの小さな画像がこの画像に依存するという欠点もあります。この画像が読み込まれていない場合、ページ全体が基本的に失われますが、現在のネットワークでは、基本的にこの問題は無視してください。基本的に、4Gネットワークまたはwifiは遅くありません。
画像のインライン：BASE64形式を使用してページに埋め込むことも、htttpリクエストを減らすための良い方法ですが、HTMLに画像を埋め込むことは後で実際に維持することが実際には簡単ではないため、実際の開発では一般的にあまり行われません。私の開発経験によれば、BASE64イメージ形式は通常、それを行う方法がないときに使用されます。
たとえば、開発プロジェクトでは、画像リソースは通常、異なるドメインのアドレスに配置されます。CANVASを使用して画像を生成する場合、canvas.toDataUrl（...）は画像の元のアドレスを汚染し、クロスドメインの問題が発生します。画像が個別に生成される場合、BASE64を使用することが最も簡単で最も失礼なソリューションです。HTMLに画像を埋め込むと、クロスドメインの状況が解決されます。
圧縮：バッチ圧縮用のいくつかのツールに画像を配置します。
HTMLページの読み込みとレンダリング
1. Webページのレンダリングプロセス
Webページのロードプロセスでは、最初に取得するのはHTMLテキストです。または、文字列の文字列を取得したと言えます。ブラウザの解析パーサーは、この文字列に対して一連の字句解析を実行し、対応する各タグを生成します各タグに対応するトークンまたはオブジェクト。これらのトークンを上から下に解析し、対応するDOMノードを上から下に段階的に生成します。
もちろん、字句解析のプロセスでは、リンクスクリプトタグを解析でき、対応するWebリソースの読み込みが要求されます。JavsScriptはブラウザーコアのV8エンジンによって実行され、cssはhtmlに似ています。彼はCSSOMに解析され、解析後にHTML、CSSM、SCRIPTが組み合わされて、ランダーツリーによって取得されたこれらの基本情報を生成します。レイアウトを入力し、最後にペイントをレンダリングします。
2番目に、HTMLロード機能
順次ロード、同時ロード：
順次ロードとは、前述の字句解析を指します。つまり、ブラウザーがHTMLページを上から下に解析すると、順次実行されます。
同時読み込みとは、同じドメイン内の静的リソースが同時にリクエスト、つまり同時リクエストを開始することを指します。もちろん、同時リクエストがあり、サーバーには同時リクエストの上限もあります。たとえば、Google Chromeは統合ドメイン内の同時リソースの数をリクエストします。 6。多数の画像を要求する必要がある場合、操作には遅延読み込みまたは事前読み込みを使用する必要があります。
CSSのブロックとJSのブロックの
CSSは、CSSの読み込みによってページの読み込みがブロックされるため、可能な限りヘッドに書き込む必要があります。これにより、CSSが読み込まれていないときにページがフラッシュされ、ページが読み込まれたときにページがフラッシュするという状況を回避できます。 、CSSの読み込みはJSの実行をブロックしますが、インポートされたJSの読み込みをブロックしません。
jsの導入はページのレンダリングをブロックし、DOMノードにも依存するため、jsはできる限りHTMLテキストの下部に記述してください。したがって、最初にHTMLとCSSを最初にロードし、次にJS、JSロードをロードする必要があります。もちろん、初期画面に影響を与えることなく、非同期ロードdefer、asyncを使用して、すぐには必要でないJSファイルをロードすることもできます。読み込みの際、DOMの完了に基づいて、読み込みと実行を順番に行い、非同期の読み込みを順番に行うかどうか、最初に読み込んでから実行する場合、このメソッドはJSが依存しているかどうかに注意する必要があり、JSの実行順序も互いに依存しています。 JSロジックの後続の実行をブロックするため、それらを順番に配置する必要があります。
deferおよびacyncに加えて、jsの動的ロードが直接使用されます。通常、このメソッドはコンポーネントの場合に使用され、コンポーネントをカプセル化してから、jsを使用してJSおよびCSSを動的にロードします。
レイジーロードとプリロード
Lazyloadは、多数の画像を読み込むために使用されますが、ユーザーの操作に応じて負荷の数を決定できます。その目的は、サーバーへの要求を減らし、ネットワークトラフィックの無駄を減らし、ユーザーエクスペリエンスを向上させることです。たとえば、一部のeコマースページでは、すべてのデータを一度に一覧表示するのではなく、製品を表示し、ブラウザがスクロールする場所に対応するデータをロードします。また、H5ページでプルダウンして更新し、プルアップしてロードすることもよくありますが、IOS自体のブラウザー特性により、対応する処理も必要になります。
プリロードは、ユーザーエクスペリエンスとスムーズなページ操作に注意を払う必要があるいくつかの状況で使用されます。ページが読み込まれた後、すべてのデータが最初に読み込まれ、次にページが開かれます。最も一般的な方法は、読み込みの進行状況バーを使用して、最初にすべての静的リソースを配列に格納し、次に計算された割合を順番に読み込み、100％に達したら次のステップに進みます。
再描画とリフロー
フレームの概念についてお話しましょう。現在、ほとんどのデバイス画面のリフレッシュレートは60回/秒です。つまり、1000/60 = 1.6msがフレームです。ブラウザーはレンダリングを実行する必要があるため、レンダリング時間は1.6ミリ秒未満またはできる限り1.6ミリ秒に近づける必要があります。そうしないと、スタッター現象が発生し、ユーザーエクスペリエンスに影響します。ブラウザがアニメーションをレンダリングする時間がちょうど1フレームであると仮定すると、このフレームのフレームは、最初にスタイル（css / domなど）を再計算し、次にリフローしてツリーを更新し、次に再描画（ペイント）し、最後にレイヤーのマージを実行します（複合）。以下に示すように
1.再
描画とリフロー：フロントエンドのパフォーマンス最適化の最も重要な側面は、ページの再描画とリフローを減らすことです。
リフロー（リフロー）は、現在のページのレイアウトと幾何学的プロパティが変更されたときにリフローをトリガーするメカニズムです。
再描画（再描画）は、Render Tree自体の一部のプロパティが更新されていますが、レイアウト全体には影響せず、背景や色などを変更するだけです。これは再描画と呼ばれます。
第二に、最適化：
再描画とリフローを減らして、リフローを
トリガーする一部の属性を使用しないようにします。一部の属性は、リフローのメカニズムをトリガーします。たとえば、上部、高さ、その他のレイアウト関連の属性、たとえば、@ keyframesアニメーションの変位方法translateXはtopを置き換えます。次の図はその例です。明らかに、レイアウトが1ステップ少なくなっています。これは、リフローをトリガーするtop属性が変換によって置き換えられるため、レンダリングプロセスのレイアウトステップが減り、レンダリング時間が短縮されて改善されるためですパフォーマンス。
明らかに、レイアウトが1つ少なくなります。これは、リフローをトリガーする最上位の属性が変換に置き換えられるため、レンダリングプロセスのレイアウトステップが削減され、レンダリング時間が短縮されてパフォーマンスが向上するためです。
レイヤーを頻繁に独立してレンダリングし、頻繁なリフローと再描画を必要とするブロックを別のレイヤーとして取り出して、ブラウザーのリフローの再描画範囲を減らし、CPUリソースの消費を減らします。なぜなら、ブラウザレンダリングのプロセスは次のとおりです。DOMが
複数のレイヤーに分割され
、各レイヤーがラスタライズされ、ノードがグラフに描画されます。
次に、レイヤーがテクスチャとしてGPUにアップロードされ、
最後にグラフが表示されます。レイヤーの再編成は、操作する必要のあるレイヤーを個別に再描画およびリフローする限り、他のレイヤーには影響しません。
上記のレンダリングプロセスに従って、GPUアクセラレーションの概念について説明します。実際にはGPUアクセラレーションである新しい合成レイヤーを作成したので、新しいレイヤーを作成するにはいくつかの方法があります
。3Dまたは透視変換
ビデオ要素を使用して高速ビデオデコードを行う;
2Dコンテキストキャンバス要素と3D（WelGL）コンテキストまたはアクセラレーター;
CSSオペレーションを実行するための要素または独自のopactiyのWebkit変換;
高速化されたCSSフィルタリングを備えた
要素; 要素Aにはz要素Bがそれ自体よりも小さなインデックスを持ち、要素Bがコンポジションレイヤーである場合（つまり、要素は複合レイヤーにレンダリングされます）、要素Aはコンポジションレイヤーに昇格されます。
ポイント2を例にとります。Leagueof Legendsゲームのライブビデオを開きます。
ここでビデオがレイヤーになる理由がわかります。ここに説明があります。
7番目の点について述べます。実際の開発プロジェクトでは、特にモバイル端末はアニメーション効果を実行するときに問題に遭遇することが多いためです。
上記の図によると、要素Bは別のコンポジションレイヤー上にあり、画面の最終的な画像はGPUで構成されている必要があります。ただし、A要素はB要素の上にあり、A要素とB要素のレベルは指定していません。次に、ブラウザーはこの時点で要素Aの新しいコンポジションレイヤーを強制するため、AとBの両方が別々のコンポジションレイヤーに変わります。したがって、GPUアクセラレーションを使用してアニメーションのパフォーマンスを向上させる場合は、現在のアニメーション要素に高いz-index属性を追加して、合成レイヤーの順序を人為的に妨害することをお勧めします。これにより、Chromeによって作成される不要な合成レイヤーを効果的に削減し、レンダリングパフォーマンスを向上できます。
新しいレイヤーを作成するときは注意が必要です。GPUはレンダリングされたレイヤー画像をGPUに送信するだけでなく、後でアニメーションで再利用するために保存する必要があります。自由にレイヤーを作成することはできません。現在のプロジェクトを分析する必要があります。新しいレイヤーを作成するとコストがかかるため、新しいレンダリングレイヤーを作成するたびに、新しいメモリ割り当てとより複雑なレイヤー管理が必要になります。モバイル機器を使用するユーザーにとっては大きな負担です。
ブラウザストレージ
1.記憶媒体の
Cookie：Cookieは通常、アカウント確認情報またはより機密性の高いユーザーデータを保存するために使用されます。または、モバイル端末の一部のプロジェクトの連携ページでログインステータス情報を取得する必要がある場合は、トランジットページを使用できます。簡単にアクセスできるように対応するデータを保存するCookie。一般に、CSの相互作用とデータストレージに使用されます。なぜなら、彼の配信方法は最初にサーバーから生成され、ブラウザはサーバーから返されたデータのヘッダーにあるローカルのset-cookieにデータを書き込み、それからすべてのhttpリクエスト（同じドメイン名の下）がcookie情報を運ぶからです。サーバーが要求されたユーザー認証を実行できるようにするため
これは非常に効率的な対話メカニズムですが、いくつかの問題も発生します。Cookieは毎回もたらされるため、リクエストの数が多いとトラフィックが消費され、読み込みが遅くなり、リソースの浪費が発生します。メインサイトとリソースサイトのドメイン名を分離するために、リソースをcdnで解決できます。もちろん、これは多数のWebページの場合にも基づいています。WebページのPVが100,000未満の場合、これは実際に今日のネットワークに当てはまります。無視してかまいません。そういえば、過去にいくつかの小企業にインタビューに行ったときのことを思い出します。彼らの会社のWebパフォーマンスの最適化について尋ねたとき、それらの技術リーダーは基本的に、「トラフィックが100,000を超えていない場合、あなたはインターフェースの通常の経験、それがいかに便利かを見ることができます。「誰もが笑った。ただし、開発者としては、プロジェクトのサイズに関係なく、可能な限り技術的な観点から進める必要があります。
localStrageとsessionStrage：Cookieと比較して、これら2つの属性はデータを保存するためにH5によって新しく開発されました。容量は最大5Mです。唯一の違いは、データが閉じた後も残り、もう1つはブラウザが閉じた後にデータをクリアすることです。フォームやショッピングカートのデータなど、一時的なデータストレージとして使用できます。
IndexDB：このブラウザのAPIはブラウザデータベースです。これは、大量の構造化データを格納する必要がある場合にのみ必要です。現在、クライアントが特に大量のデータを格納しないため、このAPIはほとんど使用されません。データは基本的にバックグラウンドに渡され、フロントエンドが基本的に格納する必要があるデータは、基本的に一時データと検証データです。別のindexDBは、対応するオフラインアプリケーションを作成することです。
サーバーワーカー：これは、大量かつ大量の計算を行うJSファイルを取得する必要がある場合に使用されます。3Dレンダリングの場合、jsファイルは大量かつ大量の計算を持ち、jsはシングルスレッドです。実装。最後のjsは処理されず、次のjsは待機する必要があります。SWは現在のWEBに依存せず、さまざまなJSがバックグラウンドで処理され、メインページが監視され、最終的に要約されます。SWのライフサイクルは次のとおりです。
PWA：プログレッシブウェブアプリとは、一連の新しいウェブ機能とUIデザインを通じて最高のユーザーエクスペリエンスを実現する新しいタイプのアプリモデルです。これは今後のWEB APPのトレンドでもあります。端的に言えば、彼はネイティブAPPのエクスペリエンス（たとえば、3つの主要な方向）にできる限り近づこうとします。まず、APPを開いてネットワークなしで使用できます。2つ目は、対応する速度を上げて最高のエクスペリエンス効果を実現することです。もう1つは、通常のAPPと同じデスクトップクリック可能を生成することで、APPをクリックすることで全画面機能とプッシュ機能にアクセスできます。
ブラウザのキャッシュ
優れたキャッシュ戦略は、http要求とWebページの遅延を減らし、不要なデータの読み込みを減らし、ネットワークの負荷を減らし、それによってページの応答速度を改善し、ユーザーがより良いブラウジングエクスペリエンスを実現できるようにします。ただし、キャッシングでは、ページを2回目に開いたときの応答速度が向上するだけで、最初にページを開いたときは、現在のネットワーク環境とデバイスによって異なります。ブラウザのキャッシュは、クライアントにファイルを保存することです。各セッションのとき、ブラウザはキャッシュされたコピーがまだ有効期間内かどうかを確認します。そうであれば、ブラウザはサーバーにファイルを要求しなくなりますが、メモリ内で直接それを取得して使用します。ファイルの有効期限が切れている場合、ブラウザはサーバーへのリクエストを開始します。これにより、不要な要求を減らし、ページの応答を高速化できます。
ウェブキャッシュ情報はhttpheaderに保存され、一部のキャッシュ戦略はhttpheaderの一部の属性を介して設定できます。この戦略により、リソースがサーバーに再度ロードするよう要求する必要があるかどうかが判断されます。これは、responseheaderまたはrequestheaderに存在できます。目的は、クライアントとサーバーに互いのキャッシュを知らせることです。
キャッシュ制御は、キャッシュ戦略を制御するhttpheaderです。max-age、s-maxage、private、public、no-cache、no-storeがあります。これらの属性は、キャッシュを構成し、キャッシュ戦略を形成するために使用されます。
max-age：max-agoは最大有効時間を示します。つまり、リソースは現在のリクエストの時間からこの時間範囲内にあり、サーバーへのリソースリクエストを開始する必要はありません。ブラウザは使用するメモリファイルを直接取得します。キンググローリーの公式ウェブサイトを開きます。
ここでロゴを見ると、キャッシュ制御の最大有効期間は86400秒であり、86400/3600 = 24に変換されます。つまり、このロゴは、サーバーが1日以内にサーバーへのリソース要求を開始しません。 Zhangのロゴが変更されました。写真のメモリキャッシュから、つまりメモリから取得できます。
s-maxage：s-maxageはmax-ageに似ています。どちらも指定された時間内にサーバーへのリソース要求を開始しませんが、s-maxageは共有キャッシュを指します（後で説明します）。例：cdn、およびmaxageとs-maxageの両方がCacha-controlで設定されている場合、s-maxageはmaxageとExpiresをオーバーライドします。
プライベートおよびパブリック：プライベートはプライベートキャッシュ、つまりユーザーだけがアクセスできるキャッシュを指し、パブリックは複数のブラウザがアクセスできる共有キャッシュを指します。プライベートまたはパブリックが指定されていない場合、デフォルトはパブリックです。もう1つ注意すべき点は、s-maxageを有効にするにはpublicに設定する必要があることです。
no-cache：これは、サーバーがmaxageではなく、キャッシュが期限切れで無効であるかどうかを確認する要求を開始するたびに、サーバーへのリソース要求を一定期間開始しないことを意味します。no-cacheの使用方法に注意してください。maxageを0に設定し、属性をprivateに設定できます：
Cache-control：private、maxage：0、no-cache
ストアなしとは、キャッシュが禁止されていることを意味し、ロードされるたびにリソース要求が必要になります。
Expires：Expiresは、キャッシュの有効期限を設定するために使用されます。max-ageと同様に、一定の時間内で指定されます。キャッシュが有効である限り、サーバーからリソースを要求しません。ただし、max-ageの優先度は高くなります。これは有効期限に使用され、サーバー側でファイルが更新されているかどうかに関係なく、有効期限は強力なキャッシュであるため、指定された時間内にサーバーへのリクエストを開始するかどうかに関係なく使用されます。もう1つのポイントは、Expiresが比較的早い時期に登場したため、ブラウザの互換性の点で有利です。
最終変更＆if-last-modified：最終変更＆if-last-modifiedは、クライアントとサーバーのキャッシュネゴシエーションメカニズムに基づく、ファイルの最終変更時間を指します。最終変更はresponseheaderに保存され、if-modifity-sinceはrequestheaderに保存されます。で
response-headerに最後に変更された時間があることがわかります。これは、サーバー上のこのファイルの最後の変更時間の時間です。ブラウザは、この時間を節約します。次のリクエスト、request-header if-modified-今回はありますので、このファイルをサーバーに伝えてください。最後の更新は今回です。この時点で、サーバー上のファイルが変更されている場合は、リロードしてステータスコード200を返します。サーバー上のリソースが変更されていない場合、ブラウザは直接キャッシュを取得して304を返します。
Etagとif-none-Match：サーバーは、ファイルのコンテンツに基づいてハッシュ値を生成し、リソースのステータスを識別します。サーバーに2回目のリクエストが行われると、サーバーは、ハッシュが一貫しているかどうかを確認して、ファイルが発生したかどうかを判断します変更、彼はどのような問題を解決できますか？最後に変更されたケースにのみ次の欠陥があります：
サーバーファイルは変更されましたが、コンテンツは変更されていません;
サーバーは
リソースの最終変更時間を正確に取得できません; リソースは数秒以内に操作されました、最終変更は認識されません。
Etagはコンテンツに基づいています。どのような操作でも、コンテンツが変更される限り、ハッシュ値は変更される必要があります。もう1つは、etagが最終変更よりも優先度が高いことです。追加するもう1つ：最終変更＆ETagは、ブラウザーが再度確認されたときにのみ使用されます。これら2つを使用する前に、キャッシュの有効期限（最大経過時間）を最初に決定する必要があります。もちろん、ETagが優先されます。レベルは最終変更よりも高いです。
キャッシュ戦略のカスタマイズ：
キャッシュ戦略を2つのカテゴリに分類しました。1つは静的リソースのキャッシュ戦略ですが、もう1つは動的リソースのキャッシュ戦略です。将来的には新しいメソッドが存在する可能性があるため、後でそれを書き出します。最初に、キャッシュは共有またはプライベートに分割する必要があることに注意してください。最初はプロキシによってキャッシュされないようにし、次にコード仕様に注意を払う習慣を身に付けます。
静的リソース：静的リソースは、css、javascript、txt、画像など、変更されないファイルを指します。css、javascriptなどのファイルの場合、パッケージ化するときにバージョン番号を指定します。つまり、名前に接尾辞が付いており、変更が発生すると、ファイル全体が更新されます。したがって、静的リソースの場合、キャッシュ戦略は比較的単純で、現在のプロジェクトに基づいて適切な変更を加えるだけです。
動的リソース：株式、先物などの価格情報などの動的リソース。ここでは、リソースは共有リソースです。ブラウザまたはプロキシサーバーは、それらが存在するたびに最新バージョンがあるかどうかを確認します。次に、次のように設定できます。
キャッシュ制御：パブリック、キャッシュなし、ストアなし
で一定期間データを保存できます。次にmax-ago = ...（秒）、必要に応じて変換できます。例：キャッシュ1時間有効な
キャッシュ制御：public、max-age = 86400
1時間後、キャッシュを厳密に制御する必要があります。それを再度使用できます：
Cache-control：public、max-age = 86400、no-cacheまたはmust-revalidate
実際、これも要求に基づいており、設定は1つのコマンドにすぎません。
Vary：Accept-Encodingこれは、gzip圧縮が有効で、プロキシサーバーによってキャッシュされるリソース用です。クライアントが圧縮をサポートしていない場合、この場合、正しいデータが取得されない可能性があるため、プロキシサーバーは2つ表示されることがあります。リソースの1つのバージョン。1つは圧縮され、もう1つは圧縮されていません。別の理由はInternet Explorerです。InternetExplorerはVeryヘッダーのリソースをサポートしていませんが、値はAccept-Encodingおよびuser-Agentではありません。
概要：ページの最適化計画は、現在のプロジェクトのニーズに応じて調整して、最高の実際のエクスペリエンスを実現する必要があります。