In today’s digital landscape, transitioning from a traditional CMS to a headless CMS promises big gains in efficiency, scalability, and flexibility. This move enables organizations to deliver content seamlessly across multiple platforms, boost site performance, and future-proof their digital strategy. However, it’s essential to approach implementation with the right expertise and planning to avoid common pitfalls that can negate these benefits. I want to discuss a situation where a site with Next.js was making roughly millions of API calls per day and how we were able to get that down to just thousands of calls per day!
 

You can easily see when our optimizations took effect. 

This was a critical issue for the website because they were making way too many redundant and unnecessary API calls which were compromising the performance and scalability of the site as driving up the costs.
Understanding the problem

• Next.js Link Pre-Fetching: Normally Next.js Links optimize the user experience making navigation near instantaneous and smooth. It does this by prefetching the pages for each link in the background, which in this case was leading to all those excessive and redundant API calls.
• SSR and SSG Confusion: Prefetching pages really only optimizes Static Site Generation (SSG) pages. Because when using SSR the API calls must be made every time a page is fetched. Where with SSG the API only needs to be called once per page on build.
• ISR Incompatibility: Incremental Static Generation sounds like it would be the perfect solution here, but there are some issues with on-demand revalidation (topic for another day)

What the problem looked like in practice is, anywhere on the page there was a link that was visible, Next.js would go and fetch that page in the background and in doing so it would also make any API calls found on that page as well. Leading to not just the api calls needed for the page you are on being made, but any page linked on that page as well. So, in our case where a homepage that should only be making 6 API calls is making more than 150 APIS calls which was a major concern.

Our solution was to refine our SSR approach to leverage our CDN and deliver pages through the CDN cache. This means now every time a page is called, instead of hitting the API directly, if it's already cached then we will just serve that page directly from the CDN. Now this solves the redundant API calls we were making but also introduces a new issue. If new content is published in Contentstack we need to know, to invalidate the cache for those specific pages and serve the new content and not old content.

For this issue we created an automation recipe in Contentstack that triggered on publish of any content entry and will revalidate the cache in the CDN. You can think of it as similar to using ISR and having a webhook revalidate the cache on publish.

Key Take Aways

• Identifying Insufficiencies is Crucial: A lack of understanding and unchecked features like Next.js link prefetching and SSR configurations can inadvertently drive-up API request and costs.
• Caching Leveraging CDN Cache and Automation: Serving pages from the CDN cache and revalidating through Contentstack’s automations, sharply reduced the API usage and increased performance.
• Expert Implementation Pays Off: Implementing the right technical solutions and best practices is essential to success with a headless CMS and it is not all about technology choice.