Reducing API Calls in Next.js with Headless WordPress

In a headless WordPress setup, WordPress serves as your content management system (CMS) while the front-end is built in Next.js. This approach provides flexibility, scalability, and performance—but only if you manage your data fetching wisely. Excessive or redundant API calls can lead to sluggish performance and reduced user satisfaction.

In this article, we’ll look at strategies for minimizing API calls when pulling data from WordPress (via REST or GraphQL), and how to implement smart caching to speed things up. We’ll keep it platform-agnostic and focus on the underlying techniques, making it easy to adapt to any hosting environment.

---

Why Reducing API Calls Matters

Every time you make an API call, you pay a performance cost. A call might involve:

• Network overhead (DNS lookup, TLS handshake, etc.).
• Server processing time.
• Parsing/transforming large JSON payloads.

The more calls you make, the more these costs add up. By batching queries and caching responses, you can cut down on unnecessary round trips and drastically improve load times. This isn’t just good for performance; it’s also cost-effective and better for the environment (fewer CPU cycles, less energy consumption).

---

Quick Overview: Headless WordPress and Next.js

1. Headless WordPress
   Traditionally, WordPress both stores and renders your content. In a headless setup, WordPress is used purely as a content database. You retrieve your data using either the WordPress REST API or WPGraphQL, and you’re free to build the front-end in any framework—like Next.js.
2. Next.js for the Front-End
   Next.js offers two primary ways of fetching data:
   • Static Site Generation (SSG): Data is fetched at build time in getStaticProps. Pages become static HTML, which you can then serve very quickly to users.
   • Server-Side Rendering (SSR): Data is fetched on-demand in getServerSideProps. The server generates the page on each request, which can be helpful for highly dynamic or personalized data.
   You can also combine these approaches across different pages if needed.
3. Where Bottlenecks Occur
   • Making multiple calls for the same data across various components or pages.
   • Pulling more data than you actually need.
   • Not leveraging caching effectively.

---

1. Batching Queries

Batching queries means requesting all needed data in fewer API calls. Instead of hitting multiple endpoints or multiple GraphQL queries, you consolidate them into a single call (or at least as few as possible).

Using WPGraphQL

If you’re already using WPGraphQL, batching is straightforward because GraphQL lets you request exactly the data you need in a single query. Rather than hitting www.example.com/wp-json/wp/v2/posts for posts, www.example.com/wp-json/wp/v2/users for authors, and so on, you can combine these into one query.

Example GraphQL Query:

GetPostsAndAuthors {
  posts(where: { status: PUBLISH }, first: 10) {
    nodes {
      id
      title
      slug
      author {
        node {
          name
          avatar {
            url
          }
        }
      }
    }
  }
  users(where: { role: AUTHOR }) {
    nodes {
      name
      description
    }
  }
}

In a single request, we get both posts (including author data) and a list of authors. This reduces the number of round trips and ensures your front-end has all it needs in one payload.

Combining REST Endpoints

If GraphQL isn’t an option, you can still create a custom REST endpoint to aggregate multiple pieces of data:

• Create a custom route in your WordPress theme or a custom plugin that fetches posts, authors, categories, etc., then returns them in a single JSON response.
• In Next.js, you’d just fetch from this single endpoint.

// pages/api/combined-data.js
export default async function handler(req, res) {
  try {
    const [posts, authors] = await Promise.all([
      fetch("https://example.com/wp-json/wp/v2/posts").then((r) => r.json()),
      fetch("https://example.com/wp-json/wp/v2/users").then((r) => r.json()),
    ]);

    res.status(200).json({ posts, authors });
  } catch (error) {
    res.status(500).json({ error: "Failed to fetch data" });
  }
}

Then in your Next.js page:

// pages/index.js
export async function getStaticProps() {
  const res = await fetch("https://your-website.com/api/combined-data");
  const { posts, authors } = await res.json();

  return {
    props: { posts, authors },
    revalidate: 60, // for incremental static regeneration
  };
}

By consolidating these calls, your Next.js page makes one request instead of two or more.

---

2. Caching Strategies

Once you’ve minimized the total number of calls, you also want to make sure that repeat requests don’t cause a performance hit. This is where caching shines.

Client-Side Caching

One of the simplest ways to reduce overhead is to cache data in the browser or in a client-side store. Libraries like React Query or SWR provide caching out of the box, including features like revalidation and invalidation.

import useSWR from "swr";

const fetcher = (url) => fetch(url).then((res) => res.json());

function MyComponent() {
  const { data, error } = useSWR("/api/combined-data", fetcher, {
    revalidateOnFocus: false,
  });

  if (error) return <div>Error loading data</div>;
  if (!data) return <div>Loading...</div>;

  return <div>{/* render your data here */}</div>;
}

Here, data is cached and will not be re-fetched unless the user revisits the page after a certain period, or re-focuses the tab (unless we disable it or change that setting).

Server-Side Caching

Next.js Caching

• Incremental Static Regeneration (ISR): When using getStaticProps, you can set a revalidate interval to rebuild the page after a certain time.
• getServerSideProps: You can implement your own caching logic at the server level (e.g., using memory caching or a key-value store) if dynamic data needs to be fetched on every request.

