狠狠撸

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やPro?les
を使う
Perfomance APIを使って自に状態を送信して監
視するようにするという手もある

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

描画パフォーマンス
? re?ow
? ブラウザのレンダリング?ツリーの再構築
? ノードの幅や高さ、親子関係を計算する
? ノードの位置やサイズが変わるか、それに関するプロパティを取得する
? repaint
? ノードの外見が変化するが、レイアウトには変更がないもの
? 背景や色の再描画
? 重たいCSSプロパティとアニメーション
? box-shadowやborder-radiusがかかった要素をアニメーションさせるのは重い

re?ow/repaintの対策
? `domElement.clientHeight` 等のレイアウト情報を取得する系
のプロパティは極力使わない?あるいはキャッシュを活用する
? `position:absolute` 等の絶対配置を使う
? `table`タグもしくは`display: table`を使わない
? JavaScriptからスタイルを書き換える頻度を減らす
? とにかくDOMのレイアウトの再構築を極力避ける

ライブラリの特性の理解
? 使っているライブラリを適切に理解すること
? 重くなる書き方?速くなる書き方
? JavaScriptとしての細かいチューニングよりよっぽど効
果がある

まとめ

今日の内容
? MFのFEとしての速度の向き合い方
? 測るべきは”ユーザ満足度”。速度はその中の一つの指標
? 遅いことを”価値”に変える方法を考える
? 最低限気を配るフロントのパフォーマンスとチューニン
グ

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

参考資料等
? ショートカットキーはマウスより遅い
? JavaScript アプリケーションのメモリー?リークを理解
する
? ReFlowの原因とマークアップの最適化

狠狠撸

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

Recommended

More Related Content

Viewers also liked (11)

Similar to フロントエンドから見たWebアプリの高速化 #gotandapm (20)

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