Server Side Rendering
Server side rendering can be explained as moving the process of rendering pages of an SPA from the client's browser to the server on initial page request. This process is similar to what we used to do a few years ago, where we had server side languages like PHP, Java, Python render the page and return an HTML response.
- The Benefits of Server Side Rendering Over Client Side Rendering Good read
- What’s Server Side Rendering and do I need it?
- When to use Server-Side Rendering (SSR) in Vue.js projects
- What is React Server Side Rendering and should I use it? - For React, by the concepts are the same.
Benefits of Server Side Rendering (SSR)
Server side rendering solves a few of the most annoying problems of single-page applications:
With SSR, pages are returned as fully rendered HTML by the server, allowing for crawlers to scan at will.
Fast Load on Slower Devices
Heavy applications that require lots of resources for the initial rendering, may cause slower or older devices to struggle. This is a real problem, as the average user doesn't have the latest cutting edge mobile device.
With SSR, the page is fully rendered on the server, eliminating that initial burden for lower end devices. When paired with some other optimisation techniques, like code splitting, pages can load much faster.
With SSR, pages are displayed with nice previews, as both the page content it self and meta tag data is present, allowing for social media crawlers to extract what they need.
Time To First Paint (TTFP)
Problems with SSR - Time to interaction - for more info.
Problems with SSR
SSR sounds awesome, there are however some things that need to be taken in consideration.
Time to Interactive
Time to First Byte (TTFB) is Slower
Because the server has to actually do the rendering, fetch async data and so on, the time it takes for the response to hit the browser is bigger.
Because there is usually a live Node.js instance always on, waiting to render a request, server costs are higher than static file hosting.
Hosting page - for more info.
This is directly related to the above. Server load is higher on initial request, while pages are being rendered, sometimes blocking other operations until the process is done.
Platform Specific APIs are not Available
Because the app is rendered in server environment, there are specific APIs that are not available, like the
window object. This means libraries like sliders and carousels may not work, and will throw errors during render.
To overcome this, developers should not interact with those APIs, in places, that are being called during server rendering. Their usage should be moved to lifecycle hooks like
mounted, where the browser environment is present.
With sliders and carousels, you could delay their rendering to after the client receives the page, so it gets rendered on the browser.
Complex to Transform Deployed SPA to SSR
Because of the above, already deployed websites are harder to transform to SSR, as there might be a lot of plugins or UI components, that rely on the Platform Specific APIs, explained above.
This is an issue mostly related with library and plugin authors not providing SSR compliant versions of their software.
There are ways around this, like using the
no-ssr component helpers, which delay rendering of components to the browser. This means that the component tag will be returned in the initial html response and not its rendered template. This might be problematic for components with SEO heavy content.
Available Options for Vue
This part of the page is still in development and could use some help.
Thankfully, there are a few options already for Vue when it comes to server-side rendering.
Nuxt is a framework on top of Vue for creating universal applications. It offers a full SSR environment, with an extendable API, out of the box.
If you are searching for a well tested solution, with a large community and nice development experience, Nuxt is most probably what you should pick.
Learn more about it on the dedicated Nuxt page.
Nuxtpress is a microframework on top of Nuxt for creating blogs and documentation using Markdown. It offers full support for Nuxt static generate mode and hot reloading for
Learn more about it on the dedicated Nuxt page.
Quasar with its CLI mode of operation, allows for you to build a SPA or PWA and have it served from the server initially. This gives you all of the advantages mentioned above. Quasar's build system offers you a Node Express Server out of the box, which you can also later enhance as you wish. The main point being, one build command through Quasar's CLI does it all for you.
Servue shares a similar scope to Nuxtjs, it allows you to render
.vue files into rendered html. It includes features for head meta tag management, layouts and more. Servue is more suitable for Multi-page-applications using existing server-side routing systems such as koa/koa-router or express.js
Ream is a lighter framework for building server-rendered applications using Vue. Opposed to Nuxt, Ream is more lower level oriented, meaning it does not rely so much on conventions, but rather lets the user choose how to configure their app.
If you need more freedom to configure your application, with little to no interference from the SSR framework, Ream may be your choice.
Vue Server Renderer
Vue Server Renderer is a lower level tool that is used by most of the above mentioned frameworks to render Vue apps on the server.
You can use it in tandem with an Express server or similar solution, to render pages on each user visit to the app. Just keep in mind, you will have to write a lot more boilerplate and configuration by yourself, compared to the already pre-made solutions.
If you don't need some really custom solution, we would advise you to pick one of the pre-made tools mentioned above.