perfcal2025-20260122.md

Web Performance Calendar 2025を読む その1

https://youtube.com/live/iZo2IgtC7Iw

これは何か

https://calendar.perfplanet.com/2025/ を読むストリーム。

Performance Calendarについて

あとで

どんなのがあるか

あとで

Improve TTFB and UX with HTTP streaming

https://calendar.perfplanet.com/2025/improve-ttfb-and-ux-with-http-streaming/

あまり使われていないHTTPのストリーミング機能を使えばTTFBを短くできる。

Mastraフレームワークではawait db.execute()みたいなものの代わりにdb.stream()というAsyncIterableを返す実装でHTTTPストリーミングを活用している。

Exploring Large HTML Documents On The Web

https://calendar.perfplanet.com/2025/exploring-large-html-documents-on-the-web/

HTML文書は基本的には小さいが、中にはとてつもなくでかいのがある。どんな理由でHTMLがでかくなってしまったのかを探る。

インラインの画像。大きなファイルサイズの画像が埋め込まれていたり、小さな埋め込みアイコンが数百もあるもの、レスポンシブイメージが埋め込まれているもの、SVGがPNGを埋め込んでいるもの、などなど。

インラインのCSS。基本的には埋め込み画像によるものが多いが、長すぎるセレクタによってファイルサイズが膨れてしまうことも（ただしgzipがきくので転送量は小さくなったりする）

インラインフォント。1つや2つならいいが、複数個あると大変。

JavaScriptフレームワークのintiial renderに使うコードがばかでかい。ローカルの開発環境ではinitialのデータは小さいが、プロダクションのDBなどからだとハイドレーションステートが膨らむ。

JSONの中に画像がインラインで埋め込まれていても大きくなるし、JSONのツリーを辿っていくとHTML→JSON→...HTML→JSONなんてパターンもあった。

HTMLがでかくなることの何が問題か？HTMLはブラウザでプライオリティが高く設定されるので、ハイドレーション用のJSがあると、レンダーブロッキングなCSSやフォントよりも先に読み込まれ、レンダーブロッキングなリソースの読み込みに悪影響が出る。

HTMLがでかくなることの何が問題か？HTMLはブラウザでプライオリティが高く設定されるので、ハイドレーション用のJSがあると、レンダーブロッキングなCSSやフォントよりも先に読み込まれ、レンダーブロッキングなリソースの読み込みに悪影響が出る。 HTMLがでかくなることの何が問題か？HTMLはブラウザでプライオリティが高く設定されるので、ハイドレーション用のJSがあると、レンダーブロッキングなCSSやフォントよりも先に読み込まれ、レンダーブロッキングなリソースの読み込みに悪影響が出る。

CPUの処理速度によっても影響が出る。MacBookだとそこまで問題ないかもしれないが、ローエンドのスマホだと影響が出る。

パフォーマンスを低下させる要因はHTMLよりも他のものがでかいかもしれないが、それでもHTMLの大きさはパフォーマンスに影響する。LCPなど。HTMLのサイズが増えていかないようにCIとかでチェックしようね。

Non-blocking cross-browser image rendering on the canvas

https://calendar.perfplanet.com/2025/non-blocking-image-canvas/

CanvasのdrawImage()でメインスレッドを止めない方法を探る。どのブラウザでもいい感じに動く方法を探すのが大変という話。

• image.decoding = "async"だけ→Chrome, Firefox, Safariでブロック
• image.decode()→FirefoxのみOK
• image.decode()とOffscreenCanvas→FirefoxのみOK
• image.decode()からcreateImageBitmap()→FirefoxとSafariでOK
• image.blob()からcreateImageBitmap()→ChromeのみOK
• image.blob()からcreateImageBitmap()をWorkerで→ChromeとSafariでOK
• 結局UA判別でdecodeからcIBとblobからcIBを振り分けて対応

仕様ではdecode()のみでうまくいくはずだが、ChromiumとWebKitではそうなってない。

NoLoJS: Reducing the JS Workload with HTML and CSS

https://calendar.perfplanet.com/2025/nolojs-reducing-js-workload-html-css/

JSで実装してたUIパターンも今だとHTML/CSSでできたりするという紹介。

perfcal2025-20260128.md

Performance Calendar 2025を読む その2

https://youtube.com/live/84TeWOjcAj0

Web Performance 2025: The Shift from Optimization to Prediction

https://calendar.perfplanet.com/2025/web-performance-2025-the-shift-from-optimization-to-prediction/

