DrupalRX Field Guide
Enterprise Drupal diagnosis, architecture, and implementation notes.
Diagnosis

Why Your Drupal JSON:API Responses Are Slow — And The Six-Step Fix

Sun, 05/24/2026 - 14:00 admin
JSON:API Performance Caching Sparse Fieldsets Headless Drupal

One of the most common complaints I hear on headless Drupal projects is:

  • “Drupal is slow.”

Usually, Drupal isn’t actually the problem.

What’s slow is the way Drupal is being used.

I’ve seen teams throw additional servers, Redis clusters, CDN configurations, and expensive infrastructure at performance problems that ultimately came down to a handful of poorly designed API requests.

In almost every headless Drupal project I’ve worked on, the same patterns appear repeatedly:

  • Massive payloads
  • Unnecessary includes
  • Missing caching
  • Poor frontend consumption patterns
  • Expensive entity relationships

The good news is that most JSON:API performance problems are fixable.

The better news is that many can be fixed without touching infrastructure.

Let’s walk through the six most common causes.

The Real Problem

Before optimizing anything, understand this:

Most teams measure performance incorrectly.

They open the browser network tab.

They see a 2-second response.

They conclude:

  • “Drupal is slow.”

But response time is only one part of the equation.

Questions you should ask:

  • How large is the payload?
  • How many entities are included?
  • Is the request cached?
  • Is the database query expensive?
  • Is serialization expensive?
  • Is the frontend requesting unnecessary data?

Without understanding these variables, you’re optimizing blindly.

Fix #1: Stop Returning Entire Entities

This is the biggest offender.

Many teams request everything.

Example:

  • /jsonapi/node/article

At first this seems harmless.

But Drupal is now returning:

  • title
  • body
  • author
  • media references
  • taxonomy references
  • timestamps
  • metadata
  • revision information
  • relationships

And potentially much more.

Most clients only need a fraction of that data.

Use Sparse Fieldsets

Instead:

  • /jsonapi/node/article?fields[node--article]=title,path,field_image

Now Drupal returns only what the frontend needs.

Benefits:

  • Smaller payloads
  • Faster serialization
  • Faster parsing
  • Better frontend performance

This should be standard practice on every headless Drupal project.

Fix #2: Reduce Include Abuse

Includes are powerful.

They’re also dangerous.

Example:

  • ?include=field_author,field_author.user_picture,field_tags

Seems reasonable.

Then someone adds:

  • ?include=*

Now every relationship gets loaded.

The API response explodes.

Payload sizes grow dramatically.

Serialization time increases.

Caching becomes less effective.

Be Intentional

Only include what the frontend requires.

Ask:

What is actually displayed on the page?

Not:

What might be useful later?

Over-fetching is one of the most expensive habits in headless architecture.

Fix #3: Audit Entity Relationships

Sometimes the API request isn’t the problem.

The content model is.

Example:

  • Article

→ Author

→ Department

→ Location

→ Organization

→ Related Content

→ Media

→ Taxonomy

Each relationship introduces additional work.

Deep relationship chains create expensive requests.

Simplify Where Possible

Not every relationship needs to be traversed in real time.

Sometimes:

  • denormalized fields
  • cached views
  • aggregated data

provide better performance.

Good architecture is often more valuable than additional infrastructure.

Fix #4: Fix Your Caching Strategy

Many headless projects accidentally disable caching benefits.

Common mistakes include:

  • No CDN
  • No edge caching
  • Cache bypassing
  • Incorrect cache headers

Drupal’s cache system is extremely powerful.

Yet many implementations never leverage it properly.

Verify Cache Behavior

Review:

  • Cache-Control headers
  • Surrogate keys
  • CDN configuration
  • Reverse proxy behavior

Questions:

Is the response cached?

How long?

Where?

How often is it invalidated?

If you don’t know the answer, start there.

Fix #5: Review Serialization Costs

Developers often focus exclusively on database queries.

Serialization can become the bottleneck.

Large entity graphs require Drupal to:

  • Load entities
  • Resolve relationships
  • Build responses
  • Serialize data

Repeatedly.

Large payloads increase serialization costs dramatically.

Measure Before Guessing

Use profiling tools.

Identify:

  • Query time
  • Serialization time
  • Network transfer time

The slowest part of the request may not be what you expect.

Fix #6: Fix Frontend Consumption Patterns

Sometimes the backend is performing perfectly.

The frontend is not.

I’ve seen React and Next.js applications:

  • Make duplicate requests
  • Fetch unnecessary resources
  • Refetch aggressively
  • Load large collections repeatedly

Developers often blame Drupal when the frontend is generating the problem.

Audit Client Behavior

Review:

  • React Query
  • RTK Query
  • SWR
  • Apollo

Look for:

  • Duplicate fetches
  • Missing caching
  • Unnecessary invalidation

The fastest API request is the one you never make.

Real-World Example

Imagine a homepage displaying:

  • Featured articles
  • Featured authors
  • Hero image
  • Categories

A common implementation:

  • /jsonapi/node/article?include=*

Response:

  • 1.8 MB
  • dozens of entities
  • multiple nested relationships

A better implementation:

/jsonapi/node/article?fields[node--article]=title,path,field_image&include=field_image

Result:

  • dramatically smaller payload
  • faster response
  • better cache efficiency

The user sees the exact same page.

Common Mistakes

Mistake #1: Optimizing Infrastructure First

Don’t buy bigger servers before measuring the API.

Mistake #2: Using Include Everything

If you’re using include=* regularly, investigate why.

Mistake #3: Ignoring Frontend Behavior

Not every performance issue originates in Drupal.

Mistake #4: Measuring Only Response Time

Payload size matters.

Serialization matters.

Caching matters.

JSON:API Performance Checklist

Payload Review

  • Sparse fieldsets used
  • Payload size measured
  • Unused fields removed

Include Review

  • Includes minimized
  • No wildcard includes
  • Relationship depth reviewed

Content Model Review

  • Entity relationships audited
  • Expensive traversals identified

Caching Review

  • CDN configured
  • Cache headers verified
  • Cache invalidation understood

Frontend Review

  • Duplicate requests eliminated
  • Client-side caching enabled
  • Query patterns reviewed

Final Thoughts

Drupal JSON:API is capable of excellent performance.

Most performance problems are architectural, not platform limitations.

Before adding infrastructure, ask:

  • Are we returning too much data?
  • Are we including too many relationships?
  • Are we caching effectively?
  • Is the frontend behaving responsibly?

Fix those four areas first.

In many cases, you’ll discover that Drupal wasn’t slow at all.

The implementation was.

Need Help Diagnosing a Headless Drupal Platform?

DrupalRX helps organizations evaluate headless Drupal architectures, JSON:API performance bottlenecks, frontend integration patterns, and modernization strategies.

If your APIs feel slow and you’re not sure where the bottleneck lives, start with a performance review before spending money on additional infrastructure.

standard