2014年のWebパフォーマンスふりかえり - 来年以降の期待etc

ふりかえり

ひさびさにWebフロントエンドパフォーマンス系の話題をつらつらと書いてみます。例によってモバイル系開発者寄りの視点かもしれません。文中の参照リンク多め。

ファクタ

まずはパフォーマンスに影響を与えるファクタについての所感。Webパフォーマンスにおけるイニシャライズとランタイム ::ハブろぐ で示した分類に基づきます。

イニシャライズ（いわゆるページロード）

• 4GやLTEが普及してもコンテンツの肥大化には追いついていない
• concat と CSS Sprites の呪いが解けない
• HTTP/2 の Streams and Multiplexing に期待
• HTTP/2 の Server Push にも期待
• 画像周りだと <picture> 関連仕様も使いたい（srcsetだけならいける？）
• WebRTC とか WebSocket とかストリーミングとかは？
  （やや疎い、てかイニシャライズじゃないか）

ページロードについて基本的なノウハウは何年も前から確立されているため、いよいよもって根本的な仕組みの改善に期待するしかないな、というのが率直な感想です。（一方で基本的なノウハウから入らないといけない現場もまだ多数があるのは認識しています）

つまるところ HTTP/2 に向けた期待にすべて集約されます(※1)。HTTP/2 が現実になればフロントエンド開発者は「concatの呪い」と「CSS Spritesの呪い」から解放されるはずと願うばかりです。（他力本願）

レスポンシブ業界でお馴染みの <picture> 関連仕様も、普及を座して待つステータスに突入しています。<picture> 要素自体はしばらく絶望的な状況ですが、srcset 属性のほうは polyfill と合わせて条件を整理してあげればモバイルでは使えるかもしれません。

1 Streams and Multiplexing は、1コネクションのなかで複数のリクエストを並列で処理するための仕組みであり、Server Push は大ざっぱに言うと「HTMLを返すときにクライアントサイドのリクエストを待たずにCSSやJavaScriptもプッシュする」という仕組みです。詳しくはググって。

ランタイム（いわゆるFPS）

• CSSの委細に気を配る時代はじきに終わる？（ will-change !? ）
• レンダリング全般に劇的な変化はないが、DevTools が確実に進化している
• JSエンジン自体が賢くなる事と、開発者が実行系を思いやる事の歩み寄り中
• 現場に about://tracing Timeline やメモリプロファイリングのノウハウが欠けてるかも
• WebGLとかどうなるんだろうね（門外漢）

レンダリング処理やJSエンジン周りはブラウザアップデートだけで完結できる分、サーバーとクライアントが絡む通信周りと比べれば着実に進捗がある印象です。Chromium の about:tracing や Layers パネルも去年と比べれば大分見やすくなりました。とはいえノウハウが定着・浸透してないイメージ。追記: 最近ならTimelineパネルでいいじゃん、ってご意見はご尤もです。取得できる情報も充実しましたし。とはいえそれも定着してなさそう。

その上でそろそろ期待したいのは、CSSのレンダリングコストや Compositing Layer を気にしなくてもいい感じになってくれることです。 position: fixed みたいな露骨なプロパティの扱いは早い段階で良くなりましたが、同様に開発者があまり気にしなくても良くなってくれればみんな幸せ。

とはいえ will-change プロパティというものが存在することからして、将来的にも完全に気にしないというわけにはいかないでしょう。

メトリクス

つぎに何を目標としてパフォーマンスを維持するかについての所感。正直、パフォーマンスについて指標を持って継続的に運用できているところは少ないのではと思っています。もちろんステージによっては対症療法のための調査計測だけでも良いでしょうが、長期運用を見込むと指標や計測方法と向き合う必要が出てくるはずです。

運用指標

1. Milestone timings （特定のタイミング）
2. SpeedIndex （Speed Index 先生）
3. Quantity based metrics（数量ベース）
4. Rule based metrics （ルールベース） Performance Budget Metrics - TimKadlec.com

よくまとまった記事からの引用ですが、これらの指標をうまく組み合わせて運用するのが基本です。2〜4はわりと簡単に適用できますが、1の Milestone timinigs にパフォーマンス測定の難しさが詰まっています。かつては window.onload や DOMContentLoaded のタイミングが是とされていましたが、それだけでは妥当性があるとは言えなくなってきています。

「リソースが読み込まれる != ユーザーに見えている != ユーザーが操作できる」

