Most WordPress site owners never think about the REST API until something breaks. The editor feels sluggish, a mobile app takes forever to load a post list, or a headless front end that should feel instant instead stutters on every navigation. In each case the page itself can be perfectly cached and fast, while the API responses behind it are slow. Fixing that gap is a different job from normal page-speed work, and it rewards a methodical approach: measure first, trim what each response carries, cache what can be cached, and fix the database queries underneath.
What a Slow REST API Response Actually Costs
The REST API is how WordPress talks to anything that is not a traditional page load. The block editor saves and previews through it. Mobile apps, decoupled front ends, search overlays, and many plugins fetch content through it too. When an endpoint takes two or three seconds to answer, the user experiences that delay directly, and no amount of page caching helps, because API responses are usually generated fresh on every request.
The cost shows up in places people misdiagnose. An editor that hangs when saving is often blamed on the hosting, when the real culprit is a plugin adding expensive fields to every post response. A search box that feels dead for a second after each keystroke is often a search endpoint running an unindexed query. Before changing anything, it is worth establishing which of these stories is actually yours.
Step 1: Measure Before You Fix Anything
Open your browser’s developer tools, go to the Network tab, and use the part of your site that feels slow — save a post in the editor, run a search, or load the app screen. Filter the network list for “wp-json” and look at the Time column. A healthy local endpoint usually answers in well under half a second. Anything consistently over a second deserves investigation, and anything over two seconds is a real problem.
Note which endpoints are slow, not just that something is slow. The posts endpoint, the search endpoint, and custom plugin endpoints behave very differently and need different fixes. Run the same test twice: the first request may be cold, while the second shows the steady-state speed. If you have Query Monitor installed, it can show the database queries behind a request, which becomes essential in Step 5. Write down your three slowest endpoints and their timings. That short list is your baseline, and it is what you will measure your fixes against.
Step 2: Ask for Less Data in Every Response
The single most common REST API mistake is fetching everything when you need a fraction of it. A request to the posts endpoint returns the full post object by default: content, excerpt, author details, embedded media, and every registered custom field. If your app only displays titles and featured images, most of that payload is dead weight that still has to be queried, assembled, and transferred.
The _fields parameter is the fix. Appending _fields=id,title,link,_links style selections to a request tells WordPress to return only those fields, and the savings on large post lists are often dramatic. Similarly, respect per_page: asking for 100 posts when the screen shows 10 means the database does ten times the work for content nobody sees. Keep page sizes close to what is actually displayed, and paginate properly instead of fetching the whole archive at once.
One caution: _embed is convenient because it bundles related resources like authors and featured media into one response, but it can quietly multiply the work behind a request. Use it only when you genuinely need the embedded data on every item, and prefer _fields to trim the embedded objects too.
Step 3: Stop Plugins From Bloating Every Response
Plugins can register extra fields on REST responses, and those fields run code on every single request to that endpoint — even when the consumer never uses them. A plugin that attaches related posts, computed statistics, or external API data to every post object can turn a fast query into a slow one, and the cost is invisible unless you look for it.
Audit what is actually attached to your busiest endpoints. Deactivate plugins one at a time on a staging site and re-measure the endpoint timing; the method is unglamorous but it finds the culprit fast. The same discipline applies to plugin audits generally, and the approach in our guide to auditing plugin performance works here too. If a plugin’s extra fields are not used by anything, disable them in the plugin’s settings or remove the plugin. If you wrote the code yourself, only register fields on the specific routes that need them, and keep the callbacks cheap — no extra database queries per item inside a field callback if you can avoid it.
Also check for endpoints you do not need at all. Some plugins register REST routes for features you never enabled. You do not have to delete them, but knowing they exist matters, because each one is surface area for abuse and for accidental load from bots probing your API.
Step 4: Cache Responses the Right Way
Because API responses are dynamic by default, caching is where the biggest wins usually live — but it has to be done carefully, because caching the wrong thing leaks private data.
Start with object caching. An object cache like Redis stores the results of expensive database queries and computations so repeat requests do not redo the work. Our guide to setting up Redis for WordPress walks through the setup, and once it is running, many slow endpoints improve without any code changes, because WordPress core and well-written plugins already use the object cache.
For custom endpoints you control, cache the assembled response itself. A transient that stores the response for a few minutes is often enough: public data like a post list or a product feed rarely needs to be second-fresh, and a short cache lifetime keeps it accurate while removing most of the load. Always include the request parameters in the cache key, so a request for page 2 never returns page 1’s cached data.
Public GET endpoints can also benefit from server-level caching. A CDN or reverse proxy can cache responses for anonymous requests, much like full-page caching, provided the endpoint returns proper cache headers and never serves logged-in or personalised data. The rule is simple and non-negotiable: if a response differs per user, or contains anything private, do not cache it at a shared layer. Cache it per user, or not at all.
Step 5: Fix the Database Underneath the API
When an endpoint is slow even with small payloads, the database is usually the bottleneck. A posts query that scans thousands of rows, a search that runs without a usable index, or a meta query joining a bloated postmeta table will be slow no matter how you format the response.
Query Monitor is your best friend here. It lists every query behind a request, how long each took, and which code triggered it. Look for three patterns: single queries taking a long time, the same query repeated dozens of times (the classic N+1 problem, often caused by per-item field callbacks), and full-table scans on large tables. Our guide to finding slow database queries explains each pattern and the safe fixes.
The usual culprits are familiar: an autoloaded options table stuffed with expired data, postmeta bloat from old plugins, and search queries that cannot use an index. Clean up what is genuinely dead, add an index only when you understand the query it serves, and if the slow queries all trace back to a plugin, that plugin is the problem, not your database. When the whole database is the bottleneck rather than one query, it is time to talk to your host about resources or a managed database, because no plugin setting will fix an undersized server.
Step 6: Cut Authentication Overhead
Authenticated requests cost more than anonymous ones. Each request must verify credentials, load the user, and check capabilities, and some authentication methods add a full session load on top. For apps and integrations making many requests, that overhead adds up — and it is charged on every call, before your endpoint code even runs.
If an integration uses cookie authentication from a browser context, make sure it is not also loading a heavy session or triggering admin-side code on every request. Application Passwords, available in WordPress core, are a cleaner fit for external apps: they authenticate directly without a browser session. Whatever method you use, avoid re-authenticating from scratch on every call when the client can reuse a token, and set sensible rate limits so a misbehaving client cannot hammer an expensive endpoint thousands of times an hour.
Also watch for background traffic. Bots routinely probe the REST API, and a flood of requests to the users endpoint or the search endpoint can look exactly like a performance problem. Rate limiting at the server or CDN level, and disabling user enumeration you do not need, keeps that noise from consuming real capacity.
Step 7: Server-Level Wins That Help Every Endpoint
A few server settings lift every endpoint at once. PHP OPcache, which caches compiled PHP so it is not recompiled on each request, is one of the cheapest wins available — see our OPcache setup guide for how to check and enable it. A current PHP version matters for the same reason: newer versions execute the same code faster, and the API path, which runs a lot of PHP per request, benefits more than a cached page does.
Keep-alive connections and HTTP/2 or HTTP/3 also help clients that make many API calls in sequence, because they avoid repeating the connection handshake. And if your API traffic comes from one region, make sure your server is near that region — a slow API response caused by sheer distance cannot be fixed with a plugin. These are not API-specific tricks, but they raise the floor for everything the API does.
What Not to Do
Three tempting shortcuts cause more harm than good. First, do not disable the REST API entirely. The block editor depends on it, and so do many plugins; disabling it breaks editing and often breaks features silently. Restrict access where it makes sense, but leave the API working.
Second, do not cache authenticated or personalised responses at a shared layer. A cached response served to the wrong user is a privacy incident, not a performance win. Third, do not raise per_page to its maximum and fetch everything in one call to “reduce requests”. One enormous response is usually slower and more fragile than several paginated ones, and it punishes mobile users on slow connections most.
A Simple Checklist
Work through this list in order, measuring after each step: identify your three slowest endpoints; trim responses with _fields and sensible page sizes; audit plugin fields on those endpoints; add object caching and short-lived response caching for public data; fix the slow queries Query Monitor exposes; streamline authentication; and confirm OPcache and a current PHP version are in place. Stop as soon as the timings meet your target — most sites find that the first three steps alone solve the problem.
A fast REST API rarely needs exotic engineering. It needs someone to look at what each endpoint actually returns, what it actually queries, and what is being cached — and to trim the waste before buying bigger hosting. Do that, and the editor, the app, and the headless front end all get faster together.
