Skip to content

Instantly share code, notes, and snippets.

@myakura

myakura/perfcal2025-20260122.md

Last active January 31, 2026 06:27
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save myakura/f4c0df2053e11ee8e03ebec129e39fd9 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save myakura/f4c0df2053e11ee8e03ebec129e39fd9 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
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でできたりするという紹介。

Raw
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テスト手法、統計的に意味があること、実際のビジネスメトリクスを使っていること（％だけじゃなく数値もあるとなおよい）。透明性があること。

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment