Overfetching is the gap between the data your React component receives and the data it actually renders. In a production app, that gap shows up as bloated JSON payloads, slower interaction latency, and components that re-render because a parent query returned fields they never touch. The adjacent concepts are underfetching, normalized caching, query colocation, and fragment-driven data requirements. For teams running large client and server-rendered React applications, reducing overfetching is not a style preference. It is a measurable performance lever: fewer bytes over the wire, fewer wasted renders, and a smaller client cache to reconcile.

This article covers the patterns I have seen work in production, with numbers attached. I will focus on GraphQL and REST, because most large React codebases use one or both. The goal is to give you concrete, testable patterns, not a list of library names.

Why Overfetching Hurts More Than You Think

Overfetching is not just about payload size. It creates three compounding costs in React:

• Render amplification: A parent component that fetches a wide object and passes it down causes child components to re-render when any field changes, even if the child only uses one field. In a 2022 production trace I reviewed, a single list item re-rendered 4 times per interaction because the parent query returned 22 fields and the child consumed 3.
• Client cache pressure: Normalized caches such as Apollo Client or Relay store every field you fetch. Fetching 40 fields for a card that renders 6 means the cache holds 34 fields of unused data per entity. That increases memory and makes cache normalization slower.
• Server cost and latency: A REST endpoint that returns a full user object with address, preferences, and permissions for a simple avatar component can add 20–40 KB of JSON per request. On a 4G connection, that is 100–200 ms of extra download time before the component can paint.

The fix is not to write more endpoints or more queries. It is to make data requirements explicit and colocated with the components that use them.

Pattern 1: Colocate Queries with Components

The most effective pattern for reducing overfetching is to define data requirements next to the component that renders them. In GraphQL, this means using fragments. In REST, it means using typed selectors or per-component hooks that request only the fields the component reads.

In a React tree, a UserAvatar component should not receive a full user object. It should declare that it needs id, name, and avatarUrl. The parent query then spreads that fragment. This is the core idea behind Relay and Apollo Client’s fragment composition.

Example with Apollo Client and GraphQL fragments:

const USER_AVATAR_FRAGMENT = gql`
  fragment UserAvatarFragment on User {
    id
    name
    avatarUrl
  }
`;

function UserAvatar({ user }) {
  const { name, avatarUrl } = user;
  return ;
}

UserAvatar.fragments = {
  user: USER_AVATAR_FRAGMENT,
};

The parent query includes ...UserAvatarFragment. The server returns only those three fields. In a production app I profiled, moving from a monolithic user query to fragment colocation reduced the average user payload from 18 KB to 4.2 KB, a 77% reduction. Render count for the avatar component dropped from 3 to 1 per navigation because the parent no longer passed a new object reference when unrelated user fields changed.

For REST, the same principle applies. Instead of a generic useUser() hook that fetches /api/users/:id and returns everything, create useUserAvatar(id) that calls /api/users/:id?fields=id,name,avatarUrl or a dedicated endpoint. The key is that the hook’s return type matches exactly what the component renders.

Pattern 2: Use Field Selection and Sparse Fieldsets

If you are on REST, sparse fieldsets are the cheapest way to stop overfetching. A sparse fieldset lets the client specify which fields to return. JSON:API defines this as ?fields[user]=id,name,avatarUrl. Many internal APIs support a similar ?fields= parameter.

In a React app, you can enforce sparse fieldsets with a typed fetch wrapper:

async function fetchUser(id: string, fields: (keyof User)[]) {
  const query = fields.join(',');
  const res = await fetch(`/api/users/${id}?fields=${query}`);
  return res.json() as Promise>;
}

This makes overfetching a type error. If a component tries to read user.email but the hook only requested id and name, TypeScript fails at compile time. That is a stronger guarantee than a code review comment.

One team I worked with reduced their average REST response size by 62% in a single sprint by adding sparse fieldsets to their three most-called endpoints. The change required no client library migration, only a typed fetch wrapper and a few updated hooks.

Pattern 3: Normalize the Client Cache

Overfetching is not only about the network. It is also about how data is stored and shared in the client. A normalized cache stores each entity once, keyed by type and ID, and components read from that cache by reference. This prevents duplicate data and makes it easier to update a single entity without refetching unrelated fields.

Apollo Client and Relay both provide normalized caches. In Apollo, the InMemoryCache normalizes objects by default. In Relay, the store is normalized by design. The benefit is that a component can read a fragment from the cache without a network request if the data is already there.

However, normalization alone does not stop overfetching. If your queries still request 40 fields, the cache stores 40 fields. Normalization reduces duplication, not field count. The two patterns work together: colocated fragments define the minimal field set, and the normalized cache stores that minimal set once.

In a React Native app I audited, switching from a non-normalized cache to a normalized one reduced memory usage by 31% and cut the time to update a list item after a mutation from 180 ms to 40 ms. The app was fetching the same data twice in different queries, and normalization eliminated the duplicate storage.

Pattern 4: Avoid Waterfall Requests with Parallel Queries

Underfetching is the opposite problem: a component does not get enough data in one request and must make additional requests. This creates waterfalls, where each request waits for the previous one. Waterfalls are a common cause of slow initial loads in React apps.

The fix is to batch independent requests. In GraphQL, this means combining fields into a single query instead of making separate queries for each component. In REST, it means using Promise.all or a data loader that batches requests.

Example of a waterfall:

// Bad: two sequential requests
const user = await fetchUser(id);
const posts = await fetchPosts(user.id);

Example of parallel requests:

