フロントエンドから見たwebアプリの高速化 #gotandapm

Copyright (c) 2015 Mobile Factory, Inc. All rights reserved.

フロントエンドから見たWebアプリの高速化

#gotanda.pm 2015/06/24 @mizuki_r


name. 飯沼　遼

account.

twitter: @mizuki_r github: ry_mizuki

role. フロントエンド寄りのエンジニア


今日お話すること

• Mobile Factoryにおける”フロントエンドエンジニア”

• フロントとサーバでの高速化に対する見方の違い

• 高速化しない選択肢

• フロントで”高速化”にコミットするには


Mobile Factoryにおける、フロントエンドエンジニアとは


持つべき責務

UXを提案し、実装する


FEの役割• UXに関し、その技術が必要なら習得する

• あらゆる職能との連携を行う

• サーバ、ディレクタ、デザイナ

• そのチームにおいて求められる範囲と求められる技術は異なる

• JavaScript, Java, Swift, Perl, etc…


今の私の場合

• チームのプロジェクトはWebアプリケーション

• 技術的には、HTML5・CSS・JavaScriptが中心

• AngularJSとかSCSSとか

なので、今日は”フロント”って言ったらその辺のことだよ！


フロントとサーバでの高速化に対する見方の違い


基本

速度の改善は、まず計測から始めるこれは一緒


関心を持つべき値サーバーフロント

レスポンス速度アプリケーションミドルウェア(DBとか)サーバの負荷状況通信速度etc…

リソースサイズ描画速度

インタラクションへの反応速度etc…

フロントエンドはあらゆるUIの「描画」や「反応」のパフォーマンスを意識する必要がある


計測方法サーバーフロント

ロギング各サーバー毎に出力、集計サーバに送信

クライアントで出力APIサーバに送信

環境任意のOS、環境を用意

できるユーザの手元のOS、ブ

ラウザ

メモリ・CPU等の状態リアルタイムで集計可能ユーザの手元なので…

基本ユーザの手元なので、情報を集めること自体が難易度高い


フロントの改善へのハードル

• Analyticsや他のツール等で追える情報はある • 頑張って自作できないこともない

• JavaScriptにパフォーマンスを取得するAPIがある • ただしブラウザによって実装状況はｋ（ｒｙ

• 計測したところで対応できない問題もある

• OSが古い。ブラウザが古い。端末スペック（笑）


やってられるか＼(^o^)／


そして、諦め

僕ゎもぅっかれたょ….

愚直に数字を集計して改善するより、もっと費用対効果のよい方法で速度を凌駕する体験を

提供できればそれでよいのでは?


高速化しない、という選択肢


なぜ高速化しないといけないのか？

• 速度が速いと…

• ユーザ満足度の向上やSEOの効果などが見込める

• 待つこと自体がストレス

• しかし… そのストレスを低減させることはできる？


例題あなたは友達と午前10:00に五反田駅で待ち合わせをしていました。

しかし、友達は10分たってもやってきません。LINEで連絡を取りますが既読にならない。

途中で何かあったのかと思いますが、ふとあなたは昨夜ずいぶん遅くまでその友達とイカになっていたことを思い出します。


この時のあなたの心情は？

• 早く反応してくれ

• イライライライライライラ

• もう帰っていイカ？


例題2

数度の呼び出しを経て彼がようやく反応しました。

予想通り寝坊のようです。あと30分でつく、と慌てた声で彼はいいました。

あなたは溜息とともに待つことを承諾します。


どうやって30分まつ？

• 携帯ゲーム

• ネットサーフィン

• 音楽を聞く

• 散歩でもする


何が言いたいかというと…

何時まで待てばいいのか、待っている間何をすればいいのか、

がわかれば人は待てる！ …と思う


具体例

• ローディングゲージ

• ローディングアニメーション

• ゲームのtips

• ミニゲーム


遅い、とユーザに思わせない。楽しいと思えるようにする

• ゲームなら世界観やゲームのチップスやキャラとか • 簡単なアニメーションでも、動かれると気になって見てしまう

• よくあるグルグル回るだけのアニメーションはNG • 演出にユーザが慣れてしまう

• イベントや告知なども効果あり • 必ず目に触れるポイントで、かつ読む時間も作れる

• ユーザに待たせないと行けないタイミングはちゃんと明確にしてあげる

• ボタンおしたらなんの反応もなく何もできない、みたいなのはNG • 過度な演出はNG

• ユーザのテンションを上げたいポイントとの差別化は必要


ユーザにとっての価値を考える

• 下手な高速化より、時間の演出によって満足度が変わる

• “遅い”を許容するのではなく、”新たな価値”を作れないかを考える

• 計測すべきは”速度”ではなく、”ユーザの満足度”


フロントエンドで高速化にコミットする


関心を持つべきポイント

• メモリリーク

• 描画パフォーマンス

• ライブラリの特性の理解


メモリリーク

検知方法: Google ChromeのdevToolsのTimelineやProfilesを使う

Perfomance APIを使って自鯖に状態を送信して監視するようにするという手もある


Google Chrome devToolsで監視

Used JS Heap を監視。意図せずこいつが増えていたら、Summaryから謎のループが発生していないか、等怪しいコードを探しだす。


描画パフォーマンス• reflow

• ブラウザのレンダリング・ツリーの再構築

• ノードの幅や高さ、親子関係を計算する

• ノードの位置やサイズが変わるか、それに関するプロパティを取得する

• repaint

• ノードの外見が変化するが、レイアウトには変更がないもの

• 背景や色の再描画

• 重たいCSSプロパティとアニメーション

• box-shadowやborder-radiusがかかった要素をアニメーションさせるのは重い


reflow/repaintの対策• `domElement.clientHeight` 等のレイアウト情報を取得する系のプロパティは極力使わない・あるいはキャッシュを活用する

• `position:absolute` 等の絶対配置を使う

• `table`タグもしくは`display: table`を使わない

• JavaScriptからスタイルを書き換える頻度を減らす

• とにかくDOMのレイアウトの再構築を極力避ける


ライブラリの特性の理解

• 使っているライブラリを適切に理解すること

• 重くなる書き方・速くなる書き方

• JavaScriptとしての細かいチューニングよりよっぽど効果がある


まとめ


今日の内容

• MFのFEとしての速度の向き合い方

• 測るべきは”ユーザ満足度”。速度はその中の一つの指標

• 遅いことを”価値”に変える方法を考える

• 最低限気を配るフロントのパフォーマンスとチューニング


ご清聴ありがとうございました


参考資料等

• ショートカットキーはマウスより遅い

• JavaScript アプリケーションのメモリー・リークを理解する

• ReFlowの原因とマークアップの最適化

http://wirelesswire.jp/2015/03/21781/

http://www.ibm.com/developerworks/jp/web/library/wa-jsmemory/

http://developers.linecorp.com/blog/?p=379

フロントエンドから見たwebアプリの高速化 #gotandapm

Technology