主なパフォーマンス指標
- 主なパフォーマンス指標ページのオフロード時間、リダイレクト時間は無視します。
- 最初のパッケージ
responseStart - domainLookupStart - 最初のレンダリング/
responseEnd - fetchStart - 初めての方
domInteractive - fetchStart - DOM対応：
domContentLoadedEventEnd - fetchStart - ページが読み込まれました：
loadEventStart - fetchStart - FPFCP
ウェブアプリケーションの複雑さとリッチさが増す中、ユーザーとのインタラクションを考慮することは、単にDOMContentLoadedとonLoadのトリガーを最適化して減らすという問題ではなく、ユーザーとのインタラクションのプロセス全体が可能な限り最適になるように、ビジネスモデルに基づいて総合的に検討する必要があります。
最初のパケットは、あなたが大まかに現在のネットワーク状況を見ることができる、一般的なDNSの消費時間は比較的大きいです、あなたはいくつかのdns -プリフェッチを行うことができます。 条件が良い、ネットワークの理由のために、あなたはhttpDNSに切り替えるには、モバイル側の従来のDNSメカニズムのいくつかを行うことができます、ネットワークの安定性を確保するだけでなく、正確にユーザープロファイルを取得します。
最初のレンダリングは、伝統的にパフォーマンスの最適化を考慮の焦点。時間のポイントのシミュレーションは、HTMLが完全に受信された後、そのようないくつかのスケジューリングスイッチのブラウザのプロセスとしても、時間の一定量を消費する必要がある、一般的に開始点の大まかなレンダリングとして、実質は多少遅れることになります。ブラウザの背景色の冒頭では、ボディの背景色がグレーに設定されている場合、ブラウザは、ボディをレンダリングすることを優先され、一般的に白い画面の時間が費やされ、灰色の画面のレンダリング開始点として知られている視覚的な色のスイッチがあるでしょう、白です。 performance.getEntriesByType('paint')[0].startTime 最近のブラウザは、FP、FCPの正確な計算も提供しています。
First Time Interactive/TTI、通常弱いネットワーク環境では、DOMは完全にロードされないかもしれませんが、ユーザーのインタラクションを妨げることなく、インタラクティブなDOMが可能な限り早期にレンダリングされることは許容されます。ページがロードされても、長いJSタスクが実行をブロックし、ユーザーとのインタラクションを妨げているようなシナリオよりも、さらに良いでしょう。
ページロード時間の最も重要な要素であるFMP(first meaningful paint)は、ビジネスサイドや開発者が計算する必要があり、基準はありません。
- 段階別指標のウォーターフォールフロー
beforeunload,unLoadイベントをリッスンすることで、最後のアンロードに費やされた時間を取得することができます。一般的に、beforeunloadイベントを無意味にリッスンすることは推奨されません。前方および後方のキャッシュフェッチとジャンプページの高速ロードに影響を与える可能性があるからです。
リダイレクト リダイレクトは、ネットワークのラウンドトリップとブラウザが新しいページを引き受けるために新しいプロセスを開始することを考えると、サイトの読み込み速度に影響を与える、リダイレクトを避けるようにしてください。
上記の最適化で述べたように、DNS。その他の例としては、スクリプトに async 属性と defer 属性を追加して、DOM 構築のブロックを回避することなどがあります。パッケージサイズの処理、オンデマンドローディング、ツリーシェイク、醜い圧縮、長いタスクのタイムスライスの削減、60FPSアニメーションなど。
リソース分析
- unLoad
unloadEventEnd - unloadEventStart
要求の数に応じて、要求が大きすぎるかどうかを考えるいくつかの要求を削減またはマージすることができ、要求のキーリンクリソースをつかむためにチャネルを取るために要求を避けるために、いくつかの遅延ロード技術を試してみてください。あなたは、リソースが自分のサーバーに統合することができるかどうかを確認するためにサードパーティであるドメインを見ることができます。制御できないリソースは、自分のサイトのサービスに大きな影響を与え、損失を引き起こす可能性があります。
- Redirect
redirectEnd - redirectStart
各ドメインのリソースの負荷数と割合が一目でわかります。各ドメインに費やされた総時間と同時接続時間から、リソースサーバーの負荷容量と選択したCDNが最適かどうかを評価できます。
クロスドメインの時間ヘッダを設定しない限り、リソースクリティカルな時間情報を取得することはできません。独自の制御可能なサービスについては、それらが設定する必要があるかどうかを検討することができます。ここでは、クロスドメインリソースドメインをランク付けし、修正を容易にするためにリストアップします。
- AppCache
domainLookupStart - fetchStart
ここでは、HTML、CSS、JS、JSON、svg+XML などのテキストタイプの圧縮設定をカウントします。これは、例えば gzip が適切に設定されていないリソースサーバを数えます。
- DNS
domainLookupEnd - domainLookupStart
サイトの形状の分析を容易にし、パフォーマンス最適化のためのサイトウェイトリソースの分析に進みます。
- TCP
connectEnd - connectStart
最も時間のかかるリクエストの一部がサンプリングされ、時折、頻度の低いキャプチャスクリプトに時間がかかりすぎていることがわかります。また、Webページのライフサイクルを使用して、いつ、どのようにレポートされるかを最適化する必要があるかどうかを検討する必要もあります。
使用方法
プラグインをクリックするか、右クリックしてパフォーマンス分析を生成またはオフにします。
提案集
継続的なメンテナンスについて、何か良い提案や要望があれば遠慮なく言ってください。
