これらの Vue プロジェクトのパフォーマンスを最適化する方法を集めれば、いつか使えるようになるでしょう。
- 青灯夜游転載
- 2022-04-29 11:04:174381ブラウズ
vue プロジェクトのパフォーマンスを最適化するにはどうすればよいですか?次の記事では、vue プロジェクトで必ず使用されるパフォーマンスの最適化方法をいくつか紹介します。皆さんのお役に立てれば幸いです。
言及パフォーマンスの最適化 大勢の前での面接の経験を鮮明に覚えていますか?いずれにせよ、私の意見では、フロントエンド分野ではパフォーマンスの最適化が常に 人気の王様 になります。
私が最近管理したプロジェクトは、たまたまこの方向に多大な労力を費やしたものです。皆さんの役に立つことを願って、いくつかの経験を共有したいと思います。
パフォーマンス最適化標準
パフォーマンスの最適化について話しているのですから、認識された標準が必要です。これは私たちが何度も聞いてきたことです Lighthouse
多くのユニットには独自のパフォーマンス監視プラットフォームがあります。対応する SDK を導入するだけで、プラットフォーム上でパフォーマンスを分析できます。誰もがページのパフォーマンスの問題について知りませんでしたか?
実際、特別なカスタマイズを必要とする要求の厳しいビジネスを除いて、ほとんどの場合、私たちの部門のパフォーマンス最適化プラットフォームは本質的にヘッドレス ブラウザ (Puppeteer) を使用して Lighthouse を実行します。
ユニットのパフォーマンス監視プラットフォームの原理を理解した後、ターゲットを絞ったパフォーマンスの最適化、つまり Lighthouse
# #Lighthouse# のプログラミングを実行できます。
##Lighthouse は、Google Chrome によって起動されたオープン ソースの自動化ツールです。複数の最新の Web ページのパフォーマンス指標を収集し、Web アプリケーションのパフォーマンスを分析し、開発者向けにパフォーマンス分析を行うためのレポートを生成できます。参照方向を示します。 <p></p>と言えば、Lighthouse は最新の Google Chrome に統合されました
First Contentful Paint(First Contentful Paint)。これは、ブラウザが最初にコンテンツ (テキスト、画像、キャンバスなど) を画面に描画する時点です。
インタラクティブ時間（インタラクティブまでの時間）。すべてのページ コンテンツが正常にロードされ、ユーザーの操作に迅速に応答できる時点を指します。
合計ブロック時間 (合計ブロック時間)。最初のコンテンツフル ペイント (FCP) からインタラクティブ化までの時間 (TTI)
最大コンテンツフル ペイントまでの合計時間を指します。このメトリクスは、ビューポート内に表示される最大の画像またはテキスト ブロックのレンダリング時間を報告します
- 累積レイアウト シフト
(# 累積レイアウト シフト)。これは、ページの存続期間中に要素が発生するたびに発生する予期しないレイアウトのシフトのスコアの合計として測定されます。 2 つのレンダリング フレームでビジュアル要素の開始位置が異なるたびに、LS (Layout Shift) が発生すると言われます。
通常の状況では、私の経験によれば、パフォーマンス監視プラットフォームとローカル プラットフォームの
により、ローカル システムは ## に到達する必要がある場合があります。 #70点、オンラインのみで合格ステータスを達成することは可能です。パフォーマンスの最適化が必要な場合は、適切に処理できます（ただし、合格で十分だと思います。結局のところ、という格言があります）大学試験: 60 点万歳、61 点は無駄です 、継承を失うことはできません、より重要なことにもっと時間を費やさなければなりません!) 一般的な従来の最適化手法
lighthouse
の優れた点は、ページ内の一般的なパフォーマンスのボトルネックを検出し、次のような最適化の提案を行うことができることです。 <p></p>
- 未使用の javascript<p></p>
- レンダリングをブロックするリソースを削除します<p></p>
- 画質圧縮<p></p>
- 使用するフォントの数を制限し、使用するフォントの種類をできる限り少なくします<p></p>
- クリティカル レンダリング パスを最適化します。現在のページ レンダリングに必要なリソースのみを読み込み、ページ レンダリングの完了後に二次リソースを読み込みます<p></p>
一般的なパフォーマンス最適化分析
Lighthouse には 6 つのパフォーマンス指標があることがわかっており、これら 6 つの指標のうち、
LCP、FCP、速度指数、これら3 つの指標は特に重要です。通常の状況では、これら 3 つの指標は TTI、TBT、CLS
0.8 秒
モバイル端末 に基づいています (モバイル端末が使用される理由は、PC の強力な計算能力とパフォーマンスのボトルネックがほとんどないためです)。ページには次のコンテンツが必要です。スコアを取得するには、コンテンツには、svg 要素内に埋め込まれた次の
- 画像要素が 1 つ以上含まれている必要があります。
- video 要素 (カバー画像を使用)
- 要素(
- CSS グラデーション を使用するのではなく) url() 関数を介してロードされた背景画像 #テキスト ノードまたは他のインライン レベルのテキスト要素の子を含む ブロック-レベル要素
- 。 #そうしないと、次のエラーが発生します
FCP (First Contentful Paint)
名前が示すように、First Content Painting です。最初にページに描画されましたが、現在開発中のページはすべてスパ アプリケーションであるため、フレームワーク レベルでの初期化には確実に一定の
パフォーマンス損失が発生します。たとえば、空のスキャフォールディングを初期化すると、パッケージ化後、デプロイメントのために CDN にアップロードした後、FCP が 0.8 秒から 1.5 秒に増加します。vue の差分が free ではなく、パフォーマンスも向上することがわかります。損失。 (学習ビデオ共有: vuejs チュートリアル)ページのコンテンツを最適化する前に、次の 3 つの前提事項を宣言します
FCP を改善する時期は実際に最適化する
クリティカル レンダリング パスそれがスタイル ファイル (CSS ファイル) の場合、ブラウザはページをレンダリングする前にそれを完全に解析する必要があります (これがそう言われる理由です) CSS レンダー ブロック)
スクリプト ファイル (JavaScript ファイル) の場合、ブラウザは次の操作を行う必要があります。解析を停止し、スクリプトをダウンロードして実行します。 JavaScript スクリプトはページのコンテンツ (特に HTML) を変更する可能性があるため、この後にのみ解析を続行できます。 (これが、JavaScript が解析をブロックする理由です)
上記のユースケース テストに基づいて、どのように最適化しても、フレームワーク自体のパフォーマンスの低下は消去できないことがわかりました。私たちができること 目的は、フレームワークが初期化をより早く実行できるようにし、より少ないコンテンツを初期化できるようにすることです。実行できる最適化方法は次のとおりです:
使用されていないすべての js ファイル初期化用のプラグインは非同期で読み込まれます。つまり、
defer- または
- asnyc
を追加し、CDN を必要とするいくつかのサードパーティ プラグインをページの下部に配置する必要があります (上部に配置されると、その解析により HTML の解析が妨げられ、CSS やその他のファイルのダウンロードに影響します。これは
Yahoo 軍事規則)js ファイルの解凍では、vue-cli を例に挙げます。通常の状況では、cli 設定の SplitChunks を使用してコード分割を行い、一部のサードパーティ パッケージを CDN に移動するか、それらを解凍できます。ルートがある場合は、ルートを解凍して、各ルートが現在のルートに対応する JS コードのみをロードするようにします ファイル サイズを最適化してフォントを削減します。パッケージ、css ファイルと js ファイルのサイズ (もちろん、これらのスキャフォールディングはデフォルトで行われています)プロジェクト構造を最適化します。各コンポーネントの初期化には
パフォーマンスの損失があります。保守性を確保することに基づいて、初期化をできるだけ減らすようにしてください。可能なコンポーネントのロード数ネットワーク プロトコル レベルでの最適化この最適化方法では、サーバーが純粋なフロントエンドと連携する必要があり、実現できません。 ##クラウド サーバー
が普及しているため、当社の組織では通常、gzipの有効化、cdnの使用など、クラウド サーバーでこれらの最適化方法をデフォルトで有効にしています。実際、それについて話しましょう。FCP を改善するための中心となる概念は、次の 2 つだけです。
と 初期ダウンロードのリソース サイズを削減する
名前が示すように、最大コンテンツ描画
、LCP を報告するタイミングと公式はこう述べていますこの潜在的な変更に対処するために、ブラウザー A largest-contentful-paint
PerformanceEntry は次のようになります。最初のフレームが描画された直後に配布され、最大のコンテンツ要素を識別するために使用されます。ただし、後続のフレームがレンダリングされた後、最大のコンテンツ要素が変更されると、ブラウザは別の PerformanceEntry を送出します。 たとえば、テキストとヘッダー画像を含む Web ページでは、ブラウザーは最初にテキスト部分のみをレンダリングし、その間に largest-contentful-paint
属性は通常、<p></p> または <h1></h1> を参照します。次に、最初の画像の読み込みが完了すると、ブラウザは element 属性が <img alt="これらの Vue プロジェクトのパフォーマンスを最適化する方法を集めれば、いつか使えるようになるでしょう。" > を参照する 2 番目の largest-contentful-paint エントリを送出します。 要素は、レンダリングが完了してユーザーに表示された後にのみ最大コンテンツ要素とみなされ得ることに注意してください。まだロードされていない画像は「レンダリング」されたとは見なされません。 フォント ブロック期間中にWebフォントを使用するテキスト ノードにも同じことが当てはまります。この場合、小さい要素が最大のコンテンツ要素として報告される可能性がありますが、大きい要素のレンダリングが完了すると、別の
オブジェクトを通じて報告されます。 実際、現地語での説明は、通常の状況では、写真、ビデオ、および大量のテキストが描画された後、 が LCP に報告するというものです
これを理解する, 最適化方法 明らかです。これらのリソースのサイズをできるだけ小さくするだけです。テスト後、最初の画面にレンダリングされる写真とビデオ コンテンツのサイズを小さくした後、全体のスコアが大幅に向上しました。いくつかの最適化方法が提供されています。
https://tinypng.com/
インターフェイスにはピクチャが付属しており、通常はユニット単位で入手可能です。対応する oss または cdn パラメータ転送設定により、アドレス バー パラメータ転送メソッドを通じて画質が制御されます。- 画像の遅延読み込み<p></p>
- <p></p> SpeedIndex
Speed Index視覚的なページ読み込みの視覚的な進行状況を使用して計算しますコンテンツのレンダリング速度の合計スコア。これを行うには、まず、ページ読み込み中のさまざまな時点で「完了」したセクションの数を計算できる必要があります。 WebPagetest では、これは、ブラウザーに読み込まれているページのビデオをキャプチャし、各ビデオ フレームをチェックすることによって行われます (ビデオ キャプチャを有効にしたテストでは 1 秒あたり 10 フレーム)。このアルゴリズムについては以下で説明しますが、今のところは、各ビデオ フレームに対する完全なパーセンテージ (各フレームの下に表示される数値)
上記は計算方法の公式の説明です。実際、一般に、いわゆる速度指数は、ビデオ フレームがどのくらい速いかを示す尺度です。ページのコンテンツが埋められています##百聞は一見に如かず
#テスト後、LCP、写真、およびビデオ コンテンツは、すべての最適化方向で SpeedIndex に多大な影響を及ぼします。これは前のものと同様です。一般的に言えば、LCP と FCP 時間が増加する限り、SpeedIndex 時間は大幅に改善されます。
ただし、インターフェイスの速度も SpeedIndex 時間に影響することに注意してください。今日では AJAX の人気により、ほとんどのデータはインターフェイスを使用して取得されます。インターフェースの速度が遅すぎると、ページの初期レンダリングに影響し、パフォーマンスの問題が発生します。したがって、パフォーマンスを最適化しながら、バックエンド パートナーの支援をリクエストすることもパフォーマンス最適化の解決策です
パフォーマンスのボトルネックのトラブルシューティング
上記の分析では、3 つの指標に基づいた従来の最適化手法がいくつか提供されています。これらの最適化手法のうち、いくつかはすぐに確認して最適化することができます。例:
最適化イメージ、フォント サイズの最適化
サーバーと連携してブラウザ キャッシュ メカニズムを利用します。cdn を有効にし、gzip を有効にするなど。
-
ネットワーク プロトコルを削減します。プロセス消費、http リクエストの削減、DNS クエリの削減、リダイレクトの回避
# - ##重要なレンダリング パスの最適化、js の非同期読み込みなど。<p></p>
パッケージの内容を分析する #通常の状況では、判断できない最適化ポイントはすべてパッケージング後にあり、それらがパッケージング上で必要なものではないことを分析することはできません。現在の問題を解決するために、新たな最適化を行うことはできません。大手バンドル メーカーも独自の分析パッケージ ソリューションを持っています。
vue-cli を例に挙げます
"report": "vue-cli-service build --report"
私たちだけです。スキャフォールディングを使用する必要がある 上記のコマンドを提供することで、パッケージング時に生成できます パッケージ全体の解析ファイル
<p></p>
# が上図に示されています。パッケージ化された js ファイルに含まれる内容を分析できます。このようにして、どのファイルが同期的にロードする必要がないのかを知ることも、CDN を使用して構成を通じてそれらのファイルを個別に分離して、パフォーマンスの問題を見つけることもできます
下図のように、
<p></p>
のコードカバレッジチェックが利用できます。それらの js または css ファイルを知るための devtool コードは使用されていません。パッケージの内容の分析と組み合わせることで、パフォーマンスのボトルネックがどこにあるかを大まかに推測し、対応する特別な処理を実行できます
上記の内容は、どこにでもある一般的な最適化手法であり、従来の最適化を行う根本的な理由を述べただけです。これらの理由をより明確に理解すると、
パフォーマンスのボトルネックを面接のために暗記するのではなく、実際に使用しても機能しないのではなく、簡単に対処できるようになります。
では、当社は Vue です。Vue のメソッドを使用する必要があります。
画像の遅延読み込み画像のいわゆる遅延読み込みこれは、ページが現在表示されている領域内の画像のみをレンダリングすることを意味します。これにより、レンダリングする他の画像の数が減り、
SpeedIndex と LCP の時間が大幅に改善され、スコアが向上します。
<p></p><p></p>https://github.com/hilongjw/vue -lazyload
使いやすく、機能が豊富- <p></p>
仮想スクロール長いリストが含まれるページを見つけたことがありますか?下にスライドすればするほど行き詰まってしまう場合は、仮想スクロールが便利です。 その基本原理は、表示領域内のいくつかのデータのみをレンダリングしますが、通常のスライドの効果をシミュレートすることです。毎回、再生領域内のデータのみをレンダリングするため、スライド時のパフォーマンスは大幅に向上します。
<p></p>vue では使いやすい 2 つのプラグインがあります:<p></p><p></p>vue-virtual-scroller: https://github.com/Akryom/vue- virtual-scroller
現在、当社では vue-virtual-scroll-list を使用しています。下にスクロールすると、ページング領域に読み込みプロンプトを追加できます- <p></p>
vue-virtual-scroll-list: https://github.com/tangbc/vue-virtual-scroll-list- <p></p>
vue の機能コンポーネント vue では、コンポーネントの初期化がパフォーマンスを消費することがわかっています。試してみてください。vue を使用してテキスト コンテンツを直接レンダリングしたり、app.vue コンポーネントを直接レンダリングしたりすると、スコアはわずかに高くなります。 違いがある。
しかし、機能コンポーネントがあれば、この問題は簡単に解決されます。
関数はコンポーネントであるため、名前が示すとおり、関数です。端的に言えば、
render function. 少ないです コンポーネントの初期化プロセスが不要になり、初期化プロセスの オーバーヘッドが大幅に節約されます
コンポーネントがビジネス ロジックがなく、コンテンツのみが表示される場合、機能コンポーネントが役に立ちます。
<p></p>v-show と KeepAlive を使用して dom を再利用します# 我们知道v-show是通过display 控制dom的展示隐藏，他并不会删除dom 而我们在切换v-show的时候其实是减少了diff的对比，而KeepAlive 则是直接复用dom，连diff 的过程都没了，并且他们俩的合理使用还不会影响到初始化渲染。如此一来减少了js 的执行开销，但是值得注意的是， 分批渲染组件 在前面我们提到过SpeedIndex 的渐进渲染是提高SpeedIndex的关键，有了这个前提，我们就可以分批异步渲染组件。先看到内容，然后在渲染其他内容 举个例子： 上述例子比较简单可能描述的不太贴切，在这里特此说明一下，当前方法适用于组件内容较多，每次render 时间过长，导致白屏时间过长，比如， 性能优化一直是一个很火的话题， 不管从面试以及工作中都非常重要，有了这些优化的点，你在写代码或者优化老项目时都能游刃有余，能提前考虑到其中的一些坑，并且规避。 但是大家需要明白的是，不要为了性能优化而性能优化，我们在要 原文地址：https://juejin.cn/post/7089241058508275725 作者：好学习吧丶他并不能优化你初始化的性能，而是操作中的性能<template>
<div>
{{ data1 }}
</div>
<div v-if="data1">
{{ data2 }}
</div>
</template>
<script>
import { ref } from 'vue'
export default {
setup() {
let data1 = ref('')
let data2 = ref('')
// 假设 这是从后端取到的数据
const data = {
data1: '这是渲染内容1',
data2: '这是渲染内容2'
}
data1.value = data.data1
//利用requestAnimationFrame 在空闲的时候当前渲染之后在渲染剩余内容
requestIdleCallback(() => {
data2.value = data.data2
})
return {
data1,
data2
}
},
}
</script>一次拉取用户列表，那么分批渲染就非常合适，先展示一部分用户信息，最后直到慢慢将所有内容渲染完毕。如此对浏览器的SpeedIndex 也非常友好最后
因地制宜，在不破坏项目可维护性的基础上去优化，千万不要你优化个项目性能是好了，但是大家都看不懂了，这就有点得不偿失了，还是那句话，60分万岁61份浪费，差不多得了，把经历留着去干更重要的事情！