実践ガイド - フロントエンドのパフォーマンスが 270% 向上 | JD Cloud テクニカルチーム

1. 背景

要件を次々と開発することにうんざりしていると、Web サイトのパフォーマンスに注意を払うことを忘れがちで、あるノードに到達すると、コードがどんどん蓄積されて Web サイトの速度がどんどん遅くなっていることに気づきます。。

このような背景から、この記事では Web サイトのフロントエンドパフォーマンスの最適化を目指し、パフォーマンスの最適化を再度行うのではなく、日常の開発中に高いパフォーマンスを維持できるようにするための一連の開発習慣をまとめます。

インジケーター名	最適化前	最適化された	推進する
ライトハウスのパフォーマンススコア	29	81	279%
FCP (First Contentful Paint の最初のコンテンツ描画)	0.7秒	0.7秒
LCP (Largest Contentful Paint の最大コンテンツ描画)	6.2秒	2.5秒	248%
TTI (Time to Interactive インタラクティブ時間)	10.1秒	2.1秒	480%
スピードインデックス	5.6秒	1.8	311%
TBT (Total Blocking Time) 合計ブロッキング時間	820ミリ秒	120ミリ秒	683%

最適化前後の比較:

最適化前後の比較

2. 最適化前

次のステップでは、最適化の前にどのようなイベントを実行する必要があるかを紹介します。

パフォーマンス指標と測定ツールについて学ぶ
最適化が必要な箇所を分析する

1. 測定ツールとパフォーマンス指標を理解する

当初は、Web サイトを開いたときに白画面の時間が長く、パフォーマンスが比較的悪いと感じていましたが、具体的にはどのようなパフォーマンス指標に注意を払う必要があるのでしょうか?

ここでは Chrome devtools に組み込まれたLighthouseを使用しています。Lighthouse は、Web アプリケーションの品質を向上させるためのオープンソース自動化ツールです。

Lighthouse は、さまざまなデバイスサイズやさまざまなネットワーク速度などの一連のテストの下で Web ページを実行します。また、色のコントラストや ARIA のベストプラクティスなどのアクセシビリティガイドラインにページが準拠しているかどうかもチェックします。

Chrome devtools Lighthouse を開いて使用します。

Lighthouse は比較的短期間でそのようなレポートを提供できます。

このレポートは、パフォーマンス、アクセシビリティ、ベストプラクティス、SEO、PWA の 5 つの領域でページを分析します。パフォーマンスの観点からは、時間のかかる一般的な統計がいくつか示されます。

最適化前

1.1 パフォーマンス

次の指標を含むパフォーマンススコア統計:

1.1.1 FCP

FCP は、ユーザーがページに移動した後、ブラウザーが DOM コンテンツの最初の部分をレンダリングするのにかかる時間を測定します。ページ上の画像、白以外の要素、SVG は<canvas>DOM コンテンツとみなされ、iframe 内のすべては除外されます。

1.1.2 LCP

LCP は、ビューポート内の最大のコンテンツ要素がいつ画面にレンダリングされるかを測定します。これは、ページのメインコンテンツがユーザーにいつ表示されるかを概算します。

LCP の計算は動的なプロセスであることに注意してください。下図の最後の図は、このページの最大のコンテンツ描画要素です。

LCP

1.1.3 TTI

TTI は、ページが完全に対話するのにかかる時間を測定します。

TTI はどのように計算されますか? 以下の図に示すように、まず、時間軸で少なくとも 5 秒の継続時間を持つクワイエットウィンドウが前方に検索されます (クワイエットウィンドウとは、長いタスクがなく、ネットワーク取得リクエストが 2 つ以下であることを意味します)処理中)、時間軸に沿って逆方向にクワイエットウィンドウの前にある最後の長いタスクを検索します。長いタスクが見つからない場合、実行は FCP ステップで停止します。TTI は、その前の最後の長いタスクの終了時刻です。 Quiet window. 長いタスクが見つからない場合、FCP 値と同じになります。

TTI

1.1.4 速度指数

Speed Index は、ページの読み込み中にコンテンツが視覚的に表示される速度を測定します。Lighthouse はまず、ブラウザーに読み込まれるページのビデオをキャプチャし、フレーム間の視覚的な進行状況を計算します。

1.1.5 未定

