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
フロントエンドパフォーマンス 入門
Search
Shouta
March 23, 2024
Programming
8
1.9k
フロントエンドパフォーマンス 入門
Shouta
March 23, 2024
Tweet
Share
Other Decks in Programming
See All in Programming
PSR-15 はあなたのための ものではない? - phpcon2024
myamagishi
0
150
PHPで作るWebSocketサーバー ~リアクティブなアプリケーションを知るために~ / WebSocket Server in PHP - To know reactive applications
seike460
PRO
2
560
開発者とQAの越境で自動テストが増える開発プロセスを実現する
92thunder
1
190
Amazon S3 NYJavaSIG 2024-12-12
sullis
0
100
どうして手を動かすよりもチーム内のコードレビューを優先するべきなのか
okashoi
3
230
Mermaid x AST x 生成AI = コードとドキュメントの完全同期への道
shibuyamizuho
0
160
テストコードのガイドライン 〜作成から運用まで〜
riku929hr
5
760
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
3
540
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
520
KubeCon + CloudNativeCon NA 2024 Overviewat Kubernetes Meetup Tokyo #68 / amsy810_k8sjp68
masayaaoyama
0
260
Cloudflare MCP ServerでClaude Desktop からWeb APIを構築
kutakutat
1
560
GitHubで育つ コラボレーション文化 : ニフティでのインナーソース挑戦事例 - 2024-12-16 GitHub Universe 2024 Recap in ZOZO
niftycorp
PRO
0
100
Featured
See All Featured
Designing for humans not robots
tammielis
250
25k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
Embracing the Ebb and Flow
colly
84
4.5k
KATA
mclloyd
29
14k
A designer walks into a library…
pauljervisheath
205
24k
Making Projects Easy
brettharned
116
6k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
Testing 201, or: Great Expectations
jmmastey
40
7.1k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
48
2.2k
Being A Developer After 40
akosma
87
590k
Rails Girls Zürich Keynote
gr2m
94
13k
A Tale of Four Properties
chriscoyier
157
23k
Transcript
フロントエンドパフォーマンス 入門 内山 翔太
自己紹介 基本的に興味関心がパフォーマンスに全振りしています SES で働いています 普段は Java を書いており、フロントエンドは趣味です(?)
今日の内容 Core Web Vitals Web パフォーマンスにおいて確認すべき要素 すぐに取り組める改善
Web サイトのパフォーマンスの重要性 ユーザー体験の向上 ユーザー体験が悪いと離脱してしまう Amazon では表示速度が 0.1 秒遅くなると売上が 1 %減少すると言われている
( 後述する) Core Web Vitals は検索順位にも影響を与える 訪問者あたりの収益が 53.37% 、コンバージョン率が 33.13% 増加したケースもあ るらしい。 https://web.dev/case-studies/rakuten?hl=ja
Core Web Vitals とは Google が提唱するパフォーマンスの指標のことです。 Core Web Vitals は、ページの読み込みパフォーマンス、インタラクティブ性、視
覚的安定性に関する実際のユーザー エクスペリエンスを測定する一連の指標で す。 https://developers.google.com/search/docs/appearance/core-web-vitals?hl=ja Lighthouse や PageSpeed Insights で手軽に計測できます。
Core Web Vitals の指標を解説 First Contentful Paint (FCP) ページで一番最初に描画されるまでにかかった時間 Largest
Contentful Paint (LCP) 最も大きな要素が描画されるまでにかかった時間 Total Blocking Time (TBT) ページがユーザー入力に応答できない時間 最近だと、Hydration と呼ばれる処理にかかる時間が長いことで悪化しやすい 印象 Cumulative Layout Shift (CLS) レイアウトシフトがどのくらい起きているかの指標
Web パフォーマンスにおい て確認すべき要素 フロントエンドエンジニアが確認す るべきは フロントエンド ネットワークの帯域( ファイルサ イズなど) React
Server Components(RSC) の登場でバックエンドまで見る 必要も... ? https://twitter.com/takehora/statu s/1499185146779607045
この画像で何を伝えたかったのか? ファイルサイズは数多くある要素の内の一部である。 ファイルサイズの削減、圧縮はその一部のみに効く施策である minify は計算量を削減しないし、処理同士の依存関係も解消しない サイト全体のファイルサイズが小さい = 速いではない 逆に、サイトが遅い =
ファイルサイズが大きいでもない!!! 処理のコスト、順序を考えるのが大切
これらの知識をどう活かすか これらの知識がなんとなくでも身につくと、どの技術が何を解決するために生まれた のか。自分はどの技術を採用すればいいのか理解しやすくなります。 例えば RSC はサーバー側で React コンポーネントを実行し、ブラウザでの実行 コストを削減する技術です。 ブラウザ上での
JavaScript の実行コストが減ると、ユーザー入力を妨げる重たい 処理が減るので、TBT や Time to Interactive( 紹介しきれなかった...) が改善する。
おまけ 最新の HTML 、CSS を学ぼう! ライブラリを使わなくても dialog 要素でダイアログ, details 要素でアコーディオ
ンを簡単に作れる。 ライブラリを使用するよりバンドルサイズも小さくなる。 軽量なライブラリを選定しよう。 bundlephobia や Shakerphobia を使用するとバンドルサイズを測定できます。 https://bundlephobia.com/ 本当にそのライブラリ必要ですか?? 上 2 つとも関係しますが、最近の HTML,CSS,JavaScript は進化しています。 標準の技術で実現できないのか?自作できないのか? まずは検討してみよう!!
おわり 入門ということで、 パフォーマンスの指標 パフォーマンスはいろんな要素が絡んでいること を中心に話しました。 ご清聴ありがとうございました!