Rendering is a key component of any search engine’s indexing process and the one with the biggest impact on your crawl budget. When a search engine (SE) crawls your website, it requests all the necessary files from your server to build the page, including HTML, CSS, and JS resources.
Although there are many ways to do so, we believe dynamic rendering is the fastest and most effective solution, as it fixes the problem from the root by taking the rendering process off the SEs’ shoulders while being easy to deploy and maintain.
However, does it mean you must always use dynamic rendering?
Should Dynamic Rendering Be the Default Solution?
We are biased to say yes. However, every website is different, and there are certain scenarios where implementing dynamic rendering – or any other rendering option for that matter – is not necessary.
That said, once your website gets to 5,000+ pages or your pages’ content refreshes faster (like a couple of days to hours), you should consider dynamic rendering.
Dynamic Rendering is Not a Replacement for Poor Site Optimization
Another thing to consider is that dynamic rendering, as a solution, works by automatically generating and caching a fully-rendered version of your page. Thanks to this, your server doesn’t have to render your page every time it gets requested (server-side rendering) or rely on your developer team to create an HTML-static version for every page on your site (static rendering), saving you both money and time.
What it doesn’t do is fix structural site problems.
Instead of using the traditional <a> tag plus href attribute, JS sites tend to use an event-triggered implementation like this one:
Yes, this implementation works, and visitors won’t notice the difference. The problem is that Google can’t interact with the website as human users would. If Googlebot can’t get to the URL, it won’t be able to crawl the rest of your site.
Here are two resources you can use to find and fix these problems:
Once you have a solid SEO-friendly site structure, dynamic rendering will ensure that Google can make the most of it.
5 Scenarios When You Should Use Dynamic Rendering
Now that we have a better idea of what dynamic rendering is and what it’s not for, let’s explore five use cases. Here, we’ll show you how rendering your pages dynamically can have a big positive impact on your SEO performance:
1. You’re trying to get a single-page application indexed in search engines
Dynamic rendering is the best solution for single-page applications (SPAs) that care about showing in organic search results.
And it’s not only important for search engines but also for social media.
Unlike Google, social media platforms don’t have a system to render your page, so if their crawlers can’t find the open graph tags within your HTML (which they won’t do without dynamic rendering), they can’t generate rich previews when your links are shared.
Pre-rendering your pages will allow search engines and social platforms to access your content faster and accurately and avoid all major JS SEO issues that could limit your single-page application’s organic growth.
As more pages are added, the more risky relying on Google’s rendering becomes.
Dynamic rendering can close the gap by turning your pages into ready-to-index snapshots, getting 100% of your content indexed by Google and other search engines that don’t have a Renderer engine.
3. You’re reaching Google’s crawl limits due to rendering delays
- Crawl limit – How many request your server can handle per second without reducing its performance and Google’s capacity.
- Crawl demand – How often you publish new content, how frequently your content gets updated, and how popular your site is.
You can tell this is happening to your site if you find a declining trend in the number of pages crawled per session during your log file audits.
Another potential cause is if you’re relying on server-side rendering (SSR) to deliver your JS content to Google.
On every request, your server has to generate the rendered page, putting more pressure on your server and reducing the number of requests it can handle per second.
Dynamic rendering, on the other hand, speeds up the process by having the rendered versions of your site generated beforehand, so the snapshot is ready when the request comes in.
In turn, it lets Google send more requests per second without overwhelming your server, increasing crawl budget and efficiency.
4. Your site’s performance is getting hurt by render-blocking resources
After implementing dynamic rendering through Prerender, we’ve seen a 100x page speed improvement on most enterprise sites.
When people think about mobile optimization, they usually imagine things like optimizing the template for responsiveness, adapting button sizes, and avoiding intrusive pop-ups.
The good news is that there are many ways to make your JS website mobile-friendly and optimize your JS code to have a lesser impact on mobile performance.
So what does dynamic rendering have to do with anything?
Image source: HTTP Archive
And after the mobile-first indexing update, Google uses a mobile crawler to evaluate your site, making mobile performance critical for your site’s overall SEO scoring.
For sites struggling to close the gap between their desktop and mobile site performance, dynamic rendering allows you to compete on equal ground with static HTML pages that are arguably faster to load on mobile but lack the user experience your site can provide.
In other words, use dynamic rendering and stop getting penalized for Google and mobile phones’ limitations.
Wrapping Up: Dynamic Rendering as a Short-Term Workaround and How Prerender Solves It
However, more recently, Google has started to talk about dynamic rendering as a short-term solution and tell users to explore other implementations like static rendering and hydration.
Both of these are valid but present their own limitations, including performance issues, scalability limitations, and complex implementations.
Note: You can learn more about these limitations in our Prerender process and benefits guide.
But why this change of heart? Are there any consequences of implementing dynamic rendering?
Well, like with any choice in life, there are certain challenges traditional dynamic rendering implementations face:
- Dynamic rendering needs a considerable amount of server resources to generate and store the pre-rendered pages – this is true to some extent, but server-side rendering requires even more resources as the renders happen on every request.
- It requires a team of experts to verify/maintain that the dynamically rendered pages are optimized and working – again, this is also true for hydration and static rendering. However, you could say that in the case of dynamic rendering, you’re technically handling two versions of your site, which can take more resources from your team.
- Dynamic rendering adds an extra layer of complexity – If something goes wrong with the dynamic rendering process, search bots can get blank pages, and it would be harder to spot because your human users are getting the full experience.
Although other solutions share similar difficulties, it is true that dynamic rendering issues and mistakes are harder to spot and can hurt your site without you realizing it.
So how does Prerender solve this?
Prerender it’s a plug-and-play solution that takes the pre-rendering process out of your servers, freeing your developers to focus on features and user experience.
After installing Prerender, it’ll crawl your submitted sitemap and generate a fully-rendered and functional snapshot of your pages, reporting the rendering process in a comprehensive dashboard that’ll give you specific crawl and render information.
The best part is that you can implement a quick solution with the reassurance of a team that dedicates 100% of its time to ensuring your pages are rendered correctly and delivered ready for indexation.