Server-side Vs Client-side Rendering and Changing SEO Practices

Sometimes it seems like web development trends are reversing conventional wisdom every six weeks. Only a few things have remained constant throughout, and one of them is that good websites need to show up well in search results.

Search engines are the front pages of the web, and their mission has always been to list websites that are high-quality and relevant to a search term. There is no better way to drive traffic to your website than to make it meet these criteria.

It sounds simple, but Search Engine Optimization (SEO) is a full-time profession. Search engines change their strategies, the things they measure, and their other secret formulas over the years, and on top of all that, we’ve changed the way we build websites.

The need for SEO is as strong as ever, and SEO experts are used to the rapid pace of change. Still, some changes are so large that we have to re-examine how search engines work — and adjust SEO best practices accordingly.

In this guide, we’ll talk about the inner workings of search engines and how they affect your SEO. In particular, the differences between server-side rendering vs client-side rendering.

In this guide to server-side vs client-side rendering, you’ll learn:

What are SSR and CSR? And why are they important?

Since their invention, search engines have analyzed websites by reading the HTML generated by their servers. The term server-side rendering (SSR) is fairly new, though. Until the last few years, we just called it “rendering,” since it was the only way web pages were served.

The web has matured into a rich application platform. Everyone now expects web pages to be as interactive and dynamic as any other graphical interface, and we achieved that by inventing ways to write HTML on the fly with JavaScript.

Much of the modern web is built with these more flexible client-side rendering (CSR) techniques. They have proved to be the best way to author reliable and scalable dynamic websites.

CSR manages the routing flexibly without refreshing the page every time a user requests a different route, making it an often-faster initial load time. But, SSR rendering displays a fully populated page on the first load for any route of the website, with a slightly slower initial load time but faster rendering after the initial load.

Search engine crawler bots aren’t full-fledged web browsers, though. They have to move rapidly through a vast web of content.

For years, these bots didn’t run JavaScript and didn’t support CSR — if your site used CSR to display its content and functionality, the Googlebot just wouldn’t see it.

Because this was the case for so long, SSR is well recognized as the content rendering method best suited for ensuring HTML content is readily available for modern search engine crawlers/bots. At this point, we’ll assume that knowledge of SSR is well understood from a strategy and execution perspective.

CSR is beneficial to the end-user experience, but it raises several questions around ensuring consistent ranking and placement requirements within search engine results.

Most major sites, and especially most eCommerce sites, have addressed this by rendering the “indexable” content of a web page on the server and then switching to CSR to manage the page once it’s loaded.

SSR is the great, time-tested solution here. We also know that — when not executed properly — SSR can make a site slower.

Today, speed and performance are equally, if not more, important to ensure search engine ranking/placement. If a search engine could crawl CSR-generated websites, then it would be simplest and fastest to render the whole app with CSR, since you’re going to need it for the fancy parts.

Right now, the largest search engines are starting to support CSR in their crawler bots, and eventually we will see many early adopters with very high result rankings, despite doing no SSR at all.

However, businesses have come to rely on SEO and search engine marketing (SEM) as a critical factor for customer acquisition and generation of revenue. Anything that is counter to the strategies that have successfully worked over the past decade has the potential to have a significant impact on a business’ continued success. Asking merchants to make the leap to Progressive web Apps (PWAs) and web storefronts that rely heavily on CSR versus SSR is a tall ask.

With PWA Studio, we’re attempting to build for what we view as the future of the web (where reliance on SSR is no longer a hard requirement) while still accommodating for the present merchant needs and concerns.

So, let’s dive into the weeds a bit and review some of the arguments for and against SSR with PWA Studio, as well as some of the current options/capabilities for meeting these requirements.

Is SSR necessary?

There’s really no simple answer here. There are arguments for and against SSR, especially in the context of PWAs and dynamic JS-based applications/storefronts. There is certainly no argument about the efficacy of SSR over the lifetime of the web.

