🩵 webフロントエンドパフォーマンス

[mayukoooo]

1日の終わりに学習したことを思い出しながらまとめる

[mayukoooo]

2024/1/2

記憶：

• レンダリングの仕組み
  • HTML解析：HTML取得 -> parse -> トークン化 -> AST(DOM) -> コンパイル -> レンダリング
  • JSが解析されている間はプライマリHTMLはブロックされるが、セカンダリHTMLパースは解析を進めてくれる。ただし、セカンダリHTMLパースでは解析できないことがある。
• JS実行の流れ
  • parse -> トークン化 -> AST(DOM) -> コンパイル -> 実行
• UIスレッド
  • 1つのスレッドを順番にしか実行できない
  • ブラウザの1タブにつき1スレッド持っている
  • ここではJSの他にCSSも管理しているので、CSSが遅れればJSも遅れる。JS解析が遅ればイベント発火も遅れる
  • JSの非同期処理を行うことで見かけ上並列し処理しているように見える
• CSSの解析
  • CSSは右から順に解析される
  • 詳細度が高い方が優先される
  • style属性のスタイルは詳細度より優先される
  • CSSはDOM毎に総当たり的に解析されるので、無駄なCSSをおくとその分パフォーマンスに響く
• JIT（Just In Time）
  • コンパイラのやり方の一つで、JSのコンパイラ方式
  • 1行毎に（正しくは一つの実行単位毎に）機械語に変換し、後続のコードも効率的に変換される

[mayukoooo]

正しくは：

• レンダリングの仕組み
  • 大まかな流れ：Loading -> Scripting -> Rendering -> Painting
  • HTML解析：Bytes -> Characters -> Tokens -> Nodes -> DOM
  • JavaScript が HTML パーサーをブロックするのはなぜ？
    • DOM を変更する可能性があるため、パーサーが到達した時点で同期 JavaScript を実行する必要がある
    • プライマリ HTML パーサーがブロックされている間、セカンダリ HTML パーサーを使用して今後のリソースをダウンロードすることで、パフォーマンスコストを削減しようする（パーサーブロックはパフォーマンスが大幅に低下する可能性がある）
• JS実行の流れ：JSコード -> トークン列 -> AST -> コンパイル -> 実行
  • トークン列：ラベル付けした文字列のリストのこと（String, Separator ...etc.）
  • JITコンパイル：プログラムを1行ずつ実行しながら、その実行で得た情報をもとに後続のコードをより効果的なマシン語に変換して実行していく方式のこと
• CSSルールのマッチング処理
  • レンダリングエンジンはDOMツリーから全てのDOM要素1つ1つに対して、どのCSSルールセットが当たるかを総当たり計算していく
  • CSSセレクタのマッチング処理は右側から行う
  • 要素のstyle属性に記述されたCSSはどのCSSよりも優先される
• UIスレッド
  • ブラウザタブ1つにつき、1UIスレッド（メインスレッド）= シングルスレッド
  • 実装する処理：レイアウトの計算、レンダリング処理、JS実行、DOMイベントの発火...etc.
  • レイアウト計算やレンダリングが遅くなるとJSの実行も遅くなる、JSの実行が遅くなるレイアウト処理やレンダリング処理が遅くなる
  • JSのイベントループ：見かけ上、複数の処理を同時に行える
    • 非同期的に実行する

[mayukoooo]

2024/1/9

• ブラウザレンダリング
• Reactレンダリング

[mayukoooo]

2024/1/18

---

• Reactレンダリング
  • Reactの画面更新ステップ
    • トリガー -> レンダリング -> コミット
      • *トリガー：stateがset関数によって更新される等
      • *コミット：レンダリング中に計算した変更差分をのみ、DOMノードを更新する
  • レンダリング：Reactがコンポーネントを呼び出すこと。
  • 画面描画：Paintと呼ぶ（ブラウザレンダリングとは区別する）

[mayukoooo]

2024/2/1

• クリティカルレンダリングパスを学ぶ意味
  • 最初のページレンダリングを必要以上にブロックしないようにすることで、ウェブパフォーマンスを向上させることができる
• クリティカルレンダリングパス
  • 最初のレンダリングを実行する前にブラウザが取る一連の手順
  • クリティカルレンダリングパスに含まれるリソース
    • HTMLの一部
      • HTMLはストリーミング方式で処理されるので、一部を読み込むだけでレンダリングを決定することができる（全ての読み込みを待つ必要がない）
    • 要素内のレンダーブロック*CSS
    • 要素内のレンダーブロック*JS
    • *レンダーブロッキング：レンダリング更新をブロックする部分のこと

パーサーブロッキング

---

• パーサーブロッキングするリソース：JS

• HTMLパーサーがJSに到達すると、DOMの構築を一時中断して、JavaScriptエンジンに制御を渡す。

何故レンダーブロックする必要があるのか？

---

[mayukoooo]

【ブラウザレンダリングの仕組み】

1. HTMLの解析: ブラウザはHTMLを受け取り、それを解析してDOM（Document Object Model）ツリーを作成する。DOMツリーはHTMLタグをノードとして持つツリー構造。

2. CSSの解析: 同時に、ブラウザはCSSを解析し、CSSOM（CSS Object Model）ツリーを作成する。CSSOMツリーはCSSルールをノードとして持つツリー構造。

3. レンダーツリーの作成: 次に、ブラウザはDOMツリーとCSSOMツリーを組み合わせてレンダーツリーを作成する。レンダーツリーはページ上に表示されるすべての要素とそれらのスタイルを持つツリー構造。

4. レイアウト: レンダーツリーが作成されたら、ブラウザは各ノードが画面のどこに配置されるべきかを計算する。これをレイアウトまたはリフローと呼ぶ。

5. ペインティング: 最後に、ブラウザはレンダーツリーの各ノードを画面に描画する。これにはテキスト、色、画像、境界線などが含まれる。

[mayukoooo]

<script>、<script async> 、 <script defer>

[mayukoooo]

• <script>

  • ブラウザはスクリプトタグを遭遇すると、HTMLの解析を停止し、スクリプトを直ちにダウンロードして実行する
  • スクリプトのダウンロードと実行が完了するまで、HTMLの解析は再開されない
    • これは、スクリプトがDOMに影響を与える可能性があるため

• <script async>

  • async属性が設定されたスクリプトは非同期にダウンロードされる = HTMLの解析と並行してスクリプトのダウンロードされる
  • ダウンロードが完了すると、HTMLの解析は一時停止し、スクリプトが実行される
  • その後、HTMLの解析が再開される
  • asyncスクリプトは順序を保証しないため、互いに依存しないスクリプトに適している

• <script defer>

  • defer属性が設定されたスクリプトも非同期にダウンロードされるが、スクリプトの実行はHTMLの解析が完了するまで遅延される
    • つまり、HTMLの解析がブロックされることがない
  • deferスクリプトは順序を保証するため、他のスクリプトに依存するスクリプトに適している

[mayukoooo]

react のメリット
脆弱性を防ぐことができる
コンポーネントの管理がしやすい
チームの共通認識を作りやすい

[mayukoooo]

ライフサイクルの機能を提供するための関数
stateを管理するための

[mayukoooo]

async await と Promise の違い
同期的にかける
処理をコールバックの中でやらなければいけない（ネストになりやすい）