フロントエンドのパフォーマンス最適化をうまく行う方法

フロントエンドの必須ツール (無料のイメージベッド、API、ChatAI、その他の実用的なツール) の推奨 Web サイト:

http://luckycola.com.cn/

序文：

フロントエンドのパフォーマンスの最適化は、フロントエンド開発者が常に注意を払わなければならない古典的なトピックです。テクノロジーの継続的な発展により、Web ページのコンテナー (ブラウザー、Web ビュー) のパフォーマンスはますます強力になっていますが、その機能はWeb サイトのアプリケーションも常に充実しており、サイズは大きくありませんが、増加を避けるために、ネットワーク環境などが良好でない場合、白画面時間が長いなど、ユーザーエクスペリエンスに重大な影響を与える問題が依然として発生します。 , フロントエンドのパフォーマンスの最適化を理解することは不可欠であり、フロントエンドの面接でも重要な部分です。よくある質問。今日はこの問題について詳しく説明します。

1. ページのレンダリング原理

面接では、面接官が次のような質問をすることによく遭遇します。ブラウザがページをレンダリングするために何をしているか知っていますか?

実際、これはフロントエンド検査における非常に古典的な質問であり、今日の「フロントエンドのパフォーマンスを最適化する方法」に関する議論の中核となる背景質問でもあります。パフォーマンスは問題の根本から始めなければなりません。したがって、フロントエンドのパフォーマンス最適化を適切に行うには、問題の原因を理解し、次にページレンダリングの原理を理解する必要があります。

ブラウザがページをレンダリングするプロセス全体が 2 つに分かれている場合、最初のステップは主にブラウザがページのレンダリングに必要なリソースを要求する部分であり、2 番目のステップはブラウザがリソースを取得してレンダリング部分を最適化する部分です。

最初の部分は主にネットワークなどの環境要因に依存し、2 番目の部分は「クリティカルレンダリングパス」の最適化要因に依存します。また、最適化計画の中で注目する必要がある部分でもあります。

クリティカルレンダリングパス図

(1)、ドムツリー

DOM は JS 経由でアクセスできるだけでなく、DOMスケーラブルベクターグラフィックス SVG、数学的マークアップ言語 MathML、同期マルチメディア統合言語 SMILには、この言語に固有のメソッドとインターフェイスが追加されています。HTML が解析されると、DOM ツリーが構築されます。以下のコードには、headerとmainの3 つの領域がありますfooter。そして外部ファイルstyle.cssとして。

上記のコードをHTMLブラウザでDOM树構造体に解析すると、各ノードの関係は次のようになります。

(2)、CSSOMツリー

CSSOMこれもオブジェクトベースのツリーです。DOM ツリーに関連するスタイルを処理します。

上記の CSS 宣言の場合、CSSOM树次のようになります。

cssの一部の属性は継承できるため、親ノードで定義された属性が条件を満たしていれば、子ノードにも対応する属性情報が保持され、最終的に対応するスタイル情報がページ上に描画されます。'

(2)、レンダーツリー:

ブラウザーは DOM ツリーを構築している間、別のツリーであるレンダーツリーも構築しており、その主な機能は、CSS 関連の知識を使用して、特定のレイアウトとスタイルに従って HTML を表示することです。MVC の観点からは、レンダーツリーは V、dom ツリーは M、C は HTMLDocumentParser などの特定のスケジューラと見なすことができます。

2. フロントエンドのパフォーマンス最適化の実践

(1) レンダリングクリティカルパスの最適化

(1)、HTML ファイルのサイズは可能な限り小さくする必要があります。

その目的は、クライアントができるだけ早く完全な HTML を受信できるようにすることです。通常、HTMLには冗長な文字がたくさんありますが、

例: JS コメント、CSS コメント、HTML コメント、ラティス、改行。さらに悪いことに、運用環境では、古いコードが多く含まれる HTML をたくさん見てきました。これは、時間の経過とともにプロジェクトがますます大きくなり、さまざまな理由で問題が歴史から残されていることが原因である可能性がありますが、とにかく、これはすべて悪いです。実稼働環境の HTML では、HTML ファイルをできるだけシンプルに保つために、無駄なコードを削除する必要があります。

(2)、CSSOM とレンダリングブロック CSS を最適化します。

CSS はレンダーツリーを構築するために不可欠な要素ですが、最初に Web ページを構築するときに JavaScript が CSS によってブロックされることがよくあります。必須ではないCSSが非クリティカルなリソース(印刷やその他のメディアクエリなど)としてマークされていることを確認し(図3.1 )、クリティカルなCSSの量が可能な限り削減され、配信時間が短縮されるようにする必要があります。できるだけ短く。

