In today’s digital landscape, transitioning from a traditional CMS to a headless CMS promises significant gains in efficiency, scalability, and flexibility. This shift enables organizations to deliver content seamlessly across multiple platforms, improve site performance, and future-proof their digital strategy.

However, successful implementation requires the right expertise and planning. Without it, common architectural pitfalls can undermine the benefits of a headless approach. In this post, I want to share a real-world scenario where a Next.js site was generating millions of API calls per day and how we were able to reduce that number to just thousands.

You can clearly see when our optimizations took effect.

This issue was critical for the website because it was generating a large number of redundant and unnecessary API calls. These excessive requests negatively impacted site performance, limited scalability, and significantly increased operational costs.

Understanding the Problem

• Next.js Link Prefetching: Normally, Next.js links optimize the user experience by making navigation almost instantaneous. This works by prefetching linked pages in the background. However, in this case, that behaviour triggered excessive and redundant API calls.

• SSR and SSG Confusion: Prefetching mainly benefits Static Site Generation (SSG) pages. With Server-Side Rendering (SSR), API calls must be made every time a page is requested. With SSG, the API is typically called only once during the build process.

• ISR Limitations: Incremental Static Regeneration (ISR) initially appeared to be the ideal solution, but limitations around on-demand revalidation made it less suitable in this scenario.

In practice, the problem occurred whenever a link appeared within the viewport. Next.js would prefetch the linked page in the background. During that process, any API calls required by that page were also executed.

This meant the application was not only making API calls for the page currently being viewed, but also for every linked page visible on that page.

For example, a homepage that should have made only six API calls was instead triggering more than 150 API calls. This created a serious performance and scalability concern.

Our solution was to refine the SSR architecture and leverage CDN caching to deliver pages more efficiently. Instead of directly hitting the API every time a page was requested, the system first checks whether the page already exists in the CDN cache. If it does, the cached version is served immediately.

This approach eliminated the majority of redundant API calls. However, it introduced a new challenge: ensuring that newly published content would invalidate the appropriate cached pages so that users always see the latest content.

To address this, we created an automation recipe in Contentstack that triggers whenever a content entry is published. This automation automatically revalidates the relevant CDN cache entries.

You can think of this as a similar approach to ISR, where a webhook triggers cache revalidation whenever new content is published.

Key Takeaways

• Identifying inefficiencies is critical: A lack of awareness around features such as Next.js link prefetching or poorly configured SSR implementations can unintentionally increase API requests and operational costs.

• Leverage CDN caching and automation: Serving pages through CDN caching and revalidating them through Contentstack automations dramatically reduced API usage while improving performance.

• Expert implementation matters: Choosing a headless CMS is only part of the solution. Implementing the right architecture and best practices is essential for long-term success.