The web development community is rapidly adopting Single Page Applications (SPAs) for various web projects. React, for example, has seen a 1633% increase in projects using SPAs from 2018 to 2021 (according to Builtwith).
Fortunately, there have been improvements made in frameworks for speed, and Google has improved its Web Rendering Service over time. However, there are still actions you can take to make further improvements.
But what are the best ways to serve content to SPAs to both search engines and users?
This removes all the complexities of dynamic rendering, showing search engines exactly what you would show to users instead of serving two separate versions that can have different representations.
Server-side rendering, however, requires a server to process all rendering requests — both from search engines and users — which can be extremely resource-intensive depending on how the SPA has been built, potentially being a highly costly approach.
Dynamic rendering is the process of serving a pre-rendered/server-side rendered version of a website to bots and the client-side rendered content to users. Google has recently come out to say this is a workaround and not a long-term solution, recommending other solutions.
Realistically, moving away from dynamic rendering can be extremely hard, as the other alternatives can be extremely costly or are long-term projects. Dynamic rendering does not penalize your website unless you serve completely different content to Google and users. However, Google has stated that “it creates additional complexities and resource requirements”.
Dynamic rendering, when done right, allows you full control of what to present to search engines. This can be especially helpful for removing unnecessary user functionality elements to search engines, allowing for a clearer view of content.
Dynamic rendering also does nothing to help speed performance for users, as the content must rely on the user’s device to render, which generally takes much longer than the other solutions outlined.
This results in lower Core Web Vitals scoring, where the Largest Contentful Paint (LCP) is usually the biggest offender and scores websites into the “Poor” category. This puts it at a disadvantage in Google’s rankings if other competitors perform better in Core Web Vitals.
Optimization efforts could be undertaken, to help improve load time and LCP, but this would make more sense to be actioned in line with scaling out a different rendering option.
These files can then be stored on your CDN (Content Delivery Network) or general cloud infrastructure, reducing costs compared to server-side rendering.
As the HTML files can be stored on an edge server, this would not incur costs like server-rendering would.
With all the above solutions, hydration is required to make any user-specific elements interactive.
The DOM nodes that would require hydration would be elements like search functionality, facet filters, navigation carousels, etc., allowing them to interact with the user. Although these would not specifically impact rankings for Google, the search engine still wants to see exactly what the user would see where possible.
Two approaches to hydration are often recommended: Full Page Hydration and Partial Hydration.
Full Page Hydration is where the framework process the full DOM to check to add interactivity where necessary, reconciling the rendered state with the application state.
Partial hydration is a more flexible option. Only certain parts of the DOM — dynamic sections called ‘islands’ — are processed by the framework to add interactivity. This option requires much less processing as only certain specified DOM nodes are checked rather than all DOM nodes.
Hydration is not always an independent rendering solution. It is a process that can take place with SSR or static rendering to add user interactivity.
Depending on your website setup, hydration can be required to render the page’s core content. For example, the shell of your website (e.g. navigation bar) can be server-side rendered, and user interactivity is required for the core content of the page — take those online newspaper simulator websites, for example. In this case, hydration is required to render the core content – which would be relying on Google to render it.
Other hydration approaches, like progressive hydration, can also be applied, which can help with speed metrics (e.g. Time To Interactive).
Which one to use?
Which rendering solution to use would be entirely dependent on your situation.
For large-scale websites that have frequently updated on-page content (e.g. news websites), server-side rendering is the way to go for your pages.
Alternatively, if you use a framework like Gatsby or Astro and don’t frequently update the content on your website (excluding sections like a blog where posts can be added with a new build from the headless CMS), static rendering will be the way to go.
Dynamic rendering, however, should only be seen as a short-term solution, as Google ultimately wants to see exactly what the user sees.
Hydration will happen naturally for both rendering solutions if your website has any user interactivity features, though different approaches can be taken to help increase speed for users.