Apply suggestions from code review

Co-authored-by: honey32 <[email protected]>

Author: smikitky

src/content/blog/2025/02/14/sunsetting-create-react-app.md

@@ -148,13 +148,13 @@ export default function App() {
 }
 ```
 
-これにより、`/dashboard` というリンクを共有すれば、アプリはダッシュボードページに移動するようになります。ルーティングライブラリには、ルートのネスト、ルートガード、ルート間画面遷移効果 (root transition) などの追加機能もあり、これらはルーティングライブラリなしには実装困難です。
+これにより、`/dashboard` というリンクを共有すれば、アプリはダッシュボードページに移動するようになります。ルーティングライブラリには、ルートのネスト、ルートガード、ルート間画面遷移効果 (route transition) などの追加機能もあり、これらはルーティングライブラリなしには実装困難です。
 
 ルーティングライブラリを使うとアプリは複雑になりますが、その代わりに、それなしでは作れないような機能も使えるようになる、というトレードオフがあるのです。
 
 ### データフェッチ {/*data-fetching*/}
 
-Create React App でのもうひとつの一般的な問題はデータフェッチです。Create React App には、特定のデータフェッチソリューションは含まれていません。まだ始めたばかりという場合、一般的な選択肢はデータをロードするためにエフェクト内で `fetch` を使用することです。
+Create React App でのもうひとつの一般的な問題はデータフェッチです。Create React App には、特定のデータフェッチソリューションは含まれていませんが、入門したばかりの方は、データをロードするためにエフェクト内で `fetch` を使う方法を選びがちです。
 
 しかし、これを行うと、データがコンポーネントのレンダー後にフェッチされるため、ネットワークウォーターフォールが発生します。ネットワークウォーターフォールは、コードとデータを並行でダウンロードするのではなく、アプリのレンダー後にデータをフェッチすることで発生します。
 
@@ -198,7 +198,7 @@ export default function Dashboard({loaderData}) {
 }
 ```
 
-初回ロード時に、ルータはルートがレンダーされる前にデータを即座にフェッチできます。ユーザがアプリ内を移動する際、ルータはデータとルートのフェッチを並列化して同時に行えます。これにより、画面上のコンテンツを見るまでの時間が短縮され、ユーザエクスペリエンスが向上します。
+初回ロード時に、ルータはルートがレンダーされる直前にデータをフェッチできます。ユーザがアプリ内を移動する際、ルータはデータとルートのフェッチを並列化して同時に行えます。これにより、画面上のコンテンツを見るまでの時間が短縮され、ユーザエクスペリエンスが向上します。
 
 ただし、これにはアプリ内のローダを正しく設定する必要があり、パフォーマンスのために複雑さが犠牲になっています。
 
@@ -284,7 +284,7 @@ Create React App、Vite、Parcel などのビルドツールでこれらの要
 
 あるページにとって CSR が正しい選択となることはありますが、多くの場合はそうではありません。アプリのほとんどがクライアントサイドという場合でも、[静的サイト生成 (SSG)](https://developer.mozilla.org/en-US/docs/Glossary/SSG) や [サーバサイドレンダリング (SSR)](https://developer.mozilla.org/en-US/docs/Glossary/SSR) などのサーバレンダー機能の恩恵を受けることができる個別ページはしばしば存在します。たとえば利用規約ページやドキュメントなどです。
 
-サーバレンダーによりクライアントに送信される JavaScript を全体的に削減し、完全な HTML ドキュメントを生成することで、[First Contentful Paint (FCP)](https://web.dev/articles/fcp) を高速化し、[Total Blocking Time (TBD)](https://web.dev/articles/tbt) を削減し、またそれにより [Interaction to Next Paint (INP)](https://web.dev/articles/inp) を低下させることができます。これが、Chrome チームが開発者に静的またはサーバサイドレンダリングを[検討するよう促した](https://web.dev/articles/rendering-on-the-web)理由でもあります。
+サーバレンダーはクライアントに送信される JavaScript を全体的に削減し、完全な HTML ドキュメントを送信することで、[First Contentful Paint (FCP)](https://web.dev/articles/fcp) を高速化し、[Total Blocking Time (TBD)](https://web.dev/articles/tbt) を削減し、またそれにより [Interaction to Next Paint (INP)](https://web.dev/articles/inp) を低下させることができます。Chrome チームが開発者に向けて、パフォーマンス最大化のために、完全にクライアントサイドに寄せた戦略ではなく静的ないしサーバサイドレンダリングを[検討するよう促している](https://web.dev/articles/rendering-on-the-web)のには、このような理由があるのです。
 
 サーバを使用することにはトレードオフがあり、すべてのページにとって常に最良の選択肢というわけではありません。サーバでページを生成することにより追加のコストと生成時間がかかるため、[Time to First Byte (TTFB)](https://web.dev/articles/ttfb) を増加させる可能性があります。最高のパフォーマンスのアプリでは、それぞれの戦略のトレードオフに基づいて、ページごとに適切なレンダー戦略を選択できます。
 
@@ -310,7 +310,7 @@ Create React App、Vite、Parcel などのビルドツールでこれらの要
 
 サーバレンダーは SEO も改善しますが、ユーザが画面上のコンテンツを見るためにダウンロード・パースする必要のある JavaScript の量を減らすことで、パフォーマンスも向上させるものです。
 
-これが、Chrome チームが開発者に対し、最高のパフォーマンスを達成するために、完全なクライアントサイドのアプローチではなく、静的ないしサーバサイドレンダリングを検討するよう[促している](https://web.dev/articles/rendering-on-the-web)理由です。
+Chrome チームが開発者に向けて、パフォーマンス最大化のために、完全なクライアントサイドに寄せた戦略ではなく、静的ないしサーバサイドレンダリングを検討するよう[促している](https://web.dev/articles/rendering-on-the-web)のには、このような理由があるのです。
 
 </Note>