Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Web Frontend Performance Tuning
Search
Shinobu Hayashi
July 18, 2020
Technology
1
380
Web Frontend Performance Tuning
サマーインターン前につよつよになっちゃおうの会でWebフロントエンドのパフォーマンスについてLTした際の資料です
Shinobu Hayashi
July 18, 2020
Tweet
Share
More Decks by Shinobu Hayashi
See All by Shinobu Hayashi
ESLint Rule により事業, 技術ドメインに沿った制約と誓約を敷衍させるアプローチのすゝめ
shinyaigeek
1
4.1k
Big “heart” of mud, 10000 lines VCL generated from .vcl.handlebars
shinyaigeek
0
170
Managing "side effect" in Frontend Development
shinyaigeek
3
3.4k
爆速の日経電子版開発の今
shinyaigeek
2
2.2k
加速するEdge Computing
shinyaigeek
6
6.7k
ブラウザ作りのすゝめ
shinyaigeek
1
440
ASTをいじいじして僕のかんがえた最強のDXを得る
shinyaigeek
0
360
フロントエンド
shinyaigeek
0
160
Other Decks in Technology
See All in Technology
AIチャットボット開発への生成AI活用
ryomrt
0
170
障害対応指揮の意思決定と情報共有における価値観 / Waroom Meetup #2
arthur1
5
480
Evangelismo técnico: ¿qué, cómo y por qué?
trishagee
0
360
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
9
1.1k
DynamoDB でスロットリングが発生したとき_大盛りver/when_throttling_occurs_in_dynamodb_long
emiki
1
430
OCI Network Firewall 概要
oracle4engineer
PRO
0
4.2k
Incident Response Practices: Waroom's Features and Future Challenges
rrreeeyyy
0
160
TypeScriptの次なる大進化なるか!? 条件型を返り値とする関数の型推論
uhyo
2
1.7k
安心してください、日本語使えますよ―Ubuntu日本語Remix提供休止に寄せて― 2024-11-17
nobutomurata
1
1k
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
28
13k
Amplify Gen2 Deep Dive / バックエンドの型をいかにしてフロントエンドへ伝えるか #TSKaigi #TSKaigiKansai #AWSAmplifyJP
tacck
PRO
0
390
【Pycon mini 東海 2024】Google Colaboratoryで試すVLM
kazuhitotakahashi
2
540
Featured
See All Featured
Designing Experiences People Love
moore
138
23k
Practical Orchestrator
shlominoach
186
10k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Rails Girls Zürich Keynote
gr2m
94
13k
Documentation Writing (for coders)
carmenintech
65
4.4k
Bash Introduction
62gerente
608
210k
Unsuck your backbone
ammeep
668
57k
Building Adaptive Systems
keathley
38
2.3k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.3k
Gamification - CAS2011
davidbonilla
80
5k
Transcript
Web Frontend Performance Tuning Shinobu Hayashi(@Shinyaigeek) @サマーインターン前にツヨツヨになっちゃおうの会
About me Shinobu Hayashi(林 仁) - Twitter & GitHub: @Shinyaigeek -
Blog: https://shinyaigeek.dev しにゃいの学習帳 - 東大工学部三年 - Web Developer - 就活中
Agenda Web Frontend Performance tuning - 計測 - 実践 -
やらかし - チューニング - 技術選定 - 何故パフォーマンスに気を配るか ♂ サーバーサイドのチューニング ♂ モバイルのチューニング
計測
計測 Core Web Vitals : Web で優れたUXを提供するために共通する重要な指標 - Largest Contentful
Paint: viewportにおいて, 最も大きな画像, テキスト(= 主要なコンテンツ)のレンダリングに要する時間 - First Input Delay: ユーザーの入力に対してどれくらい早く反応できるか - Cumulative Layout Shift: コンテンツを表示して, どれくらいがくってなるか check: https://www.youtube.com/playlist?list=PLNYkxOF6rcIDC0-BiwSL52yQ0n9rNozaF
計測 ツール達 - Web Vitals (Chrome 拡張): Web Vitalsを測ってくれる -
LightHouse: Perfやアクセシビリティを測れる. 開発環境でも使いやすい - LightHouse CI: CI上でLightHouseを実行できる. metaタグの有無のチェックとかも やってくれる - CrUX: フィールドデータを取ってこれる etc… 基本的にはフィールドデータ, ラボデータ見つつ, ローカル環境でチューニングして LightHouse CIでregressionを防止する感じで進めていく ※LightHouse等のスコアを過信しすぎるのも良くないかなと思います . ただチューニングの足がかりとして強い .
実践 「よっしゃ, 計測方法はわかった. スコアの意味もわかった. でも具 体的にどう改善していけばええんや??」 -> ということで, このLTで実際にやっていきましょう このアプリを早くします
: https://22-si-demo.vercel.app/ 見てもらえればわかるのですが , 中身はごく普通のブログです 構成はReact, WebpackでのSPAです 施策については, LTではその意味について触れるだけにするので , 実装と かはGitHubのPRみてください
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)時間がかかったりする アプリケーションになる
個人的にはパフォチューでは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!!
実践
実践 < よし! https://22-si-demo.vercel.app/ を計測だ!(Lighthouse ポチ
実践 < とりあえず I/O 見るぞ. chromeのdevtoolの Network tabポチ!!! < main.jsが10MB..デカすぎんだろ...
よし!とりあえずJSのbuild sizeを減らすぞ!
実践(チューニング以前のやらかしを潰す) そもそもproduction buildしてなかった (これをしていないとminifyされなかったり, 様々な最適化がなされなかったりする) 画像ファイルがbase64エンコードされてjsファイルに入ってる(webpackだと url-loaderとかでやりがち) route-basedなcode splittingすらしてなかった(これをしてないと例えば /profile
にア クセスした時レンダリングには不要な / のコンテンツまでロードしないとレンダリングされ ない) これらはチューニング以前のやらかし ※ ちなみにここで書いたやらかしは実際に僕がやってしまったものです
実践 < 94点まで伸びた!!!! やらかしを失くすだけでちゃんとする場合も結構ある 今回のような, ブログという小規模なアプリを意図的に重くしたようなケース は少ないと思うので, ここまで劇的に伸びるわけではないですが
実践 < よっしゃ!いよいよチューニングや! そもそも全てのブラウザに対してES5にtranspileしたコードを配信しなくて良くな い??(differential serving) リソースの一部って読み込みの優先順位上げ下げして良くない? - <link rel=”preload” />
- img preload attr
補足(differential serving) jsのコードはレガシーな環境でも動くようにbabel等でtranspileされる transpileでコード量は増えるわけ だけど, 全てのブラウザで transpileしなきゃなの -> そうでもない, これを聞いている
ような人はchromeのconsoleで class文など普通に実行できると思 います
補足(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
補足(Skeleton) Skeleton ? -> リソースがまだloadされてない間表示しておくもの 身近なSkeleton Youtube GitHub
実践 < よし!改善できた気がするから計測や!Lighthouse ビターン!!! < 表示は早なったけどまだもっさりしてる気もする
実践 何故か空の<span />でいっぱい!! (こういったのははわざと生み出した通常有り得ない例ですが ) DOMはデカくなりすぎないように気を配りましょう - 表示するコンテンツが有限でいいとき : Pagination
- 表示するコンテンツがユーザーインプットを受けて無限である時 (無 限スクロール): virtualized(library: react-virtualized https://github.com/bvaughn/react-virtualized )
実践 (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を正しく運用する
他にもチューニングはいっぱい。。! - inline require - cache - img(webp, resize) -
prefetch - idle - file comporession - HTML Streaming etc...
そもそもの話 このアプリはSSRもSSGもClientSideでfetchとかもしてなくて, jsのなかに記事 が全部埋め込まれている形式 -> ブログならSSR, SSGすれば良いのでは?? -> そもそもクライアントサイドにReactを持ち込む必要はあった??(JSXが欲しいだけな ら,
react-dom/serverでhtml生成するだけでもよい, あるいはPreactとかでやればjsの size小さくなるのでは??) -> あるいはSvelte, lit-html, solid等の選択肢もある 後で直したり移行したりはしんどかったりする -> ♂安易に決めちゃダメ
技術選定について
正直技術選定めんどくさいんじゃが。。 < そもそもフロントエンドは専門じゃないしできればこの辺お手軽にやりたい んじゃが。。 個人的にはブログとかポートフォリオサイトならNext.js, Nuxt.jsはシステム に乗っかりやすいFWで, なおかつきちんと乗っかって利用していれば大げ さにやらかすことも少ないのでオススメです 記事の管理は外部のCMSに任せるJamStack
Architectureはオススメで す. Next.jsとかだったらボイラープレートとなるexampleを指定できて, それ で結構簡単に作れます
何故パフォーマンスに気を配るの
なぜパフォーマンスに気を配るの 「いいものを作れば売れるというナイーブな考えは捨てろ」 -> (面白い | 役に立つ) (もの | サービス) だからと言って売れるとは限らない
いいものをユーザーに届けるために - 広告 - 有無を言わせぬデザイン - アクセシビリティへの配慮 - パフォーマンス 等々のアプローチも求められる 動くことは前提としてそれを届けるために「動いたらいいや」 のその先に行こう!!!!
興味がある人は とりあえず「超速!Webページ速 度改善ガイド」, 通称超速本を読 んでください ✍
ご静聴ありがとうございました