サーバー → サーバ

Author: smikitky

src/content/learn/add-react-to-an-existing-project.md

@@ -22,7 +22,7 @@ title: 既存プロジェクトに React を追加する
 
 1. [React ベースのフレームワーク](/learn/start-a-new-react-project)のうちひとつを使い、アプリの **React 部分をビルド**します。
 2. フレームワークの設定で `/some-app` を ***base path* に指定**します（方法：[Next.js](https://nextjs.org/docs/app/api-reference/config/next-config-js/basePath)、[Gatsby](https://www.gatsbyjs.com/docs/how-to/previews-deploys-hosting/path-prefix/)）。
-3. **サーバーまたはプロキシを設定**して、`/some-app/` 以下のすべてのリクエストを React アプリで処理するようにします。
+3. **サーバまたはプロキシを設定**して、`/some-app/` 以下のすべてのリクエストを React アプリで処理するようにします。
 
 こうすることで、アプリの React 部分がこれらのフレームワークに組み込まれた[ベストプラクティスを最大限に取り入れる](/learn/start-a-new-react-project#can-i-use-react-without-a-framework)ことができます。
 

src/content/learn/build-a-react-app-from-scratch.md

@@ -126,13 +126,13 @@ GraphQL API からデータを取得する場合、以下の使用をお勧め
 
 * **シングルページアプリ (SPA)** は、単一の HTML ページを読み込み、ユーザがアプリを操作した際にページを動的に更新します。SPA は始めやすいですが、初期読み込み時間が遅くなることがあります。SPA はほとんどのビルドツールにおけるデフォルトのアーキテクチャです。
 
-* **ストリーミングサーバーサイドレンダリング (SSR)** は、サーバでページをレンダーし、完全にレンダーされたページをクライアントに送信します。SSR はパフォーマンスを向上できますが、シングルページアプリよりも設定とメンテナンスが複雑になることがあります。ストリーミングを追加すると、SSR の構築とメンテナンスは非常に複雑になります。[Vite の SSR ガイド](https://vite.dev/guide/ssr)を参照してください。
+* **ストリーミングサーバサイドレンダリング (SSR)** は、サーバでページをレンダーし、完全にレンダーされたページをクライアントに送信します。SSR はパフォーマンスを向上できますが、シングルページアプリよりも設定とメンテナンスが複雑になることがあります。ストリーミングを追加すると、SSR の構築とメンテナンスは非常に複雑になります。[Vite の SSR ガイド](https://vite.dev/guide/ssr)を参照してください。
 
-* **静的サイト生成 (SSG)** は、ビルド時にアプリの静的 HTML ファイルを生成します。SSG はパフォーマンスを向上させることができますが、サーバーサイドレンダリングよりも設定とメンテナンスが複雑になることがあります。[Vite の SSG ガイド](https://vite.dev/guide/ssr.html#pre-rendering-ssg)を参照してください。
+* **静的サイト生成 (SSG)** は、ビルド時にアプリの静的 HTML ファイルを生成します。SSG はパフォーマンスを向上させることができますが、サーバサイドレンダリングよりも設定とメンテナンスが複雑になることがあります。[Vite の SSG ガイド](https://vite.dev/guide/ssr.html#pre-rendering-ssg)を参照してください。
 
 * **React Server Components (RSC)** は、ビルド時専用コンポーネント、サーバ専用コンポーネント、そしてインタラクティブなコンポーネントを、単一の React ツリーで混在させることができます。RSC はパフォーマンスを向上させることができますが、現在のところ、設定とメンテナンスには深い専門知識が必要です。[Parcel の RSC の例](https://github.com/parcel-bundler/rsc-examples)を参照してください。
 
-あなたのレンダー戦略を、ルータと統合する必要があります。それによりあなたのフレームワークで構築されたアプリが、ルートごとにレンダー戦略を選択できるようにするのです。これにより、アプリ全体を書き直すことなく、異なるレンダー戦略を利用できます。たとえば、アプリの最初のページでは静的な生成 (SSG) が有益かもしれませんが、コンテンツフィードを持つページはサーバーサイドレンダリングが最適かもしれません。
+あなたのレンダー戦略を、ルータと統合する必要があります。それによりあなたのフレームワークで構築されたアプリが、ルートごとにレンダー戦略を選択できるようにするのです。これにより、アプリ全体を書き直すことなく、異なるレンダー戦略を利用できます。たとえば、アプリの最初のページでは静的な生成 (SSG) が有益かもしれませんが、コンテンツフィードを持つページはサーバサイドレンダリングが最適かもしれません。
 
 適切なルートに適切なレンダー戦略を使用することで、コンテンツの最初のバイトが読み込まれるまでの時間 ([Time to First Byte](https://web.dev/articles/ttfb))、最初のコンテンツが表示されるまでの時間 ([First Contentful Paint](https://web.dev/articles/fcp))、およびアプリの最大の可視コンテンツが表示されるまでの時間 ([Largest Contentful Paint](https://web.dev/articles/lcp)) を短縮できるのです。