即表示されるサイトを作るのは難しかったが、ChromiumにSpeculation Rulesが入ったので実現に近づいている。

プリレンダリングを提供したら数百のEコマースサイトで300ms以下で読み込みが可能になったので、Goodとされるパフォーマンス指標について考え直すきっかけになった。

これまでGoodとされていたものをInstant、Fast、OKにさらに分割。

これまでのGood、2500msは十分ではない。instantと感じるのは100msだがそれを常に実現するのは難しい。ただ1000ms以内であれば人は十分に感じる。Eコマースにおいても1000ms以内であればCVRが高い。2500msはもうGoodではない。

Speculation Rulesはそのままでは十分な余裕を持ってプリレンダーできないのでもっと早いタイミングで実行したい、が精度が必要。精度が悪いとユーザーに無駄な負荷がかかる。またオリジンサーバーへの負荷も増大する。やみくもに実装すると10倍も負荷がかかりセルフDDoS状態になる。

一つの課題がバックグラウンドのタブでもJavaScriptが実行されることだった。アナリティクスの誤計測や、ユーザーが目にするずっと前にハイドレーションを行うなどの問題があった。Speculation Rulesの新しいprerender-until-scriptでその問題を解決できる。古いデバイスやパワフルでないデバイスでもバックグラウンドのタブ由来のjankを抑制できた。

Compression Dictionaryも期待している。gzipよりもずっと圧縮できる。バックエンドの統合、RUMデータ解析による効率的な辞書の設計と展開によって、内部のストレージや帯域を圧迫しない実装ができた。辞書はエッジでnegotiationを行うことで、アプリケーションサーバーの複雑さを減らしている。

Compression Dictによって節約できる帯域を使い、よりアグレッシブなプリロード戦略が取れるようになったのが大きかった。

2026年はCore Web Vitals計測のクロスブラウザ化などによってさらに全体を見渡せるようになると期待。

The Anatomy of a Web Performance Report

https://calendar.perfplanet.com/2025/the-anatomy-of-a-web-performance-report/

Web Performance Reportというサービスの紹介。ウッとならないように意図的にhigh-levelにしたレポートとストーリー的な紹介で開発者以外にもパフォーマンスの重要性や改善点を提示している。

The Inconvenient Truth: How Web Performance Case Studies Undermine Our Relationship with Business

https://calendar.perfplanet.com/2025/the-inconvenient-truth-how-web-performance-case-studies-undermine-our-relationship-with-business/

ビジネス的な視点でパフォーマンスの重要性を説く時にケーススタディの数字を見せたりするが、ちゃんと妥当なものを使いなさいという耳の痛い話。

ケーススタディをちゃんとやるとコストがかかるので、人は公開されているものを頼るが、悪いケーススタディを引用するとパフォーマンスコミュニティ全体の信頼も低下させてしまう。

Amazonの「100msの遅延で1％のレベニューロス」というやつが使われるがこれは最悪。データもない、20年前のA/Bテスト、Amazonという特定ドメインの事例を一般化したもので、1枚のスライドが教義のようになってしまった。スタディでもなんでもない。

ロシニョールのCVRが上がったケーススタディはリデザインも兼ねたプロジェクトだったが、パフォーマンスの影響のみを測っていない全体の数字を出していたのが問題だった。

いい例は検証可能なもの。Ron KohaviのBing.comやTalabatでのTTI改善は地味に見えるが検証可能。

いいケーススタディの見分けかた。A/Bテスト手法、統計的に意味があること、実際のビジネスメトリクスを使っていること（％だけじゃなく数値もあるとなおよい）。透明性があること。

時間もお金もかかるが、安易なものに頼るとパフォーマンスの未来がないと。

perfcal2025-20260131.md

Performance Calendar 2025を読む その3

https://youtube.com/live/GtwhQBrQNyg

React 19.2. Further Advances INP Optimization

https://calendar.perfplanet.com/2025/react-19-2-further-advances-inp-optimization/

React 19.2で入ったINP関係の話。<Activity />でステート保持したまま中のコンポーネントの処理による負荷を減らせたりする。

Chrome DevToolsのPerformance TracksでPerformanceパネルのフレームチャートからReactのスケジューリング、コンポーネント、RSCのフレームグラフも見られるように。

aiSlow

https://calendar.perfplanet.com/2025/aislow/

昔のLighthouse AuditsみたいなFirefoxの拡張YSlowをAI時代の今成功したらどうなるか。

