モバイル ページのパフォーマンスの探索_html/css_WEB-ITnose

1. 背景:

スマート端末の普及により、人々のインターネットの使用習慣が変わり、端末環境ではページのパフォーマンスに対する要求が高くなりました。携帯電話の 1 秒以内のレンダリングを画像で分析してみましょう。ページ

全体的なネットワーク消費量を分析します:

1. サーバーの応答は 200 ミリ秒未満である必要があります

2. リダイレクトはできるだけ少なくします

3. できるだけ少なくします可能な限り最初のレンダリング リクエスト

4. 過剰な JS および CSS の混雑を回避します

JS の実行効率とレンダリング効率:

1. ブラウザーに残されたレンダリング時間は 200 ミリ秒です

2. JS の実行効率とレンダリング時間を最適化します

2. 主な Web パフォーマンスの最適化

ページリクエスト: DNS ルックアップ、リダイレクト削減、並列リクエスト、圧縮、キャッシュ、オンデマンド読み込み、フロントエンドのモジュール化

実行環境: インタラクティブ、アニメーション、スクロール、メモリ、GC、FPS

3. レンダリングの問題についての考え

1) スマート端末と PC のパフォーマンスの差は非常に大きい

x86 のパフォーマンスは ARM の 5 倍以上、あるいはそれ以上です元々、多くの既存のパフォーマンスの問題は隠蔽されていましたが、端末市場が勃発した後、次のような状況で問題が発生しました:

- ユーザーが所有する端末の CPU の品質に大きな差があります

- 動作が遅い速度

- ユーザーの操作が遅い メモリ不足

2) iOS と Android のハードウェア比較 なぜAndroid スマートフォンよりも iPhone の方が優れていると思いますか? は - 4A4800MHZ512MiPhone3GSS5PC100600MHZ256MGlaxy Note Nexus OneMOTO XT615HTC レジェンド

			Android
Exynos デュアルコア 1.4GHZ	1G		Android
クアルコム 1GHZ	512M		Android
クアルコム 800MHZ	512M		Android

🎜クアルコム 600MHZ🎜 🎜384M🎜 🎜 🎜

4. パフォーマンスの最適化メトリクス

すべてのパフォーマンスの最適化は、測定可能なデータ分析に基づいています

1) レンダリングの判断パフォーマンス 標準

フレーム番号:

- ディスプレイデバイスの通常のリフレッシュレート、通常は 50~60HZ

- 1000ms/60 = 16.6ms (1 ミリ秒の最適化は 6% のパフォーマンス向上を意味します)

...

4) パフォーマンス デバッグ ツール: Chrome デバッガーのタイムライン、タイムラインにはよく使用される 2 つのモードがあります。

イベント モード (図に示す):

フレーム (Chrome 固有) モード (図に示す)

ヒント:

a) タイムライン記録動作のショートカット キーは Ctrl + E (Mac: Cmd + E) です

b) 灰色の領域は、非レンダリング エンジンで発生するレンダリング動作です

c)透明ワイヤーフレームは 2 つのモニター更新サイクルの間にあります。 待機時間

5) 一般的なレンダリングの繰り返しを回避します: フレームごとに「レンダリング ツリーの更新」アクションが 2 つだけ発生するようにします

6) レイアウト計算の繰り返しを回避します: requestAnimationFrame (以下、RAF と呼びます)

a) ヒント: タイムアウトと raf は、実際には同じスレッド上で動作します。CPU が非常にビジーな場合、RAF の実行もブロックされます。

b) イベント動作と RAF 制御の違いは次のとおりです:

無駄なレンダリング フレームのレンダリングをイベント動作を通じて直接トリガーし、ハードウェア フレームによって最終的に表示されません

を通じてレンダリング頻度を制御しますRAF、多数のイベントの計算をマージし、無効なレンダリングの数を減らす

7) ページの再描画につながる

不正な DOM 操作

ヒント: Chrome のソース コードでは、updateLayoutIgnorePendingStylesheets () メソッドを使用して、代替スタイルを無視してレイアウトを再計算します

優れた DOM 操作

ヒント:パフォーマンスを向上させるために使用する必要がある Dom 属性。読み取りと書き込みの分離

7) レンダリング動作の繰り返しを回避します

a) RAF を使用して適切なリフレッシュ時間内にアニメーションを制御します

b) レンダリングのアトミック操作を保証します読み取りおよび書き込みの分離のためのエンジンとバッチDom c）異なるスタイルは、以下に示すように、レンダリングモードで異なるパフォーマンスを持っています。アニメーション

変位: 変換: 変換(npx, npx );

スケーリング: 変換: 回転(ndeg);

透明度: 不透明度: 0 ~ 1;

1) GPU アクセラレーション (コンポジット): GPU はブラウザーでどのように動作しますか?

ハイエンドのブラウザ (Webkit、Chrome) では、ペイント動作は CPU が GPU 用のテクスチャ マテリアルを準備することです。

ヒント: 画像テクスチャを表示するには、Chrome デバッガーで合成レイヤーの境界線の表示をオンにすることができます

2) GPU の利点悪用される可能性 : テクスチャ キャッシュとグラフィックス レイヤー

GPU ハック:

a), -webkit-transform: translation3D(0px, 0px, 0px); // レイアウトを作成し、GPU 内でレイヤーを移動します。

b) アニメーション化する必要がある DOM オブジェクトを強制的に GPU にレイアウト キャッシュを作成します

-webkit-transform: translationZ(0); // レイアウトを作成してキャッシュします。

-webkit-backfface-visibility: hidden;

共通の属性は次のとおりです:translateZ、Perspective、backface-visibility、scaleZ、RotateZ、RotateX、RotateY、Translate3D、Scale3D、Rotate3D

3) GPU の合理的な使用アクセラレーション

a) GPU アクセラレーションを使用すると、レンダリング リソースを再利用できるように、GPU レイヤーのキャッシュが実際に使用されます。

b). GPU アクセラレーションは諸刃の剣です。GPU レイヤーが多すぎると、コンポジット レイアウトが 16 ミリ秒を超えるかどうかにも注意してください。

c). ユーザーの動作とアニメーションに必要なシーンでのみ GPU レイヤーを作成しますが、時間内にリサイクルする必要があります。

4) css3 アニメーションに関するいくつかの注意事項

a) translation2D を単独で使用すると、GPU レイヤーが独立して生成されず、GPU 内で合成されません。

b) CSS トゥイーン アニメーションと Translation2D を組み合わせると、計算のために GPU に一時的なレイヤーを生成できますが、「レイアウト計算」で変更が発生した場合は無効になります。

c) CSS3 アニメーションは通常、ブロックしません。描画用に独立したスレッドを取得できます

ヒント:

1. レンダリング ツリーの計算を完全に回避する必要がある場合は、Canvas を検討できます

2. className の代わりに classList を使用しますが、 chrome33 dev では一般的です。「className=」は、スタイルの繰り返しレンダリングを減らすために、すでに同じ名前で判断できます