.png){kind=logo}
Google no longer recommends using dynamic rendering as a solution to crawling and indexing problems with JavaScript, Search Engine Land reports. The search engine said that in the updated help doc, encouraging users to avoid this solution, saying it’s a workaround, not a long-term solution.
Instead, developers, webmasters and SEOs should use server-side rendering, static rendering, or hydration.
Photo source: https://developers.google.com/
What is Dynamic Rendering Exactly?
It’s a process which helps JavaScript-based websites let Google know a page is ready to be crawled into or indexed. Some search engines have trouble understanding JavaScript, thus not letting bots crawl into a page and make it recognizable to users.
With dynamic rendering, you’re serving Google an HTML version, which is easy to crawl into, index it and recognize keywords, etc. At the same time, you’re serving the user the JavaScript version.
Here’s an illustration of how it works:
Photo source: https://developers.google.com/
You may want to use dynamic rendering if you have JavaScript-generated content that changes rapidly. You might also want to use it if crawlers you care about don’t support JavaScript features. However, not all sites need to use it, nor is it a good solution.
Google shared this article on web rendering which explains why not all sites need dynamic rendering, and how there are better solutions out there.
Alternative Solutions For Dynamic Rendering
As mentioned above, Google recommends using alternative options and avoiding dynamic rendering:
Static Rendering
Server-side Rendering
Hydration
Static Rendering
This one should happen as you’re building your site. Generally, Static rendering involves creating separate HTML files for each URL in advance. As explained here, because HTML responses are generated in advance, static renders can be deployed to multiple CDNs and take advantage of edge-caching.
However, creating URLs in advance may be challenging. So, to use this method, you’d have to be very organized and have everything planned way ahead.
Server-side Rendering
Server rendering is essentially just sending text and links to the user’s browser. The approach can work well for a wide range of devices and networks. It also allows interesting browser optimizations to be applied. You can read more about it here.
Hydration
By doing both client-side rendering and server-side rendering, Universal Rendering (also referred to as SSR) strives to smooth over trade-offs between the two approaches. When a user requests a full page load or reload, the application is rendered to HTML by a server. Then, JavaScript and data are embedded in the resulting document.
This achieves an FCP and picks up by rendering again using a technique called hydration. It is a new solution for things, so this approach can come with some serious performance drawbacks, like the page looking fully loaded but is actually frozen. Read more about this approach and its drawbacks here.
Comments