Page Speed Performance in Composable Systems
You’ve likely already gone to significant lengths to please other business teams in making the website as fast as possible for your users, including Most enterprise monolithic systems use a combination of the following strategies to improve page speed:
Caching at various levels, including page delivery via CDN
Load balancers to handle traffic spikes
Database indexes and other optimizations
Page speed is still an elusive target to hit with composable sites, though parts of the equation are much easier. Here are some considerations that help with page speed.
Leaning on the deployment platform
Perhaps the biggest shift is that many organizations choose to lean on the deployment platform to handle many of the difficult, backend optimizations. If you can offload content to a headless CMS and use a deployment platform to serve your content via a CDN, you’ll remove the need to manage backend optimizations.
Prerendering content
To further increase performance, if you can pretender high-traffic content during a build step, you’ll remove database connections and minimize the number of needed requests when serving a page. This will significantly speed up the site.
The rise of SSR in composable
Rendering content from the server is back on the rise, even in composable systems. However, when you lean on a deployment platform to deliver this content, it means that computations are happening on the edge, as geographically close to the request as possible.
With the recent advancements in edge computing, many are making the claim that SSR in a composable system are achieving near the same page speeds as pre-rendered (static) content.
Using a digital asset provider
Unless asset optimizations are a core feature for your chosen headless CMS, it’s worth looking into an asset provider if you haven’t already.
Services like Cloudinary are built to scale and can perform image optimizations on the fly, so that you render the smallest possible image size. And if you combine that with modern lazy loading practices, media won’t slow down your page.
The cost of JavaScript
There were two primary motivators for SSR gaining so much popularity again:
Handling dynamic content
Avoiding client-side JavaScript in complex systems
Many popular site frameworks are built on top of frontend UI libraries, like React. After the page is rendered, the JavaScript code would then "hydrate" the page to make it interactive. This requires a lot of JavaScript, and can greatly reduce performance.
Recent advancements with React and trends with site frameworks have enabled and favored shipping less JavaScript to the client, hydrating only what is necessary. Although this pattern is still new, it is expected to be the typical pattern for enterprise sites within the near future.