上記の最適化戦略に加えて、CSS にはパフォーマンスに影響を与える可能性のある別の要因があります。それは、CSS がクリティカルなレンダリングパスをブロックすることです。CSS は重要なリソースであり、重要なレンダリングパスをブロックすることは驚くべきことではありませんが、通常、すべての CSS リソースがそれほど「重要」であるわけではありません。

たとえば、一部のレスポンシブ CSS は画面幅が条件を満たした場合にのみ有効になり、一部の CSS はページの印刷時にのみ有効になります。これらの CSS は、条件を満たさない場合には有効になりません。では、なぜブラウザに不要な CSS リソースを待機させる必要があるのでしょうか。

図 3.1 に示すように

(3) CSS での @import の使用を避ける

CSS のロードに @import を使用しないようにすることは誰もが知っているはずです。実際の作業ではこのように CSS をロードしませんが、なぜでしょうか?

これは、@import を使用して CSS をロードすると、クリティカルパスの長さが余分に追加されるためです。例えば：

図 4.1 に示すように、 index.html ファイルで style.css をリンクし、 style.cssで main.css ファイルをインポートすると、2 つの依存ファイルが連続して読み込まれます。 2 つのファイルに費やした時間 (図 4.2)

図 4.1:

図 4.2:

図 4.3に示すように、index.html 内のリンクによって style.css と main.css を直接インポートすると、それらが並行して読み込まれるため、ファイルの読み込み時間が長くなります(図 4.4)。

(4)、jsファイルの読み込み方法を最適化します。

ブラウザーが HTML 解析プロセス中に Scripe に遭遇すると、ブラウザーは HTML ページのレンダリングをブロックし、ページリクエストを送信し、JS スクリプトコードを渡し、それを JS エンジンに渡してコードを実行します。実行が完了すると、ブラウザは HTML の解析を続けます。概略図は次のとおりです。

js ファイルをロードした後、html はブロックされませんが、継続時間を短縮することはできません。

async キーワードを使用して js ファイルを非同期的にロードしますが、js の実行により html のロードがブロックされます。

js ファイルを非同期的にロードするには defer キーワードを使用しますが、js の実行は遅延し、HTML のロードはブロックされません。

さらに、プリロードやプリフェッチなどの一般的なソリューションもあります。

(2) 設計パターン最適化の適切な活用

(1)、インスタンス化の繰り返しを防ぐためにシングルトンパターンを使用します。

多くの場合、ページ上で固定関数を持つ 1 つのクラスのみインスタンス化することが許可されています。これにより、コードの可読性と保守性が向上するだけでなく、パフォーマンスのオーバーヘッドが大幅に確保され、メモリ負荷のプレッシャーが軽減されます。インスタンス化できるクラスは 1 つだけですか? クラスについてはどうですか? 例は次のとおりです。

(2)、Flyweight モードを使用して大きなデータノード (ページングなどのシーン) をレンダリングします。

実際の開発シナリオでは、ページングなどのビッグデータフロントエンドレンダリングノードの必要性が頻繁に発生しますが、フロントエンド JS の直接操作が最もパフォーマンスを消費する動作であることがわかっています。パフォーマンスのオーバーヘッドを節約するには、次のようにする必要があります。 dom ノードの直接操作を減らすために最善を尽くします。この出発点に基づいて、デザインモードのエンジョイモードが良い解決策を提供します。

次に、Flyweight モードを使用しないページングロジックを見てみましょう。

フライウェイトモードを使用した後のコードは次のとおりです。

それは注目に値します：

Flyweight モードのデータ量がどれほど大きくても、コードはそれらの 5 つの DOM ノードのみを直接操作します。ページング動作は追加の DOM ノードを繰り返し追加するのではなく、同じ 5 つのノードの内容を変更するだけです。5 つのノードは常にFlyweight モードを使用しない場合、同じ数の DOM ノードが作成され、データ量に応じて表示属性が切り替わります。2 つのソリューションのパフォーマンス消費は明らかです。

(3)、スロットル（スロットル）と手ぶれ補正（デバウンス）の使い分け

アンチシェイクとスロットリングは通常、プロジェクト最適化の手段として使用され、一般にユーザーが短期間に複数の操作を迅速かつ頻繁に実行することによってアクションの実行をトリガーするのを防ぎます。たとえば、ユーザーが送信ボタンを複数回クリックしたり、フォームの複数回の送信をトリガーしたり、ユーザーがスクロールバーを引いたり、追加の読み込みを複数回トリガーしたりすることを防止します。

