Guide > Server-Side Rendering Guide > Introduction の翻訳

src/guide/ssr/introduction.md

@@ -1,47 +1,47 @@
-# Server-Side Rendering Guide
+# サーバサイドレンダリングガイド
 
-> This guide is currently under active development
+> このガイドは執筆調整中です
 
-## What is Server-Side Rendering (SSR)?
+## サーバサイドレンダリング（SSR）とは？
 
-Vue.js is a framework for building client-side applications. By default, Vue components produce and manipulate DOM in the browser as output. However, it is also possible to render the same components into HTML strings on the server, send them directly to the browser, and finally "hydrate" the static markup into a fully interactive application on the client.
+Vue.js はクライアントサイドのアプリケーションを構築するためのフレームワークです。デフォルトでは、 Vue コンポーネントは出力としてブラウザ内で DOM の生成と操作をします。しかしサーバから、同じコンポーネントを HTML 文字列にレンダリングして、それらをブラウザに直接送信して、最終的にはクライアント上での静的なマークアップを完全にインタラクティブなアプリケーションに「Hydrate（ハイドレート）」することも可能です。
 
-A server-rendered Vue.js application can also be considered "isomorphic" or "universal". This means that the majority of your app's code runs on both the server **and** the client.
+サーバサイドレンダリングした Vue.js アプリケーションは、 「Isomorphic（アイソモルフィック）」とか「Universal（ユニバーサル）」と考えることもできます。これはつまり、アプリケーションのコードの大部分がサーバ **と** クライアントの両方で実行されるということを意味します。
 
-## Why SSR?
+## なぜ SSR なのか？
 
-Compared to a traditional SPA (Single-Page Application), the advantage of SSR primarily lies in:
+従来の SPA (Single-Page Application) と比べて、 SSR の利点は主に次の点です:
 
-- Better search engine optimization (SEO), as the search engine crawlers will directly see the fully rendered page.
+- 検索エンジンのクローラーが完全にレンダリングされたページを直接表示できて、検索エンジン最適化（SEO）が向上します。
 
-  Note that as of now, Google and Bing can index synchronous JavaScript applications just fine. Synchronous being the key word there. If your app starts with a loading spinner, then fetches content via API call, the crawler will not wait for you to finish. This means if you have content fetched asynchronously on pages where SEO is important, SSR might be necessary.
+  現在のところ、 Google と Bing は同期的な JavaScript アプリケーションを正常にインデックスできることには注意してください。同期がキーワードです。アプリケーションがローディングスピナーで始まり、API 呼び出しでコンテンツを取得する場合、クローラーはその完了を待ってくれません。つまり、 SEO が重要なページで非同期にコンテンツを取得する場合、 SSR が必要になるかもしれません。
 
-- Faster time-to-content, especially on the slow Internet connection or slow devices. Server-rendered markup doesn't need to wait until all JavaScript has been downloaded and executed to be displayed, so your user will see a fully-rendered page sooner. This generally results in better user experience, and can be critical for applications where time-to-content is directly associated with the conversion rate.
+- 特に遅いインターネット接続や遅いデバイスでも、コンテンツ表示までの時間が短縮されます。サーバレンダリングされたマークアップは、すべての JavaScript が表示のためにダウンロードと実行されるまで待つ必要がないため、ユーザがより早く完全にレンダリングされたページを見ることができます。これは一般的にユーザエクスペリエンスの向上につながり、コンテンツ表示までの時間がコンバージョン率に直結するようなアプリケーションでは重要になる可能性があります。
 
-There are also some trade-offs to consider when using SSR:
+また、 SSR を使う際には考慮すべきいくつかのトレードオフがあります:
 
-- Development constraints. Browser-specific code can only be used inside certain lifecycle hooks; some external libraries may need special treatment to be able to run in a server-rendered app.
+- 開発の制約。ブラウザ固有のコードは、特定のライフサイクルフックの中でしか使えません; 外部ライブラリの中には、サーバレンダリングしたアプリで実行するために特別な処理が必要になるものもあります。
 
-- More involved build setup and deployment requirements. Unlike a fully static SPA that can be deployed on any static file server, a server-rendered app requires an environment where a Node.js server can run.
+- より複雑なビルドのセットアップとデプロイの要件。任意の静的なファイルサーバにデプロイできる完全に静的な SPA とは異なり、サーバレンダリングされたアプリケーションは Node.js サーバが動作する環境を必要とします。
 
-- More server-side load. Rendering a full app in Node.js is going to be more CPU-intensive than just serving static files, so if you expect high traffic, be prepared for corresponding server load and wisely employ caching strategies.
+- より大きなサーバサイド負荷。 Node.js で完全なアプリケーションをレンダリングすると、静的なファイルを配信するよりも CPU 負荷が高くなるため、高いトラフィックが予想される場合は、対応するサーバ負荷に備えて、キャッシュ戦略を賢く採用してください。
 
