この記事で扱うこと
エージェントの応答を WebSocket でストリーミング しながら、メインランディングページの LCP も一緒に手を入れた。「速く見せる」と「最初の画面が速く描かれる」は別の軸だ。
1 日のまとめ
| 作業 | 何をしたかったか | やったこと | 結果 |
|---|---|---|---|
| ストリーミング | WebSocket で 部分応答 を素早く表示 | ストリーミングチャネルを WebSocket に分離 | トークン・チャンク単位で UI に露出 |
| 安定 UI | ストリーミング中の レイアウトシフト を最小化 | ストリーミング領域に 固定高さ placeholder で場所を予約 | layout shift 緩和 |
| LCP | ヒーロー画像の 優先読み込み で LCP 改善 | LCP 候補画像に resource priority を調整 | 目に見える LCP 改善 |
1. ストリーミング UI — 部分応答 + 安定レイアウト
背景知識（概念）
- WebSocket: サーバーと 双方向 の接続を維持してメッセージをやり取りするプロトコル。HTTP ポーリングよりストリーミングに有利だ。
どんな状況だったか
エージェントの応答を一度に受け取らず、トークン・チャンク単位 で UI に見せる必要があった。ところがストリーミングメッセージが増えるにつれて、レイアウトが押される（layout shift）現象があった。
核心となる作業
- ストリーミングチャネルを WebSocket に分離し、トークン・チャンク単位で UI に露出した。
- ストリーミング領域には 固定高さ placeholder で場所を予約して layout shift を緩和した。内容が増える場所を先に確保する選択だ。
教訓
- ストリーミング UI には固定高さ placeholder が必要だ — 内容が増える場所を先に確保する。
- ストリーミングの「速さ」と LCP の「first paint」は 別々に 最適化する。
2. ランディング LCP — リソース優先度
背景知識（概念）
- LCP (Largest Contentful Paint): ビューポートで最も大きいコンテンツが描画されるまでの時間。通常はヒーロー画像・大きなテキストブロックが候補だ。
- Resource priority:
fetchpriority、preload などで どのリソースを先に 受け取るかをブラウザにヒントすること。
どんな状況だったか
メインページの LCP 候補（大きな画像）の読み込み順が 体感速度 に大きな影響を与えた。
核心となる作業
LCP 候補画像に resource priority を調整し、largest-contentful-paint を基準に優先読み込みした。目に見える LCP 改善を得た。
教訓
- resource-priority の調整だけでも LCP が目に見えて変わる — 計測の前後を比較すること。
- ストリーミングの「速さ」と LCP の「first paint」は 別々に 最適化する。
→ Largest Contentful Paint · Resource priority
派生知識
次に見るもの
Blog 下書きの作成と Knowledge 文書の補強。