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 large enough that we have to re-examine how search engines do what they do and adjust SEO best practices to reflect the current reality.
What is SSR? And why is it 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.
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. It’s a basic feature of the Web platform
CSR is beneficial to the end-user experience, but it raises a number of 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.
Common arguments for SSR typically boil down to:
• 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.
• SSR is still needed to serve metadata for media objects since the SEM bots still aren’t running JavaScript.
• 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.
• There isn’t enough data/evidence that minimal (or even no) SSR actually works without having a significant impact on SEO.
And arguments against SSR:
• 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.
• 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 one 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.
• 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.
• 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:
• 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.
• Shane Osbourne (JH) recommends pre-endering 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 Magento 2.
• 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 Magento isn’t Magento 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
• Dev docs: https://pwastudio.io, https://magento.github.io/pwa-studio/technologies/basic-concepts/content-rendering/
• SEOSnap: https://github.com/experius/SeoSnap
• React-SSR: https://www.npmjs.com/package/react-ssr
• Prerender.io: http://prerender.io/
