- SAP Managed Tags:
Introduction
SSR activation and challenges behind are often misunderstands. This article will try to clarify as much as possible why SSR is not just like CSR in server side.
We won't enter in technical optimisation details. Two great articles already did that:
- https://community.sap.com/t5/crm-and-cx-blogs-by-sap/composable-storefront-ssr-performance-and-timeo...
- https://community.sap.com/t5/crm-and-cx-blogs-by-sap/managing-performance-of-server-side-rendering-i...
The aim is to give you general understanding of different challenges and steps to achieve acceptable SSR performance.
NodeJS single-thread
One big misunderstanding is how SSR (NodeJs) is processing/rendering page content. Unlike CSR (Browser), NodeJS is single thread to handle multiple concurrent calls where Browser is handling one unique page rendering with multi-CPU/threads.
In other words, hardware vertical scale cannot be executed to improve performance or to support more workload. Even worst, any page rendering must be optimized as much as possible to be executed as fast as possible by one unique CPU in order to let main thread handles next request as quickly as possible. This queue task processing can easily lead you to timeout issue.
Two solutions must be applied :
- Tracking down non-optimal code processing in local environnement with SSR mode activated
- Add CDN caching at each SSR outputs
Acceptable processing time for SSR output computation is between 1s to 5s. Less 1s is rarely possible due to the fact, we're executing scripting langage (JavaScript) with some external dependencies calls (OCC API) in single-thread.
CDN Caching
As you understand in previously chapter, SSR outputs must be set in cache. Even more, SSR is not designed to handle concurrent calls. That point means SSR should serves one time each page and then CDN should serve the content. In other words :
- Caching TTL must be longer as possible (at least one day)
- Most of content must be designed for anonymous users (personalized content will be served by CSR re-hydratation).
- CDN Caching size should be enough large to contain all websites pages
SSR Caching
When SSR is processing content, common data or/and calls can be executed to render any page as BaseSites for example. It is important to identify those parts and set them in local SSR caching.
OCC API Caching
SSR is executing same code as Browser to render a page. For that, it will need to do external call to fetch raw data (CMS Content, Product Content). SAP Commerce Cloud is exposing this data through OCC API.
As other anonymous content, OCC API should be setup in cache to reduce processing/response time. And, as we already see, it is more impacting in SSR than CSR.
For caching, two different strategy can be applied :
- OCC API caching at local level with ehCache (in each node)
- OCC API caching at global level in CDN caching
OCC API local caching reduces network latency but it increases memory consumption and caching warm up time. Where, global CDN caching is increasing network latency (from 10 to 30ms), has some limitation with SNAT exhaustion and reduces caching warm up time.
When it is possible, CDN caching should be privileged.
WebCore vitals
Last but not least : the WebCore vitals, It is not rare to see better response time in CSR than SSR first. LCP and FCP are deeply impacted by CSR re-hydratation.
When SSR first is activated, Browser will load firstly full page content from SSR output and then apply what we call CSR re-hydratation. If CSR has been badly implemented, the CSS and Images can be reloaded on top of SSR rendering. This overriding processing delays LCP / FCP response time.
Solution is to debug closely how page is rendering by browser and see how CSR can be applied to enrich SSR rendering instead of overriding it.
In other hand, you should not forget to optimise page content size: HTML, CSS, JS, and Images. Less data your browser has to compute and better WebCore vitals will be. 4MB of resources to load a page is a threshold that should not be exceeded.
Conclusion
SSR optimisation is complex topic and it can demand significant effort. You should not under estimate the complexity. SAP Commerce Composable Storefront is a headless framework solution that should help you to achieve easier this goal (and many others). However, the best practices must be respected.
SAP Expert Services can help you to apply those best practices and implement the needed optimisations.
4 Comments
