SEO for Single Page Apps: The Need for Server Side Rendering
Aronis is a Backend and Machine Learning Engineer with over a decade of industry experience. He's an open source enthusiast, in love with data science, especially when it's applied to sports.
The Differences Between Client Side and Server Side Rendering
- Where the rendering happens. In CSR, rendering happens in the client browser, while on the server-side the render happens in the server, this means in scenarios where real-time updates are needed, SSR is going to add a big latency penalty since the whole page needs to be retrieved on each call.
- Whose resources are we using? CSR uses the client web browser, therefore their CPU RAM and GPU. In SSR we need to allocate the CPU GPU and RAM for it.
- How many times do you render? Because of the previously mentioned performance considerations, in SSR we use to render once, cache it and serve it multiple times, while in CSR we render it every time on the client's browser.
What Is Server-Side Rendering?
We can also server-side render those single-page applications. We can either run a headless browser in our server, run the single page application there, generate the final HTML fully rendered, or use some tool’s specific scripts to render the HTML.
There are different kinds of Server Side Rendered websites:
- Traditional SSR, serving static HTML or doing HTML pre-processing using Freemarker or any other server-side preprocessor language, generates a fully rendered HTML page that gets served to the client.
- Static SSR, here our web app is built as a single page web application (SPA), but all pages get pre-rendered on the server, and the JS is removed before serving it.
- CSR with Prerendering, an SPA with the initial shell and skeleton pre-rendered in our server, could add simple meta tags to our SPA for social media crawlers and basic SEO improvements.
Why is Server Side Rendering Growing in Popularity?
There are various types of server-side rendered (SSR) websites. The traditional kind we are used to — serving plain HTML or using Freemarker or any other server-side preprocessor language— generates a fully rendered HTML page that gets served to the client. And also the modern take of server-side rendering, where we fully render on the server a single page application that would traditionally be CSR, and generate and serve the fully rendered HTML based on it. The popularity of SSR is confirmed by the rapid growth of questions on Stack Overflow related to server-side rendering over the last few years.
But there is a major drawback to single-page apps, as they tend to be bad out of the box in their SEO. The way we deal with that is using server side rendering.
How SSR Affects SEO
- It is slower, your page updates will take more time to be reflected in search results, and this single-handedly could reduce your traffic opportunities!
- It is less reliable. Even if the search engine renders it, we cannot be sure to what extent, so we could end up with no-follow links, a bad parsed structure overall, or a broken mobile experience.
SSR Best Practices for SEO
SEO in CSR and SSR is not black and white. There are degrees of interoperability that we can navigate, but you should avoid full CSR web apps. Regardless of the approach you take, please consider the following when implementing an SSR solution:
- Confirm your page is being rendered correctly, take a deep dive into your rendered HTML, and check snapshots of the website based on the rendered HTML.
- Ensure your HTML result is mobile-friendly.
- Some SSR may be slow, so if you serve it on request, you will be penalized by the search engines if your response was too slow. Cache your results, and do it before the bots ask to be as part of your DevOps pipeline. And consider using a headless CMS like Crafter that natively supports high-performance SSR.
- Use Google's mobile-friendly tool test to ensure you are correctly rendering your page.
CrafterCMS Provides First-Class SEO Support
CrafterCMS enables SEO-friendly websites to be built with a wide variety of content authoring capabilities, including a best-in-class content authoring environment that allows content creators and editors to optimize URL structures, metadata, mobile experiences, and more. Moreover, CrafterCMS provides developers with total freedom to implement sites using technologies and methodologies that work best to solve the challenges they face.
Major enterprises use CrafterCMS to build and manage large-scale, SEO-friendly websites that deliver top-ranked search engine results for their content. To learn more, read the Case Study Penn Mutual: CrafterCMS Enables Modern Digital Experiences for Life Insurance Leader.
Magnolia Alternatives: Why Enterprises Choose CrafterCMS
Attention Content Authors: Don't Worry About What Technology Your Headless CMS Developers are Using
Sitefinity Alternatives: Why Enterprises Choose CrafterCMS
Modernizing Video Delivery and Content Management at CPAC, A Canadian Nationwide Broadcaster
Building React Apps on a Headless CMS
Where is Headless CMS Architecture Headed?
A Better Headless CMS for ReactJS Apps
How to Build Engaging Websites with Modern Front-End Technologies