デバウンスの特徴は、イベントが連続してトリガーされた場合に、アクションが 1 回だけ実行されることです。

手ぶれ補正とスロットリングは本質的に異なります。アンチバウンスは複数回トリガーされますが、実行されるのは 1 回だけです。スロットリングは複数回トリガーされますが、実行されるのはサイクル内に 1 回だけです。

スロットリングの場合、スロットリング戦略は、各期間内にイベントが何回トリガーされたとしても、1 つのアクションのみを実行することです。前の期間が終了すると、別のイベントがトリガーされ、新しい期間が開始されます。同様に、新しい期間では 1 つのアクションのみが実行されます。

さらに、多くのデザインパターンがあります。興味のある方は、「JavaScript デザインパターン」という本を読んでください。ここでは、典型的な例をいくつか紹介します。

(3) その他の一般的な最適化ソリューション

(1)、遅延読み込み

リソースの遅延読み込み

読み込みのポイントは「遅延読み込み」です。あらゆるメディアリソース、CSS、JavaScript、画像、さらにはHTML遅延読み込みすることもできます。制限されたページコンテンツを一度に読み込むと、クリティカルレンダリングパスが改善される可能性があります。

ページをロードするときに、このCSSページ全体をロードしJavaScriptないでくださいHTML。
代わりに、1 つのイベントリスナーを追加しbutton、ユーザーがボタンをクリックしたときにのみスクリプトをロードすることができます。
Webpack遅延読み込み機能を完了するために使用します。

ここでは、純粋な JavaScript を使用した遅延読み込みのテクニックをいくつか紹介します。

たとえば、今度は別の. このような場合、タグに付属するデフォルトの属性を<img/>/<iframe/>利用できます。ブラウザがこのタグを認識すると、読み込みと.<img><iframe>loadingiframeimage

(2)、Web Worderの合理的な使用

ご存知のとおり、JavaScript は 1 つのスレッドで実行されます。すべてのタスクは 1 つのスレッドで実行されます。次のタスクは、現在のタスクが実行された後にのみ処理できます。それ以外の場合、後続のタスクは待機することしかできないため、完全な使用が制限されます。マルチコアコンピューターの計算能力。同時に、ブラウザでは JavaScript の実行は通常、スタイル計算、ページレイアウト、描画と並行してメインスレッド上で行われます。JavaScript の実行時間が長すぎると、必然的に他の作業タスクがブロックされます。フレームロスの原因となります。

この目的のために、一部の純粋なコンピューティング作業を Web Worker に移行し、JavaScript 実行のためのマルチスレッド環境を提供します。メインスレッドは、Worker サブスレッドを作成することで、独自のタスク実行圧力の一部を共有できます。Worker サブスレッドで実行されるタスクは、メインスレッドに干渉しません。タスクが完了すると、結果がメインスレッドに返されます。これには、メインスレッドが UI インタラクションの処理により集中できるという利点があり、ページの使用プロセスを体験してください。

(3)、スケルトン画面は白い画面の継続時間を最適化します。

スケルトン画面を使用すると、白い画面時間が短縮され、ユーザーエクスペリエンスが向上します。中国の主流の Web サイトのほとんどはスケルトン画面を使用しており、特に携帯電話の SPA シングルページアプリケーションでは、Vue や React に関係なく、最初の HTML は空白であり、コンテンツは JS をロードしてルートノードにマウントする必要があります。仕組み: 長時間白画面が発生します一般的なスケルトン画面プラグインはこの原理に基づいていますプロジェクトをパッケージ化する際、スケルトン画面の内容は html ファイルのルートノードに直接配置されますスケルトン画面プラグイン、パッケージ化されたHTMLファイル（ルートノードの内部がスケルトン画面）：

同じプロジェクトについて、スケルトンスクリーンを使用する前と後の FP ホワイトスクリーン時間を比較します。

スケルトンレス画面：白い画面が長時間持続します。

スケルトンスクリーン付き：白スクリーン

スケルトン画面プラグインの推奨: vue-skeleton-webpack-plugin

結論

フロントエンドのパフォーマンスの最適化は、フロントエンド開発の分野では常に古典的なトピックです。テクノロジーの発展に伴い、ますます多くのソリューションが登場しています。記事の長さに制限があるため、ここではいくつかの古典的な最適化ソリューションのみを説明します。ご興味がございましたら、さらに情報や書籍を共有してください。