これはルーチンのないフロントエンドブロガーです。彼はあらゆる種類のフロントエンド指向の操作に熱心です。彼は思いついたときにどこでもよく書きます。テクノロジーとフロントエンド効果に興味がある場合は、メッセージを残してください〜ブロガーそれを見た後、全員のためにピットを踏みます。
ホームページ:オリバー・インのホームページ
座右の銘：転んでも起き上がれ〜
目次
4.2 リソースの送信とダウンロード (フロントエンドとバックエンドの対話)
I.はじめに
最近、パートナーがプロジェクト内でパフォーマンスに関連するいくつかの問題に遭遇したため、フロントエンドのパフォーマンスを最適化するためのいくつかの方法について話し合いました。この記事を作成しました~
辛抱強く読んでください、何かを得られるかもしれません〜
2. コンテンツ概要
この記事では、まずページのライフサイクルからリンクプロセス全体を理解し、各プロセスで最適化できるポイントを簡単にまとめます。この記事では具体的な方法はありませんが、最初に概要を説明します。この記事の一般的な内容は次のように要約されます。
3. ページのライフサイクル
ライフサイクルとは何ですか? 平たく言えば、物が生まれてから死ぬまでの過程のことであり、これをライフサイクルと呼びますが、ページに当てはめると、ライフサイクルは当然、ページの誕生からページの作成までを指します。
それで、考えてみましょう、ページの誕生はいつ始まったのでしょうか? ページ上のレンダリングは Vue にマウントされたものと似ていますか? 実際には、そうではありません。ページのライフサイクルは、ブラウザーに入力された URL からページがレンダリングされるまでカウントされる必要があります。
一般的なプロセスは次のとおりです。
ブラウザに url を入力すると、ブラウザは最初にurl のネットワーク リクエスト スレッドを作成します。作成プロセス中に、ホストの解析、ポート プロットの解析など、URL が解析されます。
作成が完了したら、当然のことながらhttp リクエストの作成を 開始します。このリクエストのプロセスでは、通常「3 つのハンドシェイク、4 つのウェーブ」と呼ばれる処理が行われます。
リクエストが正常に確立されると、バックエンドはフロントエンド パッケージをデータ パケットの形式でブラウザに送信します。このフロントエンド パッケージは、毎日のフロントエンド開発プロジェクトのコードであり、主に Html+CSS+Javascript です。
ブラウザはデータ パケットを受信した後に動作を開始し、その作業はブラウザ内のレンダリング プロセス に存在します。おおよそ次のとおりです。
では、これはパフォーマンスの最適化とどのような関係があるのでしょうか? このリンクのいずれかのリンクに問題がある場合、それはエンド ユーザーの認識に反映され、「Web ページを開くことができない」、「開くのが非常に遅い」、「深刻な問題が発生している」、その他の問題;
したがって、完全なリンクを知ることによってのみ、このリンク内の各リンクを最適化し、フロントエンドのパフォーマンスの最適化という最終目標を達成することができます。
私たちが毎日話しているパフォーマンスの最適化は、多くの場合、コード レベルの 4 番目のリンクを対象としていますが、これだけでは問題を解決できない場合もあります。パフォーマンスに問題がある場合、最初に確認するのは、パフォーマンスの問題がどのリンクにあるのかです。に登場〜
4. パフォーマンスの最適化
4.1 http リンクの最適化を確立する
このリンクにおける最も重要な最適化は、http リクエストの数を減らすことです。これが最適化の中心的な目的です。最も直接的な方法は、リソースをマージすることです。たとえば、通常の状況では、取得するには 2 つの http リクエストを開始する必要があります。リソース: 一部の構築方法では、2 つのリソースがパッケージ化されて 1 つにマージされるため、要求は 1 つだけです。
もちろん、http リクエストの削減には、遅延読み込み手法の使用も含まれます。たとえば、画像のリクエストは、画像が表示領域に表示される直前に行う必要があります。
次に http プロトコルです。もちろん、最新のブラウザのプロトコルはアップグレードされています。通常の状況では、この最適化ポイントを行う必要はありません。http1.0 プロトコルでは、「3 ハンドシェイク、4 ウェーブ」のプロセスが行われています。 , http リクエストを継続的に作成する必要があります。http1.1 以降に達すると、この時点で tcp プロトコルを再利用できますが、プロジェクトが実際に http1.0 プロトコルである場合は、アップグレードする時期が来ています...
4.2 リソースの送信とダウンロード (フロントエンドとバックエンドの対話)
フロントエンドの観点から見ると、このリンクで実行できる最適化はまだ多くありません。主な目的は大きく 2 つあります。
- リソースを圧縮し、応答パケットのサイズを削減します。
- リソースをダウンロードするリクエストを繰り返し送信することを避けるために、いくつかのキャッシュ技術を使用してください。
最初のポイントは、リソースを圧縮してデータ パッケージを削減することです。これにより、Vue や React のような単一ページ アプリケーションの最初のロード時間が短縮されます。一般的なものはwebpackやrollupなどのツールです。これらのツールを使用すると、コード ロジックに影響を与えることなくコード サイズを大幅に削減できます。
さらに、これらのツールは、パッケージ化プロセス中に同時にリソースをマージすることがよくあります。たとえば、最初は 3 つの js ファイルを作成しました。パッケージ化後、ツールは自動的にそれらを 1 つのツールにマージするのに役立ちます。これらのツールを上手に活用することは、最適化されたもの。
2 番目のポイントは、いくつかのキャッシュ テクノロジを使用することです。ブラウザには通常、これらのキャッシュ テクノロジ用の一連のデフォルトの実行メソッドがあります。したがって、シングルページ アプリケーションは、初回ロード時にのみすべてのリソースを要求し、2 回目からはキャッシュを使用することがよくあります。ただし、ここで注意すべき点が 1 つあります。キャッシュにより、タイミングの悪い更新も発生します。たとえば、コンテンツは更新されますが、ユーザーは依然として古いリソースを使用します。したがって、キャッシュは諸刃の剣であり、合理的なキャッシュ戦略です。最適化もされています。
4.3 レンダリングの最適化
このリンクは、フロントエンドが日常生活で実際に注意を払う必要があるものです。上記の 2 つのリンクとは異なります。上記の 2 つのリンクは、実際には主にツールの使用に関するものであり、特に足場上に構築されたプロジェクトの場合に当てはまります。彼らは独自のパッケージ化ツールを合理的に使用しており、圧縮とマージの問題を解決できます。
しかし、このリンクは違います。パフォーマンスを向上させるには、私たちが毎日書くコードが必要です。個人的には、核となるのは、不必要な再描画とリフローを減らし、合理的なコード作成と不要な変数の手動リリースだと思います。
パフォーマンスが厳しい場合、高パフォーマンスの操作によりブラウザが応答しなくなる可能性が高く、応答がなくなった場合、これを行う唯一の方法はブラウザを閉じることです。
再描画とリフローについては皆さんも理解していると思いますが、最後の 2 点について簡単に説明します。合理的なコードの意味としては、無限ループなどの論理エラーが発生してはなりません。無限ループが発生すると、その結果は言うまでもありません...
次のステップは、不要な変数を手動で解放することですが、毎日の実装は基本的に整っておらず、次のようなブラウザのガベージ コレクション メカニズムに依存していると感じます。
// 通过接口获取到了一大串数据
let result = {//...后台数据}
function handle(){
// 正对数据进行了一大串的操作
}
// 结束以后释放
result=null一連の操作を実行した後、このデータが必要なくなった場合は、変数結果を手動で解放する必要があります。この方法でのみ、キャッシュ内のデータがクリアされ、保持されなくなります。そうでない場合は、待つしかありません。ブラウザ自体がガベージ コレクション メカニズムを実行するまでクリーンアップされます。ブラウザ自身の実行はほとんどの場合大きな問題ではありませんが、何と言うか、ガベージ コレクション メカニズムはクリーンアップするだけで、変数は使用されなくなります。場合によっては、コーディングの問題により変数が常に占有されているため、ブラウザーがそれらをクリーンアップせず、メモリがますます蓄積されて最終的に最終的な結果が得られます。
V. まとめ
本稿ではリンク全体を俯瞰的に最適化できる点を中心に説明しますが、最適化方法としては大きく分けて以下のような方法があります。
- 読み込みの最適化の目的は、http リクエストと遅延読み込みテクノロジを削減することで、最初の画面の読み込み時間を短縮することです。
- 構築の最適化の目的は、リソースの量と量を削減し、webpack などの主流の構築ツールを合理的に使用してリソースをマージおよび圧縮することです。
- キャッシュの最適化の目的は、リクエストの繰り返しを避けることですが、メリットとデメリットがあるため、キャッシュ戦略を慎重に検討する必要があります。
- レンダリングの最適化。その目的は、再描画とリフローの削減、合理的なコード、リソースのタイムリーなリリースなど、高パフォーマンスの操作を削減することです。