フロントエンドパフォーマンス入門

フロントエンドパフォーマンス入門内山翔太

自己紹介基本的に興味関心がパフォーマンスに全振りしています 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 は進化しています。標準の技術で実現できないのか？自作できないのか？まずは検討してみよう！！

おわり入門ということで、パフォーマンスの指標パフォーマンスはいろんな要素が絡んでいることを中心に話しました。ご清聴ありがとうございました！

フロントエンドパフォーマンス入門

フロントエンドパフォーマンス入門

Shouta

Other Decks in Programming

Featured

Transcript