Web パフォーマンスの問題

1. SPA（Single Page Application）の最初の画面の読み込み速度が遅い問題

First Contentful Paint とは、ブラウザがユーザーが入力した URL アドレスに応答してから、最初の画面のコンテンツがレンダリングされるまでの時間を指します. このとき、Web ページ全体が完全にレンダリングされる必要はありませんが、現在のウィンドウに必要なコンテンツを表示します。最初の画面読み込みは、間違いなくユーザーエクスペリエンスの最も重要な部分です。
最初の画面の時間を DOMContentLoad または performance.timing で計算できます。

// 方案一：
document.addEventListener('DOMContentLoaded', (event) => {
    
    
    console.log('first contentful painting');
});
// 方案二：
let 白屏时间 = firstPaint - performance.timing.navigationStart;

読み込みが遅い理由
ページのレンダリングの過程で、読み込み速度が遅くなる要因は次のとおりです。

ネットワーク遅延の問題
リソースファイルのサイズが大きすぎるかどうか
リソースが読み込み要求を繰り返し送信したかどうか
スクリプトをロードすると、レンダリングコンテンツがブロックされる

最初の画面のレンダリング時間を短縮するには多くの方法がありますが、これは一般に、リソース読み込みの最適化とページレンダリングの最適化の 2 つの部分に分けることができます。

いくつかの一般的な SPA 最初の画面の最適化方法

エントリーファイルのサイズを小さくする

ルートの遅延読み込みを使用して、関数の形式でルートを読み込みます。異なるルートに対応するコンポーネントは異なるコードブロックに分割され、ルートが要求されるとルートが個別にパッケージ化されるため、エントリファイルが小さくなり、読み込み速度が大幅に向上します。
コンポーネント: () => import('./components/header.vue')

静的リソースのローカルキャッシュ

バックエンドリターン: HTTP キャッシュを使用し、Cache-Control、Last-Modified、Etag およびその他の応答ヘッダーを設定します。Service Worker オフラインキャッシュを使用し、
フロントエンドで localStorage を合理的に使用します。

オンデマンドで読み込まれる UI フレームワーク

例: import {Button, Input} from 'element-ui';

画像リソースの圧縮

画像リソースはエンコード処理中ではありませんが、ページのパフォーマンスに最も影響を与える要因であり、画像リソースに対して適切な圧縮を行うことができます。
ページで使用されるアイコンについては、オンラインフォントアイコンまたはスプライト画像を使用して、多くの小さなアイコンを同じ画像に結合し、http 要求の圧力を軽減できます。

コンポーネントは再パッケージ化されています

A.jsファイルが一般的に使用されるライブラリであると仮定すると、A.jsファイルを使用する複数のルートがあり、ダウンロードが繰り返されます
.webpackの構成ファイルで、CommonsChunkPlugin構成のminChunks: 3を変更して、それが3回以上使用されたパッケージは抽出され、パブリック依存ファイルに入れられ、コンポーネントの繰り返しのロードを回避します

GZip 圧縮を有効にする

解凍後、gzip を使用して圧縮し、compression-webpack-plugin をインストールし、cnmp i compression-webpack-plugin -D を実行して、webpack 構成を変更します。
対応する設定はサーバー上でも行う必要があります. リクエストを送信するブラウザーが gzip をサポートしている場合は、gzip 形式のファイルを送信します.

const CompressionPlugin = require('compression-webpack-plugin')
configureWebpack: (config) => {
    
    
        if (process.env.NODE_ENV === 'production') {
    
    
            // 为生产环境修改配置...
            config.mode = 'production'
            return {
    
    
                plugins: [new CompressionPlugin({
    
    
                    test: /\.js$|\.html$|\.css/, //匹配文件名
                    threshold: 10240, //对超过10k的数据进行压缩
                    deleteOriginalAssets: false //是否删除原文件
                })]
            }
        }

SSRを使う

SSR (サーバー側)、つまり、サーバー側のレンダリング、コンポーネントまたはページは、サーバーを介して html 文字列を生成し、それらをブラウザーに送信します。
サーバーサイドレンダリングをゼロから構築するのは非常に複雑です. Nuxt.js を使用して vue アプリケーションのサーバーサイドレンダリングを実装することをお勧めします.

白い画面の問題

ホワイトスクリーン時間：ユーザーがリンクをクリックしたり、ブラウザを開いてURLアドレスを入力したりした後、画面が空白になってから最初の画面が表示されるまでの時間を指します。ページのレンダリング時間が短いほど、ユーザーの待ち時間が短くなり、ユーザーがページを認識する速度が速くなります。これにより、ユーザーエクスペリエンスが大幅に向上し、

ホワイトスクリーンプロセス。URLの入力からページの画面表示までの流れ

1. まずブラウザのアドレスバーにURLを入力
2. ブラウザはまずブラウザのキャッシュシステムキャッシュルーターキャッシュをチェックし、キャッシュにキャッシュがあればページの内容を直接画面に表示します。そうでない場合は、http 要求が開始されます。
3. http リクエストを送信する前に、対応する IP アドレスを取得するためにドメイン名の解決 (DNS 解決) が必要です。
4. ブラウザはサーバーへの tcp 接続を開始し、ブラウザとの tcp スリーウェイハンドシェイクを確立します。
5. ハンドシェークが成功すると、ブラウザーはサーバーに http 要求を送信して、データパケットを要求します。
6. サーバーは受信したリクエストを処理し、データをブラウザに返します.
7. ブラウザは HTTP レスポンスを受信します
. 8. ページのコンテンツを読み取り、ブラウザでレンダリングし、html ソースコードを解析します
. 9. 解析しますHTML ファイルを読み込み、DOM ツリーを構築します。CSSの解析、CSSOM Tree（CSSルールツリー）の構築
10. DOM TreeとCSSOM Treeのマージ、Render tree（レンダリングツリー）の構築、

リフロー (再配置): リフローとも呼ばれるレンダリングツリーに従ってノード情報 (レイアウト) を計算します。レンダリングツリーノードが変更されると、ノードの幾何学的プロパティ (幅、高さ、内側マージン、外側マージンなど) に影響します。または float、position、display: none; など)、ノードの位置が変更されます. このとき、ブラウザはリフロー (リフロー) をトリガーされ、レンダリングツリーを再生成する必要があります。たとえば、JS は p タグノードに新しいスタイル「display:none;」を追加します。その結果、p タグが非表示になり、p タグの後のすべてのノードの位置が変更されます。このとき、ブラウザはレンダリングツリーを再生成して再レイアウトする必要があります。
repaint ( redraw ): 計算された情報に従って、ページ全体 (Painting) を描画します。レンダリングツリーノードは変更されますが、ページ内のノードの空間位置とサイズには影響しません。たとえば、div ラベルノードの背景色、フォント色などが変更されても、div ラベルノードの幅、高さ、および内側と外側のマージンが変更されない場合、これによりブラウザーが再描画 (再描画) されます。

