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

by Shunsuke Mano

Slide 1

Slide 1 text

2025.09.21 | FEC Tokyo 2025 | @progfay パフォーマンスチューニングで Web 技術を深掘り直す

Slide 2

Slide 2 text

Name: 眞野隼輔まのしゅんすけ    @progfay ・株式会社リクルート所属 (2020 ~) ・ Web Frontend Engineer ・普段は Web の動向を追っかけている *この発表は個人の見解であり、所属する組織の公式見解ではありません。

Slide 3

Slide 3 text

本発表のテーマパフォーマンスチューニングから得られる学びについて

Slide 4

Slide 4 text

本発表のテーマパフォーマンスチューニングから得られる学びについてではない！「手を動かさないと得られない学びがある」という話

Slide 5

Slide 5 text

「学び方を変えてみよう！」という話

Slide 6

Slide 6 text

• 勉強がフロントエンドに偏っている • React についての勉強ばかりで、通信の仕組みについて学ぶ機会がない • 新しくて有名な技術は古い技術よりも常に優れていると思っている • HTTP/ 1 . 1 より HTTP/ 2 , JPEG より WebP • まだ学んでない Web の側面に触れたい想定視聴者

Slide 7

Slide 7 text

• スピードハッカソン研修の紹介 • パフォーマンスチューニングの何が良いか？ • 本学習方法の実践について発表の流れ

Slide 8

Slide 8 text

https://techblog.recruit.co.jp/article-5841/

Slide 9

Slide 9 text

スピードハッカソンとは 👨💻 Web Page Server • イメージ: Web フロントエンド版 ISUCON* * "ISUCON" は、LINEヤフー株式会社の商標または登録商標です。

Slide 10

Slide 10 text

• イメージ: Web フロントエンド版 ISUCON* スピードハッカソンとは 👨💻 Web Page Server ISUCON* はここを速くするスピードハッカソンの対象はこっち * "ISUCON" は、LINEヤフー株式会社の商標または登録商標です。

Slide 11

Slide 11 text

スピードハッカソンの目的 👨💻 Web Page Server Browser フロントエンドインフラ Network Web の構成要素をそれぞれ学ぶ

Slide 12

Slide 12 text

• 特定のライブラリやフレームワーク、ツールの知識に (極力 ) 依らない • Pure な HTML / CSS / JavaScript で構成された Web サイトを対象とする • リアルワールドさを学ぶことが主目的ではない • 競技中のボトルネックには「実際にありそう」も「そうはならんやろ」も両方出てくる • Performance Tuning のやり方を体系的には教えない • 計測 → 改善のループは実際に手を動かして学んだ方が早そうスピードハッカソンでやらないこと

Slide 13

Slide 13 text

• チーム戦 (1 チーム 3 ~ 4 名) • チームごとに環境と高速化対象の Web サイトのコードが渡される • Web サイトのパフォーマンスを計測してスコア化する Benchmarker が用意されている • 競技中は計測結果がスコアボードに表示される • 研修後に全体の振り返りと解説研修概要

Slide 14

Slide 14 text

• メディアサイトの一覧画面っぽいサイト • ページ自体が超長い • 大量の画像が含まれている • インタラクションは少ない • 初期状態では Node.js による静的ファイル配信のみ • 最新の Google Chrome で動作すれば OK とするチューニング対象の Web サイト

Slide 15

Slide 15 text

• Puppeteer と Lighthouse でシナリオを実行する 1 . Navigation 2 . 上から下までスクロール 3 . 機能 1 を使う 4 . 機能 2 を使う • Lighthouse の report からスコア算出 Benchmark https://web.dev/articles/lighthouse-user-flows

Slide 16

Slide 16 text

• 画像サイズが表示するサイズよりも大きい (表示サイズの 8 倍) • 初期ロード時に全ての画像が読み込まれる • 不要なライブラリ (JavaScript, CSS) が含まれている • gzip 圧縮されていない • 謎の激重スクリプトが読み込まれている • etc... ページが遅くなっている原因

Slide 17

Slide 17 text

1 . Lighthouse で計測した結果を確認する 2 . Diagnostics / Opportunities から改善できそうなものに取り組む 3 . 修正できたらベンチマークを実行する 4 . これを繰り返す競技者はどうやってパフォーマンス改善するか？ https://example.com の Diagnostics

Slide 18

Slide 18 text