It does, however, add additional overhead and cost to do it, so we need to be clear-eyed about how much SSR is still doing for us and whether it’s worth it. Given modern browsers and technologies, it’s justifiable to question the continued importance (and additional cost) of SSR — especially when it is increasingly evident that search engines are capable of indexing dynamic sites and continually improving their effectiveness.

The advantages and disadvantages of SSR

Development teams often focus on a few key arguments for and against SSR.

For SSR
Against SSR

We need to implement SSR because it has worked before and continues to work. We are not willing to risk our business objectives while developers wait around to see how the SSR/CSR story develops in the coming years.

Other big technology companies continue to invest in and have a reliance on SSR. It’s not just for SEO.

High-profile web development leaders often discourage SSR because poor implementations can reduce performance and ranking. In PWAs especially, the UI should load as early as possible, even if it’s not fully loaded. SSR does a lot of up-front calculations which the CSR-driven client might not even use.
SSR is still needed to serve metadata for media objects since the SEM bots still aren’t running JavaScript.
Risks of platform lock-in or code duplication. The premier experience of an eCommerce PWA is client-side, as a dynamic native-feeling JS app, but cross-platform SSR requires implementing that experience in two different places — the server and the client — and the logic can’t really be reused. The solution to that is to use a server that can render HTML generated by the frontend UI code. The best server for this is NodeJS, since it can run the JavaScript UI code directly and generate HTML responses. But that does lock developers into a particular backend technology.
As a partner or agency, not having a clear SEO strategy that relies on SSR is hindering our ability to build merchant confidence and improve adoption of PWAs.
SSR increases TCO because of the additional tech requirements and the extra steps in development and continuous integration. It’s easier than it used to be, but it’s always extra work to write code that is going to run in two very different environments.
There isn’t enough data/evidence that minimal (or even no) SSR actually works without having a significant impact on SEO.
As search engines get better at indexing dynamic sites — and the major ones are great at it today — it becomes harder to justify the cost of SSR.

What SSR solutions exist for PWA Studio?

Does PWA Studio, today, support SSR? While there are a number of possible solutions and areas for enhancement, yes, PWA Studio does support and allow for SSR. If you’ve been a participant in our community #pwa Slack channel, then you know this has been a hot topic of late that we’ve spent a good amount of time covering in our weekly PWA Studio Community meetings.

To summarize the current options for implementing SSR, today, with PWA Studio:

So, what’s next for PWA Studio and SSR?

We’ve listened to and learned from our community, and we understand that our purposely minimal SSR solution doesn’t offer enough to confidently start new store deployments. SSR will be less important in the web’s future; we remain certain. But we need to help you do more today.

Our greatest hope is that PWA Studio will give you options for sane, simple SSR by opening up the server-side render rules as part of our new extensibility framework. We want an ecosystem of PWA extensions to grow, and they should include options for server-side render.

Choice is good, and Adobe Commerce isn’t Adobe Commerce without powerful extensibility.

However, we’re still committed to delivering improved tools and resources to simplify the developer experience and cost in this area. We continue to explore ways to improve the out-of-the-box SSR story for merchants and partners — whether it’s putting React SSR in the core, making Rendertron our preferred solution, enhancing UPWARD SSR abilities, or even retiring UPWARD entirely.

We’re actively discussing and reviewing each option alongside our highly engaged community to make sure that, in the end, we deliver a viable and scalable solution that delivers best-in-class SEO for PWA Studio storefronts.

Resources

Glossary

Frequently asked questions about server-side vs client-side rendering

Is client-side better than server-side rendering?

Server-side rendering can improve your load times. This in turn can improve your site performance. However, client-side rendering can reduce the burden on your server and can be more flexible to the specific needs of your website.

Is server-side rendering better for SEO?

As server-side rendering can improve your load times and user experience, which aid SEO rankings. What’s more, search engines can index your pages quicker, as the content is loaded before the page is rendered for the user.

Is server-side rendering more secure?

Server-side rendering is seen as more secure. It adds an extra layer of external validation. For example, if a user fills out a form incorrectly on a server-rendered webpage, they’ll receive error messages telling them to amend the details accordingly. This security is absent from client-rendered sites.