Why Dynamic Rendering Is Not a Long-Term Solution

In case you missed it, Google recently specified that:

• Dynamic rendering is a workaround and not a long-term solution for JavaScript issues, and
• Google recommends using server-side rendering, static rendering, or hydration instead.

Although the official Google documentation sheds light on how we should treat dynamic rendering now, the question that bothers many remains: why exactly should we consider dynamic rendering a temporary solution?

If this question triggers you to look for the answer like me, let’s dig in!

Why is this update important?

To understand why we consider this update vital, let’s travel back to see how Google previously treated (dynamic) rendering.

The dynamic rendering story timeline

It all started in 2009 when Google realized that almost 70% of all the websites Google knew about already used JavaScript. But the problem was that at that time, they weren’t able to render JavaScript at all.

To ensure crawling and indexing JavaScript, Google suggested serving a static HTML version of a website to bots when serving a fully-featured JavaScript-based website to users. It was the very beginning of today’s dynamic rendering as a workaround in cases when Google couldn’t deal with a client-side rendered website.

In 2014, Google officially admitted that they started rendering JavaScript-based websites, to update in 2015 that they are generally able to render JavaScript. However, many websites still struggled with correctly rendering and indexing their JavaScript content.

That’s why Bartosz Góralewicz, CEO of Onely, started researching the topic and experimenting to find out if Google can properly crawl and index JavaScript frameworks. It was also the beginning of Onely providing JavaScript SEO services to its clients.

Whereas, from Google’s side, more precise information on dynamic rendering showed up in 2018. During the Google I/O conference, Googlers admitted that they use two waves of indexing. It outlined that, in general, the rendering of JavaScript-based websites is deferred as long as Google doesn’t have the resources to process that content. Also, shortly after the conference, Google published its official documentation (now updated), recommending dynamic rendering to get your JavaScipt content indexed faster.

Then, in 2019, Bartosz Goralewicz elaborated on dynamic rendering during his presentation at SMX WEST. He aimed to explain why this solution isn’t a silver bullet to all rendering issues.

And although we, at Onely, already knew by then that dynamic rendering isn’t the best solution, Google still recommended it as a workaround to processing JavaScript by crawlers so that webmasters kept using it. But unfortunately, they often didn’t realize how expensive it is to host.

What is dynamic rendering?

Dynamic rendering (also known as prerendering) consists of serving a fully-featured JavaScript version of your website to users and a static HTML version to crawlers to present your JavaScript content. It works by detecting and distinguishing different user agents and serving suitable website versions to users and bots.

However, it doesn’t necessarily mean users have to be served entirely client-side rendered content; they just aren’t served the same static files as bots. In general terms, the whole JavaScript experience is served to users and the HTML files ‒ to robots.

Google complements that definition by specifying:

We call it dynamic because your site dynamically detects whether or not the request there is a search engine crawler, like Googlebot, and only then sends the server-side rendered content directly to the client. You can include other web services here, as well, that can’t deal with rendering. For example, maybe social media services, chat services, anything that tries to extract structured information from your pages. And for all other requesters, so your normal users, you would serve your normal hybrid or client-side rendered code.

source: John Muller

As the rendering stage, in general, is expensive to be processed by crawlers, dynamic rendering serves  Googlebot an easily understandable, lightweight, static HTML version to make your content ready for possible indexing faster.

That’s why Google suggests dynamic rendering can be a trade-off mainly for websites:

• frequently changing their content such as news publishing websites ‒ they need to index their fresh content as soon as possible so they can’t defer the execution of JavaScript rendering,
• using modern JavaScript features that aren’t supported by crawlers, and
• relying on sharing their content through social media or chat applications.

How does dynamic rendering differ from other popular ways of serving JavaScript?

Rendering is a crucial step of the indexing pipeline ‒ how your website gets rendered affects how search engines see your content. And to address the needs of both bots and users, you need to learn about two different approaches: server-side and client-side rendering. 

Understanding them is crucial as those concepts also recur in different ways of serving JavaScript that you may choose, such as dynamic rendering.

Client-side rendering

Client-side rendering is based on processing content directly in the browser using JavaScript. At first, browsers and crawlers get initial HTML (which usually represents blank pages with little or no content). Then, JavaScript is asynchronously downloaded and run from the server displaying your dynamic content to users.

However, taking this approach, you risk your content not getting rendered by Google as it may struggle to process the JavaScript-based version of a website independently due to its limited resources. Keep in mind that client-side rendering on its own is not a problem and Google can deal with it, but unless it’s well optimized, it’s very expensive for Google to crawl, render, and index.

Server-side rendering

With server-side rendering, bots and users receive your website’s HTML version fully rendered on the server immediately, at the request time. The fact that rendering HTML is handled on the server makes the whole process faster for browsers and generally easier for search engines to pick up the content.

Also, although server-side rendering is a recommended solution, Google underlines that choosing it doesn’t influence your rankings ‒ it only differs from dynamic rendering in terms of setup and maintenance:

There are no SEO ranking bonuses for implementing it one way or another – they’re just different ways of making the content indexable (as is client-side rendering). The differences between dynamic rendering and server-side rendering from my POV are more in terms of practical infrastructure setup & maintenance (it can also affect speed, depending on how you have things set up).

