無駄のタイプ

現状の機能やUIを維持しながら、パフォーマンスを良くすることは無駄を削ることとほぼ同義です。

生放送の視聴ページに関する無駄を削っていくことがパフォーマンスの向上につながります。 その"無駄"には幾つかの種類があると考えられます。

無駄の種類

ブラウザにはI/Oなどはないため主に次の要素が挙げられます。

  • ネットワーク
  • レンダリング
  • スクリプティング

これはブラウザの開発者ツールのTimelineやNetworkパネルなどでみれます。

これらについては次のサイトや書籍が参考になります。

参考

ネットワークにおける無駄

不必要なものを読み込まないのがもっとも効率的です。 余計なリソースを読み込まないことはファーストビューの表示に直接反映されるため、ページロードを短くするならばネットワークの無駄を探すのがもっとも効率的な改善です。 App Shell モデルなどはこの効率化をパターンしたものです。

今回は目的で述べたように、視聴中におけるパフォーマンス改善なので省略します。

レンダリングとスクリプティングにおける無駄

生放送という性質上、視聴中に無駄となるものレンダリングやスクリプティングが多くの割合を占めます。 なぜなら、生放送の動画などは先読みキャッシュなどができないため、ネットワークは必要悪となりがちです。（映像の最適化などは別途必要）

視聴ページではReactが使われているので、reactでよくある問題を箇条書きします。

  • 無駄な更新
    • これは同じ値にもかかわらず同じ結果に更新されているView
  • 無駄な判定
    • これはshouldComponentUpdateの判定自体が不要なのにしなければならなくなっている場合
    • Parent > Child でParentの時点で受け取ったpropsが全く同じならChildではshouldComponentUpdateを判定自体しなくていい
    • ComponentのTree構造にも関係するので、トップダウンとボトムアップどちらも必要
    • トップダウン（上のコンポーネントで止める）と効果は高いが、相対的にトップでとまるものはあまり多くない
      • トップダウンで止めやすいようにDOM構造を変更するのも1つの手段
    • ボトムアップ（末端に近いコンポーネントで止める、結果的に止まればDOM APIを叩かない）で止めることは、効果は小さい範囲が広い
  • 無駄なDOM API
    • componentWillUpdateやcomponentDidUpdateなどでのDOM APIを叩く
    • 主にstyle操作やlayout操作に関係あるものをここでやるとコストが高い
    • たとえばcomponentDidUpdateでelement.getBoundingClientRectを叩くなど
      • CSS Triggersに載っているものを操作するDOM APIを叩くときは注意が必要
      • 方針としては、"更新したからLayout情報を取る"ではなく"更新されたからLayout情報を取る"にする
      • IntersectionObserver や scroll イベントなどイベントを使ってLayout情報を更新を行う
      • Viewをrenderしたからと言ってそのタイミングでLayoutが更新されるとは限らないので、イベント駆動にして最小限にする（基本Layoutコストは高い）
  • 毎回作られる関数のハンドラ

results matching ""

    No results matching ""