This is a shortened version of a very long and detailed article published here. https://blog.webiny.com/serverless-side-rendering-e1c0924b8da1

The article talks about our experience of implementing SSR mechanism for Webiny Serverless CMS. Many of our findings are transferable to other solutions so it will hopefully provide you with some useful insight.

In short (and believe me, this is short):

• single page applications (SPAs) are cool but unfortunately, have bad SEO support
• learn about different approaches of rendering on the web by checking out this Google article, and choose the approach that works best for your use case
• for the Webiny Page Builder app, we decided to try “Prerendering on-demand” (using chrome-aws-lambda) and “SSR with (re)hydration”
• implementing both of these approaches in the AWS cloud can be achieved with just a couple of serverless services — S3, Lambda, API Gateway, and CloudFront
• prerendering on-demand works and it’s a good approach if the initial loading screen (shown while the app is initializing) is not an issue in terms of UX, and SEO is your only concern, otherwise use SSR with (re)hydration
• allocate more RAM (1600MB+ ) to the Lambda function that will actually be doing the pre-rendering, and a minimum amount of RAM to the one that will be just serving static files (128MB or 256MB)
• although we didn’t try it, you would probably need to implement some form of caching of the prerendered content, so that you get a better SEO results by returning the initial HTML faster
• when implementing SSR with (re)hydration, allocate more RAM to the Lambda function that will actually be generating the SSR HTML
• in general, SSR is a resource-intensive task, which will prevent you from serving your website fast enough, so you will most likely need to implement some kind of caching
• we used CloudFront CDN to cache SSR HTML and depending on the app you’re building, choose between short and long-lived cache TTLs
• if going with the latter, know that you will need to do cache invalidation which can get tricky very quickly
• do cache-invalidation selectively, or in other words, if possible, invalidate cache only for pages that actually require it — this may save you significant amount money along the way (cache invalidation requests are charged by CloudFront)
• if the content is changing very frequently, use shorter TTLs because it’s more effective
• the good news is that, with Webiny, this is all handled and maintained for you, feel free to check us out if this sounds interesting 🚀 🙂

I hope you found this useful - make sure to check out the full article.