WordPress-Level Caching

• Object Caching: Tools like Redis or Memcached can store query results.
• Page Caching Plugins: Caching plugins (e.g., W3 Total Cache, WP Super Cache) generate static HTML pages within WordPress to reduce load on the database.

Whenever possible, reduce the workload on your WordPress server by caching frequently requested data. This ensures that each Next.js request to the WordPress API returns a fast, pre-computed or partially-cached response.

---

3. Reducing Unnecessary Overhead

Even with batching and caching, it’s possible to over-fetch or make redundant queries.

1. Fetch Only the Data You Need
   In GraphQL, specify the exact fields your front-end requires. In REST, use query parameters or custom endpoints to minimize response size.
2. Consolidate Data for Commonly Visited Pages
   If multiple pages use the same data, consider pulling that data once (in a higher-level component or layout) and passing it down, rather than refetching in each component.
3. Avoid Re-Rendering Loops
   Components that re-fetch data on every state update can quickly balloon your API usage. Make sure your data fetching is intentionally triggered (e.g., once on component mount, or after specific user actions).

---

4. Practical Implementation Examples

Let’s combine these ideas into a quick example using Next.js and WPGraphQL.

Install & Configure WPGraphQL

• In WordPress, install the WPGraphQL plugin.
• Configure your WordPress site to serve GraphQL at yourdomain.com/graphql.

Set up Apollo Client in Next.js
You can create a simple Apollo setup file:

// lib/apolloClient.js
import { ApolloClient, InMemoryCache } from "@apollo/client";

const client = new ApolloClient({
  uri: "https://yourdomain.com/graphql",
  cache: new InMemoryCache(),
});

export default client;

Then in your page:

// pages/index.js
import client from "../lib/apolloClient";
import { gql } from "@apollo/client";

export async function getStaticProps() {
  const { data } = await client.query({
    query: gql`
      query GetPostsAndAuthors {
        posts(where: { status: PUBLISH }, first: 10) {
          nodes {
            id
            title
            slug
            author {
              node {
                name
                avatar {
                  url
                }
              }
            }
          }
        }
        users(where: { role: AUTHOR }) {
          nodes {
            name
            description
          }
        }
      }
    `,
  });

  return {
    props: {
      posts: data.posts.nodes,
      authors: data.users.nodes,
    },
    // revalidate determines how often static content is refreshed
    revalidate: 60, 
  };
}

export default function HomePage({ posts, authors }) {
  // Render your data here
  return (
    <div>
      <h1>Recent Posts</h1>
      {posts.map((post) => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>by {post.author.node.name}</p>
        </article>
      ))}
      <h2>Authors</h2>
      {authors.map((author, idx) => (
        <div key={idx}>
          <strong>{author.name}</strong>
          <p>{author.description}</p>
        </div>
      ))}
    </div>
  );
}

Here we’ve batched the retrieval of posts and authors into one GraphQL query, and we’re caching results with the default InMemoryCache in Apollo, plus Next.js is revalidating this data every 60 seconds.

---

5. Monitoring & Performance Tuning

1. Count Your Requests
   Use your browser’s DevTools (Network tab) to see exactly how many requests are made and to track response sizes.
2. Analyze Build Performance
   Keep an eye on your Next.js build logs. If you’re pulling large amounts of data at build time, you might consider pagination or partial fetches.
3. Use Performance Audits
   Tools like Lighthouse or PageSpeed Insights give an overview of front-end performance. For server performance, try a monitoring tool that can show CPU and memory usage.

---

6. Common Pitfalls (and How to Avoid Them)

1. Overfetching
   Requesting more data than needed might simplify your code initially, but it’ll slow everything down. Always tailor queries to each view’s needs.
2. Cache Invalidation
   Stale data is a real problem. If your content updates often, implement revalidation intervals or dynamic triggers (like Next.js on-demand revalidation if your site supports it).
3. Ignoring SSG for Everything
   If you rely purely on server-side rendering, you might be hitting your WordPress server more frequently than necessary. Use Static Site Generation whenever possible and revalidate periodically.

---

Conclusion

Reducing API calls in a Next.js + Headless WordPress setup is all about smart batching, aggressive caching, and fetching only what you need. By carefully combining GraphQL (or combined REST endpoints), caching at both the client and server level, and thoughtful data-fetching patterns, you can seriously cut down on unnecessary overhead and dramatically boost performance.

Key Takeaways:

• Leverage GraphQL or custom REST endpoints to retrieve everything in fewer calls.
• Use client-side caching libraries (like React Query or SWR) to minimize repeated fetches.
• Take advantage of Next.js features like Incremental Static Regeneration to update static pages at set intervals.
• Continuously monitor and refine your setup to stay on top of potential performance issues.

With these strategies in place, your site will be more resilient, faster to load, and more enjoyable for your visitors—no matter where it’s hosted or how complex your WordPress data might be.

---

Further Resources

• Next.js Official Documentation
• WordPress REST API Handbook
• WPGraphQL Documentation
• Apollo Client Documentation

And as always, keep exploring, experimenting, and tuning your setup to find the best balance between build times, page load speeds, and editorial workflows. Happy coding!