Webパフォーマンスにおけるイニシャライズとランタイム

Webフロントエンド・パフォーマンス

思考整理系。

Webフロントエンドにおける3要素として、過去のセッションでは下記の3つを中心に紹介していました。

  • 通信コスト - Networking
  • 描画コスト - Rendering
  • 計算コスト - Computing

これらの問題は複雑に絡み合い、時として相反する関係をとります。例えば、通信コストを減らすために、視覚表現を画像からCSS3に置き換えたら、描画コストが高くなってしまいスクロールが重くなった、なんてケースは頻繁にあるでしょう。

理解の問題

この3つのコストは確かにパフォーマンスに影響を与える要因であります。しかし、その要因がWebフロントエンドのページライフサイクルにおいて、どこで影響を与えているかは表してくれません。

要因がどのような影響を及ぼしうるかという基礎的な理解と、パフォーマンスの問題に取り組むための切り口としての理解は、それぞれ別のものです。

そのわりに「パフォーマンス」と一言で表したときに、何処のパフォーマンスなのか、対象がざっくりしすぎているのが現状です。

昨今の振り返り

Webのパフォーマンスというと、これまで最初のページロードやレンダリングの完了といった、初期フェーズの話がほとんどを占めていました。その流れで言えば、スマートフォンの普及により、すべてのサイトが非力なスペックと脆弱な通信環境を伴ったモバイルデバイスで閲覧されることを前提としなければならなくなったのは、大きな転換期だったようにも思います。

今や、初期フェーズだけがパフォーマンスの問題となるわけではありません。WebアプリケーションにおけるサーバーサイドはAPIプロバイダーとしての性質を強めてきています。その一方で、画面遷移やテンプレート処理といった、これまでサーバーサイドで行っていた処理や、特定のビジネスロジックすらも、クライアントサイドのJavaScriptが処理するようになり、実行時のスクリプト処理は肥大化する傾向にあります。

ブラウザゲームやFlashの時代は、元々そうだったようにも思います

これらの話を踏まえながら、Webのパフォーマンス問題と正面から向き合うためには、影響を与える要因による分類ではなく、ページライフサイクルにおけるフェーズを元にすべきではないかと考えるようになりました。

ページライフサイクルの観点

ページライフサイクルというと大仰ですが、大ざっぱには次のような流れを指しています。

  1. URLを開いてページをロードする
  2. ユーザーの操作に応答してUIを更新する
  3. ページが閉じられて終了する

この流れを踏まえて、特に1と2を対象としたパフォーマンスのフェーズとして明確に分類して考えるようにしています。

この分類によって、漠然と「パフォーマンスを良くしたい」「サイトを速くしたい」といった願いに対して、どこを速くしたいのかという視点をもって取り組むことが出来るように思います。そもそもビジネスゴール的に、どのフェーズのパフォーマンスにアプローチすべきかは本来的に異なっているはずです。

初期化パフォーマンス - Initialize

「ブラウザがWebページのロードを始めてから、ユーザーがページを見られるようになるまでの速度」

DNS解決・TCP接続・HTTP通信・サブリソースのロード・スタイル評価・スクリプト評価・レンダリングに至る部分のパフォーマンスを指します。

追いかける指標としてはページロード時間系の指標のいずれかが妥当だと考えられますが、WebPagetestで示されるSpeed Indexが最も現実的かもしれません。目標にすべきはPage Speedであれば1000以下、ページロードの時間(やや濁してます)であれば1秒が目安でしょう。

通常のWebサイト的なページであれば、これまでどおり、ここの初期化パフォーマンスを改善することで、目的を達成することができるはずです。

実行時パフォーマンス - Runtime

「ページが表示されてから、ユーザーがページ内を操作・回遊して離脱するまでの応答性」

ユーザーの操作に応答して、パララックスしたり、ページ遷移することなくアニメーションつきで画面が変わったり、何らかのタスクを実行したりする部分のパフォーマンスを指します。

追いかけるべき指標としては、UIが更新されるときのフレームレート/FPSが妥当だと考えられ、目標にすべきは60FPSです。いわゆる1フレームを16.6msにおさめる努力です。

昨今のWebアプリ風なページになると、途端にこのフェーズのパフォーマンスが重要さを増します。例えばシングルページアプリケーションであれば、イニシャライズを犠牲にしてでもランタイムのパフォーマンスを獲得しなければならないケースだってあることでしょう。

視点の話でした

というような感じの視点をみんなで共有できれば、会話もしやすいし、パフォーマンスの問題にも個別に対応しやすいかな、と思って改めて書いてみた次第。

今更といえば今更で、目新しいことはなにもなかったと思います。ごめん(´・ω・`)


Author

ahomuAyumu Sato

overflow, Inc.VPoE

東京資本で生きる名古屋の鳥類

Web 技術、組織開発、趣味など雑多なブログ。技術の話題は zenn にも分散して投稿しています。

Bio: aho.mu
X: @ahomu
Zenn: ahomu
GitHub: ahomu

Related

Latest

Archives

Tags

Search