Rendering SEO Success (Part 2)

In our previous post, we looked at the different rendering strategies we have when building web applications, each with their own advantages and drawbacks. And we looked at the importance of good SEO, especially in B2B eCommerce. You can check that post out here if you missed it!

Ideally, you’d want the speed of static rendering and the up-to-date data from dynamic rendering for different sections of the same web page. This is especially important for B2B eCommerce sites where, in order to achieve a higher SEO ranking, the site needs to load the latest data, and fast.

But seamlessly rendering a page’s static and dynamic data separately used to be quite the task as:

• The engineering complexity of implementing different rendering strategies on a framework that did not natively support the feature was immense...
• Which called for separate teams to build and maintain the appropriate infrastructure themselves, making this endeavor quite a resource-intensive one.

This was until React introduced Server Components out of the box, which allowed us to have both static and dynamic rendering on the same page with minimal effort through Out of Order Streaming Components.

React Server components also boast other features such as zero-bundle-size components, which means that (unlike with SPAs) new features can be added without contributing to the size of the application bundle which has to be downloaded by the browser to make the site interactive. This means that the user doesn’t have to wait longer to use the site as the scope/feature set of a site grows—which is perfect in the case of B2B eCommerce sites.

Not having to send the JavaScript bundle of components to the browser also allows for new patterns of development which weren’t previously possible, like direct database calls within the component itself. This used to not be possible because if you used a database call in your component, it would send that code to the browser, posing a massive security risk. Now with server components, we can guarantee that such code runs exclusively on the server and never on the client/browser.

Out of Order Streaming Components

Out of Order Streaming essentially allows allows the server to send information to the browser in chunks as it becomes available, rather than waiting to send the complete page (in essence, how an online video buffers while you’re already watching it).

Because of this, we can instruct the server to immediately send the static sections of a page while its dynamic sections are still being generated or fetched. This means a much improved FCP (and potentially LCP) and better perceived overall performance.

As illustrated in the example above, the static elements of the web page, namely the image carousel and the product information, can be sent first with fallbacks for the dynamic elements of the page: the product availability and pricing. Once the data for those sections is ready, it’ll be sent to the browser to replace their respective fallbacks—the best of both dynamic and static rendering.

The connection between the browser and frontend server is not closed until all parts of the page have been streamed in, so crawlers are present until the entire page loads, ensuring even the dynamic elements, like product availability and pricing, are indexed for search engines.

Another type of page where Out of Order streaming would be ideal is a product category page. The product category details would be static, but the product lists and filters would be dynamic because they depend on the user’s selection.

Conclusion

Out of order is indeed the ‘best of both worlds’, but that doesn’t mean it’s THE choice for all your webpages. At the end of the day, the rendering strategy you choose depends on the kind of website you have.

That being said, implementing Out of Order streaming on our B2B enterprise clients’ websites (in addition to other frontend, backend and design features) has shown to significantly improve SEO rankings and, as a result, generate record-breaking sales quarters!

In short 👇🏻

• It bypasses the issues we had with MPAs, SPAs and the other strategies mentioned in our last post, especially when it comes to rendering more complex pages and sites, as with B2B sites.
• It effectively handles large pages and sites with 10000+ product pages, etc., because of the reduced client-side bundle size through server components.
• A feature once limited to larger teams due to its resource-intensive practices and engineering complexity is now achievable by smaller teams due to out-of-the-box support by libraries and frameworks.

Good SEO (and everything that contributes to it) is the difference between having the best products and actually selling them.

Want to learn more? Let’s talk!