-Before using SSR for your application, the first question you should ask is whether you actually need it. It mostly depends on how important time-to-content is for your application. For example, if you are building an internal dashboard where an extra few hundred milliseconds on the initial load doesn't matter that much, SSR would be overkill. However, in cases where time-to-content is absolutely critical, SSR can help you achieve the best possible initial load performance.
+アプリケーションに SSR を使う前に、最初に確認すべきことは、本当に SSR が必要かどうかです。これはアプリケーションにとってコンテンツ表示までの時間がどれだけ重要かによります。例えば、内部のダッシュボードを構築していて、初期ロードで余計な数百ミリ秒があってもそれほど問題にならない場合、 SSR はやりすぎになります。ただし、コンテンツ表示までの時間が絶対的に重要な場合、 SSR は可能な限りの最高の初期ロードパフォーマンスを達成するのに役立ちます。
 
-## SSR vs Prerendering
+## SSR とプリレンダリングの比較
 
-If you're only investigating SSR to improve the SEO of a handful of marketing pages (e.g. `/`, `/about`, `/contact`, etc), then you probably want **prerendering** instead. Rather than using a web server to compile HTML on-the-fly, prerendering generates static HTML files for specific routes at build time. The advantage is setting up prerendering is much simpler and allows you to keep your frontend as a fully static site.
+もし、ひと握りのマーケティングページ（例: `/`、 `/about`、`/contact` など）の SEO を改善するために SSR を検討しているならば、代わりに **プリレンダリング** が必要でしょう。プリレンダリングは、ウェブサーバを使ってオンザフライで HTML をコンパイルするのではなく、ビルド時に特定のルーティングの静的 HTML ファイルを生成します。利点はプリレンダリングの設定がよりシンプルで、フロントエンドを完全に静的サイトとして維持できることです。
 
-If you're using [webpack](https://webpack.js.org/), you can add prerendering with the [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). It's been extensively tested with Vue apps.
+[Webpack](https://webpack.js.org/) を使っている場合、 [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin) でプリレンダリングを追加できます。このプラグインは、 Vue アプリケーションで広くテストされています。
 
-## About This Guide
+## このガイドについて
 
-[//]: # 'TODO: This guide is focused on server-rendered Single-Page Applications using Node.js as the server. Mixing Vue SSR with other backend setups is a topic of its own and briefly discussed in a [dedicated section].'
+[//]: # 'TODO: このガイドは、 Node.js をサーバとして使ったサーバサイドレンダリング SPA (Single Page Application) に焦点を当てています。他のバックエンドの設定と Vue SSR を混ぜることは独自のトピックであり、 [専用のセクション] で簡単に説明しています。'
 
-This guide will be very in-depth and assumes you are already familiar with Vue.js itself, and have a decent working knowledge of Node.js and webpack.
+このガイドは非常に詳細で、 Vue.js 自体に精通しており、 Node.js と Webpack の実用的な知識があることを前提としています。
 
-[//]: # 'If you prefer a higher-level solution that provides a smooth out-of-the-box experience, you should probably give [Nuxt.js](https://nuxtjs.org/) a try. It's built upon the same Vue stack but abstracts away a lot of the boilerplate, and provides some extra features such as static site generation. However, it may not suit your use case if you need more direct control of your app's structure. Regardless, it would still be beneficial to read through this guide to understand better how things work together.'
+[//]: # 'すぐに使えるようなエクスペリエンスを提供する高レベルのソリューションが必要な場合は、 [Nuxt.js](https://nuxtjs.org/) を試してみるとよいでしょう。これは同じ Vue スタックに基づいて構築されていますが、多くのボイラープレートを抽象化して、静的サイトの生成など追加機能を提供しています。ただし、アプリケーションの構造をより直接制御する必要がある場合は、ユースケースに合わないかもしれません。いずれにしても、このガイドを読んで、物事がどのように連携しているのかをよりよく理解することはためになるでしょう。'
 
-[//]: # 'TODO: As you read along, it would be helpful to refer to the official [HackerNews Demo](https://github.com/vuejs/vue-hackernews-2.0/), which makes use of most of the techniques covered in this guide'
+[//]: # 'TODO: 読み進めていく中で、このガイドで取り上げているほとんどのテクニックを使っている公式の [HackerNews デモ](https://github.com/vuejs/vue-hackernews-2.0/) を参照すると便利です'
 
-Finally, note that the solutions in this guide are not definitive - we've found them to be working well for us, but that doesn't mean they cannot be improved. They might get revised in the future - and feel free to contribute by submitting pull requests!
+最後に、このガイドのソリューションは決定的ではないことに注意してください - このソリューションはうまく動作していることがわかりましたが、それは改善できないという意味ではありません。将来的には改定される可能性があります - プルリクエストを出して気軽に貢献してください！