streaming-ssr
サーバー側でHTMLを生成しながらチャンク単位で配信するStreaming SSRの手法を解説します。Time to First ByteやFirst Contentful Paintを改善し、より高速な初期表示を実現したい場合に活用してください。
description の原文を見る
Teaches streaming server-side rendering for chunked HTML delivery. Use when you need faster Time to First Byte and First Contentful Paint by streaming HTML as it's generated on the server.
SKILL.md 本文
ストリーミング・サーバーサイドレンダリング
アプリケーションのコンテンツを ストリーミング することで、アプリケーションをサーバーレンダリングしながら Time To Interactive を削減できます。現在のナビゲーションに必要なマークアップを含む 1 つの大きな HTML 文字列を生成する代わりに、最初にシェルを送信し、後で遅い部分をストリーミングできます。クライアントが最初の HTML チャンクを受信した瞬間から、ページの解析と描画を開始できます。
最新の React ストリーミングは、Node ランタイムで renderToPipeableStream() を使用するか、Web Stream ランタイムで renderToReadableStream() を使用し、クライアント側で hydrateRoot() で応答をハイドレートします。
使用する場合
- HTML が生成されるにつれて増分的に送信することで、TTFB と FCP を改善したい場合
- 完全な HTML を待つことで初期描画が遅延する大規模なページの場合
使用しない場合
- ホスティング環境がストリーミングレスポンスをサポートしていない場合(一部のサーバーレス プラットフォームは完全なレスポンスをバッファリングします)
- HTML が十分に小さいため、ストリーミングが意味のある改善をもたらさない単純な静的ページの場合
- スタック内のミドルウェアまたはリバース プロキシがレスポンスをバッファリングし、ストリーミングの利点を無効にしている場合
手順
- 廃止予定の
renderToNodeStreamの代わりにrenderToPipeableStream(React 18 以上)を使用する - ストリーミングと
Suspense境界を組み合わせて、遅い部分の読み込み中に部分的なコンテンツをストリーミングする onShellReadyコールバックを使用して、重要なシェルの準備ができたらストリーミングを開始するonErrorコールバックでストリーミング エラーを処理する
詳細
最初の HTML は、App コンポーネントからのデータ チャンクと一緒に応答オブジェクトに送信されます:
<!DOCTYPE html>
<html>
<head>
<title>Cat Facts</title>
<link rel="stylesheet" href="/style.css" />
<script type="module" defer src="/build/client.js"></script>
</head>
<body>
<h1>Stream Rendered Cat Facts!</h1>
<div id="approot"></div>
</body>
</html>
Node での最新の React ストリーミングは renderToPipeableStream を使用します:
import { renderToPipeableStream } from "react-dom/server";
app.use("*", (request, response) => {
let didError = false;
const { pipe } = renderToPipeableStream(<App />, {
bootstrapScripts: ["/build/client.js"],
onShellReady() {
response.statusCode = didError ? 500 : 200;
response.setHeader("Content-Type", "text/html");
pipe(response);
},
onError(error) {
didError = true;
console.error(error);
},
});
});
renderToString を使用して App コンポーネントをサーバーレンダリングする場合、ツリー全体がレンダリングされるまで待つ必要があります。ストリーミングでは、サーバーはシェルを早期にフラッシュし、遅いコンテンツの準備ができたら送信を続けることができます。
概念
プログレッシブハイドレーションと同様に、ストリーミングは SSR パフォーマンスを改善するために使用できるレンダリング メカニズムです。名前が示唆するように、ストリーミングは HTML のチャンクがサーバーで生成されるにつれてノード サーバーからクライアントにストリーミングされることを意味します。クライアントが大規模ページであっても早期に HTML の「バイト」を受信し始めるため、TTFB は削減され、比較的一定になります。すべての主流ブラウザーはストリーミングされたコンテンツまたは部分的な応答をより早期に解析とレンダリングを開始します。レンダリングは段階的であるため、高速な FP と FCP が実現されます。
ストリーミングはネットワーク バックプレッシャーに対応します。ネットワークが詰まり、これ以上バイトを転送できない場合、レンダラーはシグナルを受け取り、ネットワークがクリアされるまでストリーミングを停止します。したがって、サーバーはより少ないメモリを使用し、I/O 条件に対して応答性が高くなります。これにより、Node.js サーバーは同時に複数のリクエストをレンダリングでき、重いリクエストが軽いリクエストを長時間ブロックすることを防ぎます。結果として、サイトは困難な状況でも応答性を保ちます。
React ストリーミング用
React 18 は最新のストリーミング API を導入しました:
renderToPipeableStream(element, options)は Node.js HTTP レスポンス用です。renderToReadableStream(element, options)はエッジ環境などの Web Streams ランタイム用です。
これらの API は Suspense 境界、onShellReady、onAllReady、およびクライアント側で hydrateRoot() を通じたプログレッシブハイドレーションをサポートしています。
ストリーム出力は、シェルの準備ができたらすぐにバイトを発行できます。レスポンスは段階的にクライアントにデータ チャンクを送信し、遅いチャンクはサーバーで引き続きレンダリングされます。
ストリーミング SSR - 利点と欠点
ストリーミングは React での SSR の速度を改善することを目的としており、以下の利点があります:
-
パフォーマンスの向上: 最初のバイトがサーバーでレンダリングが開始された直後にクライアントに到達するため、TTFB は SSR のものより優れています。ページサイズに関係なく、より一貫性があります。クライアントが受信したらすぐに HTML の解析を開始できるため、FP と FCP も低くなります。
-
バックプレッシャーの処理: ストリーミングはネットワーク バックプレッシャーまたは混雑に対応し、困難な状況でも応答性の高い Web サイトを実現できます。
-
SEO サポート: ストリーミングされたレスポンスは検索エンジン クローラーで読み取ることができるため、Web サイトで SEO を行うことができます。
renderToString から renderToPipeableStream() への単純な検索置換ではなく、ストリーミング実装は複雑であることに注意することが重要です。SSR で機能するコードがストリーミングではそのまま機能しないケースがあります:
-
SSR レンダリング パスを使用して、SSR されたチャンクの前にドキュメントに追加する必要があるマークアップを生成するフレームワーク。例えば、ページに追加する CSS を先行する
<style>タグで動的に決定するフレームワークです。 -
renderToStaticMarkupを使用してページテンプレートを生成し、renderToString呼び出しが埋め込まれて動的コンテンツを生成するコード。これらの場合、コンポーネントに対応する文字列が必要とされるため、ストリームで置き換えることはできません。例えば:
res.write("<!DOCTYPE html>");
res.write(renderToStaticMarkup(
<html>
<head>
<title>My Page</title>
</head>
<body>
<div id="content">
{ renderToString(<MyPage/>) }
</div>
</body>
</html>);
ストリーミングとプログレッシブハイドレーションの両方が、純粋な SSR と CSR 体験の間のギャップを埋めるのに役立つことができます。
ソース
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- patternsdev
- リポジトリ
- patternsdev/skills
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/patternsdev/skills / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。