Server-Side vs Client-Side Rendering And Changing SEO Practices
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.