分かりやすい例では Single Page Application (SPA) があります。このテのプロダクトの window.onload はおおよそアテになりません。本来はレンダリングの開始時点やアプリケーションが操作可能になった時点などを計測したくなるはずです。そうでなくてもソーシャル系プラグインや広告がふんだんに埋め込まれた昨今のWebサイトを妥当に計測するのは困難です。（そのために Speed Index みたいな指標があるわけですが）

なんにせよ「どこをどのように測るのか」がプロダクトのビジネスによってまちまちであることは間違いなく、専門家の指標設定と開発者がアクション可能な領域をうまくかぶせてアプローチしていくしかなさそうです。予算決めはこういう記事も参考になりそう。

ツール

• ページロード周りの計測は指標が明確であれば難しくはない
• レンダリング周りは決め手になるツールが不在の状態

ページロード系については、Speed Index でお馴染みのWebPagetest 先生はもちろん、コンサルやら集計分析やらコミコミでパッケージされた商用ツールも豊富にあります。古典的には PageSpeed や YSlow 、Sitespeed.io といった減点法のポイントチェッカー系を併用しても良いでしょう。

WebPagetest のプライベートインスタンスを立てて CI で回すのは確かに大がかりですが、Resource Timing を利用して Speed Index を算出する RUM-SpeedIndex のようなツールにも期待がもてます。

一方、レンダリング速度の測定は決め手がありません。もちろん開発者が DevTools を開けば情報を得られますが、継続的に定常データを収集する手段に乏しいということです。axemclion/browser-perf というabout:tracing 相当のデータを抜いて解析してくれるのも今年のPerformance Calendarで紹介されていましたが、限定したブラウザで頑張っている感が否めません。将来的にはFrame Timing が主要ブラウザに行き渡ればもっとカジュアルに実現できそうなので期待したいです。

これから求められるもの

1年前くらい前から言っていたのですが、パフォーマンスにまつわる基礎知識は十分に公開されている状態にあります。基礎の啓蒙やポジショントークも大事ですが、いよいよ開発者界隈で望まれるべきはケーススタディの共有会ではないかと思います。

• パフォーマンス改善でどのような効果が得られたか
• パフォーマンス系の取り組みをどうやって組織に浸透させたか
• 指標をどのようにして決めて、運用しているか
• 何を行ってパフォーマンスを改善させることができたか

こういう知見が幅広く共有されていくと、パフォーマンスの話題がより現実的な関心をもって取り組まれるようになるのかもしれません。とかいってたら昨日やってたDeNA?のイベントの発表とか良い感じっぽいですね。（行きたかった）

組織系はクリティカルな話題のように思います。いわゆるUXDの一分野と捉えると、単一プロダクトだけでなく組織を変えるつもりで働きかけなければ全体の調和が取れない問題でもあります。そいういう取り組みをしてるひとの話を聞いてみたい。

これから出てくるかも問題

• Polyfill の利用頻度upに伴うアレコレ
• HTTPS 移行にまつわるアレソレ
• Web Components のリソース断片化
• Service Worker (Cache) の使い方

W3C方面にせよECMA方面にせよ、ブラウザには漸次で新しいAPIが実装されるため、今後は一層 Polyfill の利用頻度が高まることも予想されます。ひょっとすると、そのような Polyfill たちが新しいパフォーマンス問題を引き起こすかもしれません。(※2)

そのほかにも、新しい技術仕様がでるたびに気になるポイントは変わっていきますが、きっと各方面の識者が開拓してくれることでしょう。

2 polyfill のパフォーマンス問題は legacy IE に対する過剰なhackライブラリぶっ込みで表面化しかけたことありましたね

おしまい

ということで Frontrend Advent Calendar 2014 - Qiita の17日目でした。なんだかんだ長文になってしまった感。

パフォーマンス関連の過去ログ

参考までに。

• スライド: Web Frontend Rendering Performance Knowledge & Tips
• スライド: High Performance Web Frontend 2013 秋
• スライド: Web Frontend Performance Tuning TIPS *n
• Webパフォーマンスにおけるイニシャライズとランタイム
• フロントエンドチューニングの箇条殴り書き
• Skia DebuggerにみるCSSプロパティの重み
• GPUアクセラレーションとposition: relativeによるレイヤー生成について
• picture要素の関連仕様って今どうなってるんだっけ？を調べたメモ

---