- Shop NEW!
- The Vue Instance
- Template Syntax
- Computed Properties and Watchers
- Class and Style Bindings
- Conditional Rendering
- List Rendering
- Event Handling
- Form Input Bindings
- Reactivity in Depth
- Transition Effects
- Transitioning State
- Render Functions
- Custom Directives
- Single File Components
- Production Deployment Tips
- State Management
- Unit Testing
- Server-Side Rendering
- TypeScript Support
- Migration from Vue 1.x
- Migration from Vue Router 0.7.x
- Migration from Vuex 0.6.x to 1.0
- Comparison with Other Frameworks
- Join the Vue.js Community!
Before diving into SSR, let’s explore what it actually does for you and when you might need it.
This means if you have content fetched asynchronously on pages where SEO is important, SSR might be necessary.
Users might come to your site from a remote area with slow Internet - or just with a bad cell connection. In these cases, you’ll want to minimize the number and size of requests necessary for users to see basic content.
You can use Webpack’s code splitting to avoid forcing users to download your entire application to view a single page, but it still won’t be as performant as downloading a single, pre-rendered HTML file.
For some demographics or areas of the world, using a computer from 1998 to access the Internet might be the only option. While Vue only works with IE9+, you may still want to deliver basic content to those on older browsers - or to hipster hackers using Lynx in the terminal.
If you’re only investigating SSR to improve the SEO of a handful of marketing pages (e.g.
/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. It’s been extensively tested with Vue apps - and in fact, the creator is a member of the Vue core team.
If you’ve gotten this far, you’re ready to see SSR in action. It sounds complex, but a simple Node.js script demoing the feature requires only 3 steps:
Not so scary, right? Of course, this example is much simpler than most applications. We don’t yet have to worry about:
- A Web Server
- Response Streaming
- Component Caching
- A Build Process
- Vuex State Hydration
In the rest of this guide, we’ll walk through how to work with some of these features. Once you understand the basics, we’ll then direct you to more detailed documentation and advanced examples to help you handle edge cases.
It’s kind of a stretch to call it “server-side rendering” when we don’t actually have a web server, so let’s fix that. We’ll build a very simple SSR app, using only ES5 and without any build step or Vue plugins.
We’ll start off with an app that just tells the user how many seconds they’ve been on the page:
To adapt this for SSR, there are a few modifications we’ll have to make, so that it will work both in the browser and within Node.js:
- When in the browser, add an instance of our app to the global context (i.e.
window), so that we can mount it.
- When in Node.js, export a factory function so that we can create a fresh instance of the app for every request.
Accomplishing this requires a little boilerplate:
Now that we have our application code, let’s put together an
As long as the referenced
assets directory contains the
app.js file we created earlier, as well as a
vue.js file with Vue, we should now have a working single-page application!
Then to get it working with server-side rendering, there’s just one more step - the web server:
And that’s it! Here’s the full application, in case you’d like to clone it and experiment further. Once you have it running locally, you can confirm that server-side rendering really is working by right-clicking on the page and selecting
View Page Source (or similar). You should see this in the body:
Vue also supports rendering to a stream, which is preferred for web servers that support streaming. This allows HTML to be written to the response as it’s generated, rather than all at once at the end. The result is requests are served faster, with no downsides!
To adapt our app from the previous section for streaming, we can simply replace the
server.get('*', ...) block with the following:
As you can see, it’s not much more complicated than the previous version, even if streams may be conceptually new to you. We just:
- Set up the stream
- Write the HTML that comes before the app to the response
- Write the app HTML to the response as it becomes available
- Write the HTML that comes after the app to the response and end it
- Handle any errors
Vue’s SSR is very fast by default, but you can further improve performance by caching rendered components. This should be considered an advanced feature however, as caching the wrong components (or the right components with the wrong key) could lead to misrendering your app. Specifically:
You should not cache a component containing child components that rely on global state (e.g. from a vuex store). If you do, those child components (and in fact, the entire sub-tree) will be cached as well. Be especially wary with components that accept slots/children.
With that warning out of the way, here’s how you cache components.
That will cache up to 1000 unique renders. For other configurations that more closely align to memory usage, see the lru-cache options.
Then for components you want to cache, you must provide them with:
- a unique
serverCacheKeyfunction, returning a unique key scoped to the component
Any “pure” component can be safely cached - that is, any component that is guaranteed to generate the same HTML given the same props. Common examples of these include:
- Static components (i.e. they always generate the same HTML, so the
serverCacheKeyfunction can just return
- List item components (when part of large lists, caching these can significantly improve performance)
- Generic UI components (e.g. buttons, alerts, etc - at least those that accept content through props rather than slots/children)
By now, you should understand the fundamental concepts behind server-side rendering. However, as you introduce a build process, routing, and vuex, each introduces its own considerations.
To truly master server-side rendering in complex applications, we recommend a deep dive into the following resources:
- vue-server-renderer docs: more details on topics covered here, as well as documentation of more advanced topics, such as preventing cross-request contamination and adding a separate server build
- vue-hackernews-2.0: the definitive example of integrating all major Vue libraries and concepts in a single application
Properly configuring all the discussed aspects of a production-ready server-rendered app can be a daunting task. Luckily, there is an excellent community project that aims to make all of this easier: Nuxt.js. Nuxt.js is a higher-level framework built on top of the Vue ecosystem which provides an extremely streamlined development experience for writing universal Vue applications. Better yet, you can even use it as a static site generator (with pages authored as single-file Vue components)! We highly recommend giving it a try.