• 競技のサポートをする • 「ssh ってどうやるの？」「なにもしてないのにこわれた」 • 技術的な質問に答える • 「HTTP/ 2 化ってどうやればいい？」「gzip 圧縮って何？」 • 改善のヒントを与える • 「画像のファイルサイズを確認してみよう」「indent って実は消しても動くんです」講師の役割

Slide 19

Slide 19 text

研修のテーマ裏テーマ: Web の奥深さを知ってもらう何がパフォーマンスを毀損するかを知ってもらいパフォーマンスを維持するための文化醸成を目指す

Slide 20

Slide 20 text

1 . 楽しい 2 . 普段とは違う角度から学べる 3 . 技術の深掘りが求められる本研修の何が良いか？

Slide 21

Slide 21 text

• 一般的な研修は座学が多いため、飽きてしまう • グループワーク & 競争をさせることで、研修参加のモチベーションを引き出す • 研修のマンネリ解消も狙っている • 研修のアンケートの結果、満足率が高かった • 参加者全員から「この研修には参加意義がある」と評価を頂いた「楽しい」は正義！

Slide 22

Slide 22 text

1 . 楽しい 2 . 普段とは違う角度から学べる 3 . 技術の深掘りが求められる本研修の何が良いか？

Slide 23

Slide 23 text

What's「普段の学び方」自分の持つ知識を中心に、隣接する技術や領域を学ぶ 👨💻 Frontend Backend Infra Design Browser

Slide 24

Slide 24 text

What's「普段の学び方」自分の持つ知識を中心に、隣接する技術や領域を学ぶ ✅ ✅ 👨💻 ✅ ✅ Frontend Backend Infra Design Browser

Slide 25

Slide 25 text

What's「普段の学び方」自分の持つ知識を中心に、隣接する技術や領域を学ぶ ✅ ✅ ✅ ✅ 👨💻 ✅ ✅ ✅ ✅ Frontend Backend Infra Design Browser

Slide 26

Slide 26 text

👨💻 Poor High Performance という軸で Sort する

Slide 27

Slide 27 text

👨💻 High Bottleneck に遭遇する Poor

Slide 28

Slide 28 text

👨💻 High Poor 解決すると次の Bottleneck に遭遇する ✅

Slide 29

Slide 29 text

👨💻 High Poor 発見 → 改善 → 解消を繰り返す ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

Slide 30

Slide 30 text

✅ ✅ 👨💻 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ 👨💻 ✅ ✅ ✅ ✅ 自分の現在地 Performance という軸主観的・相対的客観的・絶対的モチベーションを保ちつつ、普段と違う角度から学べる！興味分野に近い Performance を改善したい

Slide 31

Slide 31 text

1 . 楽しい 2 . 普段とは違う角度から学べる 3 . 技術の深掘りが求められる本研修の何が良いか？

Slide 32

Slide 32 text

• 取り扱う問題は実際に動作している Web Application • Lighthouse はパフォーマンス改善の提案をしてくれる • しかし、その通りにしても必ず改善されるわけではない技術の深掘りが求められるパフォーマンスを改善するには技術の深掘りが必要になる

Slide 33

Slide 33 text

• 初期状態では 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

Slide 34

Slide 34 text

• 初期状態では 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 にするとスコアが下がる 😱

Slide 35

Slide 35 text

HTTP/ 1 . 1 v.s. HTTP/ 2 (HTTP Level) HTTP/ 1 . 1 HTTP/ 2 ブラウザは並列に 6 Connection までしか張れない (HTTP の Head of Line Blocking) 1 Connection 上にリクエストが多重化される

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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 に弱い

Slide 38

Slide 38 text

• メディアサイトの一覧画面っぽいサイト • ページ自体が超長い • 大量の画像が含まれている • インタラクションは少ない • 初期状態では Node.js による静的ファイル配信のみ • 最新の Google Chrome で動作すれば OK とするチューニング対象の Web サイト再掲

Slide 39

Slide 39 text

現状 • benchmark では意図的に粗悪な通信環境をシミュレートしている (Network throttling) • 大きな画像が大量に、初期ロード時に読み込まれる仮説 • パケットロスの発生率が高くなってしまう • TCP の Head of Line Blocking により画像読み込みの完了までが遅れてしまう？なぜ HTTP/ 1 . 1 より HTTP/ 2 のほうがスコアが下がったのか？

Slide 40

Slide 40 text

