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 を捉え直すことで実践できる まとめ