Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Web Frontend Performance Tuning

Web Frontend Performance Tuning

サマーインターン前につよつよになっちゃおうの会でWebフロントエンドのパフォーマンスについてLTした際の資料です

Shinobu Hayashi

July 18, 2020
Tweet

More Decks by Shinobu Hayashi

Other Decks in Technology

Transcript

  1. About me Shinobu Hayashi(林 仁) - Twitter & GitHub: @Shinyaigeek -

    Blog: https://shinyaigeek.dev しにゃいの学習帳 - 東大工学部三年 - Web Developer - 就活中
  2. Agenda Web Frontend Performance tuning - 計測 - 実践 -

    やらかし - チューニング - 技術選定 - 何故パフォーマンスに気を配るか ‍♂ サーバーサイドのチューニング ‍♂ モバイルのチューニング
  3. 計測 Core Web Vitals : Web で優れたUXを提供するために共通する重要な指標 - Largest Contentful

    Paint: viewportにおいて, 最も大きな画像, テキスト(= 主要なコンテンツ)のレンダリングに要する時間 - First Input Delay: ユーザーの入力に対してどれくらい早く反応できるか - Cumulative Layout Shift: コンテンツを表示して, どれくらいがくってなるか check: https://www.youtube.com/playlist?list=PLNYkxOF6rcIDC0-BiwSL52yQ0n9rNozaF
  4. 計測 ツール達 - Web Vitals (Chrome 拡張): Web Vitalsを測ってくれる -

    LightHouse: Perfやアクセシビリティを測れる. 開発環境でも使いやすい - LightHouse CI: CI上でLightHouseを実行できる. metaタグの有無のチェックとかも やってくれる - CrUX: フィールドデータを取ってこれる etc… 基本的にはフィールドデータ, ラボデータ見つつ, ローカル環境でチューニングして LightHouse CIでregressionを防止する感じで進めていく ※LightHouse等のスコアを過信しすぎるのも良くないかなと思います . ただチューニングの足がかりとして強い .
  5. 実践 「よっしゃ, 計測方法はわかった. スコアの意味もわかった. でも具 体的にどう改善していけばええんや??」 -> ということで, このLTで実際にやっていきましょう このアプリを早くします

    : https://22-si-demo.vercel.app/ 見てもらえればわかるのですが , 中身はごく普通のブログです 構成はReact, WebpackでのSPAです 施策については, LTではその意味について触れるだけにするので , 実装と かはGitHubのPRみてください
  6. Runtime Cost, I/O Cost その前に... - Runtime Cost: ユーザー操作, setInterval等を受けての処理のコスト,

    あるいは レンダリングのコスト cf: Runtime : Node.js, deno, browser(chrome, safari…), electron… v8, spider monkeyはengine Runtime Costが高いとなんかカクカク, もっさりしたアプリケーションになる - ⚡ I/O Cost: Input/Output処理のコスト. この場合サーバー とのReq/Resのやり取りのコスト I/O Costが高いと, なかなか遷移しなかったり, ユーザー操 作を受け取れるようになるまで(TTI)時間がかかったりする アプリケーションになる
  7. 個人的にはパフォチューではRuntime CostとI/O Costの二つを改善していく ことを念頭に置けばやりやすいと思います - Runtime Cost DOMが大きくなりすぎないように (React, Vueなど仮想DOMを扱うライブラリを用いている時

    ) 不要なre-renderは減らす 非同期処理はちゃんと扱う (あとjsのファイルサイズを減らせば parse, compile, execの内parse, compileというlong taskに かかる時間が減るため Runtime Costが減るという見方もあったりします ) - I/O Cost ⚡ file sizeを減らす ⚡ 配信するコンテンツの優先順位をつける (preload, lazy load) ⚡ fileを圧縮する(gzip, Brotli) ⚡ Cache !! Cache!! Cache!!
  8. 補足(differential serving) 90%以上のブラウザがES6で書かれたコードを実行可能 (https://caniuse.com/#feat=es6-module) -> モダンな環境にはモダンなJSを, レガシーな環境にはレガシーなJSを配信したい どうやんの ? -

    module-nomodule pattern - Feature Detection - User-Agent Sniffing in detail: https://philipwalton.com/articles/deploying-es2015-code-in-production-today/, https://nodaguti.hatenablog.com/entry/2020/04/18/184251
  9. 実践 何故か空の<span />でいっぱい!! (こういったのははわざと生み出した通常有り得ない例ですが ) DOMはデカくなりすぎないように気を配りましょう - 表示するコンテンツが有限でいいとき : Pagination

    - 表示するコンテンツがユーザーインプットを受けて無限である時 (無 限スクロール): virtualized(library: react-virtualized https://github.com/bvaughn/react-virtualized )
  10. 実践 (Reactで) 不要なre-renderingを避ける chrome extensionsの “React Developer Tools”を 入れる ->

    devtoolを開く -> Profilerを開く -> ⚙をク リックして✅Highlihgt update when component renderにチェックをつけると componentがmount, re-renderされたタイミングでハイライトすることが出 来る 無駄なre-renderingを避けるためには - React memo - key props - stateを正しく運用する
  11. そもそもの話 このアプリはSSRもSSGもClientSideでfetchとかもしてなくて, jsのなかに記事 が全部埋め込まれている形式 -> ブログならSSR, SSGすれば良いのでは?? -> そもそもクライアントサイドにReactを持ち込む必要はあった??(JSXが欲しいだけな ら,

    react-dom/serverでhtml生成するだけでもよい, あるいはPreactとかでやればjsの size小さくなるのでは??) -> あるいはSvelte, lit-html, solid等の選択肢もある 後で直したり移行したりはしんどかったりする -> ‍♂安易に決めちゃダメ
  12. なぜパフォーマンスに気を配るの ‍「いいものを作れば売れるというナイーブな考えは捨てろ」 -> (面白い | 役に立つ) (もの | サービス) だからと言って売れるとは限らない

    いいものをユーザーに届けるために - 広告 - 有無を言わせぬデザイン - アクセシビリティへの配慮 - パフォーマンス 等々のアプローチも求められる 動くことは前提としてそれを届けるために「動いたらいいや」 のその先に行こう!!!!