WCAN 2013 Summer で「ハイパフォーマンスWebフロントエンド」を話してきました
Posted: Updated:
スライド
振り返り
50分という限られた時間の中で、Network・Render・Computeという3本柱についてご紹介するという構成に挑ませていただきました。
恐らくフロントエンドが専門でない方も多くいらした中で、どこまでニュアンスだけでも届けられるように、という面の調整が多かったです。
結果的には目に見えるRenderについて多めに盛り込んで着地しています。
WebKit依存の内容が多めの所から、Canaryに載っている開発者ツールの使い方を通して、パフォーマンス問題の検証と対策について肉付けしている構成です。
参考にした資料のURLリスト
導入のあたり
- 開発者のための WebKit (“WebKit for Developers” 日本語訳)
- Performance Checklist for the Mobile Web - YouTube
- Strangeloop - Impact of 1-second delay - Web Site Optimization
- Webサイトパフォーマンス最新動向
Networkのあたり
- Webパフォーマンス ベストプラクティス - Make the Web Faster | LPWS
- PageSpeed Insights — Google Developers
- Chrome Networking: DNS Prefetch & TCP Preconnect - igvita.com
- High Performance Browser Networking
- Optimizing the Critical Rendering Path for Instant Mobile Websites: Velocity 2013
- Mobile Performance from the Radio Up: Battery, Latency and Bandwidth Optimization — Google I/O 2013
Renderのあたり
- Accelerated Rendering in Chrome: The Layer Model - HTML5 Rocks
- DevTools: Visually Re-engineering CSS For Faster Paint Times
- Chromium Blog: Build smoother web apps with Chrome Developer Tools
- GPU Accelerated Compositing in Chrome - The Chromium Projects
- The stacking context - Web developer guide | MDN
- Fastersite: How (not) to trigger a layout in WebKit
- Compare frames per second: which looks better?
- kelly norton: On Layout & Web Performance
- The CSS and GPU Cheatsheet: Velocity 2013 - O'Reilly Conferences, June 18 - 20, 2013, Santa Clara, CA
- Web Page Design with the GPU in Mind — Google I/O 2013
- Accidental layer creation
- Adventures in Jank Busting: Parallax, performance, and the new Flickr Home Page | code.flickr.com
- Gone In 60 Frames Per Second: A Pinterest Paint Performance Case Study | Smashing Magazine
Computeのあたり
- Memory leaks | JavaScript Tutorial
- Taming The Unicorn: Easing JavaScript Memory Profiling In Chrome DevTools
- Effectively managing memory at Gmail scale - HTML5 Rocks
- Use forensics and detective work to solve JavaScript performance mysteries - HTML5 Rocks
- Structural and Sampling (JavaScript) Profiling in Google Chrome - YouTube
- Static Memory Javascript with Object Pools - HTML5 Rocks
- High-Performance, Garbage-Collector-Friendly Code - Build New Games
- エデンの園でおきたこと - steps to phantasien
- GCアルゴリズム詳細解説 - Seesaa Wiki（ウィキ）
- Using Chrome Developer Tools to Find Memory Leaks - New Relic blog
- Performance — Writing Fast, Memory-Efficient JavaScript | Smashing Coding
上記資料のほか、CyberAgentの素晴らしい同僚ディベロッパーのみなさまと日々行っている情報交換により、今回のスライドは作られております。みなさま毎度お世話になっております(*´▽`)
次回の抱負
スライドつくり始めてみたら50分でちょっと収まらない系だったので、主にNetworkとCompute周りが削られています。今度は以下の内容を乗せつつ90分版ですかね。
パフォーマンスの問題も、Backboneのときと同様の「古典的Webサイト」「昨今のWebサービス」「最新のWebアプリ」のケースから、それぞれにおけるパフォーマンスの必要性について語っていったほうが良かったかも。ということをフィードバックもらってたり。
Compute周り
今回はTimelineに見る、何かしら問題があって対策すべき波形パターンと、それに関連する要因について手短にご紹介する程度におさまっています。今度は、次の2点についてキチンと紹介できるように準備したいですね。
- Garbage Collection
- Memory Leak
HTML5Rocksとか見ていると、Garbage Collection周りとかはフロントの人間も分かる人は分かってる問題ということで、しばしば紹介されています。今回は「ガベコレとはルンバである」とか喩えによる表現でお伝えしましたが、原理の面も人前で紹介できるようにまとめたい。
Memory Leakも同様ですね。技術色の強い話になりますが、これも人前で紹介できるレベルでまとめていきたい。
このあたりは低水準言語を理解しているようなプログラマ諸氏には、逆に当然の話かもしれないけど、自分みたいな、ゆるふわ系のフロントエンダにとってはこれから突破したいハードルのひとつと言えるかも。
Network周り
･･･は、言うほどあんまり無い気もしますが、ページロードのクリティカルパスになぞらえて、ページロード完了までの一連の出来事を詳説していく話は、どこかで必要かもしれない。
各所への学習支援として資料をぶん投げる際には、抑えるべき所を網羅的に抑えておいたほうが都合がよろしいということもございますれば。
Mental？周り
セッションの冒頭で、エンジニアリングとしてNetwork, Render, Computeを効率化する、という話を行うけれど、やむをえず遅いものやディレイが入るものを速く見せる、という心理的なパフォーマンスについては触れないと申しました。
が、今後はその分野も体系立てて、今回の3本柱と同様に取り扱うべきであると考えています。画像ロードや画面遷移、UIの細かいアニメーションetc…非常に多く語るべき部分を持っていることでしょう。
このような心理面に対する実装アプローチからのフォローも、フロントエンダならではの領域だと思っていますので、機会があればご紹介してみたいと思います。
ありがとうございました
まさかまさかの帰省ついでに、名古屋でこのようなお話をさせていただける貴重な機会をいただき大変うれしく思います。
関係者各位、重ねて御礼申し上げます。おつかれさまでした！