TBT は、マウスのクリック、画面のタップ、キーボードの押下などのユーザー入力に対するページの応答がブロックされる合計時間を測定します。

合計は、最初のコンテンツフルペイントとインタラクティブまでの時間の間のすべての長いタスクのブロック部分を追加することによって計算されます。実行に 50 ミリ秒を超えるタスクは長いタスクです。

50 ミリ秒後の時間がブロック部分になります。たとえば、Lighthouse が 70 ミリ秒の長さのタスクを検出した場合、ブロック部分は 20 ミリ秒になります。

下図の薄赤の部分の合計時間がこのページのTBTスコアとなります。

1.2 ベストプラクティス

ドキュメントタイプが含まれているかどうか、画像の縦横比が正しいかどうかなど、Web アプリケーションの全体的なコードの健全性を検出するために使用されます。

1.3 SEO

検索エンジンが Web コンテンツをどの程度理解しているかを検出するために使用されます。

2. 最適化する必要がある領域を分析する

重要なパフォーマンス指標を理解したら、現在の Web サイトのパフォーマンスを測定できます。

上で見られるように、総合スコアは非常に低いため、Lighthouse は最適化をどこから始めるべきかについての提案を提供します。

2.1 パフォーマンス

パフォーマンスの最適化に関する提案には、主に次の点が含まれます。

未使用の JS を削減します。
画像形式を合理的に使用してください。webp または avif の方が高速です。
表示されていない画像の遅延読み込み。
JS圧縮。
画像のサイズは適切である必要があります。
使われていないCSSを減らします。

パフォーマンスの最適化に関する提案

Lighthouse によって診断された Web サイトの問題:

ロードするにはリソースが多すぎます。リクエストは 147 件あり、合計 11MB です。
40 の静的リソースの場合、キャッシュはわずか 1 時間です
スクロールイベントにはマークが付けられていない{passive: true})ため、ページをスクロールする前にリスナーの実行が完了するまで待つ必要があります。
画像要素には明示的な幅と高さのセットがありません。
JS ファイルが多すぎ、メインスレッドのワークロードが大きすぎ、JS の実行時間が長すぎます。

既存の問題

2.2 ベストプラクティス

ベストプラクティスに関しては、次のような疑問があります。

画像の解像度が低すぎて、鮮明さが十分ではありません。
CSP ポリシーが設定されていません。

ベストプラクティスの質問

2.3 SEO

SEOには次のような問題があります。

メタディスクリプションはありません。
画像には alt 属性がありません。
robots.txt が無効です。

SEOの問題

3. パフォーマンスの最適化

上記の Lighthouse レポートによると、次の点を含む、プロジェクトのパフォーマンスに最も影響を与える要因を見てみましょう。

ボリュームが大きすぎます（最大 11mb）。
画像が大きすぎる場合は、画像フォーマットも影響します。

1. ボリュームの最適化

1.1 コード圧縮

圧縮されたスペースがまだあるか、または圧縮されていないツールライブラリがあるかどうかを確認してください。

1.2 コードの下請け

webpack-bundle-analyzer プラグインを通じてパッケージサイズを分析し、いくつかの大きな npm パッケージと runtimeChunk を個別にサブパッケージ化して、パッケージサイズを削減します。

1.3 コンポーネントはオンデマンドでロードされます

React.lazy + Suspense は遅延ロードされたコンポーネントをカプセル化し、ルートレベルのコンポーネントは遅延ロードされたコンポーネントを導入します。
同時に、スケルトン画面を遅延読み込みの下部コンポーネントとして使用すると、ユーザーは読み込みが速くなったと感じることができます。
マウスがナビゲーションバーに移動したときにルーティングコンポーネントをプリロードすると、ページの表示速度が向上します。

1.4 オンデマンドでロードされるツールライブラリ

import('xx').then(xx) を介してオンデマンドでツールライブラリをロードします。

1.5 静的リソースを CDN にアップロードする

プロジェクト内の json ファイルに保存されている静的データがいくつかあります。これらのファイルは CDN にアップロードされ、オンデマンドでインポートするようにフェッチされるように変更されます。

1.6 不要なリソースを削除する

プロジェクト内に導入されている mf および npm リソースを確認し、使用していないリソースを削除します。

1.7 npm パッケージの重複導入を避ける

