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
400
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.7k
Big “heart” of mud, 10000 lines VCL generated from .vcl.handlebars
shinyaigeek
0
210
Managing "side effect" in Frontend Development
shinyaigeek
3
3.6k
爆速の日経電子版開発の今
shinyaigeek
3
2.6k
加速するEdge Computing
shinyaigeek
6
6.8k
ブラウザ作りのすゝめ
shinyaigeek
1
480
ASTをいじいじして僕のかんがえた最強のDXを得る
shinyaigeek
0
400
フロントエンド
shinyaigeek
0
180
Other Decks in Technology
See All in Technology
非エンジニアにも伝えるメールセキュリティ / Email security for non-engineers
ykanoh
13
3.9k
ISUCONにPHPで挑み続けてできるようになっ(てき)たこと / phperkaigi2025
blue_goheimochi
0
140
Why Go?
xpmatteo
0
130
コンソールで学ぶ!AWS CodePipelineの機能とオプション
umekou
2
110
RAGの基礎から実践運用まで:AWS BedrockとLangfuseで実現する構築・監視・評価
sonoda_mj
0
430
セマンティックレイヤー入門
ikkimiyazaki
8
2.7k
[CATS]Amazon Bedrock GenUハンズオン座学資料 #2 GenU環境でRAGを体験してみよう
tsukuboshi
0
140
OPENLOGI Company Profile for engineer
hr01
1
22k
Amazon Q Developer 他⽣成AIと⽐較してみた
takano0131
1
120
グループポリシー再確認
murachiakira
0
160
Riverpod & Riverpod Generatorを利用して状態管理部分の処理を書き換えてみる簡単な事例紹介
fumiyasac0921
0
100
チームビルディング「脅威モデリング」ワークショップ
koheiyoshikawa
0
130
Featured
See All Featured
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
Testing 201, or: Great Expectations
jmmastey
42
7.4k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
GitHub's CSS Performance
jonrohan
1030
460k
Designing for humans not robots
tammielis
250
25k
BBQ
matthewcrist
88
9.5k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.3k
Typedesign – Prime Four
hannesfritz
41
2.6k
How to train your dragon (web standard)
notwaldorf
91
5.9k
Bash Introduction
62gerente
611
210k
YesSQL, Process and Tooling at Scale
rocio
172
14k
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ページ速 度改善ガイド」, 通称超速本を読 んでください ✍
ご静聴ありがとうございました