Frontrend Vol.10

Frontrend Vol.10 - 夏の終わりに納涼パフォーマンス話 - connpassに参加してきたのでメモ。

FRESH!: クライアントサイドパフォーマンス改善 by @sutiwo_

パフォーマンスを改善して本を売る！「読書のお時間です」の取り組みについて

  • 5年続いたSPAのウェブサービスをSSRにした話
  • 問題分析
    • ボトルネック調査
  • 設計
    • Before
      • jQuery
      • handlebars
      • Grunt
    • After
      • React/webpack色々
  • 開発
    • プロイピング
    • 主要ページからリニューアルする
    • 旧仕様のページと行き来できる作り(共存する)
    • #! から / に変更
  • リリース
    • ページロード 30% down
    • コンテンツサイズ 50% down
  • 展開
    • 対象ページが100ページ以上あった
    • 既存のものを運用しないといけない
  • 画像との戦い
    • 本の表紙 = 書影
    • 画像の提供元によってサイズなどがバラバラ
  • パフォーマンス計測とKPIの紐付け

アメブロ: Isomprhicアプリケーションのパフォーマンス・チューニング

スライド: アメブロ: Isomprhicアプリケーションのパフォーマンス・チューニング // Speaker Deck

  • アメブロ2016 ~ React/ReduxでつくるIsomorphic web app ~の話
  • Javaベース -> Node.jsベースに変更
  • SSR: Isomorphic App(SPA + SSR) + React+ Redux + React Router
  • バックエンドキャッシュは大分
    • React SSRはパフォーマンスが悪い
  • クライントは特定のユーザー、サーバサイドはすべてのユーザにサービスを提供
    • なのでサーバサイドはキャッシュとかしないと
  • バックエンドのキャッシュの設計
  • 問題点を洗い出す
    • 何をキャッシュするか
      • Router -> Redux Store準備(API Object) -> Render -> HTML
      • RenderToStringはとても重たい
      • RenderToStringはキャッシュしたい
      • ただしユーザーによって違うのでそのままキャッシュできない
      • RenderToStringはテンプレートを吐き出して、クライアントサイドでそれをレンダリングする
      • API Objectもキャッシュすることでより改善された
    • キャッシュするタイミング
      • アクセスされたとき
    • キャッシュを削除するタイミング
      • 記事を更新したら、記事IDから記事のキャッシュを消すのはNG
      • 実際は記事を更新したら、記事本体、記事一覧、記事の前後などいろんなところを影響する
      • 実装はかなり複雑になるので、キャッシュの削除は難しい
      • AmebaブログはユーザIDに紐付いているので、更新したらユーザIDに紐づくページをすべて削除する
      • FallbackとしてキャッシュのTTLで失効させる
    • キッシュのトランザクション
      • キャッシュの更新とアクセスでキャッシュ作られたときに衝突してしまう問題
      • キャッシュのkeyは namespace(user-id)+version をつかうようにした
      • なので削除ではなくバージョンの更新 = キャッシュの削除
    • Local Cache VS Cache Server
      • Node.jsのインスタンス数が多い(オンメモリだけではばらけてしまう)
      • オンメモリのキャッシュ + キャッシュサーバを併用
  • 遅延ロード
  • Service Worker
  • HTTP/2 && コード分割
    • Chromeは一度にリクエストできるの6つまで
    • 一括で読み込むと詰まることがある
    • この辺は改善していきたい

Q&A

  • Q. パフォーマンス計測ツールはアメーバ社内で共通化されてるの?
  • A. アメブロはSpeedCurveとか
  • 1000chに聞いて