Thankfully, that’s not the case.
In short, rendering delays.
Client-side, server-side, pre-rendering, and dynamic rendering: a crash course
There are four main ways to render the content of a website: client-size, server-side, pre-rendering, and dynamic rendering.
Client-side rendering: the least SEO-friendly option
Client-side rendering is the least SEO-friendly of all the rendering options, but when done properly, it can have some advantages when it comes to user experience.
Client-side rendering means all the burden of rendering the content is on the “client” - that means you! Instead of the page being assembled at the server and then sent to your browser, the page is sent to your browser disassembled, leaving your browser to do all the work of loading the content. This means that your browser has to make multiple round trips to a server to grab and then load all of the content on the page.
Client-side rendered content is subject to Google’s “rendering budget,” which means there will be a delay before Google accesses it, and nearly inaccessible by other search engines, but many businesses (particularly those people dealing with infrastructure and finance) prefer this option because it reduces the load on their own servers.
Server-side rendering: the SEO-preferred option
Most SEOs prefer server-side rendering because all the meaningful content gets rendered on the website’s server, which means it’s not subject to the two waves of indexing. Both users and bots will receive a fully-loaded page, without the need to request additional resources.
Server-side rendering takes the burden of rendering a page off of you (browser) and places it on the website’s server.
Pre-rendering: a workaround option
Pre-rendering can be a viable option for some websites, but it’s somewhat of a workaround. It works like this:
- Website receives a request (or a specified period of time elapses)
- A service renders the page
- Only search engines receive the pre-rendered version of the page
Because pre-rendering is a solution for search engines, there’s no real benefit for users. Third party pre-rendering solutions like prerender.io can also be expensive, and they’re prone to bugs and can break on occasion.
Pre-rendering also may not be a great solution for websites with pages that change often. For example, we worked with an e-commerce business whose prerender solution was causing product prices to get out of sync — Google was seeing one price while users were seeing another. It works best when used on sites that don’t often change or are completely static.
Dynamic rendering: treating users and bots differently
Dynamic rendering is a method that uses a different rendering process depending on who’s trying to access the page. Search engine crawlers will receive a full server-rendered HTML, while humans will receive the initial HTML and make all the additional requests on their end.
While this solution helps search engines see your fully-loaded page instantly, it still places the entire burden of loading the page on the user.
What does it mean to “render” a page?
If you’ve gotten to this point and are still unclear on what rendering means, that’s understandable! Rendering is a somewhat foreign concept to non-developers, but easy enough to understand once you break it down.
Rendering is the process your phone, computer, tablet, or other device’s browser has to go through in order to actually “build” a web page.
Most of the time, this requires your computer to go out and get hundreds of different resources in order to make the page work the way the site intended it to.
The “rendering” process can take a long time, depending on the size and quantity of those different resources your browser has to go and fetch.
This comes at a cost to you (battery, speed, data, etc.) as well as search engines.
When it comes to crawling your site for SEO analysis, there are certain resources you’d want to ignore, such as:
- CSS - Stands for “cascading style sheets.” CSS is used to style elements of your website, such as colors and fonts.
- Tracking tags - These are used for tracking users and monetization purposes. Google Tag Manager and Google Ads conversion tracking tags are good examples of this.
When you’re crawling a site for the purpose of SEO analysis, you’ll primarily be interested in simulating a search engine’s experience. That’s why it’s a good idea to configure your crawler so that it’s looking at content (text) and internal links to other pages.
At Botify, we often work with customers to decide which (if any) of their website’s resources that load on a page are needed to do a proper SEO analysis. By eliminating any unnecessary resources, we ensure we’re only looking at the elements that matter for SEO, and not wasting time crawling things that aren’t important for your analysis.
- Enable caching of external resources
- Comply with your website’s robots.txt instructions, but these can also be replaced with other instructions that you specify
- Check load times