source: John Muller

Also, take a look at our ultimate guide to JavaScript SEO to learn more about the different solutions for serving JavaScript on your website.

How does dynamic rendering work?

Dynamic rendering may use an external renderer to facilitate changing initial HTML and JavaScript into the static HTML that crawlers can process.

Google recommends using the following dynamic renderers:

• Prerender.io (third-party software),
• Puppeteer (open-source software), or
• Rendertron (open-source software).

Having configured any of the recommended solutions, remember to:

1. Choose the user agents you want to serve the static HTML version of your website, e.g., “googlebot” or “twitterbot.”
2. Set up a cache to enable your website to be served as quickly as possible and avoid timeouts.
3. Ensure that the prerendered version of your website serves the device-oriented version. In other words, mobile search engine crawlers should see the mobile version of your site when other crawlers ‒ the desktop one. 
4. Ensure that your server can serve the static HTML to the chosen user agents.

Regarding implementing dynamic rendering, Google provides its official documentation on implementing and verifying dynamic rendering configuration.

Why and how to start navigating the dynamic rendering issues?

Google can’t fully index a JavaScript-based website until it gets fully rendered. So if dynamic rendering fails, your content won’t be included in SERPs.

And just take popular US-based eCommerce websites as an example: 80% use JavaScript to generate main content and links to similar products. It poses a severe threat to the indexability of the critical parts of those domains. Now, think about how it translates to their revenue going down.

That’s why the crucial step of implementing dynamic rendering is to navigate and verify the potential problems. 

Use the Mobile-Friendly Test

The tool allows you to ensure your website’s mobile friendliness and to see the rendered source code of the tested website, along with a screenshot of how Googlebot renders your page on mobile devices.

You may observe some parts of your content missing in the source code ‒ that’s a signal for you that Googlebot wasn’t able to render those resources, and this may be the result of improperly implemented dynamic rendering.

Within the tool, you can dive into the Details section to learn when and by what crawler the page was crawled or even check the HTTP response. If you’re checking your domain, the Mobile-Friendly Test can transfer you into further analysis in Google Search Console.

If you happen to find any issues using the Mobile-Friendly Test, read the article on our blog to learn how to optimize your website for mobile devices.

Use Google Search Console

One of the reports you need to check to make sure you properly implemented dynamic rendering is the Index Coverage (Page indexing) report. It helps you navigate your indexing issues and informs you about which of your pages aren’t indexed and why.

An example of a status that can suggest rendering issues on your website is the “Page indexed without content” status ‒ Googlebot couldn’t see the content because it couldn’t render the page.

Another helpful feature within Google Search Console is the URL Inspection tool. Similar to the Mobile-Friendly Test, the URL Inspection tool allows you to check the status of a tested page and see its rendered version.

Use ZipTie.dev

As indexing issues may stem from rendering problems, it’s worth analyzing how your website is indexed. You should look at both the number of indexed pages and whether specific sections of those pages get indexed.

To check if a particular fragment of your page is indexed, you can use the site: command together with a text fragment in quotes. But when you have a large website with millions of URLs to analyze, you won’t be able to check them all manually.

ZipTie.dev analyzes indexing together with other data points like word count, titles, headers, meta descriptions, and more.  This will help you identify the potential causes of your indexing (and so rendering) problems.

Use the Rich Results test

If you use structured data on your website and care about your rich results, use the Rich Results test to check if the markup is correctly implemented.

The test also shows you the rendered version of your website and outlines how Googlebot understands your markup specifying any errors, their types, and where they appear in the code.

However, just checking off the boxes on the list “How to troubleshoot the dynamic rendering issues” may usually not be enough. The larger and more complex the website, the more difficult it may be to specify what exactly went wrong at first glance.

For example, the error results from the Mobile-Friendly Test may suggest that you have some rendering issues. But, at the same time, the server may have just experienced a temporary glitch and didn’t effectively respond with other resources, such as CSS files. As a result, it influences how the website is displayed, but it may only be a one-time situation.

Troubleshooting (dynamic) rendering will always require general technical SEO auditing and thorough analysis.

Why is dynamic rendering not a long-term solution?

Dynamic rendering uses significant amounts of server resources

Dynamic rendering may significantly slow down your server. A large amount of prerendering requests can make the renderer fail, so as a result, Googlebot will:

• Receive a blank page ‒ Googlebot sees only the initial HTML, but as there is no JavaScript reference in the code, the rest of a website is invisible to it. The website can’t be indexed because Googlebot doesn’t see the content.
• Receive a client-side rendered version of a website ‒ Google can technically deal with JavaScript in many cases, but the whole point of implementing dynamic rendering was to serve it static content. In some instances, the cost of downloading the JavaScript content and updating the initial HTML version of a website with it may be too high for Googlebot.

Therefore, before you decide on dynamic rendering, it is essential to make a deliberate decision if your website needs it.

Implementation and maintenance of dynamic rendering can use a significant amount of server resources. And if you see Googlebot is able to index your pages properly, then if you’re not making critical, high-frequency changes to your site, maybe you don’t need to actually implement anything special. […]

