Velocity 2013
ちょりーっす！コミュニティ部門でWebデベロッパーをしています石本（@t32k）です。今回は6/18-6/20、米国のサンタクララで開催されたVelocity 2013のレポートを書いてみるよ。
Velocityは『ハイパフォーマンスWebサイト』の著者でも有名なSteve Souders氏が2008年から開催している、Web Performance（フロント、バックエンド問わず）, Web Operationsなどを幅広く取り扱ってるカンファレンスです。また同名のカンファレンスが、ニューヨーク、ロンドン、北京でも開催されており、まさしく世界的なカンファレンスと言ってもいいでしょう。
『ハイパフォーマンスWebサイト』を読んだ時から、私にとっていつかは行きたいと思ってた憧れのカンファレンスだったので、3日間興奮しまくりでした。その中でも特に印象的だったTwitter社のMarcel Duran氏のセッションを紹介したいと思います。
- Velocity 2013 - O'Reilly Conferences, June 18 - 20, 2013, Santa Clara, CA
Avoiding Performance Regression at Twitter
TwitterのWeb-CoreチームでパフォーマンスエンジニアをしているMarcel Duran氏は問題を抱えていました。バグフィックスや新機能を追加し新しくリリースした時に、パフォーマンスの低下が見受けられました。困った問題です。これらの簡単なソリューションはCTRL+Rを押してリロードすれば早くなります（冗談です）。
通常であればMonitorして、不具合があれば修正をBuildし、Testし、Deployし、Usersに届けるといった典型的な開発サイクルをとるでしょう。しかし、新しい機能追加、バグフィックスごとに多くのブランチが存在します。とあるケースで100msパフォーマンスが低下したとしましょう。この原因を探すことは干草の山から一本の針を探すようなもので、不可能に近いです。
Tools
そこで、パフォーマンスを理解するために便利なツールが多く存在しますのでいくつか紹介します。
Cuzillion
CuzillionはSteve Souders氏が作ったツールで、ページで読まれているコンポーネントがどのように相互作用するのか確認できます。外部JS、外部CSS,画像などのコンポーネントをどのような順番で読み込ませるのか、組み合わせテストすることできます。
YSlow
YSlowはページのパフォーマンス評価を測定してくれるツールです。Chromeであれば拡張機能をインストールし、計測したいページでYSlowを実行するだけで、パフォーマンス評価を項目ごとにレポートしてくれる便利なツールです。
HAR
HARはHTTP Archiveファイルと呼ばれるもので、ページで読み込まれるコンポーネントのHTTP通信のログをJSONファイルでまとめたものです。ChromeやFirefoxなどのNetworkタイムラインを見ることができる開発者ツールでHARファイルを書き出すことができます。また、PhantomJS、Charles、WebPagetest、HTTPWatch、Fiddlerなどのアプリ、サービスでもHARを取得することができます。
WebPagetest
WebPagetestはパフォーマンスを計測してくれるWebサービスです。サイトを訪問してみればわかると思いますが、テストするロケーションを世界各地から選択することができ、またテストするブラウザーも組み合わせることで様々なパフォーマンステストを行うことができます。
また、First View、Repeat Viewでのウォーターフォールチャートの作成、Start Renderタイムの表示、PageSpeedスコアの表示、スクリーンショットの作成、ビデオ比較など非常に高機能なWebサービスです。
Show Slow
Show Slowは各ページのYSlowグレード、 PageSpeedスコア、dynaTraceランク、WebPagetestの指標を記録・公開するWebサービスです。一度サイトから計測したいページのURLを入力すれば、24時間毎に自動的に計測しつづけてくれます。
$ npm install yslow -g
Node ModuleのYSlowを使えばコマンドラインから使用することができ、それらの結果をShow SlowのBeacon URLで叩けば、任意のタイミングで記録することも可能です。
Continuous Integration
Yahoo! Profileでは継続的開発において、Unit, Integration, Acceptance, Smoke, Regression, Ninja などのさまざまなテストを行なっています。しかし、Webパフォーマンスに関してはどうでしょうか？全くもって皆無です。デプロイしてユーザーに届いてからWebPagetestでパフォーマンス低下を発見できても時既に遅し、後手後手の対応を取らざるを得ません。
そこで、PhantomJSというものを使います。PhantomJSはHeadless WebkitブラウザーでJavaScriptから動かすことが可能です。
--------
クリエイターズブログでもPhantomJSを使ったテストについて書かれています。
- PhantomJSを使ったスマホサイトテストの自動化(前編)｜1 pixel
- PhantomJSを使ったスマホサイトテストの自動化(後編)｜1 pixel
--------
$ phantomjs yslow.js http://yslow.org
PhantomJSでYSlowを動かすモジュールも提供されていますので、これをJenkins上で動かすことにしましょう。
--------
前回のエンジニアブログでもJenkinsについて書かれています。
- 第6回テックヒルズでアメーバピグにおけるJenkinsの活用例を発表しました。｜エンジニアブログ
--------
-f, --format {format}
(json|xml|plain|tap|junit)YSlowで吐き出す結果のフォーマットのデフォルトはjsonですが、TAP(Test Anything Protocol)を指定しましょう。
あらかじめ、JenkinsのTAP Pluginをインストールしておきます。
こうすることで、YSlowで生成されたテスト結果（TAPファイル）をJenkins上で良い感じにレポーティングしてくれます。
phantomjs yslow.js --info all --format tap --threshold '{"overall": "B", "ycdn": "F", "yexpires": "F", "ydns": "D"}' --ua "Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_2 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8H7 Safari/6533.18.5" http://yslow.org > yslow.tapフリースタイルのジョブを新規作成し、上記のようなシェルを実行すればOKです。
--infoオプションは吐き出すログの種類 (basic|grade|stats|comps|all)です。
--thresholdオプションはしきい値([0-100]|[A-F]|{JSON})で、JSONを書くことで細かい設定が可能です。一般的にはUses ContentDelivery Networkなどの項目をクリアすることは難しいかもしれないので、そうゆう項目はFランクのままでもテストがOKになるようにこのオプションで指定します。
--ua は文字通りUser Agentを指定するもので、スマホ専用サイトの計測などに便利です。
TAP Pluginのレポートで上記のように表示されます。完璧ですね。
このようなプロセスをDeploy前に組み込むことで、問題があれば再度修正し先手先手の対応が可能となります。
High Performance
ただ、問題なのはYSlowの評価はわりと大雑把というか読み込み時間などの細かな変化をレポーティングすることはできません。世の中にはWebパフォーマンスを評価するうえで様々な指標が存在します。- TTFB (Time To First Bite)
- Start Render
- Page Load
- domReady
- AFT(Above the Fold Time)
- Speed Inedx
一般的な指標は上記のようなものですが、扱っているサービスごとに重要な指標というのは変わってきます。Twitter社ではTTFT（Time To First Tweet）最初のTweetが表示されるまでの時間に着目しています。
この数値を出すために、WebPagetest APIを利用し、なおかつNode.jsで利用できるようにラッパーを作成しました。
- WebPageTest API Wrapper
さらに、Peregrineというツールを使い、dev, staging, prodなど環境ごとにWebPagetestを走らせ、レポーティングを可能にしています。Peregrineは近日中にはオープンソースとして公開する予定です。
このような試みより、パフォーマンス低下に怯えることなく安全・安心に新機能追加・バグフィックスのデプロイすることができるようになりました。
その他参加セッションリスト
フロントエンド多めです。Tue 18 Jun
Avoiding Performance Regression at Twitter / Marcel Duran (Twitter Inc.)
本記事のセッション。一発目からテンションだだあがりでした！
Bits on the Wire / Mark Nottingham (Akamai)
TCP/HTTP/DNSなどネットワークの基礎から応用まで丁寧に解説。
Speeding Up Your Mobile HTML5 Experience / Maximiliano Firtman (ITMaster Professional Training)
高速化のためのTipsやToolsを広く網羅してる内容。
A Picture Costs a Thousand Words / Guy Podjarny (Akamai)
画像形式ごとの仕組みやメリット・デメリットを解説。
Wed 19 Jun
Keynotes
Conquering The Uncanny Valley: Making Web Apps As Smooth As Native / Andrew Betts (FT Labs)
便利なモバイルフレームワークを多く作ってるFT Labさんの実用的なTips集。
Optimizing JavaScript Runtime Performance for Touch / Stephen Woods (Yahoo!)
JavaScript実行の最適化とか
The Curious Case of Dust Javascript and Performance / Veena Basavaraj (LinkedIn)
LinkedInでJSテンプレート（Dust.js）を採用した経緯について。
The CSS and GPU Cheatsheet / Colt McAnlis (Google)
GPUレンダリングを正しく理解するための各種レイヤーの説明
A Baseline for Web Performance with PhantomJS / Wesley Hales (Apigee), Ryan Bridges (Turner Broadcasting/CNN Digital)
PhantomJSとloadreport.jsを使ったパフォーマンスレポート作成
HTTP/2.0: What's Happening, and What's Next?
次期HTTP仕様に関してのパネル・ディスカッション
Thu 20 Jun
Keynotes
The Top 5 Performance Shenanigans of CSS Preprocessors / Nicole Sullivan (Stubbornella)
CSS プリプロッセー使用でよくあるミスをパフォーマンスの観点から。
Emerging Language Tools to Track JavaScript Quality and Performance/ Ariya Hidayat (Sencha)
Esprimaの使い方とか
Benchmarking the Front End: Expanding What Performance Means and How to Track it /Emily Nakashima (ModCloth), Rachel Myers (GitHub)
Single-Page Appのパフォーマンス計測に関して取り組んだ事例、必見！
Performance Monitoring: Synthetic vs RUM / Jon Fox (Torbit)
統合計測とリアルタイム計測の比較・使い分けを分かりやすく解説。
Top 10 WPO Disasters: Don't Let This Happen To You / Joshua Marantz (Google)
パフォーマンス最適化に際し、陥りがちな落とし穴10個！
Improving 3rd Party Script Performance With IFrames / Philip Tellis (SOASTA, INC)
ノンブロッキングなJS読み込みパターンについての解説。
Enough With The JavaScript Already! / Nicholas Zakas (Box)
そのJavaScript本当に必要ですか？
感想
『ハイパフォーマンスWebサイト』で、一般的にパフォーマンスの原因がフロントエンド：バックエンドで 8:2の割合であると述べられてから、フロントエンドのパフォーマンス改善は重要視されてきており、それに対する改善策なども多く行われてきました。しかし、海の向こうのフロントエンドエンジニアはそれだけでは満足せず、改善を行った結果をより正確に、より分かりやすく他の職種の人に共有する努力をしていると感じました。
このセッションに限らず、ほかのセッションでもPhantomJSとloadreport.jsを使用しレポーティングの自動化を行なっていたり(またCIサーバに組み込んだり)、Single-Page Appのパフォーマンス計測では、従来のNavigationTiming APIが意味をなさないので、Google AnalyticsのUser Timings機能を使い、独自の評価軸を設けている事例などがありました。
Front-End Opsという言葉が出てきてるように、私はDeveloperだからOperationのことは知らない・分からない。私はフロントエンドだからバックエンドのことは知らない・分からない、と言っているようであれば確実に取り残されてしまう業界であると痛感するとともに、非常に刺激を受けた良いカンファレンスでした。また来年も行きたいです。
Velocityでの資料は以下のページに集約されていく予定なので、みなさんもぜひチェックしてみてください。
- Speaker Slides: Velocity 2013