It often seems like patterns in Web creation overturn 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 Web’s front pages, and their goal has always been to list high-quality websites that are important to a search word.There is no better way than to make it follow these requirements to drive traffic to your website.
It sounds simple, but Search Engine Optimization (SEO) is a career that works full time. Over the years, search engines have altered their tactics, the things they calculate, and their other hidden formulas, and we’ve modified the way we create websites on top of all that.
As high as ever, the need for SEO is, and SEO experts are used to the rapid pace of change. Nevertheless, some modifications are major enough that we have to re-examine how search engines do what they do and adapt SEO best practises to match the actual reality.
What does SSR mean? And why does that matter?
Search engines have been analysing websites since their invention by reading the HTML created by their servers. However, the word Server-Side Rendering (SSR) is fairly recent. We only named it “rendering” until the last few years, because it was the only way Web pages were served.
They have proven to be the best way to create dynamic websites that are efficient and scalable.
The end-user experience benefits from CSR, but it poses a range of concerns regarding maintaining consistent ranking and placement criteria within the results of the search engine. Most major websites, and most eCommerce sites in particular, have solved this by making a web page’s “indexable” content on the server and then moving to CSR to handle the page once it has been loaded. We also know that SSR will render a site slower when not performed correctly. Speed and efficiency are equally, if not more, critical today to ensure ranking/placement for search engines. If a search engine could crawl CSR-generated websites, making the entire app with CSR would be simpler and quicker, as you’re going to need it for the fancy bits. The biggest search engines are beginning to support CSR in their crawler bots right now, and finally, despite doing no SSR at all, we can see many early adopters with very high result rankings.
However, as a crucial factor for customer acquisition and revenue generation, companies have come to rely on SEO and search engine marketing (SEM). Anything that challenges the tactics that have worked effectively over the past decade has the potential to have a major effect on the continued success of an organisation.It is a big question to ask merchants to make the transition to Progressive Mobile Apps (PWAs) and Web storefronts that are heavily reliant on CSR versus SSR.
With PWA Studio, we strive to create what we see as the Web’s future (where SSR dependency is no longer a difficult requirement) while also accommodating the current needs and concerns of the merchant.
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. 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 storey 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.
- 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.
- 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 #pwaSlackchannel, 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 offers a solution for simple page data and metadata rendering by SSR. This serves as a basic use case considered by PWA advocates to be a best practise. Other solutions are available for more complicated requirements (rendering the full-page React app).
- With the headless browser crawler, Prerender. A Rendertron solution is being suggested by Jordan Eisenburger (Experius). The dev approach is non-invasive, but first-time users can have trouble setting it up. On the Eleganza website, this method is used and will go to open source as SEOSnap.
- As it is a well-known and embraced technique, Shane Osbourne (JH) suggests pre-endering the React app with something like ReactDOMServer. This approach is feasible, capable, and fast, but, along with the other requirements of Magento 2, it needs a NodeJS Web server in development.
- To serve up prerendered HTML pages, Niklas Wolf (Mothership) suggests routing bots to a service such as Prerender.io. This is similar to the Experius prerendering process, except that instead of a custom hosted one, it uses a SaaS prerenderer.