すべての dom の変更または css の幾何学的プロパティの変更により、ブラウザーの再配置/再描画プロセスが発生し、それが css の非幾何学的プロパティの変更である場合は、再描画プロセスのみが発生します。したがって、再配置は間違いなく再描画を引き起こし、再描画は必ずしも再配置を引き起こすとは限りません。

ブラウザーが HTML をダウンロードした後、最初にヘッダーコードを解析し、スタイルシートをダウンロードしてから、HTML コードを下方向に解析し続け、DOM ツリーを構築し、同時にスタイルシートをダウンロードします。DOM ツリーが構築されたら、すぐに CSSOM ツリーの構築を開始します。スタイルシートのダウンロード速度が十分に速く、DOM ツリーと CSSOM ツリーが並列プロセスに入り、2 つのツリーが構築されると、レンダリングツリーが構築されてから描画されることが理想的です。
ヒント: HTML の解析に対するブラウザーのセキュリティ解析戦略の影響:
HTML を解析する場合、インライン JS コードに遭遇すると DOM ツリーの構築がブロックされ、JS コードが最初に実行されます; CSS スタイルファイルがダウンロードされていない場合、 HTML の解析中にインライン JS コードが検出されると、ブラウザは JS スクリプトの実行と HTML の解析を一時停止します。CSS ファイルのダウンロードが完了するまで、CSSOM ツリーの構築が完了し、元の解析が再開されます。
JavaScript は DOM 生成をブロックし、スタイルファイルは JavaScript の実行をブロックします. したがって、実際のプロジェクトでは、JavaScript ファイルとスタイルシートファイルに焦点を当てる必要があります. 不適切な使用はページのパフォーマンスに影響します.

白い画面 - パフォーマンスの最適化

DNS 解決の最適化

DNS（Domain Name System）とはDomain Name Systemの英語の略で、システム内の各ホストのIPとホスト名（ドメイン名）との対応を維持する組織のシステム管理機関です。

DNS ルックアップリンクの DNS 解決を最適化します。
1. DNS キャッシュの最適化
2. DNS プリロード戦略
3. 安定した信頼性の高い DNS サーバー

TCP ネットワークリンクの最適化
サーバーサイド処理の最適化
バックエンドの最適化
ブラウザのダウンロード、解析、レンダリングページの最適化
1) HTML コードと構造を可能な限り合理化する
2) CSS ファイルと構造を可能な限り最適化する
3) JS コードを合理的に配置し、インライン JS コードを使用しないようにする
4) インライン化スクロールせずに見えるコンテンツを HTML にレンダリングするために必要な重要な CSS により、CSS のダウンロードが大幅に高速化されます。HTML のダウンロードが完了してからレンダリングすることができ、ページのレンダリング時間を早めることで、最初の画面のレンダリング時間を短縮 5) 最初の画面の
不要な画像の読み込みを遅らせ、必要な画像の読み込みを優先する最初の画面

JavaScript は DOM 生成をブロックし、スタイルファイルは JavaScript の実行をブロックするため、実際のプロジェクトでは JavaScript ファイルとスタイルシートファイルに焦点を当てる必要があり、不適切な使用はページのパフォーマンスに影響します。

ロングリストデータ

表示するデータが 10,000,000 個ある場合、ユーザーエクスペリエンスを向上させるためにどのような最適化を行う必要がありますか?

(1)データのページング、ページングの原則を使用して、サーバーは毎回一定量のデータのみを返し、ブラウザは毎回その一部のみをロードします。

(2)遅延ロード方式を使用して、データの一部を毎回ロードし、必要に応じて残りのデータをロードします。

(3)配列ブロック技術を使用して、基本的な考え方は、処理するアイテムのキューを作成し、タイマーを設定してデータの一部を時々フェッチし、タイマーを使用して次のアイテムをフェッチすることです。処理するアイテムを処理してから、別のタイマーを設定します。

(4)仮想リスト、ビューポートを必要とする部分のみがレンダリングされるたびに

1. SPA（Single Page Application）の最初の画面の読み込み速度が遅い問題

白い画面の問題

ロングリストデータ

おすすめ