source: John Muller

Dynamic rendering creates two separate site structures instead of one

Using dynamic rendering, you maintain two versions of your website. It means you need to verify separately that your website is well-optimized for users and for bots.

A dynamically rendered website requires excellent SEO and development teams. And even if you have such teams at your disposal as a website owner, think about how better they could spend their time when not focusing on the dynamic rendering verification instead.

Dynamic rendering worsens the user experience

Dynamic rendering implies your users are served a client-side rendered version, and this can poorly impact page performance for users as it requires their browsers to handle the rendering process on their side.  And that can be a real struggle, especially for users with older phones which will have difficulty processing large amounts of JavaScript. While client-side rendering is not all evil, we recommend going the server-side route whenever possible.

Dynamic rendering adds an extra layer of complexity when optimizing a website

With dynamic rendering, it’s more challenging to spot and recognize problems generated by it.

Due to problems on the server or missing components, dynamic rendering often fails. As a result, Googlebot receives a blank page. Unfortunately, you have no clue about it when you’re looking at the website as a user (with fully-featured JavaScript), not as a bot. To troubleshoot that, switch the user agent to Googlebot in your browser.

Diagnosing such issues and discovering the user agent generating a particular problem requires significant SEO expertise. And you need to be aware that no response to your rendering problems can reflect on your website’s indexing. 

What are the better alternatives to dynamic rendering?

When well-implemented, all of the solutions mentioned below may be equally beneficial for your website from an SEO perspective.

However, the effect of implementation relies mainly on the technology you’re using and your development team. Regarding the dev resources, each solution’s implementation cost may differ, but it should be evaluated individually depending on the situation.

Server-side rendering

It’s one of the most popular solutions you can use instead of dynamic rendering. 

From the SEO perspective, the most significant advantage of using server-side rendering relies on maintaining only one version of your website. In contrast to dynamic rendering, you don’t have to verify if the versions for users and Googlebot are identical ‒ all user agents receive the same content. 

Moreover, unlike dynamic rendering, server-side rendering doesn’t make users process JavaScript files on their side to generate key page elements. It makes a page load faster; some web performance metrics impact your rankings and user experience.

But watch out: with server-side rendering, users can experience slightly worse Time to First Byte metrics if the server needs to generate static HTML ad hoc, or the server caching the responses is not efficient enough.

And just to clarify: even though the server-side rendering is correctly implemented, SEOs still need to verify all website elements. But all in all, it’s easier to maintain with only one version of a website.

Static rendering

Static rendering (also known as static generation) relies on serving bots and users the static HTML version generated at build time. It means that your website’s code is ready to be processed by crawlers and users just waiting on the server to be downloaded.

Similarly to server-side rendering, you must verify only one version of your website for all user agents while using this solution.

Also, in contrast to dynamic rendering, static rendering improves the page performance as it serves the prerendered version of your website faster ‒ the static files may be cached on users’ devices and used again.

Rehydration

Rehydration also serves only one version of a website to bots and users like the two previous solutions. However, it works in two stages.

In the first stage, crawlers and users receive a server-side rendered page that contains critical elements. For example, in the case of an eCommerce website, these may be the name of the product, description or product ratings. In the second stage, JavaScript downloads all the non-critical resources that are essential SEO-wise, but users can receive them with a delay. These are, e.g., chat widgets or comment sections.

When auditing a website using rehydration, you need to check if all the elements added by JavaScript are the non-critical ones.

Can dynamic rendering ever work long-term?

It may but rarely does. Especially if you have a large website and aren’t tech SEO savvy, don’t take this approach alone.

And remember that even if you aren’t worried about technical SEO, dynamic rendering still will be expensive to maintain.

Here are two examples of when our clients used dynamic rendering for:

Serving client-side rendered links for users in the footer

In that case, thanks to dynamic rendering, Googlebot could find the links in the source code, but at the same time, the footer links were generated for users and added to the DOM (which represents the state of your page after rendering) once they started scrolling the page. The client decided to implement dynamic rendering to optimize its performance ‒ not all the elements need to be stored in the DOM immediately if users don’t scroll to the end of the page.

Serving client-side rendered list of internal search results to users

The client decided to serve the server-side rendered version to bots (a lighter version of the listings) and client-side rendered versions to users (when the list of products is generated ad hoc and can be personalized).

Wrapping up

Whereas dynamic rendering should only be considered as a temporary solution, in some cases, you’ll consider it as a life belt for your website.

If you need to implement dynamic rendering, remember to follow these four steps:

1. Plan your updates and deployments. Ensure your development and SEO teams have enough resources to deal with the implementation and maintenance of a prerendered website.
2. Make sure the setup is efficient and free of bugs. Develop a way to verify that the setup is working correctly and no key page elements are missing from the version served to bots.
3. Remember that you need to be able to compare the HTML and JavaScript versions of your website and detect discrepancies.
4. Remember that, in most cases, dynamic rendering should only be a workaround. Look for opportunities to switch to other recommended solutions, considering your development resources and technology capabilities.