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
フロントエンドから触れるHTTPパフォーマンス
Search
Tatsuki Sugiura
August 20, 2025
Technology
0
1
フロントエンドから触れるHTTPパフォーマンス
Tatsuki Sugiura
August 20, 2025
Tweet
Share
More Decks by Tatsuki Sugiura
See All by Tatsuki Sugiura
103 Early Hints
sugi_0000
1
610
No more parser-inserted js - defer / async を今こそ完全に理解する
sugi_0000
0
69
FLOSSむかしばなし
sugi_0000
0
12
和暦 & 漢数字 gem
sugi_0000
0
21
FLOSS とフリーカルチャーの流れ
sugi_0000
0
17
Git overview
sugi_0000
0
28
飲む方の茶会
sugi_0000
0
16
Other Decks in Technology
See All in Technology
どこで動かすか、誰が動かすか 〜 kintoneのインフラ基盤刷新と運用体制のシフト 〜
ueokande
0
200
JuniorからSeniorまで: DevOpsエンジニアの成長ロードマップ
yuriemori
2
260
広島銀行におけるAWS活用の取り組みについて
masakimori
0
150
Devinを使ったモバイルアプリ開発 / Mobile app development with Devin
yanzm
0
200
LLMエージェント時代に適応した開発フロー
hiragram
1
430
Yahoo!ニュースにおけるソフトウェア開発
lycorptech_jp
PRO
0
400
ゆるふわエンジニアでもAIフローにチャレンジしたい!!~Zapierのすゝめ~
masakiokuda
2
100
新卒(ほぼ)専業Kagglerという選択肢
nocchi1
1
2.4k
制約理論(ToC)入門
recruitengineers
PRO
7
2.2k
Jaws-ug名古屋_LT資料_20250829
azoo2024
3
130
実践アプリケーション設計 ③ドメイン駆動設計
recruitengineers
PRO
9
1.4k
新規案件の立ち上げ専門チームから見たAI駆動開発の始め方
shuyakinjo
0
180
Featured
See All Featured
Site-Speed That Sticks
csswizardry
10
790
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Side Projects
sachag
455
43k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.6k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Scaling GitHub
holman
462
140k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
How STYLIGHT went responsive
nonsquared
100
5.7k
Why Our Code Smells
bkeepers
PRO
338
57k
Making Projects Easy
brettharned
117
6.3k
Visualization
eitanlees
147
16k
The Art of Programming - Codeland 2020
erikaheidi
55
13k
Transcript
フロントエンドから触れる HTTPパフォーマンス 2025-08-20 Tatsuki Sugiura <
[email protected]
> <
[email protected]
>
自己紹介 - sugi - Tatsuki Sugiura • 現在 Repro Inc.
で Booster という Web サイト高 速化ツールの開発をしています • 個人では RoR を使った開発や和暦gem とか • ESR の 「ハッカーになろう」から OSS活動をはじめる • 過去に OSDN や スラド (/.j) の開発・運営 • お茶が大好きです!
今日のトピック • 申し訳ない。あんまりモダンJS環境向けの話ではないです! ◦ でも使えるところはあると思う • ページが表示されるまでHTTPの通信復習 • 実はブラウザからHTTP通信の順序に介入する方法あるよ •
コントロールのための具体的方法 • 今日話さないこと ◦ プロトコルの詳細 (パケット, RT, フレーム)
ページが表示されるまで (1) • ページが読み込みから表示完成までに起こっていること ◦ HTML の解釈 ◦ サブリソースの転送
◦ JS の実行
ページが表示されるまで (2) - HTMLパースとDOM構築 HTML stream <html> <head> <meta charset=....
Web Server Tokenizer Tree Construction <html> <head> <meta… DOM Tree html head meta link body
ページが表示されるまで (3) • HTMLは流れてくるものを随時反映 • サブリソースは(基本的には)出現したら転送開始 HTML転送 CSS転送 JS転送 JS実行
画像転送
ページが表示されるまで (4) - レンダリングパス • レンダリングするには以下が必要 ◦ HTML DOM Tree
◦ CSSOM Tree ◦ Sync JS (parser-inserted js) の実行 • HTML は順次反映できるが、 CSS と JS は全体を読みきらない と利用できない • CSS は基本的にその時点でレンダリングをブロックする • Sync JS の実行は先行するレンダーブロッキング CSS の解釈後 まで待たれる (転送は先にできるが、実行はCSS解釈後) • 画像は随時読み込まれる
早くページを表示するには • First view に必要なものを如何に早く読み込むか • 適切な順でサブリソースを読み込む • HTML の後ろにある要素でも、重要なものは早めに読みたい
◦ (例) LCP 画像 • ページ内のサブリソースの依存関係は複雑なため、表示されない ものでも結果的に First View のレンダリングに必要なケースはま まある -> 読み込み順が重要!
どうやって順序をコントロールするの? # 定番で言われること • そもそも HTML上の順序を適切にする ◦ ただし、ブラウザは必ずしも発見次第リクエストするわけではない • 不要なブロッキング要素を置かない
◦ 不要なブロッキングCSSを置かない ◦ JS に適切に asyncをつける # おさえて置くと良いトピック • Priority (Fetch Priority) • Resource Hints (Preload) • Lazy loading (asyc, loading) - 今回話しません
Priority / Fetch priority • ページに必要なリソースの読み込み優先度 • 優先度は複数層で管理されている ◦ ↓
HTML上の指定 ◦ ↓ ブラウザ内の管理 ◦ HTTPのプロトコル上の指定 • HTML属性をつけることで HTTP のプロトコル上の優先度を制御 可能
優先度はなぜ必要? - 並列の定番の落とし穴 • 今のHTTPではリソースを複数ストリームで並列にロードする • もし優先度が同じならすべてを発見次第同時にリクエスト • 帯域は有限なので競合する •
競合するものを並列に 処理にすると結果的に 全てが遅くなる
Priority in browsers • リソースごとに優先度を持つ ◦ Lowest - Low -
Medium - High - Highest の 5段階 • 手軽に Devtools で確認できます
Fetch Priority HTML Attribute • fetchPriority 属性を追加するだけ ◦ 3段階 (auto/low/high)
• 初期表示に必要なものだけに high をつける • 要らないものに low • 全部 high にすれば良いというわけ ではないことに注意。余計遅くなる <div class=”carousel”> <img src=”hero1.jpg” fetchPriority=”high” class=”active”> <img src=”item2.jpg” fetchPriority=”low”> <img src=”item3.jpg” fetchPriority=”low”> <img src=”item4.jpg” fetchPriority=”low”> </div>
Fetch Priority with JavaScript • RequestInit に priority を指定可能 ◦
fetch() ◦ new Request() • コンテンツ表示用APIと、バックグラ ウンド通信APIなどで priority を使い 分けられる fetch(‘http://localhost/items’, { priority: ‘high’ }); new Request( ‘http://localhost/status-ping’, {priority: ‘low’} );
HTTP Priority - プロトコル側の機能 • HTTP ストリームは Priority を持っていて優先度が高いものが優 先される
(ことになっている) • ブラウザ内で管理している優先度からマッピング • HTTP/2 は優先度ツリー, HTTP/3 は優先度とincremental https://calendar.perfplanet.com/2022/http-3-prioritization-demystified/
Resource Hints (Preload) • HTML の Link タグで先に読み込むべきリソースを指示 • LCP
画像など実際に利用するHTMLタグが後ろのものを、先にダ ウンロードしておくことができる • CSS, JS, Font など色々使える • ただ、Head 上の方にある js など、すぐに読み込みが始まるもの を指定する意味はあまりない • 不必要なものを指定すぎないこと! 余計遅くなる。 ◦ ブラウザによっては上限を管理している <link rel="preload" href="/lcp-image.jpg" as="image" fetchPriority=“high”>
Resource Hints 補足 • ブラウザによって、優先度の ポリシーが違う • as=”image” の場合は、標 準の
Priority が低い ◦ Chrome だけあげられる https://calendar.perfplanet.com/2022/http-3-prioritizat ion-demystified/
おまけ: もっと効果的なプロトコルレベル Preload • HTML の link rel=”preload” ではなく、Link
ヘッダでも同様の 指定ができる ◦ Chrome だとここでも priority が効く • さらに、103 Early Hints を使えば遥かに早い段階でロードを開 始できる ◦ この場合はメインの CSS や JS のロードをしておくとよい ◦ HTML 内と使い分けると良さそう ◦ 103 自体の悩ましさはある
Lazy load / Async script • 画像や iframe を viewport
に入るまで読み込みを遅延する • これにより、必要なものを先に読み込める • そろそろ JS 版の lazy load を使うのはやめよう <img src=”item.jpg” loading=”lazy”> <script src=”module.js” type=”module”></script> <script src=”src.js” async></script> <script src=”legacy.js” defer></script> • モダンなスクリプトなら module にすると自動で非同期に • とにかく Parser-inserted script を避ける