Let’s talk about the pros and cons of server-side rendering

Welcome to part two of our video series on the topic of page speed and SEO. This time, I speak with Ainsley Clark, our Senior Full Stack Software Engineer (and creator of Reddico’s Verbis CMS) on the pros and cons of server-side rendering. 

Below, I’ve summarised key takeaways from the questions I asked Ainsley. I’ve also provided timings for each section of the video, should you want to dig into the answers you’re most interested in.

01:00: What is server-side rendering and why is it important?

SSR is a typical solution for websites that rely heavily on JavaScript, with a populated version of the website existing on the server. Having a version of the site server-side speeds up the rendering process and allows Google to parse information about the site quickly, something which JavaScript can give us problems around.

Ainsley says the importance of SSR needs to be contextualised within the topic of rendering and the process of rendering itself: 

• Rendering is the process of populating templates with HTML or text. This can come from APIs, databases, or CMSs.

• This can happen both on the server-side (i.e. a virtual machine or computer running in the cloud populating rich data using HTML) or on the client side (the client’s browser).

• Client-side rendering is a dynamic rendering method that uses JavaScript or frameworks to populate content.

• SSR relies on the server to do the heavy lifting, grabbing content from a database or another dyanmic source to present to the user and search engine. From the client’s point of view, all that’s required is to download enhancement styles such as images and JavaScript.

• If content is relying on JavaScript to be populated, this may cause problems for large sites when it comes to managing their crawl budget, and certain content may not get rendered.

• Developers should use JavaScript to enhance the page (such as animation) but not rely on it for actual content and markup. 

05:05: What is the <noscript> fallback and why is it important?

The <noscript> fallback forms an important part of learning when it comes to JavaScript SEO and SSR. What is it, why is it important and can it be used in both client-side rendering and sever-side rendering? Here’s what Ainsley had to say:

• The <noscript> fallback is one of the most powerful HTML elements for SEO. It serves as an HTML element that you can house content in which only renders if there’s no JavaScript enabled in the browser. 

• It can be a great way to signal to Google what content you’ve got on a page if you’re populating it by JavaScript. 

• For example, if you have an H1 that is populated by JavaScript on the client side, using a <noscript> tag to detail this will allow Google to see this on its first wave of indexing. 

• The content tagged under <noscript> elements must be the same as what’s being populated by JavaScript, otherwise this sends mixed messages and could impact your rankings.

• The <noscript> fallback can also be used for imagery and styles too, such as  serving CSS to browsers with JavaScript disabled.

• This means that if you disable JavaScript in your browser, the HTML featured in the <noscript> will ensure the page looks the same to both users and search engines.

08:12: What are the most common blockers in terms of SSR implementation?

There are of course a lot of surrounding factors around this, and each scenario and website will have their own set of potential barriers that may get in the way of SSR implementation. However, what are the most common blockers Ainsley has seen come up when it comes to getting SSR over the line?

• The most common blocker for SSR implementation is often the tech stack that a company chooses to use and what libraries developers are using. Does this content rely on an external API or anything else for rendering markup, for example?

• It’s also important to use a suitable CMS that allows SSR implementation, as this can often be a problem.

• Many developers use framework libraries which although are an effective and efficient way to build sites, rely a lot on JavaScript, which can also be a big blocker.

• Libraries such as React and Vue are great for building back-end applications, though aren’t great for front-end applications that need to perform for SEO. Reliance on these can be blockers for SSR implementation.

• There are ways in which you can get around this and build SSR into a JavaScript framework by rendering the content at compile time, and some libraries do allow this. 

• One potential pitfall to keep in mind here however is that if links are generated by JavaScript frameworks then they won’t pass any weight to the respective pages.

12:25: How can developers implement SSR easily?

With some of these common blockers in mind, what are the best ways for developers to easily implement SSR? What does Ainsley see as the best methods to achieve SSR for websites?

• Progressive enhancement is a great overarching strategy to have in place throughout this process. Progressive enhancement is a philosophy for web design and development that puts emphasis on content before anything else. 

• In essence, this means that the user is able to access the content of a web page before anything else.

• With the aforementioned blockers in mind, this is something that needs to be considered from the very beginning, and this means using the right tech stack when starting a build. 

• For pre-existing websites, the use of <noscript> tags can help display content to search engines which resembles JS-generated content.

• Dynamic rendering is another popular method of implementing SSR. This serves a rendered HTML page to search engines and ensures users still get the same experience with JavaScript websites. A great example of this is Prerender.io

Server-side rendering, with all its considerations around how it can alleviate some of the problems presented by JavaScript-heavy websites among other things, presents a perfect opportunity for SEOs to work alongside developers to find solutions to build websites that solve the need for both the user and the search engine. 

If you would like to learn more about JavaScript and how it can affect page speed, read and watch part 1 of our series - Let’s talk about page speed, JavaScript and everything in between