改善 • 画像のファイルサイズを小さくする (表示サイズまで縮小するなど) • 初期ロード時には Above the fold のみの読み込みを行う (Lazy loading) 結果 • HTTP/ 1 . 1 と HTTP/ 2 で比較した結果、スコアに大きな違いはなかった • ボトルネックがネットワークではなくなったと考えられる仮説の検証

Slide 41

Slide 41 text

• ほとんどの画像が 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

Slide 42

Slide 42 text

• WebP には Block Prediction という手法が使われている • decode したい Block の情報を、decode 済みの周囲の Block を元に予測する • これにより高い圧縮率を実現できる • 一方で decode 処理は逐次実行になってしまう Block Prediction https://web.dev/learn/images/webp#block_prediction

Slide 43

Slide 43 text

前提 • benchmark では CPU slowdown も行なっている • 画像の内在サイズが大きい仮説 • 画像の内在サイズが大きいせいで decode 処理の実行時間の差が顕著になっている？なぜ WebP にしたらスコアが落ちたのか？

Slide 44

Slide 44 text

改善 • 画像の内在サイズを小さくする (表示サイズまで縮小するなど) 結果 • JPEG と WebP で比較した結果、スコアに大きな違いはなくなった • ボトルネックが画像ではなくなったと考えられるなぜ WebP にしたらスコアが落ちたのか？

Slide 45

Slide 45 text

• 「有名で新しい技術は常に優れているか？」には "No" と答えられる • しかし「それはどんな時か？」と聞かれて答えられる人は少ない • 深い知識を得る機会は、能動的に学びに行かない限り滅多にない • それこそ実際に手を動かさないと遭遇できない技術の深掘りから得られる学び

Slide 46

Slide 46 text

知識知恵ただ知っている活用できる記憶する体験する技術の深掘りによって知識は知恵へと昇華される

Slide 47

Slide 47 text

本研修の何が良いか？ 1 . 楽しい 2 . 普段とは違う角度から学べる 3 . 技術の深掘りが求められる → 学びのモチベーションを保つ → 学びの軸を相対から絶対に → 知識を知恵に昇華する

Slide 48

Slide 48 text

Known Unknown Known Unknown Known-Knowns Unknown-Knowns Known-Unknowns Unknown-Unknowns Unkown-Unknowns に遭遇できる機会が比較的多いイメージ

Slide 49

Slide 49 text

• 理解が追いついてなくても開発が進んでしまう時代 • 「なんかわからないけど問題が発生した」という場面は今以上に増えてくるはず • 問題解決のためには広く深い知恵が必要になってくる AI 時代でも有効な学習法か？

Slide 50

Slide 50 text

• 理解が追いついてなくても開発が進んでしまう時代 • 「なんかわからないけど問題が発生した」という場面は今以上に増えてくるはず • 問題解決のためには広く深い知恵が必要になってくる AI 時代でも有効な学習法か？ Let's 実践！

Slide 51

Slide 51 text

• まずスピードハッカソンを開催します Let's 実践

Slide 52

Slide 52 text

• まずスピードハッカソンを開催します ← ハードルめちゃ高い！ Let's 実践競技型イベントの開催って超大変... (;´Д`) Let's 実践

Slide 53

Slide 53 text

• 自作の Web Application のパフォーマンスをチューニングする • 最初は初期表示だけをチューニングする (計測 → 考察 → 改善のループ) • 慣れてきたら難易度を上げてみるのも良い • Lighthouse user flows を使ってユーザー操作もチューニングの対象にする • 想定しうるユーザーのうち、もっとも端末 spec が低そうな環境をシミュレートする Let's 実践 (パフォーマンス編)

Slide 54

Slide 54 text

• パフォーマンスのような普段とは違う切り口で学ぶことが大事 • 例えばセキュリティ: • 攻撃者の視点に立ってみる • CTF の Web 問に挑戦してみる • RFC の Security Considerations を読んでみる • 他にも切り口はたくさんあるはず！ Let's 実践 (別路線編)

Slide 55

Slide 55 text

• スピードハッカソン研修では普段とは違う学び方」ができる • パフォーマンスという絶対軸で Web の見え方を変える • 技術の深掘りによって知識は知恵へと昇華される • 結果: 普段触れない技術範囲を学べたり、問題解決能力が向上したりする • パフォーマンスやセキュリティなど、普段とは違う切り口で Web を捉え直すことで実践できるまとめ