HTTPArchiveから遅いサイトと速いサイトのデータをクエリーし比較してモデルをトレーニングする。LightGBMを使いSpeedIndexを予測するモデルを作った。

トレーニングしたモデルとは別にコンサルタント用のモデルを準備する。SHAPを利用。

what-ifというものを用意。一番影響のある特徴を省いたらどれくらいSpeedIndexが向上するかを試算する。影響力のある特徴を比較するグラフも出せる。

Intro to Performance of React Server Components

https://calendar.perfplanet.com/2025/intro-to-performance-of-react-server-components/

Reactに詳しくない人向けのReact Server Componentsの紹介。

単体では使えないのでまずSPAを作った。複数のAPIエンドポイントがある。それぞれの実行時間が異なる。

まずCSR。HTMLとJSが読み込まれる前は真っ白なのでLCPも遅い。

データフェッチなしSSR。JSを全部待たなくてもページの一部は表示される。LCPが向上する。ただJavaScriptの実行は待たないといけないので、インタラクティブになるまでの差が広がる。Next.jsなどSSRフレンドリーなフレームワークでLCPはさらに改善することも。

データフェッチつきSSR。サーバーサイドでデータフェッチしてできたものをReactに渡す。クライアントサイドでのAPIのリクエストがなくなる。データフェッチをサーバーサイドでやる分LCPがちょっと遅くなる。ただ各々のコンポーネントは速くなる。

データフェッチが賢くなってコンポーネント単位で返せるようになればもっと速くなるはず。これがRSC。実装したらさらに向上した。

RSCはデータフェッチングを解決するだけなので、向いてないところもある。設計や実装を考え直さないといけない。ベンダーロックインや最近の脆弱性の話もあるのでまだまだこれから。

perfcal2025-20260201.md

Performance Calendar 2025を読む その4

https://youtube.com/live/o_obVzM7yw4

How to load CSS (fast)

https://calendar.perfplanet.com/2025/how-to-load-css-fast/

CSSを速く読み込むのは難しい。必要なCSSだけを読み込みたい、不必要なCSSを全て読み込みたくはない、個々のページに必要なCSSだけを読み込むと共通部分が重複してしまうのでそれも避けたい。

クリティカルなCSSだけをインライン化するか、完全なCSSを1回読み込むようにするか。どちらも理想的ではない。完全なCSSの場合は、ブラウザが必要ないCSSを処理する必要が出てくる。

Compression Dictionariesで解決できる！

Compression Dictには2つある。デルタ圧縮は今のリソースからこれからのリソースを圧縮する。共通ディクショナリは複数リソースの共通部分を圧縮する。

ページA、ページBからなるサイトで、AからBに行く場合。a.cssとb.cssの共通部分が無駄になる。a.css, b.cssを統合したfull.cssを辞書として使う。Use-As-Dictionaryヘッダーをfull, a, bそれぞれに、<link rel="compression-dictionary">をHTMLに指定して辞書を結びつける。

Aを読み込む。a.cssが読み込まれる。アイドル時にfull.cssが読み込まれる。この時a.cssがdictとして使われる。 Bに移動する。b.cssが読み込まれるが、full.cssをdictとして使うように指定されているので、b.cssの読み込まれるバイト数はとても小さい。（デモあり）

Comp Dictを使うと、初回読み込みがクリティカルのみになる。その後full.cssがアイドル時に読み込まれ、以降のCSSの辞書として使われる。なので以降のCSSの帯域はほぼ0になる。ブラウザ内での処理も使われるCSSだけ処理される。

CSSが更新された場合も、新しいCSSが古いfull.cssを辞書として読み込む。古いfull.cssは新しいfull.cssのスーパーセットなので、差分だけが読み込まれる。その後full.cssもアイドル時に更新される。

辞書の提供にはサーバーサイドの仕組みが必要。バリエーションが多いほど提供する差分の数が増える。コンテンツ更新時に古いリソースを辞書として使う場合もオンザフライか複数バリエーションの静的な辞書の圧縮が必要。キャッシュのVaryも気をつけないといけない。

現在はChromiumのみだが、Firefoxでも実装中。

A tale of two animations

https://calendar.perfplanet.com/2025/a-tale-of-two-animations-the-compositor-in-the-skies/

CompositorがCSSアニメーションにどう役立つか。またどんな制約があるか。

Compositor GPUは一部のアニメーションについてメインスレッドよりもパフォーマンスの良い別のスレッドを指す。

