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 is it important?
- Is SSR necessary?
- The advantages and disadvantages of SSR.
- What SSR solutions exist for PWA Studio?
- So, what’s next for PWA Studio and SSR?
- Frequently asked questions
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.
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.
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.
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.
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:
- UPWARD provides a solution for simple SSR rendering of page data and metadata. This serves a simple use case that PWA advocates consider to be a best practice. For more complex requirements (rendering the full page React app), other solutions are available.
- Prerender with a headless browser crawler. Jordan Eisenburger (Experius) recommends a Rendertron solution. It is noninvasive to the dev process, but first-time users may have difficulty setting it up. This tool is used on the Eleganza site and will go open source as SEOSnap.
- React App. Shane Osbourne (JH) recommends pre-rendering the React app with something like ReactDOMServer because it is a well-known and supported approach. This approach is doable, capable, and fast, but it requires a NodeJS web server in production, along with the other requirements of Adobe Commerce.
- Prerender.io. Niklas Wolf (Mothership) recommends routing bots to a service such as Prerender.io to serve up prerendered HTML pages. This is similar to the prerender approach used by Experius, except it uses a SaaS prerenderer instead of a custom hosted one.
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.
- Server-side rendering (SSR) — where browsers and search engines request information from servers to render a website.
- CSS — Cascading style sheets (CSS) is used to render the style and layout of HTML webpages. It alters elements like font, spacing and decorative features.
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.