For most WordPress projects, start with the built-in REST API if its routes provide the data your application needs. Consider WPGraphQL when clients benefit from selecting fields and related content in one query—and your team can install, extend, secure, and maintain the plugin. Neither is automatically faster: compare both against the same real workload.
What you’re comparing
The WordPress REST API is part of WordPress. It exposes resources such as posts and pages as JSON over HTTP and supports the Block Editor. WPGraphQL is a separate, free, open-source plugin that adds a GraphQL schema for querying WordPress content. GraphQL is the query language and runtime model; WPGraphQL is the specific WordPress implementation considered here. WordPress Developer Resources · WPGraphQL plugin
How the trade-offs compare
| Decision | WordPress REST API | WPGraphQL |
|---|---|---|
| Availability | Included with WordPress, with core resource routes available through the site’s REST API. | Requires installing and maintaining the WPGraphQL plugin. |
| Request model | Call resource-oriented URLs using HTTP methods; responses have defined structures and can include linked or embedded resources. | Send a query selecting fields and nested relationships exposed by the schema. |
| Discovery | The site index and OPTIONS requests help discover routes; REST schemas describe accepted and returned data. | Schema introspection and GraphiQL-style tools help explore available fields and compose queries. |
| Collection pagination | Use page, per_page, and offset. The documented per_page maximum is 100 records; responses can include X-WP-Total and X-WP-TotalPages. |
WPGraphQL documents Relay-style cursor pagination with first/after or last/before. Choose page sizes appropriate to the workload. |
| Authentication and writes | Cookie authentication is intended for a logged-in WordPress context and still requires the user’s relevant capability. | Most mutations require authentication and the proper capability; mutations use POST. |
| Performance and caching | Resource routes and standard HTTP behavior are familiar to HTTP caches, but actual caching depends on responses, headers, and hosting. | Field selection can reduce downloaded data and a query can combine related data, but deeply nested connections may increase server and database work. GET queries, persisted queries, and Smart Cache may help in supported configurations. |
| Team impact | Uses WordPress’s native interface and often avoids extra API infrastructure when core routes are sufficient. | Adds GraphQL-specific schema, query, compatibility, and operational knowledge. |
For REST details, see the REST API reference and pagination guide. WPGraphQL documents its query model and performance considerations.
Choose based on the application
Use REST for straightforward integrations
Choose the REST API when standard post, page, or media routes supply what a script, app, or frontend needs. It is available without adding a GraphQL plugin, works with clients that can make HTTP requests and process JSON, and has documented discovery, pagination, and authentication behavior. The WordPress handbook says, “If you want a structured, extensible, and simple way to get data in and out of WordPress, you probably want to use the REST API.” WordPress REST API Handbook
Consider WPGraphQL for varied, related data
WPGraphQL may suit a headless frontend or integration whose screens need different combinations of fields and related content. A client can request the fields it needs and combine related data in a query instead of making separate requests for every resource. This is useful only if the schema and compatible extensions expose the content required, and the team is ready to operate GraphQL safely.
Keep both when their roles are distinct
A site can retain REST-based WordPress behavior or integrations while using WPGraphQL for a separate frontend. Whether that arrangement is practical depends on plugin support, access policies, monitoring, and the team’s capacity to maintain both interfaces; it is not a universal requirement.
Rank #2
Does WPGraphQL perform better?
There is no universal speed winner. GraphQL can reduce round trips and response size for a particular query, but selecting too much data or deeply nesting relationships can increase resolver and database work. REST performance also depends on route choice, payload, hosting, network, and caching. Compare the same screens and content requirements rather than treating either API’s name as a performance guarantee.
WPGraphQL’s comparison page reports a demonstration involving 100 posts: REST downloaded 335 kB and took 7.91 seconds, while WPGraphQL downloaded 6.4 kB and took 67 ms. The page does not state a year for the example. These are vendor-reported results for a particular site and query, not an independent controlled benchmark or an expected result for other WordPress projects. WPGraphQL comparison page
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
Benchmark the work your site will do
Test representative reads and writes on the actual theme, plugins, content relationships, authentication setup, network, cache, and hosting. Measure response size and server time alongside database/query behavior, cache hits, and invalidation. Include realistic cache misses as well as hits; otherwise a result may describe only one part of production behavior.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Plan access control and custom fields
Neither API overrides WordPress permissions. Map public reads, editorial actions, and mutations to the required user capabilities, then verify what anonymous and authenticated users can retrieve. Pay particular attention to custom fields, custom post types, and fields added by plugins: adding a field to an API does not make it safe to expose.
WordPress says cookie authentication applies when the API is used inside WordPress and the current user is logged in, and the user still needs the appropriate capability. For supported remote use, the documentation recommends application passwords; it says its separately documented Basic Authentication plugin should be limited to development and testing. WordPress REST API authentication WPGraphQL’s mutation guidance likewise requires authentication and appropriate capabilities for most mutations, which use POST. WPGraphQL mutations
Quick Recap
A practical decision checklist
- Choose REST if its existing routes cover the data and actions your application needs.
- Consider WPGraphQL if client-selected fields and related data in one query solve a recurring integration problem.
- Inspect the actual REST routes or GraphQL schema, including plugin-provided fields, before committing to either.
- Account for team familiarity, plugin compatibility, custom-extension work, security review, and ongoing monitoring.
- Benchmark representative requests and cache behavior before making a performance decision.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