transform/opacityなど限定的なプロパティについて、メインスレッドからの副作用を避ける形でアニメーションをさせられる。

non-composited/compositedの違い。

作ったウェブサイトで意図しないメインスレッドのアクティビティがあった。

一つはleftプロパティをアニメーションさせてたから。どっからかコピってきたやつだった。これはtransformとwill-changeで解決。

もう一つはbox-shadowのアニメーションで、これはnon-compositedなアニメーションだったので移行できない。そんな成功と失敗談。

RUMCG – A year in review

https://calendar.perfplanet.com/2025/rumcg-a-year-in-review/

perf.now() 2024でRUMCGをアナウンスした。Akamai, SpeedCurve, RUMvisionの人がco-chair。現在メンバー75人。GitHubでアクティビティを記録。

いろんな企業や背景の人が参加。2025年はCDNやSPAの課題などについて話した。Chromeからのアップデート共有やMozillaとのディスカッションも行った。Perfnowの前にF2Fもやって楽しかった。

Core Web VitalsのAPIがInteropで採用されたのも嬉しい。ただ同じものを計測できているのかはわからないので、今後やってそのフィードバックもしていきたい。

2026年は何するか。

AIエージェントの行動はRUMと呼べるのか。クロスブラウザでのLCP/INP APIの差はあったりするか？SPAとソフトナビゲーション。その他ブラウザAPI。

perfcal2025-20260207.md

Performance Calendar 2025を読む その5

https://youtube.com/live/ebXPlaDZtd8

Why we should stop talking performance metrics to Business Leaders

https://calendar.perfplanet.com/2025/why-we-should-stop-talking-performance-metrics-to-business-leaders/

パフォーマンスは空港を歩いているようなもの。ふつうに進められれば特に何も気にしない。どこかが詰まっていたら気になる。

KPIではなく、ユーザーが何かする時の体験を伝える。ユーザーが勢いに乗って「簡単だ」と思えるかがすべて。

体験はしているはずなのに、それを語るときに体験として出てこない。パフォーマンスにおいてもTTFBやバンドルサイズの話になってしまう。frictionを技術的に解決したことを説明する時に、その説明がfrictionになってしまう。パフォーマンスは技術ではなく人間的なもの。

flowは全てがうまくいってる時のこと。読み込まれ、ちゃんと反応し、それ以外にユーザーの注意を奪うものがない。心理学者の定義では「effortless progress and full engagement」。フローはメトリクスではない。感じるもの。リズムに乗ったらユーザーはもっと行動し、信頼してくれる。

ユーザーはリズムを期待するが、リズムは簡単に崩れる。最初のページ読み込みが速い場合、以降のステップもその体験で判断されれる。ちょっとしたことでそのリズムが崩れてしまう。 ニールセンのリサーチでは、0.1sがinstant、1s以内だとflow of thoughtが保たれる、ただそれ以上はだめ。

ユーザーはなぜ遅いかというのは気にしない。

frictionは信頼をquietlyに奪っていくもの。常に問題なわけではないが、小さなことの積み重ねで起こる。タップの反応が悪かったり、レイアウトシフト、チカチカした画像、白いままの画面。個々では害はないかもしれないが、積み重なるとユーザーの自信を喪失させる。

著者の経験。ランディングページの0.5sのINPを改善したことについて説明したが、理解ができてないようだったのでセッションリプレイを見せたら遅いとわかってくれた。メトリクスではなくfrictionが重要だったのだ。

Googleオフィスでのアンカンファレンスでもその話題になった。パフォーマンスの重要性はわかっていても、その伝え方がステークホルダーに刺さらないので、エンジニアリングから出ていかない。

苛立ち、ドロップオフ、ユーザーがサイト移動中に保つ自信。friction/flowがこうしたパフォーマンスをアウトカムとして翻訳している。メトリクスは裏付けられるが、ストーリーを伝えられない。

伝える言語がターゲットにマッチしていない問題。LCP, INP, etc.ではなく、trust, certainty, etc.とツアえる。friction/flowはビジネスリーダーがわかる言葉であり、ユーザーがわかる言葉でもある。それがパフォーマンスについて伝える時の言語になる。

技術的な仕事は重要だが、それを伝えることをしないといけない。数値よりも先に意義を伝える。friction/flowはパフォーマンスを伝える言語になる。メトリクスは作業の測定に使い、friction/flowをコミュニケーションに使おう。