diff --git a/LANGS.md b/LANGS.md
index 25b60e8a..f379e75a 100644
--- a/LANGS.md
+++ b/LANGS.md
@@ -1 +1,2 @@
 * [English](en/)
+* [Русский](ru/)
diff --git a/ru/README.md b/ru/README.md
new file mode 100644
index 00000000..084c25b9
--- /dev/null
+++ b/ru/README.md
@@ -0,0 +1,50 @@
+# Vue.js Server-Side Rendering Guide
+
+> **Note:** this guide requires the following minimum versions of Vue and supporting libraries:
+> - vue & vue-server-renderer >= 2.3.0
+> - vue-router >= 2.5.0
+> - vue-loader >= 12.0.0 & vue-style-loader >= 3.0.0
+
+> If you have previously used Vue 2.2 with SSR, you will notice that the recommended code structure is now [a bit different](./structure.md) (with the new [runInNewContext](./api.md#runinnewcontext) option set to `false`). Your existing app should continue to work, but it's recommended to migrate to the new recommendations.
+
+## What is Server-Side Rendering (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 app on the client.
+
+A server-rendered Vue.js app can also be considered "isomorphic" or "universal", in the sense that the majority of your app's code runs on both the server **and** the client.
+
+## Why SSR?
+
+Compared to a traditional SPA (Single-Page Application), the advantage of SSR primarily lies in:
+
+- Better SEO, as the search engine crawlers will directly see the fully rendered page.
+
+  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 Ajax, 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.
+
+- Faster time-to-content, especially on slow internet 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 conversion rate.
+
+There are also some trade-offs to consider when using 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.
+
+- More server-side load. Rendering a full app in Node.js is obviously 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.
+
+Before using SSR for your app, the first question you should ask it whether you actually need it. It mostly depends on how important time-to-content is for your app. For example, if you are building an internal dashboard where an extra few hundred milliseconds on initial load doesn't matter that much, SSR would be an overkill. However, in cases where time-to-content is absolutely critical, SSR can help you achieve the best possible initial load performance.
+
+## SSR vs Prerendering
+
+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 simply 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.
+
+If you're using Webpack, you can easily add prerendering with the [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). It's been extensively tested with Vue apps - and in fact, [the creator](https://github.com/chrisvfritz) is a member of the Vue core team.
+
+## About This Guide
+
+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 is not covered in this guide.
+
+This guide will be very in-depth and assumes you are already familiar with Vue.js itself, and have decent working knowledge of Node.js and webpack. If you prefer a higher-level solution that provides a smooth out-of-the-box experience, you should probably give [Nuxt.js](http://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 better understand how things work together.
+
+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.
+
+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!
diff --git a/ru/SUMMARY.md b/ru/SUMMARY.md
new file mode 100644
index 00000000..efd9eaf7
--- /dev/null
+++ b/ru/SUMMARY.md
@@ -0,0 +1,27 @@
+- [Basic Usage](basic.md)
+- [Writing Universal Code](universal.md)
+- [Source Code Structure](structure.md)
+- [Routing and Code-Splitting](routing.md)
+- [Data Pre-fetching and State](data.md)
+- [Client Side Hydration](hydration.md)
+- [Introducing Bundle Renderer](bundle-renderer.md)
+- [Build Configuration](build-config.md)
+- [CSS Management](css.md)
+- [Head Management](head.md)
+- [Caching](caching.md)
+- [Streaming](streaming.md)
+- [API Reference](api.md)
+  - [createRenderer](api.md#createrendereroptions)
+  - [createBundleRenderer](api.md#createbundlerendererbundle-options)
+  - [Class: Renderer](api.md#class-renderer)
+  - [Class: BundleRenderer](api.md#class-bundlerenderer)
+  - [Renderer Options](api.md#renderer-options)
+    - [template](api.md#template)
+    - [clientManifest](api.md#clientmanifest)
+    - [inject](api.md#inject)
+    - [shouldPreload](api.md#shouldpreload)
+    - [runInNewContext](api.md#runinnewcontext)
+    - [basedir](api.md#basedir)
+    - [cache](api.md#cache)
+    - [directives](api.md#directives)
+  - [Webpack Plugins](api.md#webpack-plugins)
diff --git a/ru/api.md b/ru/api.md
new file mode 100644
index 00000000..8c82f6b5
--- /dev/null
+++ b/ru/api.md
@@ -0,0 +1,227 @@
+# API Reference
+
+## `createRenderer([options])`
+
+Create a [`Renderer`](#class-renderer) instance with (optional) [options](#renderer-options).
+
+``` js
+const { createRenderer } = require('vue-server-renderer')
+const renderer = createRenderer({ ... })
+```
+
+## `createBundleRenderer(bundle[, options])`
+
+Create a [`BundleRenderer`](#class-bundlerenderer) instance with a server bundle and (optional) [options](#renderer-options).
+
+``` js
+const { createBundleRenderer } = require('vue-server-renderer')
+const renderer = createBundleRenderer(serverBundle, { ... })
+```
+
+The `serverBundle` argument can be one of the following:
+
+- An absolute path to generated bundle file (`.js` or `.json`). Must start with `/` to be treated as a file path.
+
+- A bundle object generated by webpack + `vue-server-renderer/server-plugin`.
+
+- A string of JavaScript code (not recommended).
+
+See [Introducing the Server Bundle](./bundle-renderer.md) and [Build Configuration](./build-config.md) for more details.
+
+## `Class: Renderer`
+
+- #### `renderer.renderToString(vm[, context], callback)`
+
+  Render a Vue instance to string. The context object is optional. The callback is a typical Node.js style callback where the first argument is the error and the second argument is the rendered string.
+
+- #### `renderer.renderToStream(vm[, context])`
+
+  Render a Vue instance to a Node.js stream. The context object is optional. See [Streaming](./streaming.md) for more details.
+
+## `Class: BundleRenderer`
+
+- #### `bundleRenderer.renderToString([context, ]callback)`
+
+  Render the bundle to a string. The context object is optional. The callback is a typical Node.js style callback where the first argument is the error and the second argument is the rendered string.
+
+- #### `bundleRenderer.renderToStream([context])`
+
+  Render the bundle to a Node.js stream. The context object is optional. See [Streaming](./streaming.md) for more details.
+
+## Renderer Options
+
+- #### `template`
+
+  Provide a template for the entire page's HTML. The template should contain a comment `<!--vue-ssr-outlet-->` which serves as the placeholder for rendered app content.
+
+  The template also supports basic interpolation using the render context:
+
+  - Use double-mustache for HTML-escaped interpolation;
+  - Use triple-mustache for non-HTML-escaped interpolation.
+
+  The template automatically injects appropriate content when certain data is found on the render context:
+
+  - `context.head`: (string) any head markup that should be injected into the head of the page.
+
+  - `context.styles`: (string) any inline CSS that should be injected into the head of the page. Note this property will be automatically populated if using `vue-loader` + `vue-style-loader` for component CSS.
+
+  - `context.state`: (Object) initial Vuex store state that should be inlined in the page as `window.__INITIAL_STATE__`. The inlined JSON is automatically sanitized with [serialize-javascript](https://github.com/yahoo/serialize-javascript) to prevent XSS.
+
+  In addition, when `clientManifest` is also provided, the template automatically injects the following:
+
+  - Client-side JavaScript and CSS assets needed by the render (with async chunks automatically inferred);
+  - Optimal `<link rel="preload/prefetch">` resource hints for the rendered page.
+
+  You can disable all automatic injections by also passing `inject: false` to the renderer.
+
+  See also:
+
+  - [Using a Page Template](./basic.md#using-a-page-template)
+  - [Manual Asset Injection](./build-config.md#manual-asset-injection)
+
+- #### `clientManifest`
+
+  - 2.3.0+
+  - only used in `createBundleRenderer`
+
+  Provide a client build manifest object generated by `vue-server-renderer/server-plugin`. The client manifest provides the bundle renderer with the proper information for automatic asset injection into the HTML template. For more details, see [Generating clientManifest](./build-config.md#generating-clientmanifest).
+
+- #### `inject`
+
+  - 2.3.0+
+
+  Controls whether to perform automatic injections when using `template`. Defaults to `true`.
+
+  See also: [Manual Asset Injection](./build-config.md#manual-asset-injection).
+
+- #### `shouldPreload`
+
+  - 2.3.0+
+
+  A function to control what files should have `<link rel="preload">` resource hints generated.
+
+  By default, only JavaScript and CSS files will be preloaded, as they are absolutely needed for your application to boot.
+
+  For other types of assets such as images or fonts, preloading too much may waste bandwidth and even hurt performance, so what to preload will be scenario-dependent. You can control precisely what to preload using the `shouldPreload` option:
+
+  ``` js
+  const renderer = createBundleRenderer(bundle, {
+    template,
+    clientManifest,
+    shouldPreload: (file, type) => {
+      // type is inferred based on the file extension.
+      // https://fetch.spec.whatwg.org/#concept-request-destination
+      if (type === 'script' || type === 'style') {
+        return true
+      }
+      if (type === 'font') {
+        // only preload woff2 fonts
+        return /\.woff2$/.test(file)
+      }
+      if (type === 'image') {
+        // only preload important images
+        return file === 'hero.jpg'
+      }
+    }
+  })
+  ```
+
+- #### `runInNewContext`
+
+  - 2.3.0+
+  - only used in `createBundleRenderer`
+
+  By default, for each render the bundle renderer will create a fresh V8 context and re-execute the entire bundle. This has some benefits - for example, we don't need to worry about the "stateful singleton" problem we mentioned earlier. However, this mode comes at some considerable performance cost because re-executing the bundle is expensive especially when the app gets bigger.
+
+  This option defaults to `true` for backwards compatibility, but it is recommended to use `runInNewContext: false` whenever you can.
+
+  See also: [Source Code Structure](./structure.md)
+
+- #### `basedir`
+
+  - 2.2.0+
+  - only used in `createBundleRenderer`
+
+  Explicitly declare the base directory for the server bundle to resolve `node_modules` dependencies from. This is only needed if your generated bundle file is placed in a different location from where the externalized NPM dependencies are installed, or your `vue-server-renderer` is npm-linked into your current project.
+
+- #### `cache`
+
+  Provide a [component cache](./caching.md#component-level-caching) implementation. The cache object must implement the following interface (using Flow notations):
+
+  ``` js
+  type RenderCache = {
+    get: (key: string, cb?: Function) => string | void;
+    set: (key: string, val: string) => void;
+    has?: (key: string, cb?: Function) => boolean | void;
+  };
+  ```
+
+  A typical usage is passing in an [lru-cache](https://github.com/isaacs/node-lru-cache):
+
+  ``` js
+  const LRU = require('lru-cache')
+
+  const renderer = createRenderer({
+    cache: LRU({
+      max: 10000
+    })
+  })
+  ```
+
+  Note that the cache object should at least implement `get` and `set`. In addition, `get` and `has` can be optionally async if they accept a second argument as callback. This allows the cache to make use of async APIs, e.g. a redis client:
+
+  ``` js
+  const renderer = createRenderer({
+    cache: {
+      get: (key, cb) => {
+        redisClient.get(key, (err, res) => {
+          // handle error if any
+          cb(res)
+        })
+      },
+      set: (key, val) => {
+        redisClient.set(key, val)
+      }
+    }
+  })
+  ```
+
+- #### `directives`
+
+  Allows you to provide server-side implementations for your custom directives:
+
+  ``` js
+  const renderer = createRenderer({
+    directives: {
+      example (vnode, directiveMeta) {
+        // transform vnode based on directive binding metadata
+      }
+    }
+  })
+  ```
+
+  As an example, check out [`v-show`'s server-side implementation](https://github.com/vuejs/vue/blob/dev/src/platforms/web/server/directives/show.js).
+
+## Webpack Plugins
+
+The webpack plugins are provided as standalone files and should be required directly:
+
+``` js
+const VueSSRServerPlugin = require('vue-server-renderer/server-plugin')
+const VueSSRClientPlugin = require('vue-server-renderer/client-plugin')
+```
+
+The default files generated are:
+
+- `vue-ssr-server-bundle.json` for the server plugin;
+- `vue-ssr-client-manifest.json` for the client plugin.
+
+The filenames can be customized when creating the plugin instances:
+
+``` js
+const plugin = new VueSSRServerPlugin({
+  filename: 'my-server-bundle.json'
+})
+```
+
+See [Build Configuration](./build-config.md) for more information.
diff --git a/ru/basic.md b/ru/basic.md
new file mode 100644
index 00000000..bc50f593
--- /dev/null
+++ b/ru/basic.md
@@ -0,0 +1,147 @@
+# Basic Usage
+
+## Installation
+
+``` bash
+npm install vue vue-server-renderer --save
+```
+
+We will be using NPM throughout the guide, but feel free to use [Yarn](https://yarnpkg.com/en/) instead.
+
+#### Notes
+
+- It's recommended to use Node.js version 6+.
+- `vue-server-renderer` and `vue` must have matching versions.
+- `vue-server-renderer` relies on some Node.js native modules and therefore can only be used in Node.js. We may provide a simpler build that can be run in other JavaScript runtimes in the future.
+
+## Rendering a Vue Instance
+
+``` js
+// Step 1: Create a Vue instance
+const Vue = require('vue')
+const app = new Vue({
+  template: `<div>Hello World</div>`
+})
+
+// Step 2: Create a renderer
+const renderer = require('vue-server-renderer').createRenderer()
+
+// Step 3: Render the Vue instance to HTML
+renderer.renderToString(app, (err, html) => {
+  if (err) throw err
+  console.log(html)
+  // => <div data-server-rendered="true">hello world</div>
+})
+```
+
+## Integrating with a Server
+
+It is pretty straightforward when used inside a Node.js server, for example [Express](https://expressjs.com/):
+
+``` bash
+npm install express --save
+```
+---
+``` js
+const Vue = require('vue')
+const server = require('express')()
+const renderer = require('vue-server-renderer').createRenderer()
+
+server.get('*', (req, res) => {
+  const app = new Vue({
+    data: {
+      url: req.url
+    },
+    template: `<div>The visited URL is: {{ url }}</div>`
+  })
+
+  renderer.renderToString(app, (err, html) => {
+    if (err) {
+      res.status(500).end('Internal Server Error')
+      return
+    }
+    res.end(`
+      <!DOCTYPE html>
+      <html lang="en">
+        <head><title>Hello</title></head>
+        <body>${html}</body>
+      </html>
+    `)
+  })
+})
+
+server.listen(8080)
+```
+
+## Using a Page Template
+
+When you render a Vue app, the renderer only generates the markup of the app. In the example we had to wrap the output with an extra HTML page shell.
+
+To simplify this, you can directly provide a page template when creating the renderer. Most of the time we will put the page template in its own file, e.g. `index.template.html`:
+
+``` html
+<!DOCTYPE html>
+<html lang="en">
+  <head><title>Hello</title></head>
+  <body>
+    <!--vue-ssr-outlet-->
+  </body>
+</html>
+```
+
+Notice the `<!--vue-ssr-outlet-->` comment -- this is where your app's markup will be injected.
+
+We can then read and pass the file to the Vue renderer:
+
+``` js
+const renderer = createRenderer({
+  template: require('fs').readFileSync('./index.template.html', 'utf-8')
+})
+
+renderer.renderToString(app, (err, html) => {
+  console.log(html) // will be the full page with app content injected.
+})
+```
+
+### Template Interpolation
+
+The template also supports simple interpolation. Given the following template:
+
+``` html
+<html>
+  <head>
+    <title>{{ title }}</title>
+    {{{ meta }}}
+  </head>
+  <body>
+    <!--vue-ssr-outlet-->
+  </body>
+</html>
+```
+
+We can provide interpolation data by passing a "render context object" as the second argument to `renderToString`:
+
+``` js
+const context = {
+  title: 'hello',
+  meta: `
+    <meta ...>
+    <meta ...>
+  `
+}
+
+renderer.renderToString(app, context, (err, html) => {
+  // page title will be "hello"
+  // with meta tags injected
+})
+```
+
+The `context` object can also be shared with the Vue app instance, allowing components to dynamically register data for template interpolation.
+
+In addition, the template supports some advanced features such as:
+
+- Auto injection of critical CSS when using `*.vue` components;
+- Auto injection of asset links and resource hints when using `clientManifest`;
+- Auto injection and XSS prevention when embedding Vuex state for client-side hydration.
+
+We will discuss these when we introduce the associated concepts later in the guide.
diff --git a/ru/build-config.md b/ru/build-config.md
new file mode 100644
index 00000000..d857c107
--- /dev/null
+++ b/ru/build-config.md
@@ -0,0 +1,209 @@
+# Build Configuration
+
+We will assume you already know how to configure webpack for a client-only project. The config for an SSR project will be largely similar, but we suggest breaking the config into three files: *base*, *client* and *server*. The base config contains config shared for both environments, such as output path, aliases, and loaders. The server config and client config can simply extend the base config using [webpack-merge](https://github.com/survivejs/webpack-merge).
+
+## Server Config
+
+The server config is meant for generating the server bundle that will be passed to `createBundleRenderer`. It should look like this:
+
+``` js
+const merge = require('webpack-merge')
+const nodeExternals = require('webpack-node-externals')
+const baseConfig = require('./webpack.base.config.js')
+const VueSSRServerPlugin = require('vue-server-renderer/server-plugin')
+
+module.exports = merge(baseConfig, {
+  // Point entry to your app's server entry file
+  entry: '/path/to/entry-server.js',
+
+  // This allows webpack to handle dynamic imports in a Node-appropriate
+  // fashion, and also tells `vue-loader` to emit server-oriented code when
+  // compiling Vue components.
+  target: 'node',
+
+  // For bundle renderer source map support
+  devtool: 'source-map',
+
+  // This tells the server bundle to use Node-style exports
+  output: {
+    libraryTarget: 'commonjs2'
+  },
+
+  // https://webpack.js.org/configuration/externals/#function
+  // https://github.com/liady/webpack-node-externals
+  // Externalize app dependencies. This makes the server build much faster
+  // and generates a smaller bundle file.
+  externals: nodeExternals({
+    // do not externalize dependencies that need to be processed by webpack.
+    // you can add more file types here e.g. raw *.vue files
+    whitelist: /\.css$/
+  }),
+
+  // This is the plugin that turns the entire output of the server build
+  // into a single JSON file. The default file name will be
+  // `vue-ssr-server-bundle.json`
+  plugins: [
+    new VueSSRServerPlugin()
+  ]
+})
+```
+
+After `vue-ssr-server-bundle.json` has been generated, simply pass the file path to `createBundleRenderer`:
+
+``` js
+const { createBundleRenderer } = require('vue-server-renderer')
+const renderer = createBundleRenderer('/path/to/vue-ssr-server-bundle.json', {
+  // ...other renderer options
+})
+```
+
+Alternatively, you can also pass the bundle as an Object to `createBundleRenderer`. This is useful for hot-reload during development - see the HackerNews demo for a [reference setup](https://github.com/vuejs/vue-hackernews-2.0/blob/master/build/setup-dev-server.js).
+
+## Client Config
+
+The client config can remain largely the same with the base config. Obviously you need to point `entry` to your client entry file. Aside from that, if you are using `CommonsChunkPlugin`, make sure to use it only in the client config because the server bundle requires a single entry chunk.
+
+### Generating `clientManifest`
+
+> requires version 2.3.0+
+
+In addition to the server bundle, we can also generate a client build manifest. With the client manifest and the server bundle, the renderer now has information of both the server *and* client builds, so it can automatically infer and inject [preload / prefetch directives](https://css-tricks.com/prefetching-preloading-prebrowsing/) and css links / script tags into the rendered HTML.
+
+The benefits is two-fold:
+
+1. It can replace `html-webpack-plugin` for injecting the correct asset URLs when there are hashes in your generated filenames.
+
+2. When rendering a bundle that leverages webpack's on-demand code splitting features, we can ensure the optimal chunks are preloaded / prefetched, and also intelligently inject `<script>` tags for needed async chunks to avoid waterfall requests on the client, thus improving TTI (time-to-interactive).
+
+To make use of the client manifest, the client config would look something like this:
+
+``` js
+const webpack = require('webpack')
+const merge = require('webpack-merge')
+const baseConfig = require('./webpack.base.config.js')
+const VueSSRClientPlugin = require('vue-server-renderer/client-plugin')
+
+module.exports = merge(baseConfig, {
+  entry: '/path/to/entry-client.js',
+  plugins: [
+    // Important: this splits the webpack runtime into a leading chunk
+    // so that async chunks can be injected right after it.
+    // this also enables better caching for your app/vendor code.
+    new webpack.optimize.CommonsChunkPlugin({
+      name: "manifest",
+      minChunks: Infinity
+    }),
+    // This plugins generates `vue-ssr-client-manifest.json` in the
+    // output directory.
+    new VueSSRClientPlugin()
+  ]
+})
+```
+
+You can then use the generated client manifest, together with a page template:
+
+``` js
+const { createBundleRenderer } = require('vue-server-renderer')
+
+const template = require('fs').readFileSync('/path/to/template.html', 'utf-8')
+const serverBundle = require('/path/to/vue-ssr-server-bundle.json')
+const clientManifest = require('/path/to/vue-ssr-client-manifest.json')
+
+const renderer = createBundleRenderer(serverBundle, {
+  template,
+  clientManifest
+})
+```
+
+With this setup, your server-rendered HTML for a build with code-splitting will look something like this (everything auto-injected):
+
+``` html
+<html>
+  <head>
+    <!-- chunks used for this render will be preloaded -->
+    <link rel="preload" href="/manifest.js" as="script">
+    <link rel="preload" href="/main.js" as="script">
+    <link rel="preload" href="/0.js" as="script">
+    <!-- unused async chunks will be prefetched (lower priority) -->
+    <link rel="prefetch" href="/1.js" as="script">
+  </head>
+  <body>
+    <!-- app content -->
+    <div data-server-rendered="true"><div>async</div></div>
+    <!-- manifest chunk should be first -->
+    <script src="/manifest.js"></script>
+    <!-- async chunks injected before main chunk -->
+    <script src="/0.js"></script>
+    <script src="/main.js"></script>
+  </body>
+</html>`
+```
+
+### Manual Asset Injection
+
+By default, asset injection is automatic when you provide the `template` render option. But sometimes you might want finer-grained control over how assets are injected into the template, or maybe you are not using a template at all. In such a case, you can pass `inject: false` when creating the renderer and manually perform asset injection.
+
+In the `renderToString` callback, the `context` object you passed in will expose the following methods:
+
+- `context.renderStyles()`
+
+  This will return inline `<style>` tags containing all the critical CSS collected from the `*.vue` components used during the render. See [CSS Management](./css.md) for more details.
+
+  If a `clientManifest` is provided, the returned string will also contain `<link rel="stylesheet">` tags for webpack-emitted CSS files (e.g. CSS extracted with `extract-text-webpack-plugin` or imported with `file-loader`)
+
+- `context.renderState(options?: Object)`
+
+  This method serializes `context.state` and returns an inline script that embeds the state as `window.__INITIAL_STATE__`.
+
+  The context state key and window state key can both be customized by passing an options object:
+
+  ``` js
+  context.renderState({
+    contextKey: 'myCustomState',
+    windowKey: '__MY_STATE__'
+  })
+
+  // -> <script>window.__MY_STATE__={...}</script>
+  ```
+
+- `context.renderScripts()`
+
+  - requires `clientManifest`
+
+  This method returns the `<script>` tags needed for the client application to boot. When using async code-splitting in the app code, this method will intelligently infer the correct async chunks to include.
+
+- `context.renderResourceHints()`
+
+  - requires `clientManifest`
+
+  This method returns the `<link rel="preload/prefetch">` resource hints needed for the current rendered page. By default it will:
+
+  - Preload the JavaScript and CSS files needed by the page
+  - Prefetch async JavaScript chunks that might be needed later
+
+  Preloaded files can be further customized with the [`shouldPreload`](./api.md#shouldpreload) option.
+
+- `context.getPreloadFiles()`
+
+  - requires `clientManifest`
+
+  This method does not return a string - instead, it returns an Array of file objects representing the assets that should be preloaded. This can be used to programmatically perform HTTP/2 server push.
+
+Since the `template` passed to `createBundleRenderer` will be interpolated using `context`, you can make use of these methods inside the template (with `inject: false`):
+
+``` html
+<html>
+  <head>
+    <!-- use triple mustache for non-HTML-escaped interpolation -->
+    {{{ renderResourceHints() }}}
+    {{{ renderStyles() }}}
+  </head>
+  <body>
+    <!--vue-ssr-outlet-->
+    {{{ renderState() }}}
+    {{{ renderScripts() }}}
+  </body>
+</html>
+```
+
+If you are not using `template` at all, you can concatenate the strings yourself.
diff --git a/ru/bundle-renderer.md b/ru/bundle-renderer.md
new file mode 100644
index 00000000..2be30fe9
--- /dev/null
+++ b/ru/bundle-renderer.md
@@ -0,0 +1,58 @@
+# Introducing Bundle Renderer
+
+## Problems with Basic SSR
+
+Up to this point, we have assumed that the bundled server-side code will be directly used by the server via `require`:
+
+``` js
+const createApp = require('/path/to/built-server-bundle.js')
+```
+
+This is straightforward, however whenever you edit your app source code, you would have to stop and restart the server. This hurts productivity quite a bit during development. In addition, Node.js doesn't support source maps natively.
+
+## Enter BundleRenderer
+
+`vue-server-renderer` provides an API called `createBundleRenderer` to deal with this problem. With a custom webpack plugin, the server bundle is generated as a special JSON file that can be passed to the bundle renderer. Once the bundle renderer is created, usage is the same as the normal renderer, however the bundle renderer provides the following benefits:
+
+- Built-in source map support (with `devtool: 'source-map'` in webpack config)
+
+- Hot-reload during development and even deployment (by simply reading the updated bundle and re-creating the renderer instance)
+
+- Critical CSS injection (when using `*.vue` files): automatically inlines the CSS needed by components used during the render. See the [CSS](./css.md) section for more details.
+
+- Asset injection with [clientManifest](./client-manifest.md): automatically infers the optimal preload and prefetch directives, and the code-split chunks needed for the initial render.
+
+---
+
+We will discuss how to configure webpack to generate the build artifacts needed by the bundle renderer in the next section, but for now let's assume we already have what we need, and this is how to create a use a bundle renderer:
+
+``` js
+const { createBundleRenderer } = require('vue-server-renderer')
+
+const renderer = createBundleRenderer(serverBundle, {
+  runInNewContext: false, // recommended
+  template, // (optinal) page template
+  clientManifest // (optional) client build manifest
+})
+
+// inside a server handler...
+server.get('*', (req, res) => {
+  const context = { url: req.url }
+  // No need to pass an app here because it is auto-created by the
+  // executing the bundle. Now our server is decoupled from our Vue app!
+  renderer.renderToString(context, (err, html) => {
+    // handle error...
+    res.end(html)
+  })
+})
+```
+
+When `rendertoString` is called on a bundle renderer, it will automatically execute the function exported by the bundle to create an app instance (passing `context` as the argument) , and then render it.
+
+---
+
+### The `runInNewContext` Option
+
+By default, for each render the bundle renderer will create a fresh V8 context and re-execute the entire bundle. This has some benefits - for example, we don't need to worry about the "stateful singleton" problem we mentioned earlier. However, this mode comes at some considerable performance cost because re-executing the bundle is expensive especially when the app gets bigger.
+
+In `vue-server-renderer >= 2.3.0`, this option still defaults to `true` for backwards compatibility, but it is recommended to use `runInNewContext: false` whenever you can.
diff --git a/ru/caching.md b/ru/caching.md
new file mode 100644
index 00000000..5568a032
--- /dev/null
+++ b/ru/caching.md
@@ -0,0 +1,87 @@
+# Caching
+
+Although Vue's SSR is quite fast, it can't match the performance of pure string-based templating due to the cost of creating component instances and Virtual DOM nodes. In cases where SSR performance is critical, wisely leveraging caching strategies can greatly improve response time and reduce server load.
+
+## Page-level Caching
+
+A server-rendered app in most cases relies on external data, so the content is dynamic by nature and cannot be cached for extended periods. However, if the content is not user-specific (i.e. for the same URL it always renders the same content for all users), we can leverage a strategy called [micro-caching](https://www.nginx.com/blog/benefits-of-microcaching-nginx/) to drastically improve our app's capability of handling high traffic.
+
+This is usually done at the Nginx layer, but we can also implement it in Node.js:
+
+``` js
+const microCache = LRU({
+  max: 100,
+  maxAge: 1000 // Important: entries expires after 1 second.
+})
+
+const isCacheable = req => {
+  // implement logic to check if the request is user-specific.
+  // only non-user-specific pages are cache-able
+}
+
+server.get('*', (req, res) => {
+  const cacheable = isCacheable(req)
+  if (cacheable) {
+    const hit = microCache.get(req.url)
+    if (hit) {
+      return res.end(hit)
+    }
+  }
+
+  renderer.renderToString((err, html) => {
+    res.end(html)
+    if (cacheable) {
+      microCache.set(req.url, html)
+    }
+  })
+})
+```
+
+Since the content is cached for only one second, users will not see outdated content. However, this means the server only has to perform at most one full render per second for each cached page.
+
+## Component-level Caching
+
+`vue-server-renderer` has built-in support for component-level caching. To enable it you need to provide a [cache implementation](./api.md#cache) when creating the renderer. Typical usage is passing in an [lru-cache](https://github.com/isaacs/node-lru-cache):
+
+``` js
+const LRU = require('lru-cache')
+
+const renderer = createRenderer({
+  cache: LRU({
+    max: 10000,
+    maxAge: ...
+  })
+})
+```
+
+You can then cache a component by implementing a `serverCacheKey` function:
+
+``` js
+export default {
+  name: 'item', // required
+  props: ['item'],
+  serverCacheKey: props => props.item.id,
+  render (h) {
+    return h('div', this.item.id)
+  }
+}
+```
+
+Note that cache-able component **must also define a unique "name" option**. With a unique name, the cache key is thus per-component: you don't need to worry about two components returning the same key.
+
+The key returned from `serverCacheKey` should contain sufficient information to represent the shape of the render result. The above is a good implementation if the render result is solely determined by `props.item.id`. However, if the item with the same id may change over time, or if render result also relies on another prop, then you need to modify your `getCacheKey` implementation to take those other variables into account.
+
+Returning a constant will cause the component to always be cached, which is good for purely static components.
+
+### When to use component caching
+
+If the renderer hits a cache for a component during render, it will directly reuse the cached result for the entire sub tree. This means you should **NOT** cache a component when:
+
+- It has child components that may rely on global state.
+- It has child components that produces side effects on the render `context`.
+
+Component caching should therefore be applied carefully to address performance bottlenecks. In most cases, you shouldn't and don't need to cache single-instance components. The most common type of components that are suitable for caching are ones repeated in big `v-for` lists. Since these components are usually driven by objects in database collections, they can make use of a simple caching strategy: generate their cache keys using their unique id plus the last updated timestamp:
+
+``` js
+serverCacheKey: props => props.item.id + '::' + props.item.last_updated
+```
diff --git a/ru/css.md b/ru/css.md
new file mode 100644
index 00000000..7d6e846d
--- /dev/null
+++ b/ru/css.md
@@ -0,0 +1,114 @@
+# CSS Management
+
+The recommended way to manage CSS is to simply use `<style>` inside `*.vue` single file components, which offers:
+
+- Collocated, component-scoped CSS
+- Ability to leverage pre-processors or PostCSS
+- Hot-reload during development
+
+More importantly, `vue-style-loader`, the loader used internally by `vue-loader`, has some special features for server rendering:
+
+- Universal authoring experience for client and server.
+
+- Automatic critical CSS when using `bundleRenderer`.
+
+  If used during a server render, a component's CSS can be collected and inlined in the HTML (automatically handled when using `template` option). On the client, when the component is used for the first time, `vue-style-loader` will check if there is already server-inlined CSS for this component - if not, the CSS will be dynamically injected via a `<style>` tag.
+
+- Common CSS Extraction.
+
+  This setup support using [`extract-text-webpack-plugin`](https://github.com/webpack-contrib/extract-text-webpack-plugin) to extract the CSS in the main chunk into a separate CSS file (auto injected with `template`), which allows the file to be individually cached. This is recommended when there is a lot of shared CSS.
+
+  CSS inside async components will remain inlined as JavaScript strings and handled by `vue-style-loader`.
+
+## Enabling CSS Extraction
+
+To extract CSS from `*.vue` files, use `vue-loader`'s `extractCSS` option (requires `vue-loader>=12.0.0`):
+
+``` js
+// webpack.config.js
+const ExtractTextPlugin = require('extract-text-webpack-plugin')
+
+// CSS extraction should only be enabled for production
+// so that we still get hot-reload during development.
+const isProduction = process.env.NODE_ENV === 'production'
+
+module.exports = {
+  // ...
+  module: {
+    rules: [
+      {
+        test: /\.vue$/,
+        loader: 'vue-loader',
+        options: {
+          // enable CSS extraction
+          extractCSS: isProduction
+        }
+      },
+      // ...
+    ]
+  },
+  plugins: isProduction
+    // make sure to add the plugin!
+    ? [new ExtractTextPlugin({ filename: 'common.[chunkhash].css' })]
+    : []
+}
+```
+
+Note that the above config only applies to styles in `*.vue` files, but you can use `<style src="./foo.css">` to import external CSS into Vue components.
+
+If you wish to import CSS from JavaScript, e.g. `import 'foo.css'`, you need to configure the appropriate loaders:
+
+``` js
+module.exports = {
+  // ...
+  module: {
+    rules: [
+      {
+        test: /\.css$/,
+        // important: use vue-style-loader instead of style-loader
+        use: isProduction
+          ? ExtractTextPlugin.extract({
+              use: 'css-loader',
+              fallback: 'vue-style-loader'
+            })
+          : ['vue-style-loader', 'css-loader']
+      }
+    ]
+  },
+  // ...
+}
+```
+
+## Importing Styles from Dependencies
+
+A few things to take note when importing CSS from an NPM dependency:
+
+1. It should not be externalized in the server build.
+
+2. If using CSS extraction + vendor extracting with `CommonsChunkPlugin`, `extract-text-webpack-plugin` will run into problems if the extracted CSS in inside an extracted vendors chunk. To work around this, avoid including CSS files in the vendor chunk. An example client webpack config:
+
+  ``` js
+  module.exports = {
+    // ...
+    plugins: [
+      // it is common to extract deps into a vendor chunk for better caching.
+      new webpack.optimize.CommonsChunkPlugin({
+        name: 'vendor',
+        minChunks: function (module) {
+          // a module is extracted into the vendor chunk when...
+          return (
+            // if it's inside node_modules
+            /node_modules/.test(module.context) &&
+            // do not externalize if the request is a CSS file
+            !/\.css$/.test(module.request)
+          )
+        }
+      }),
+      // extract webpack runtime & manifest
+      new webpack.optimize.CommonsChunkPlugin({
+        name: 'manifest'
+      }),
+      // ...
+    ]
+  }
+  ```
diff --git a/ru/data.md b/ru/data.md
new file mode 100644
index 00000000..7d41bd38
--- /dev/null
+++ b/ru/data.md
@@ -0,0 +1,259 @@
+# Data Pre-Fetching and State
+
+## Data Store
+
+During SSR, we are essentially rendering a "snapshot" of our app, so if the app relies on some asynchronous data, **these data need to be pre-fetched and resolved before we start the rendering process**.
+
+Another concern is that on the client, the same data needs to be available before we mount the client side app - otherwise the client app would render using different state and the hydration would fail.
+
+To address this, the fetched data needs to live outside the view components, in a dedicated data store, or a "state container". On the server, we can pre-fetch and fill data into the store before rendering. In addition, we will serialize and inline the state in the HTML. The client-side store can directly pick up the inlined state before we mount the app.
+
+We will be using the official state management library [Vuex](https://github.com/vuejs/vuex/) for this purpose. Let's create a `store.js` file, with some mocked logic for fetching an item based on an id:
+
+``` js
+// store.js
+import Vue from 'vue'
+import Vuex from 'vuex'
+
+Vue.use(Vuex)
+
+// Assume we have a universal API that returns Promises
+// and ignore the implementation details
+import { fetchItem } from './api'
+
+export function createStore () {
+  return new Vuex.Store({
+    state: {
+      items: {}
+    },
+    actions: {
+      fetchItem ({ commit }, id) {
+        // return the Promise via store.dispatch() so that we know
+        // when the data has been fetched
+        return fetchItem(id).then(item => {
+          commit('setItem', { id, item })
+        })
+      }
+    },
+    mutations: {
+      setItem (state, { id, item }) {
+        Vue.set(state.items, id, item)
+      }
+    }
+  })
+}
+```
+
+And update `app.js`:
+
+``` js
+// app.js
+import Vue from 'vue'
+import App from './App.vue'
+import { createRouter } from './router'
+import { createStore } from './store'
+import { sync } from 'vuex-router-sync'
+
+export function createApp () {
+  // create router and store instances
+  const router = createRouter()
+  const store = createStore()
+
+  // sync so that route state is available as part of the store
+  sync(store, router)
+
+  // create the app instance, injecting both the router and the store
+  const app = new Vue({
+    router,
+    store,
+    render: h => h(App)
+  })
+
+  // expose the app, the router and the store.
+  return { app, router, store }
+}
+```
+
+## Logic Collocation with Components
+
+So, where do we place the code that dispatches the data-fetching actions?
+
+The data we need to fetch is determined by the route visited - which also determines what components are rendered. In fact, the data needed for a given route is also the data needed by the components rendered at that route. So it would be natural to place the data fetching logic inside route components.
+
+We will expose a custom static function `asyncData` on our route components. Note because this function will be called before the components are instantiated, it doesn't have access to `this`. The store and route information needs to be passed in as arguments:
+
+``` html
+<!-- Item.vue -->
+<template>
+  <div>{{ item.title }}</div>
+</template>
+
+<script>
+export default {
+  asyncData ({ store, route }) {
+    // return the Promise from the action
+    return store.dispatch('fetchItem', route.params.id)
+  },
+
+  computed: {
+    // display the item from store state.
+    items () {
+      return this.$store.state.items[this.$route.params.id]
+    }
+  }
+}
+</script>
+```
+
+## Server Data Fetching
+
+In `entry-server.js` we can get the components matched by a route with `router.getMatchedComponents()`, and call `asyncData` if the component exposes it. Then we need to attach resolved state to the render context.
+
+``` js
+// entry-server.js
+import { createApp } from './app'
+
+export default context => {
+  return new Promise((resolve, reject) => {
+    const { app, router, store } = createApp()
+
+    router.push(context.url)
+
+    router.onReady(() => {
+      const matchedComponents = router.getMatchedComponents()
+      if (!matchedComponents.length) {
+        reject({ code: 404 })
+      }
+
+      // call asyncData() on all matched route components
+      Promise.all(matchedComponents.map(Component => {
+        if (Component.asyncData) {
+          return Component.asyncData({
+            store,
+            route: router.currentRoute
+          })
+        }
+      })).then(() => {
+        // After all preFetch hooks are resolved, our store is now
+        // filled with the state needed to render the app.
+        // When we attach the state to the context, and the `template` option
+        // is used for the renderer, the state will automatically be
+        // serialized and injected into the HTML as window.__INITIAL_STATE__.
+        context.state = store.state
+
+        resolve(app)
+      }).catch(reject)
+    }, reject)
+  })
+}
+```
+
+When using `template`, `context.state` will automatically be embedded in the final HTML as `window.__INITIAL__` state. On the client, the store should pick up the state before mounting the application:
+
+``` js
+// entry-client.js
+
+const { app, router, store } = createApp()
+
+if (window.__INITIAL_STATE__) {
+  store.replaceState(window.__INITIAL_STATE__)
+}
+```
+
+## Client Data Fetching
+
+On the client, there are two different approaches for handling data fetching:
+
+1. **Resolve data before route navigation:**
+
+  With this strategy, the app will stay on the current view until the data needed by the incoming view has been resolved. The benefit is that the incoming view can directly render the full content when it's ready, but if the data fetching takes a long time, the user will feel "stuck" on the current view. It is therefore recommended to provide a data loading indicator if using this strategy.
+
+  We can implement this strategy on the client by checking matched components and invoking their `asyncData` function inside a global route hook. Note we should register this hook after the initial route is ready so that we don't unnecessarily fetch the server-fetched data again.
+
+  ``` js
+  // entry-client.js
+
+  // ...omitting unrelated code
+
+  router.onReady(() => {
+    // Add router hook for handling asyncData.
+    // Doing it after initial route is resolved so that we don't double-fetch
+    // the data that we already have. Using router.beforeResolve() so that all
+    // async components are resolved.
+    router.beforeResolve((to, from, next) => {
+      const matched = router.getMatchedComponents(to)
+      const prevMatched = router.getMatchedComponents(from)
+
+      // we only care about none-previously-rendered components,
+      // so we compare them until the two matched lists differ
+      let diffed = false
+      const activated = matched.filter((c, i) => {
+        return diffed || (diffed = (prevMatched[i] !== c))
+      })
+
+      if (!activated.length) {
+        return next()
+      }
+
+      // this is where we should trigger a loading indicator if there is one
+
+      Promise.all(activated.map(c => {
+        if (c.asyncData) {
+          return c.asyncData({ store, route: to })
+        }
+      })).then(() => {
+
+        // stop loading indicator
+
+        next()
+      }).catch(next)
+    })
+
+    app.$mount('#app')
+  })
+  ```
+
+2. **Fetch data after the matched view is rendered:**
+
+  This strategy places the client-side data-fetching logic in a view component's `beforeMount` function. This allows the views to switch instantly when a route navigation is triggered, so the app feels a bit more responsive. However, the incoming view will not have the full data available when it's rendered. It is therefore necessary to have a conditional loading state for each view component that uses this strategy.
+
+  This can be achieved with a client-only global mixin:
+
+  ``` js
+  Vue.mixin({
+    beforeMount () {
+      const { asyncData } = this.$options
+      if (asyncData) {
+        // assign the fetch operation to a promise
+        // so that in components we can do `this.dataPromise.then(...)` to
+        // perform other tasks after data is ready
+        this.dataPromise = asyncData({
+          store: this.$store,
+          route: this.$route
+        })
+      }
+    }
+  })
+  ```
+
+The two strategies are ultimately different UX decisions and should be picked based on the actual scenario of the app you are building. But regardless of which strategy you pick, the `asyncData` function should also be called when a route component is reused (same route, but params or query changed. e.g. from `user/1` to `user/2`). We can also handle this with a client-only global mixin:
+
+``` js
+Vue.mixin({
+  beforeRouteUpdate (to, from, next) {
+    const { asyncData } = this.$options
+    if (asyncData) {
+      asyncData({
+        store: this.$store,
+        route: to
+      }).then(next).catch(next)
+    } else {
+      next()
+    }
+  }
+})
+```
+
+---
+
+Phew, that was a lot of code! This is because universal data-fetching is probably the most complex problem in a server-rendered app and we are laying the groundwork for easier further development. Once the boilerplate is set up, authoring individual components will be actually quite pleasant.
diff --git a/ru/head.md b/ru/head.md
new file mode 100644
index 00000000..864f824f
--- /dev/null
+++ b/ru/head.md
@@ -0,0 +1,108 @@
+# Head Management
+
+Similar to asset injection, head management follows the same idea: we can dynamically attach data to the render `context` in a component's lifecycle, and then interpolate those data in `template`.
+
+To do that we need to have access to the SSR context inside a nested component. We can simply pass the `context` to `createApp()` and expose it on the root instance's `$options`:
+
+``` js
+// app.js
+
+export function createApp (ssrContext) {
+  // ...
+  const app = new Vue({
+    router,
+    store,
+    // all child components can access this as this.$root.$options.ssrContext
+    ssrContext,
+    render: h => h(App)
+  })
+  // ...
+}
+```
+
+This can also be done via `provide/inject`, but since we know it's going to be on `$root`, we can avoid the injection resolution costs.
+
+With the context injected, we can write a simple mixin to perform title management:
+
+``` js
+// title-mixin.js
+
+function getTitle (vm) {
+  // components can simply provide a `title` option
+  // which can be either a string or a function
+  const { title } = vm.$options
+  if (title) {
+    return typeof title === 'function'
+      ? title.call(vm)
+      : title
+  }
+}
+
+const serverTitleMixin = {
+  created () {
+    const title = getTitle(this)
+    if (title) {
+      this.$root.$options.ssrContext.title = title
+    }
+  }
+}
+
+const clientTitleMixin = {
+  mounted () {
+    const title = getTitle(this)
+    if (title) {
+      document.title = title
+    }
+  }
+}
+
+// VUE_ENV can be injected with webpack.DefinePlugin
+export default process.env.VUE_ENV === 'server'
+  ? serverTitleMixin
+  : clientTitleMixin
+```
+
+Now, a route component can make use of this to control the document title:
+
+``` js
+// Item.vue
+export default {
+  mixins: [titleMixin],
+  title () {
+    return this.item.title
+  }
+
+  asyncData ({ store, route }) {
+    return store.dispatch('fetchItem', route.params.id)
+  },
+
+  computed: {
+    item () {
+      return this.$store.state.items[this.$route.params.id]
+    }
+  }
+}
+```
+
+And inside the `template` passed to bundle renderer:
+
+``` html
+<html>
+  <head>
+    <title>{{ title }}</title>
+  </head>
+  <body>
+    ...
+  </body>
+</html>
+```
+
+**Notes:**
+
+- Use double-mustache (HTML-escaped interpolation) to avoid XSS attacks.
+
+- You should provide a default title when creating the `context` object in case no component has set a title during render.
+
+---
+
+Using the same strategy, you can easily expand this mixin into a generic head management utility.
diff --git a/ru/hydration.md b/ru/hydration.md
new file mode 100644
index 00000000..6a11574f
--- /dev/null
+++ b/ru/hydration.md
@@ -0,0 +1,32 @@
+# Client Side Hydration
+
+In `entry-client.js`, we are simply mounting the app with this line:
+
+``` js
+// this assumes App.vue template root element has id="app"
+app.$mount('#app')
+```
+
+Since the server has already rendered the markup, we obviously do not want to throw that away and re-create all the DOM elements. Instead, we want to "hydrate" the static markup and make it interactive.
+
+If you inspect the server-rendered output, you will notice that the app's root element has a special attribute:
+
+``` js
+<div id="app" data-server-rendered="true">
+```
+
+The `data-server-rendered` special attribute lets the client-side Vue know that the markup is rendered by the server and it should mount in hydration mode.
+
+In development mode, Vue will assert the client-side generated virtual DOM tree matches the DOM structure rendered from the server. If there is a mismatch, it will bail hydration, discard existing DOM and render from scratch. **In production mode, this assertion is disabled for maximum performance.**
+
+### Hydration Caveats
+
+One thing to be aware of when using SSR + client hydration is some special HTML structures that may be altered by the browser. For example, when you write this in a Vue template:
+
+``` html
+<table>
+  <tr><td>hi</td></tr>
+</table>
+```
+
+The browser will automatically inject `<tbody>` inside `<table>`, however, the virtual DOM generated by Vue does not contain `<tbody>`, so it will cause a mismatch. To ensure correct matching, make sure to write valid HTML in your templates.
diff --git a/ru/routing.md b/ru/routing.md
new file mode 100644
index 00000000..4ccf64f9
--- /dev/null
+++ b/ru/routing.md
@@ -0,0 +1,153 @@
+# Routing and Code-Splitting
+
+## Routing with `vue-router`
+
+You may have noticed that our server code uses a `*` handler which accepts arbitrary URLs. This allows us to pass the visited URL into our Vue app, and reuse the same routing config for both client and server!
+
+It is recommended to use the official `vue-router` for this purpose. Let's first create a file where we create the router. Note similar to `createApp`, we also need a fresh router instance for each request, so the file exports a `createRouter` function:
+
+``` js
+// router.js
+import Vue from 'vue'
+import Router from 'vue-router'
+
+Vue.use(Router)
+
+export function createRouter () {
+  return new Router({
+    mode: 'history',
+    routes: [
+      // ...
+    ]
+  })
+}
+```
+
+And update `app.js`:
+
+``` js
+// app.js
+import Vue from 'vue'
+import App from './App.vue'
+import { createRouter } from './router'
+
+export function createApp () {
+  // create router instance
+  const router = createRouter()
+
+  const app new Vue({
+    // inject router into root Vue instance
+    router,
+    render: h => h(App)
+  })
+
+  // return both the app and the router
+  return { app, router }
+}
+```
+
+Now we need to implement the server-side routing logic in `entry-server.js`:
+
+``` js
+// entry-server.js
+import { createApp } from './app'
+
+export default context => {
+  // since there could potentially be asynchronous route hooks or components,
+  // we will be returning a Promise so that the server can wait until
+  // everything is ready before rendering.
+  return new Promise((resolve, reject) => {
+    const { app, router } = createApp()
+
+    // set server-side router's location
+    router.push(context.url)
+
+    // wait until router has resolved possible async components and hooks
+    router.onReady(() => {
+      const matchedComponents = router.getMatchedComponents()
+      // no matched routes, reject with 404
+      if (!matchedComponents.length) {
+        reject({ code: 404 })
+      }
+
+      // the Promise should resolve to the app instance so it can be rendered
+      resolve(app)
+    }, reject)
+  })
+}
+```
+
+Assuming the server bundle is already built (again, ignoring build setup for now), the server usage would look like this:
+
+``` js
+// server.js
+const createApp = require('/path/to/built-server-bundle.js')
+
+server.get('*', (req, res) => {
+  const context = { url: req.url }
+
+  createApp(context).then(app => {
+    renderer.renderToString(app, (err, html) => {
+      if (err) {
+        if (err.code === 404) {
+          res.status(404).end('Page not found')
+        } else {
+          res.status(500).end('Internal Server Error')
+        }
+      } else {
+        res.end(html)
+      }
+    })
+  })
+})
+```
+
+## Code-Splitting
+
+Code-splitting, or lazy-loading part of your app, helps reducing the amount of assets that need to be downloaded by the browser for the initial render, and can greatly improve TTI (time-to-interactive) for apps with large bundles. The key is "loading just what is needed" for the initial screen.
+
+Vue provides async components as a first-class concept, combining it with [webpack 2's support for using dynamic import as a code-split point](https://webpack.js.org/guides/code-splitting-async/), all you need to do is:
+
+``` js
+// changing this...
+import Foo from './Foo.vue'
+
+// to this:
+const Foo = () => import('./Foo.vue')
+```
+
+This would work under any scenario if you are building a pure client-side Vue app. However, there are some limitations when using this in SSR. First, you need to resolve all the async components upfront on the server before starting the render, because otherwise you will just get an empty placeholder in the markup. On the client, you also need to do this before starting the hydration, otherwise the client will run into content mismatch errors.
+
+This makes it a bit tricky to use async components at arbitrary locations in your app (we will likely improve this in the future). However, **it works seamlessly if you do it at the route level** - i.e. use async components in your route configuration - because `vue-router` will automatically resolve matched async components when resolving a route. What you need to do is make sure to use `router.onReady` on both server and client. We already did that in our server entry, and now we just need to update the client entry:
+
+``` js
+// entry-client.js
+
+import { createApp } from './app'
+
+const { app, router } = createApp()
+
+router.onReady(() => {
+  app.$mount('#app')
+})
+```
+
+An example route config with async route components:
+
+``` js
+// router.js
+import Vue from 'vue'
+import Router from 'vue-router'
+
+Vue.use(Router)
+
+export function createRouter () {
+  return new Router({
+    mode: 'history',
+    routes: [
+      { path: '/', component: () => import('./components/Home.vue') },
+      { path: '/item/:id', component: () => import('./components/Item.vue') }
+    ]
+  })
+}
+```
diff --git a/ru/streaming.md b/ru/streaming.md
new file mode 100644
index 00000000..cfcb3d81
--- /dev/null
+++ b/ru/streaming.md
@@ -0,0 +1,33 @@
+# Streaming
+
+`vue-server-renderer` supports stream rendering out of the box, for both the base renderer and the bundle renderer. All you need to do is use `renderToStream` instead of `renderToString`:
+
+``` js
+const stream = renderer.renderToStream(context)
+```
+
+The returned value is a [Node.js stream](https://nodejs.org/api/stream.html):
+
+``` js
+let html = ''
+
+stream.on('data', data => {
+  html += data.toString()
+})
+
+stream.on('end', () => {
+  console.log(html) // render complete
+})
+
+stream.on('error', err => {
+  // handle error...
+})
+```
+
+## Streaming Caveats
+
+In stream rendering mode, data is emitted as soon as possible when the renderer traverses the Virtual DOM tree. This means we can get an earlier "first chunk" and start sending it to the client faster.
+
+However, when the first data chunk is emitted, the child components may not even be instantiated yet, neither will their lifecycle hooks get called. This means if the child components need to attach data to the render context in their lifecycle hooks, these data will not be available when the stream starts. Since a lot of the context information (like head information or inlined critical CSS) needs to be appear before the application markup, we essentially have to wait until the stream to complete before we can start making use of these context data.
+
+It is therefore **NOT** recommended to use streaming mode if you rely on context data populated by component lifecycle hooks.
diff --git a/ru/structure.md b/ru/structure.md
new file mode 100644
index 00000000..930240fb
--- /dev/null
+++ b/ru/structure.md
@@ -0,0 +1,123 @@
+# Source Code Structure
+
+## Avoid Stateful Singletons
+
+When writing client-only code, we are used to the fact that our code will be evaluated in a fresh context every time. However, a Node.js server is a long-running process. When our code is required into the process, it will be evaluated once and stays in memory. This means if you create a singleton object, it will be shared between every incoming request.
+
+As seen in the basic example, we are **creating a new root Vue instance for each request.** This is similar to how each user will be using a fresh instance of the app in their own browser. If we use a shared instance across multiple requests, it will easily lead to cross-request state pollution.
+
+So, instead of directly creating an app instance, we should expose a factory function that can be repeatedly executed to create fresh app instances for each request:
+
+``` js
+// app.js
+const Vue = require('vue')
+
+module.exports = function createApp (context) {
+  return new Vue({
+    data: {
+      url: context.url
+    },
+    template: `<div>The visited URL is: {{ url }}</div>`
+  })
+}
+```
+
+And our server code now becomes:
+
+``` js
+// server.js
+const createApp = require('./app')
+
+server.get('*', (req, res) => {
+  const context = { url: req.url }
+  const app = createApp(context)
+
+  renderer.renderToString(app, (err, html) => {
+    // handle error...
+    res.end(html)
+  })
+})
+```
+
+The same rule applies to router, store and event bus instances as well. Instead of exporting it directly from a module and importing it across your app, you need to create a fresh instance in `createApp` and inject it from the root Vue instance.
+
+> This constraint can be eliminated when using the bundle renderer with `{ runInNewContext: true }`, however it comes with some significant performance cost because a new vm context needs to be created for each request.
+
+## Introducing a Build Step
+
+So far, we haven't discussed how to deliver the same Vue app to the client yet. To do that, we need to use webpack to bundle our Vue app. In fact, we probably want to use webpack to bundle the Vue app on the server as well, because:
+
+- Typical Vue apps are built with webpack and `vue-loader`, and many webpack-specific features such as importing files via `file-loader`, importing CSS via `css-loader` would not work directly in Node.js.
+
+- Although the latest version of Node.js fully supports ES2015 features, we still need to transpile client-side code to cater to older browsers. This again involves a build step.
+
+So the basic idea is we will be using webpack to bundle our app for both client and server - the server bundle will be required by the server and used for SSR, while the client bundle is sent to the browser to hydrate the static markup.
+
+![architecture](https://cloud.githubusercontent.com/assets/499550/17607895/786a415a-5fee-11e6-9c11-45a2cfdf085c.png)
+
+We will discuss the details of the setup in later sections - for now, let's just assume we've got the build setup figured out and we can write our Vue app code with webpack enabled.
+
+## Code Structure with Webpack
+
+Now that we are using webpack to process the app for both server and client, the majority of our source code can be written in a universal fashion, with access to all the webpack-powered features. At the same time, there are [a number of things](./universal.md) you should keep in mind when writing universal code.
+
+A simple project would look like this:
+
+``` bash
+src
+├── components
+│   ├── Foo.vue
+│   ├── Bar.vue
+│   └── Baz.vue
+├── App.vue
+├── app.js # universal entry
+├── entry-client.js # runs in browser only
+└── entry-server.js # runs on server only
+```
+
+### `app.js`
+
+`app.js` is the universal entry to our app. In a client-only app, we would create the root Vue instance right in this file and mount directly to DOM. However, for SSR that responsibility is moved into the client-only entry file. `app.js` simply exports a `createApp` function:
+
+``` js
+import Vue from 'vue'
+import App from './App.vue'
+
+// export a factory function for creating fresh app, router and store
+// instances
+export function createApp () {
+  const app = new Vue({
+    // the root instance simply renders the App component.
+    render: h => h(App)
+  })
+  return { app }
+}
+```
+
+### `entry-client.js`:
+
+The client entry simply creates the app and mounts it to the DOM:
+
+``` js
+import { createApp } from './app'
+
+// client-specific bootstrapping logic...
+
+const { app } = createApp()
+
+// this assumes App.vue template root element has id="app"
+app.$mount('#app')
+```
+
+### `entry-server.js`:
+
+The server entry uses a default export which is a function that can be called repeatedly for each render. At this moment, it doesn't do much other than creating and returning the app instance - but later when we will perform server-side route matching and data pre-fetching logic here.
+
+``` js
+import { createApp } from './app'
+
+export default context => {
+  const { app } = createApp()
+  return app
+}
+```
diff --git a/ru/universal.md b/ru/universal.md
new file mode 100644
index 00000000..062ee206
--- /dev/null
+++ b/ru/universal.md
@@ -0,0 +1,31 @@
+# Writing Universal Code
+
+Before going further, let's take a moment to discuss the constraints when writing "universal" code - that is, code that runs on both the server and the client. Due to use case and platform API differences, the behavior of our code will not be exactly the same when running in different environments. Here we will go over the key things you need to aware of.
+
+## Data Reactivity on the Server
+
+In a client-only app, every user will be using a fresh instance of the app in their browser. For server-side rendering we want the same: each request should have a fresh, isolated app instance so that there is no cross-request state pollution.
+
+Because the actual rendering process needs to be deterministic, we will also be "pre-fetching" data on the server - this means our application state will be already resolved when we start rendering. This means data reactivity is unnecessary on the server, so it is disabled by default. Disabling data reactivity also avoids the performance cost of converting data into reactive objects.
+
+## Component Lifecycle Hooks
+
+Since there are no dynamic updates, of all the lifecycle hooks, only `beforeCreate` and `created` will be called during SSR. This means any code inside other lifecycle hooks such as `beforeMount` or `mounted` will only be executed on the client.
+
+## Access to Platform-Specific APIs
+
+Universal code cannot assume access to platform-specific APIs, so if your code directly uses browser-only globals like `window` or `document`, they will throw errors when executed in Node.js, and vice-versa.
+
+For tasks shared between server and client but use different platform APIs, it's recommended to wrap the platform-specific implementations inside a universal API, or use libraries that do this for you. For example, [axios](https://github.com/mzabriskie/axios) is an HTTP client that exposes the same API for both server and client.
+
+For browser-only APIs, the common approach is to lazily access them inside client-only lifecycle hooks.
+
+Note that if a 3rd party library is not written with universal usage in mind, it could be tricky to integrate it into an server-rendered app. You *might* be able to get it working by mocking some of the globals, but it would be hacky and may interfere with the environment detection code of other libraries.
+
+## Custom Directives
+
+Most custom directives directly manipulate the DOM, and therefore will cause error during SSR. There are two ways to work around this:
+
+1. Prefer using components as the abstraction mechanism and work at the Virtual-DOM level (e.g. using render functions) instead.
+
+2. If you have a custom directive that cannot be easily replaced by components, you can provide a "server-side version" of it using the [`directives`](./api.md#directives) option when creating the server renderer.