パフォーマンスチューニングで Web 技術を深掘り直す

フロントエンドカンファレンス東京 2025 での発表資料です。
https://fec-tokyo.github.io/2025/

Transcript

1. 2025.09.21 | FEC Tokyo 2025 | @progfay パフォーマンスチューニングで Web 技術を深掘り直す
2. Name: 眞野 隼 輔 ま の しゅんすけ    @progfay ・ 株式会社リクルート所属 (2020 ~) ・ Web Frontend Engineer ・ 普段は Web の動向を追っかけている *この発表は個 人 の 見 解であり、所属する組織の公式 見 解ではありません。
3. 本発表のテーマ パフォーマンスチューニングから得られる学びについて
4. 本発表のテーマ パフォーマンスチューニングから得られる学びについて ではない！ 「 手 を動かさないと得られない学びがある」という話
5. 「学び 方 を変えてみよう！」という話
6. • 勉強がフロントエンドに偏っている • React についての勉強ばかりで、通信の仕組みについて 学ぶ機会がない • 新しくて有名な技術は古い技術よりも 常に 優れていると思っている • HTTP/ 1 . 1 より HTTP/ 2 , JPEG より WebP • まだ学んでない Web の側 面 に触れたい 想定視聴者
7. • スピードハッカソン研修の紹介 • パフォーマンスチューニングの何が良いか？ • 本学習 方 法の実践について 発表の流れ
8. https://techblog.recruit.co.jp/article-5841/
9. スピードハッカソンとは 👨💻 Web Page Server • イメージ: Web フロントエンド版 ISUCON* * "ISUCON" は、LINEヤフー株式会社の商標または登録商標です。
10. • イメージ: Web フロントエンド版 ISUCON* スピードハッカソンとは 👨💻 Web Page Server ISUCON* はここを速くする スピードハッカソンの対象はこっち * "ISUCON" は、LINEヤフー株式会社の商標または登録商標です。
11. スピードハッカソンの 目 的 👨💻 Web Page Server Browser フロントエンド インフラ Network Web の構成要素をそれぞれ学ぶ
12. • 特定のライブラリやフレームワーク、ツールの知識に (極 力 ) 依らない • Pure な HTML / CSS / JavaScript で構成された Web サイトを対象とする • リアルワールドさを学ぶことが主 目 的ではない • 競技中のボトルネックには「実際にありそう」も「そうはならんやろ」も両 方 出てくる • Performance Tuning のやり 方 を体系的には教えない • 計測 → 改善のループは実際に 手 を動かして学んだ 方 が早そう スピードハッカソンでやらないこと
13. • チーム戦 (1 チーム 3 ~ 4 名) • チームごとに環境と 高 速化対象の Web サイトのコードが渡される • Web サイトのパフォーマンスを計測してスコア化する Benchmarker が 用 意されている • 競技中は計測結果がスコアボードに表 示 される • 研修後に全体の振り返りと解説 研修概要
14. • メディアサイトの 一 覧画 面 っぽいサイト • ページ 自 体が超 長 い • 大 量の画像が含まれている • インタラクションは少ない • 初期状態では Node.js による静的ファイル配信のみ • 最新の Google Chrome で動作すれば OK とする チューニング対象の Web サイト <img> <img> <img> <img> <img> <img> <img> <img> <img> <img> <img> <img>
15. • Puppeteer と Lighthouse でシナリオを実 行 する 1 . Navigation 2 . 上から下までスクロール 3 . 機能 1 を使う 4 . 機能 2 を使う • Lighthouse の report からスコア算出 Benchmark https://web.dev/articles/lighthouse-user-flows
16. • 画像サイズが表 示 するサイズよりも 大 きい (表 示 サイズの 8 倍) • 初期ロード時に全ての画像が読み込まれる • 不要なライブラリ (JavaScript, CSS) が含まれている • gzip 圧縮されていない • 謎の激重スクリプトが読み込まれている • etc... ページが遅くなっている原因
17. 1 . Lighthouse で計測した結果を確認する 2 . Diagnostics / Opportunities から改善できそうなものに取り組む 3 . 修正できたらベンチマークを実 行 する 4 . これを繰り返す 競技者はどうやってパフォーマンス改善するか？ https://example.com の Diagnostics
18. • 競技のサポートをする • 「ssh ってどうやるの？」「なにもしてないのにこわれた」 • 技術的な質問に答える • 「HTTP/ 2 化ってどうやればいい？」「gzip 圧縮って何？」 • 改善のヒントを与える • 「画像のファイルサイズを確認してみよう」「indent って実は消しても動くんです」 講師の役割
19. 研修のテーマ 裏テーマ: Web の 奥深さ を知ってもらう 何がパフォーマンスを毀損するかを知ってもらい パフォーマンスを維持するための 文 化醸成 を 目 指す
20. 1 . 楽しい 2 . 普段とは違う 角 度から学べる 3 . 技術の深掘りが求められる 本研修の何が良いか？
21. • 一 般的な研修は座学が多いため、飽きてしまう • グループワーク & 競争をさせることで、研修参加のモチベーションを引き出す • 研修のマンネリ解消も狙っている • 研修のアンケートの結果、満 足 率が 高 かった • 参加者全員から「この研修には参加意義がある」と評価を頂いた 「楽しい」は正義！
22. 1 . 楽しい 2 . 普段とは違う 角 度から学べる 3 . 技術の深掘りが求められる 本研修の何が良いか？
23. What's「普段の学び 方 」 自 分の持つ知識を中 心 に、隣接する技術や領域を学ぶ 👨💻 Frontend Backend Infra Design Browser
24. What's「普段の学び 方 」 自 分の持つ知識を中 心 に、隣接する技術や領域を学ぶ ✅ ✅ 👨💻 ✅ ✅ Frontend Backend Infra Design Browser
25. What's「普段の学び 方 」 自 分の持つ知識を中 心 に、隣接する技術や領域を学ぶ ✅ ✅ ✅ ✅ 👨💻 ✅ ✅ ✅ ✅ Frontend Backend Infra Design Browser
26. 👨💻 Poor High Performance という軸で Sort する
27. 👨💻 High Bottleneck に遭遇する Poor
28. 👨💻 High Poor 解決すると次の Bottleneck に遭遇する ✅
29. 👨💻 High Poor 発 見 → 改善 → 解消を繰り返す ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
30. ✅ ✅ 👨💻 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ 👨💻 ✅ ✅ ✅ ✅ 自 分の現在地 Performance という軸 主観的 ・ 相対的 客観的 ・ 絶対的 モチベーションを保ちつつ、普段と違う 角 度から学べる！ 興味分野に近い Performance を改善したい
31. 1 . 楽しい 2 . 普段とは違う 角 度から学べる 3 . 技術の深掘りが求められる 本研修の何が良いか？
32. • 取り扱う問題は実際に動作している Web Application • Lighthouse はパフォーマンス改善の提案をしてくれる • しかし、その通りにしても必ず改善されるわけではない 技術の深掘りが求められる パフォーマンスを改善するには 技術の深掘り が必要になる
33. • 初期状態では HTTP/ 1 . 1 を使っているため Lighthouse から指摘される • 多重化やヘッダ圧縮により 高 速になるらしい Diagnostics - Uses HTTP/ 2 HTTP/2 offers many benefits over HTTP/1.1, including binary headers, multiplexing, and server push. ref. https://developer.chrome.com/docs/lighthouse/best-practices/uses-http2
34. • 初期状態では HTTP/ 1 . 1 を使っているため Lighthouse から指摘される • 多重化、サーバープッシュ、ヘッダ圧縮により 高 速になるらしい Diagnostics - Uses HTTP/ 2 HTTP/2 offers many benefits over HTTP/1.1, including binary headers, multiplexing, and server push. ref. https://developer.chrome.com/docs/lighthouse/best-practices/uses-http2 HTTP/ 2 にすると スコアが下がる 😱
35. HTTP/ 1 . 1 v.s. HTTP/ 2 (HTTP Level) HTTP/ 1 . 1 HTTP/ 2 ブラウザは並列に 6 Connection までしか張れない (HTTP の Head of Line Blocking) 1 Connection 上にリクエストが 多重化される
36. HTTP/ 1 . 1 v.s. HTTP/ 2 (TCP Level) HTTP/ 1 . 1 HTTP/ 2 Request: Connection = 1 : 1 Request: Connection = N : 1 A1 A2 A3 B1 B2 B3 C1 C2 C3 A1 A2 C1 A3 B1 B2 B3 C2 C3
37. HTTP/ 1 . 1 v.s. HTTP/ 2 (Packet Loss) HTTP/ 1 . 1 HTTP/ 2 Connection が分離されているため 他の Connection に影響しない TCP の順序制御により Packet Loss すると全体が遅れてしまう (TCP の Head of Line Blocking) A1 A2 A3 B1 B2 B3 C1 C2 C3 ❌ A2 B, C 完了 A 完了 A3 B1 B2 A, B, C 完了 再送 再送 Lost Lost A1 A2 C1 A3 B1 B2 B3 C2 C3 ❌ HTTP/ 2 は HTTP/ 1 . 1 よりも Packet Loss に弱い
38. • メディアサイトの 一 覧画 面 っぽいサイト • ページ 自 体が超 長 い • 大 量の画像が含まれている • インタラクションは少ない • 初期状態では Node.js による静的ファイル配信のみ • 最新の Google Chrome で動作すれば OK とする チューニング対象の Web サイト <img> <img> <img> <img> <img> <img> <img> <img> <img> <img> <img> <img> 再 掲
39. 現状 • benchmark では意図的に粗悪な通信環境をシミュレートしている (Network throttling) • 大 きな画像が 大 量に、初期ロード時に読み込まれる 仮説 • パケットロスの発 生 率が 高 くなってしまう • TCP の Head of Line Blocking により 画像読み込みの完了までが遅れてしまう？ なぜ HTTP/ 1 . 1 より HTTP/ 2 のほうがスコアが下がったのか？
40. 改善 • 画像のファイルサイズを 小 さくする (表 示 サイズまで縮 小 するなど) • 初期ロード時には Above the fold のみの読み込みを 行 う (Lazy loading) 結果 • HTTP/ 1 . 1 と HTTP/ 2 で 比 較した結果、スコアに 大 きな違いはなかった • ボトルネックがネットワークではなくなったと考えられる 仮説の検証
41. • ほとんどの画像が JPEG で配信されており、Lighthouse は WebP に変換することを提案してくる • 実際に変換するとファイルサイズは 60% ほどに！ Opportunities - Serve images in next-gen formats しかし WebP に変換するとスコアが下がる場合も... AVIF と WebP は、従来の JPEG や PNG と 比 較して圧縮率と品質の 面 で優れた画像形式です。 JPEG や PNG ではなくこれらの形式で画像をエンコードすると、 読み込みが速くなり、モバイルデータの使 用 量を抑えることができます。 ref. https://developer.chrome.com/docs/lighthouse/performance/uses-webp-images
42. • WebP には Block Prediction という 手 法が使われている • decode したい Block の情報を、decode 済みの周囲の Block を元に予測する • これにより 高 い圧縮率を実現できる • 一 方 で decode 処理は逐次実 行 になってしまう Block Prediction https://web.dev/learn/images/webp#block_prediction
43. 前提 • benchmark では CPU slowdown も 行 なっている • 画像の内在サイズが 大 きい 仮説 • 画像の内在サイズが 大 きいせいで decode 処理の実 行 時間の差が顕著になっている？ なぜ WebP にしたらスコアが落ちたのか？
44. 改善 • 画像の内在サイズを 小 さくする (表 示 サイズまで縮 小 するなど) 結果 • JPEG と WebP で 比 較した結果、スコアに 大 きな違いはなくなった • ボトルネックが画像ではなくなったと考えられる なぜ WebP にしたらスコアが落ちたのか？
45. • 「有名で新しい技術は常に優れているか？」には "No" と答えられる • しかし「それはどんな時か？」と聞かれて答えられる 人 は少ない • 深い知識を得る機会は、能動的に学びに 行 かない限り滅多にない • それこそ実際に 手 を動かさないと遭遇できない 技術の深掘りから得られる学び
46. 知識 知恵 ただ知っている 活 用 できる 記憶する 体験する 技術の深掘り によって 知識は知恵へと昇華される
47. 本研修の何が良いか？ 1 . 楽しい 2 . 普段とは違う 角 度から学べる 3 . 技術の深掘りが求められる → 学びのモチベーションを保つ → 学びの軸を相対から絶対に → 知識を知恵に昇華する
48. Known Unknown Known Unknown Known-Knowns Unknown-Knowns Known-Unknowns Unknown-Unknowns Unkown-Unknowns に遭遇できる機会が 比 較的多いイメージ
49. • 理解が追いついてなくても開発が進んでしまう時代 • 「なんかわからないけど問題が発 生 した」という場 面 は今以上に増えてくるはず • 問題解決のためには広く深い知恵が必要になってくる AI 時代でも有効な学習法か？
50. • 理解が追いついてなくても開発が進んでしまう時代 • 「なんかわからないけど問題が発 生 した」という場 面 は今以上に増えてくるはず • 問題解決のためには広く深い知恵が必要になってくる AI 時代でも有効な学習法か？ Let's 実践！
51. • まずスピードハッカソンを開催します Let's 実践
52. • まずスピードハッカソンを開催します ← ハードルめちゃ 高 い！ Let's 実践 競技型イベントの開催って超 大 変... (;´Д`) Let's 実践
53. • 自 作の Web Application のパフォーマンスをチューニングする • 最初は初期表 示 だけをチューニングする (計測 → 考察 → 改善のループ) • 慣れてきたら難易度を上げてみるのも良い • Lighthouse user flows を使ってユーザー操作もチューニングの対象にする • 想定しうるユーザーのうち、もっとも端末 spec が低そうな環境をシミュレートする Let's 実践 (パフォーマンス編)
54. • パフォーマンスのような 普段とは違う切り 口 で学ぶ ことが 大 事 • 例えばセキュリティ: • 攻撃者の視点に 立 ってみる • CTF の Web 問に挑戦してみる • RFC の Security Considerations を読んでみる • 他にも切り 口 はたくさんあるはず！ Let's 実践 (別路線編)
55. • スピードハッカソン研修では 普段とは違う学び 方 」ができる • パフォーマンスという絶対軸で Web の 見 え 方 を変える • 技術の深掘りによって知識は知恵へと昇華される • 結果: 普段触れない技術範囲を学べたり、問題解決能 力 が向上したりする • パフォーマンスやセキュリティなど、普段とは違う切り 口 で Web を捉え直すことで実践できる まとめ