client-side-rendering
SEOよりもインタラクティブ性を重視するReactアプリケーションのクライアントサイドレンダリング（CSR）を解説するスキルです。ユーザー操作によってUIが動的に変化する高度なインタラクティブアプリを構築する際に活用してください。
description の原文を見る
Teaches client-side rendering (CSR) for React applications. Use when building highly interactive apps where SEO is not a priority and the UI is driven by user actions.
SKILL.md 本文
クライアント側レンダリング
クライアント側レンダリング(CSR)では、サーバーはページの最小限のHTMLコンテナのみをレンダリングします。ページにコンテンツを表示するために必要なロジック、データ取得、テンプレート、ルーティングはすべてブラウザ/クライアントで実行されるJavaScriptコードによって処理されます。CSRはシングルページアプリケーションを構築する方法として人気が出ました。Webサイトとインストール済みアプリケーションの違いを曖昧にするのに役立ちました。
使用時期
- SEOが優先事項でない内部ツール、ダッシュボード、またはSPAに使用してください
- 完全にインタラクティブなシングルページアプリケーション体験が必要な場合に役立ちます
非推奨
- 検索エンジンがコンテンツをインデックスするためにサーバーレンダリングされたHTMLが必要なSEO重要ページ
- JavaScriptが読み込まれて実行されるまでユーザーが空白ページを見るコンテンツ豊富なサイト
- First Contentful Paintが主要な指標である場合 — CSRはすべてのレンダリングをクライアントに遅延させます
指示
- First Contentful Paintを高速化するため、初期JavaScriptバンドルを小さく保つ(圧縮済み/gzip化で100-170KB以下)
- コード分割と遅延読み込みを使用して、重要でないJavaScriptを遅延させる
- SEOと初期読み込みパフォーマンスが重要な公開ページではSSR/SSGを検討する
- サービスワーカーとアプリケーションシェル キャッシングを使用して、オフラインと再訪問時のパフォーマンスを実現する
詳細
基本構造
Reactを使用してページに現在の時刻を表示および更新するシンプルな例を考えます。
import { createRoot } from 'react-dom/client'
import { useEffect, useState } from 'react'
function Clock() {
const [time, setTime] = useState(new Date())
useEffect(() => {
const id = setInterval(() => setTime(new Date()), 1000)
return () => clearInterval(id)
}, [])
return (
<div>
<h1>Hello, world!</h1>
<h2>It is {time.toLocaleTimeString()}.</h2>
</div>
)
}
createRoot(document.getElementById('root')!).render(<Clock />)
<div id="root"></div>
HTMLは単一のルート <div> タグのみで構成されています。コンテンツの表示と更新はすべてJavaScriptで処理されます。サーバーへのラウンドトリップはなく、レンダリングされたHTMLはインプレースで更新されます。ここで時刻は、APIから取得した為替レートや株価などの他のリアルタイム情報に置き換えることができ、ページを更新したりサーバーへのラウンドトリップなしに表示できます。
JavaScriptバンドルとパフォーマンス
ページの複雑さが増して、画像を表示したり、データストアからデータを表示したり、イベント処理を含めたりするようになると、ページをレンダリングするために必要なJavaScriptコードの複雑さとサイズも増加します。CSRの結果、大きなJavaScriptバンドルが生成され、ページのFCPとTTIが増加しました。
bundle.jsのサイズが増加するにつれて、FCPとTTIが先延ばしになります。これは、ユーザーがFPからFCPまでの間、ずっと空白の画面を見ることになることを意味します。
メリットとデメリット
Reactではほとんどのアプリケーションロジックがクライアント側で実行され、APIコールを通じてサーバーと相互作用してデータを取得または保存します。したがって、UIはほぼすべてクライアント側で生成されます。Webアプリケーション全体は最初のリクエストで読み込まれます。ユーザーがリンクをクリックして移動する際、ページをレンダリングするためのサーバーへの新しいリクエストは生成されません。コードはクライアント側で実行され、ビュー/データを変更します。
CSRでは、ページ更新なしにナビゲーションをサポートし、優れたユーザー体験を提供するシングルページアプリケーションを実現できます。ビューを変更するために処理されるデータが限定されるため、ページ間のルーティングは通常より高速であり、CSRアプリケーションはより反応性が高く見えます。CSRはまた、開発者がクライアントとサーバーのコード間で明確な分離を実現することを可能にします。
優れたインタラクティブ体験を提供する一方で、CSRにはいくつかの落とし穴があります:
-
SEOに関する考慮事項: ほとんどのWebクローラーはサーバーレンダリングされたWebサイトを直線的に解釈できます。クライアント側レンダリングの場合は、大きなペイロードとネットワークリクエストの滝(例:APIレスポンス)により、意味のあるコンテンツがクローラーのインデックス化に十分な速度でレンダリングされない可能性があるため、少し複雑になります。クローラーはJavaScriptを理解できますが、制限があります。したがって、クライアントレンダリングされたWebサイトをSEOフレンドリーにするためには、いくつかの回避策が必要です。
-
パフォーマンス: クライアント側レンダリングでは、サーバーへのラウンドトリップがないため、インタラクション中の応答時間が大幅に改善されます。ただし、ブラウザがクライアント側でコンテンツを初めてレンダリングするには、まずJavaScriptが読み込まれて処理が開始されるのを待つ必要があります。したがって、ユーザーは初期ページが読み込まれるまでにある程度の遅延を経験します。これはJSバンドルのサイズが大きくなったり、クライアントの処理能力が不足したりすると、ユーザー体験に悪影響を与える可能性があります。
-
コード保守性: コードの一部の要素は、クライアントとサーバー(API)の間で異なる言語で繰り返される可能性があります。他の場合では、ビジネスロジックの明確な分離が不可能な場合があります。例としては、通貨フィールドと日付フィールドの検証とフォーマットロジックが挙げられます。
-
データ取得: クライアント側レンダリングでは、データ取得は通常イベント駆動です。ページは最初はデータなしで読み込まれる可能性があります。その後、ページ読み込みやボタンクリックなどのイベントの発生時にAPIコールを使用してデータが取得されます。データのサイズに応じて、これはアプリケーションの読み込み/インタラクション時間に加わる可能性があります。
これらの考慮事項の重要性は、アプリケーション間で異なる場合があります。開発者は、インタラクション時間を損なわずに、より高速にページを提供できるSEOフレンドリーなソリューションを見つけることに関心があることが多いです。
CSRパフォーマンスの改善
CSRのパフォーマンスはJavaScriptバンドルのサイズに反比例するため、最善のことはJavaScriptコードを最適なパフォーマンスのために構成することです。以下は役立つ可能性のあるポイントのリストです:
-
JavaScriptの予算化: 初期ページ読み込みに合理的にタイトなJavaScript予算があることを確認してください。100-170KB圧縮およびgzip化された初期バンドルは良い出発点です。その後、必要に応じてコードをオンデマンドで読み込むことができます。
-
プリロード: このテクニックは、ページライフサイクルの早期にページで必要とされる重要なリソースをプリロードするために使用できます。重要なリソースは、HTMLの
<head>セクションに以下のディレクティブを含めることでプリロードできるJavaScriptが含まれます。
<link rel="preload" as="script" href="critical.js" />
これは、ページレンダリングメカニズムが開始される前に critical.js ファイルの読み込みを開始するようブラウザに指示します。スクリプトは早期に利用可能になり、ページレンダリングメカニズムをブロックしないため、パフォーマンスが向上します。
-
遅延読み込み: 遅延読み込みでは、重要でないリソースを識別して、必要な時にのみこれらをロードできます。この方法を使用すると、最初に読み込まれるリソースのサイズが削減されるため、初期ページロード時間を改善できます。例えば、チャットウィジェットコンポーネントは通常、ページ読み込み時にすぐには必要とされず、遅延読み込みできます。
-
コード分割: 大きなJavaScriptコードバンドルを回避するために、バンドルの分割を開始できます。コード分割はWebpackなどのバンドラーでサポートされており、実行時に動的に読み込むことができる複数のバンドルを作成するために使用できます。コード分割により、JavaScriptリソースを遅延読み込みすることもできます。
-
サービスワーカーを使用したアプリケーションシェル キャッシング: このテクニックは、ユーザーインターフェースを支える最小限のHTML、CSS、JavaScriptであるアプリケーションシェルをキャッシングすることを含みます。サービスワーカーを使用して、アプリケーションシェルをオフラインでキャッシュできます。これは、ネイティブシングルページアプリ体験を提供し、残りのコンテンツが必要に応じて段階的に読み込まれるのに役立つ可能性があります。
これらのテクニックにより、CSRは適切なFCPとTTIを備えた高速なシングルページアプリケーション体験を提供するのに役立ちます。
ソース
ライセンス: 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
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。