Bonfire Frontend #3
https://gyazo.com/f1377dfa455b0e26a33a4adf68cd8b5d
https://yj-meetup.connpass.com/event/114979/
技術刷新から考えるWeb 開発のプロダクティビティ改善
竹野 峻輔 / Retty株式会社
SE 2年目
データエンジニア
日本最大級の実名グルメサービス「Retty」
実名制
口コミ
友人とのつながり
月間利用者数 4000万人突破(2018/11)
以前のアプリケーションの主体はサーバ(SSR)
近年はクライアントサイドが主体
明らかなパラダイムシフト
Rettyの現状
モノシック & カオティック
短期的なパフォーマンスチューニングも
中長期的にはなかったことになっている
裏側をリニューアルしていく
リニューアル=リアーキテクチャ
なんのためにやるか
UX改善を持続的に行うためにDXを築いていく取り組み
プロダクティビティ改善
マイクロサービス化
それぞれで最適化を行う
ミクロの観点をもつ
境界区切った部分に注力する
スコープ
凝集かと分割(modularize)
システムの構成要素の役割の再整理
時速的な変更可能性の確保(sustainability)
個々の開発負担の軽減
ユーザ、ビジネス、開発をマイクロ・ミクロの観点でみていく
プロダクトとチームを一緒に作り変えていく
コラボレーション
多角的な視点でアーキテクチャを整理する
ユーザログ機構をフロントエンドにうまく統合する
上位から回のコンポーネントにデータを渡す
データの人がフロントの人に開発サイクルのコンテキストを相談
コンポーネントを汚さないログ設計が可能になった
親和性
チームとして力を集約する
フロントエンドとバックエンドの共同作業
技術選定:GraphQL
スキーマのレビュー会の開催
フロント。バックエンドの療法が必要な思想と開発・設計のすり合わせ
納 得 と 覚 悟 の 醸 成
まとめ
プロダクティビティ=人×モノ
安易な責任の分割はしない
一休.comのフロントエンドパフォーマンス改善
https://slides.com/ryoutsunomiya/ikyu-frontend-perf-optimization/
宇都宮 諒 / 株式会社一休
@ryo511
UIチーム所属
一休コンシェルジュの開発サポート
一休.comと一休コンシェルジュ
一休.com
広告がでない
サーバーサイドは古い
一休コンシェルジュ
https://www.ikyu.com/concierge/
広告なし
WordPress
最適なパフォーマンスとは?
サイトの種類や性質によって最適化のポイントは異なる
ECサイトやメディアサイトはロード時間が重要
ゲームはロードは多少長くてもよいが、プレイ中に動作が重くなるのはNG
最適化のものさし
lighthouse
サイトの速さは3分割
0〜49: Slow
50〜89: Average
90〜100: Fast
指標
1. First Meaningful Paint
2. First CPU Idle
3. First Contentful Paint
4. SpeedIndex
5. Time To Interactive
スコアを見るか指標をみるか?
バージョンアップに寄って計算式が変わる
Calibre等を使ってればTTIやSpeedIndexを確認すべき
相対評価のものさしとして見るべき
PageSpeed Insights
3Gのプロファイルで計測している
Service Workerによる高速が効かない
WebPageTest
回線速度をこまかく設定できる
ECサイト
50を超えれば大抵は早い
70以上は業界トップクラス
メディアサイト
70超えがマイルストーン
要件次第では90超えいけそう
一休.com
72点
トップページ: 32点
ホテルリストページ: 41点
ホテルページ: 72点
ホテルページ(amp): 80点
表示は速いが、ロード完了は遅い
サードパーティスクリプトが要?
あまりキャッシュできない
細かい検索クエリに対応する必要ある
詳細ページはコンテンツが多くなりがち
最適化
画像サイズの適正
Imgixを利用
Above the Foleに入らない画像はlazyload
レンダリングブロック解消
一休コンシェルジュ
トップ: 79点
記事: 84点
最適化先約
Fastlyを利用
Imgix
ampの活用
Canonical AMP化を検討
パフォーマンス最適化戦略
遅い要素を減らす
ただしサイトの性質によって利用できる最適化のオプションは異なる
パフォーマンスのためのアーキテクチャ
SPAかMPAか
SSRするか
CDNのキャッシュ戦略
Service Workerの活用
一休.comの方針
Jamstackを利用していきたい
サーバサイドはAPIのみ
パフォーマンスと疎結合
SEOに懸念点
GooglebotはChrome 41相当のJSを実行できる
Dynamic Rendering
Rendertronで実験中
これからのフロントエンド
TTIを5秒以内
TTFB改善
トップ+リスト+詳細のSPA化の検討
SSRの優先度は低い
Dynamic Renderingが担保してくれる
まとめ
パフォーマンス最適化は適切な計測から始まる
パフォーマンスの伸びしろは、サイトの要件次第
大幅な改善はアーキテクチャレベルの変更が必要
パフォーマンス改善の具体例とサービスへの売上貢献
笹原 翼 / ヤフー株式会社
ヤフーショッピングを担当
技術部長 兼 サービスマネージャー
ヤフーショッピングのパフォーマンス改善
結果
各ページ時間削減
CVRが110%アップ
なぜパフォーマンス改善をやるのか
速度が早くなると
ユーザー体験向上
KPIによい影響(仮説)
表示速度が0.1秒減ると売上1%増加
KPI
取扱高
注文単価
CVR
サブKPIも色々
極論として早くなって悪くなることはない
進め方
ABテストで証明
APIんぼ非同期化
キャッシュ化
クオリティ85に
プロジェクトを立ち上げる
速度改善しまくり状態
どこでパフォーマンス改善をやるべきか
注力する領域は事前調査で定める
どのページ
PV/UUの多いところ
多くの人が使っている
TOP
検索
商品ページ
経由取扱高の高いページ
カート
SpeedCurveを採用している
https://speedcurve.com/
定期実行できる
グラフ化
いろんな指標がとれる
競合と比較改善結果がすぐに出る
ランニングコスト
5万サイト/月で5万円
どんな改善をやったのか
指標を見ていくのか決める
ファーストビュー90%見えたら
Speed Index
安定した測定環境
測定が安定すると改善結果が見えやすい
改善の具体例
遅い、直列なAPIのモジュールを非同期化
間違った非同期化をやめる
onloadで画像読み込み開始をやめる
画像のpreload
レンダリングブロック後に描写できるようにする
JS,CSSのpreload
検索ページの時点で非同期で商品ページのJSを読み込む
JS, CSSの非同期読み込み
画像の最適化
クオリティを85に
解像度を適したものに
ハードのリプレイス、スケールアウト
高スペックにするとよくなる
JS, CSSの軽量化
圧縮形式をgzipからbrotliに変える
どんな効果があったのか
表示速度は競合で3位から2位に
CVRが約110%アップ
SEOにもよい影響・クロール量の増加
今後
さらなるパフォーマンス改善
AMP化?
自社ドメインで問題解決
SIgned HTTP Exchanges
計測は実ユーザデータを使いたい
キャッシュヒット、ページ遷移計測が正確に
やること
1. パフォーマンスとサービスKPIの相関を証明
2. 注力領域を定める
3. 評価指標を決めて、安定した測定環境を整える
4. 課題点を見つけて改善
5. 効果をしっかり出して継続し続ける