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
430
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
5.1k
Big “heart” of mud, 10000 lines VCL generated from .vcl.handlebars
shinyaigeek
0
230
Managing "side effect" in Frontend Development
shinyaigeek
3
3.7k
爆速の日経電子版開発の今
shinyaigeek
3
2.7k
加速するEdge Computing
shinyaigeek
6
6.8k
ブラウザ作りのすゝめ
shinyaigeek
1
510
ASTをいじいじして僕のかんがえた最強のDXを得る
shinyaigeek
0
430
フロントエンド
shinyaigeek
0
190
Other Decks in Technology
See All in Technology
公開初日に Gemini CLI を試した話や FFmpeg と組み合わせてみた話など / Gemini CLI 初学者勉強会(#AI道場)
you
PRO
0
600
敢えて生成AIを使わないマネジメント業務
kzkmaeda
2
490
Copilot coding agentにベットしたいCTOが開発組織で取り組んだこと / GitHub Copilot coding agent in Team
tnir
0
110
TableauLangchainとは何か?
cielo1985
1
140
OpenTelemetryセマンティック規約の恩恵とMackerel APMにおける活用例 / SRE NEXT 2025
mackerelio
2
1.3k
「クラウドコスト絶対削減」を支える技術—FinOpsを超えた徹底的なクラウドコスト削減の実践論
delta_tech
4
180
AWS CDK 入門ガイド これだけは知っておきたいヒント集
anank
3
470
Lakebaseを使ったAIエージェントを実装してみる
kameitomohiro
0
170
How Do I Contact HP Printer Support? [Full 2025 Guide for U.S. Businesses]
harrry1211
0
130
CDKTFについてざっくり理解する!!~CloudFormationからCDKTFへ変換するツールも作ってみた~
masakiokuda
1
190
american airlines®️ USA Contact Numbers: Complete 2025 Support Guide
supportflight
1
110
助けて! XからWaylandに移行しないと新しいGNOMEが使えなくなっちゃう 2025-07-12
nobutomurata
2
120
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Music & Morning Musume
bryan
46
6.6k
Six Lessons from altMBA
skipperchong
28
3.9k
The Invisible Side of Design
smashingmag
301
51k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Code Reviewing Like a Champion
maltzj
524
40k
Gamification - CAS2011
davidbonilla
81
5.4k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
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ページ速 度改善ガイド」, 通称超速本を読 んでください ✍
ご静聴ありがとうございました