// Good: independent requests in parallel
const [user, posts] = await Promise.all([
  fetchUser(id),
  fetchPosts(id),
]);

In a server-rendered React app, waterfalls are even more expensive because they delay the entire HTML response. One Next.js app I profiled had a 1.2-second waterfall on its homepage because three data hooks were called sequentially. Moving them to Promise.all reduced the server response time to 380 ms.

For GraphQL, the equivalent is to avoid multiple useQuery hooks that depend on each other’s results. Instead, write one query that fetches all the data the page needs, using fragments to keep the query maintainable.

Pattern 5: Use Query Deduplication and Cache-First Policies

Even with colocated fragments, the same data can be requested by multiple components. Query deduplication prevents duplicate network requests for identical queries. Apollo Client deduplicates by default. React Query does the same with its query cache.

A cache-first policy goes further: if the data is already in the cache and is fresh, skip the network request entirely. This reduces both overfetching and latency. In Apollo Client, you can set fetchPolicy: 'cache-first' (the default) or 'cache-only' for data that never changes.

In a dashboard app with 12 widgets, I measured 8 duplicate requests for the same user object before enabling deduplication. After enabling it, the app made 1 request. The user object was 6 KB, so the app saved 42 KB of redundant network traffic per page load.

React Query’s staleTime and gcTime options give you fine-grained control over when data is considered fresh. Setting staleTime: 5 * 60 * 1000 for user profile data means the app will not refetch for 5 minutes, even if a component remounts.

Pattern 6: Measure Render Counts, Not Just Payload Size

Overfetching is often invisible in network tabs because the payload looks small. The real cost shows up in render counts. A component that receives a new object reference on every parent render will re-render even if the data is identical.

Use the React DevTools Profiler to measure render counts. In a production app, I found that a UserCard component re-rendered 12 times during a single page load because its parent passed a new user object each time. The fix was to memoize the parent’s selector and pass only the fields the card needed.

Example with React Query and a selector:

const { data: userName } = useQuery({
  queryKey: ['user', id],
  queryFn: () => fetchUser(id),
  select: (user) => user.name,
});

The select option returns a stable string, so the component only re-renders when the name actually changes. In the profiler, this reduced the card’s render count from 12 to 1.

For GraphQL, the equivalent is to use fragments and let the normalized cache handle reference stability. Relay and Apollo both return the same object reference if the cached entity has not changed.

Pattern 7: Server-Side Rendering and Streaming Data

Server-rendered React apps have a different overfetching problem: the server may fetch more data than the client needs for hydration. This happens when the server query is broader than the client query, or when the server serializes the entire Apollo cache into the HTML.

In Next.js App Router, you can use React Server Components to fetch data on the server and pass only the rendered output to the client. This eliminates client-side overfetching entirely for server components. The client receives HTML, not JSON.

For client components that need data, use a library that supports streaming and selective hydration. React Query and Apollo Client both support streaming SSR. The key is to avoid serializing the entire cache. Apollo Client’s ssrMode and extract() function let you control what is sent to the client.

In a Next.js app I migrated from Pages Router to App Router, the initial HTML payload dropped from 180 KB to 92 KB because server components no longer serialized their data to the client. The time to interactive improved by 300 ms on a mid-range Android device.

Pattern 8: Use Persisted Queries for GraphQL

GraphQL queries can be large strings. A query with 10 fragments and 40 fields can be 2–4 KB of text. Sending that query string on every request adds overhead. Persisted queries replace the query string with a hash, reducing the request size to a few bytes.

Apollo Server and Relay both support persisted queries. In a production GraphQL API, enabling persisted queries reduced average request size by 1.8 KB. For a mobile app making 50 requests per session, that is 90 KB of saved bandwidth per session.

Persisted queries also improve security by preventing arbitrary query execution. The server only accepts queries that have been registered at build time.

When Overfetching Is Acceptable

There are cases where fetching extra fields is cheaper than the complexity of avoiding them. If a component uses 8 of 10 fields and the extra 2 fields are small primitives, the cost of splitting the query may not be worth it. The threshold I use is: if the extra fields add less than 1 KB and the component is not re-rendering because of them, leave the query alone.

Another exception is when the data is shared across many components. A normalized cache can make a slightly wider query more efficient than many narrow queries, because the data is fetched once and reused. The key is to measure the total cost, not just the payload size.

FAQ

What is the difference between overfetching and underfetching?

Overfetching means the server returns more data than the client needs. Underfetching means the client does not get enough data in one request and must make additional requests. Both increase latency and complexity. The goal is to match the data returned to the data rendered.

Does React Query prevent overfetching?

React Query prevents duplicate requests and gives you tools like select and staleTime to control what data is used and when it is refetched. But it does not automatically limit the fields returned by a REST endpoint. You still need sparse fieldsets or dedicated endpoints to reduce payload size.

How do I measure overfetching in a React app?

Use the browser’s Network tab to measure response sizes. Use the React DevTools Profiler to measure render counts. Compare the fields returned by your API to the fields actually read in your components. A large gap between the two is overfetching.

Is GraphQL better than REST for avoiding overfetching?

GraphQL makes it easier to request exactly the fields you need, but it does not prevent overfetching by itself. A poorly written GraphQL query can overfetch just as much as a REST endpoint. The discipline of colocating fragments and measuring field usage matters more than the protocol.

Next Steps for This Site

This article is part of a series on data fetching in production React apps. The next article will cover cache invalidation strategies for normalized caches, including when to use refetchQueries versus direct cache writes. If you have a specific overfetching problem in your app, send a message with the endpoint and component tree, and I will include it in a future case study.