npm を介してビジネスコンポーネントライブラリによって導入されたアトミックコンポーネントライブラリを検出します。導入された 2 パスのアトミックコンポーネントライブラリと比較すると、プロジェクト自体は mf を介して導入されたアトミックコンポーネントライブラリです。

このとき業務コンポーネントライブラリを変換し、mfのメソッドでインポートするように変更する必要があります。

1.8 ESM 依存関係のネストを回避する

Webpack のオンデマンド読み込みはインポートとエクスポートによってマークされるため、適切なオンデマンド読み込み効果が必要な場合は、依存関係のネストの問題を回避する必要があります。

1.9 アイコンはオンデマンドでロードされます

アトミックコンポーネントライブラリ mf の公開方法では、アイコンが 1 つだけ使用され、コンポーネントライブラリ内のすべてのアイコンに対応するチャンクがロードされるため、リソースが無駄になります。

アイコンのオンデマンドインポート用に新しいアイコン npm パッケージを作成します。

1.10 概要

上記の最適化方法により、容量は 11.7mb から 1.1mb に減少し、10.6 分の 1 に削減されます。

最適化前:

最適化前

最適化:

最適化された

2. 画像の最適化

1.1 画像の遅延読み込み

最初の画面にない画像には、画像の遅延読み込み戦略を使用します。

1.2 画像サイズ

画像を使用する場合は、適切な画像サイズを設定してください。

1.3 画像フォーマットの設定

Webp 形式の画像が推奨されます。

4. ベストプラクティスの最適化

1. CSPポリシーを設定する

2. 適切な画像解像度を設定する

プロジェクト内の画像解像度を最適化します。

5. SEOを最適化する

1. メタディスクリプション、キーワードの最適化

詳細なメタディスクリプションとキーワードにより、SEO が高速化されます。

<meta name="keywords" content="xx" /> <meta name="description" content="xx" />

2. 画像にalt属性を追加する

<img src="smiley.gif" alt="Smiley face" />

6. 最適化前後の比較

前後の比較を振り返ってみましょう。

最適化する前は、明らかな白い画面時間が長く感じられます。

最適化前

最適化後は、キャッシュがクリアされたときに数秒で開くこともできます。

最適化された

全体的なパフォーマンスが 270% 向上しました。

最適化前後の比較

7、パフォーマンス監視

後続の反復で高いパフォーマンスを維持するために、フロントエンドのパフォーマンスを視覚的に監視するために、内部フロントエンド監視プラットフォームであるCandle Dragonが導入されています。

最初のステップは、cdn プラグインをロードすることです。

<script
  defer
  src="https://h5static.m.jd.com/act/jd-jssdk/latest/jd-jssdk.min.js"
></script>

2 番目のステップは、エントリファイルで cdn プラグインを初期化することです。

useEffect(() => {
  // 初始化测速组件,在这里可以打开一些控制的开关，如是否上报接口
  if (IS_PROD) {
    // @ts-ignore
    jmfe.profilerInit({
      flag: xxx, // 这是应用ID，需要先在烛龙申请应用
      autoReport: true,
      autoAddStaticReport: true,
      autoAddApiReport: true,
      autoAddImageReport: false, // 支持所有图片上报,如果图片多，切记关闭，否则存在性能问题
      performanceReportTime: 8000,
      profilingRate: 1,
    })
  }
}, [])

3 番目のステップは、監視データを表示することです。

Zhulong プラットフォームでは、ウィジェットのパフォーマンススコアは 96 ポイントに達します。

監視データの表示

4 番目のステップは、アラームを追加し、リアルタイムで監視することです。

Zhulong プラットフォームは多次元アラームサービスをサポートしており、パフォーマンス指標に関連するアラームを追加し、パフォーマンスが変化したときに問題を適時に検出し、パフォーマンスを最適化します。

まとめ

この記事では、最適化前の課題分析から具体的な最適化策まで、フロントエンドプロジェクトの最適化の具体的なプロセスを詳しく紹介し、最終的にフロントエンドのパフォーマンスを3倍近く向上させることに成功しました。同時に、パフォーマンス指標も監視プラットフォーム上に配置され、フロントエンドのパフォーマンス指標の視覚的な監視を実現します。

お役に立てれば幸いです、読んでいただきありがとうございます~

参考文献

著者: JD Retail 唐焦

出典: JD Cloud 開発者コミュニティ