WP REST API vs GraphQL Performance 🔗 **Source:** [WP REST API vs GraphQL Performance](https://georgestephanis.wordpress.com/2025/12/28/wp-rest-api-vs-graphql-performance/) > [!note]+ Document Notes > tags: [wordpress, performance, api] > author: George Stephanis > source: georgestephanis.wordpress.com > reference: [https://georgestephanis.wordpress.com/2025/12/28/wp-rest-api-vs-graphql-performance/] > date created: 2025-12-29 00:00 > > # 🏷️ Title: WP REST API vs GraphQL Performance > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. --- ## 📝 Summary - The author investigates claims that WPGraphQL is 100x faster than the WordPress REST API for fetching 100 posts, based on a WPGraphQL marketing example. - By re-running tests locally and on hosted environments, and adding “realistic” plugin bloat, he finds WPGraphQL is faster, but usually by ~1.2–2x, not 100x. - Stakeholders: WordPress developers, API consumers, hosting providers, and project owners deciding between REST and GraphQL. - Risks: misleading benchmarks, over-optimizing for the wrong layer (API vs caching), and ignoring like-for-like tuning. - Bottom line: WP REST API is fine and deeply integrated; WPGraphQL can be modestly faster and more efficient when you control the stack, but comparisons must consider caching, payload size, and query patterns. --- ## 📖 Main Content - The article starts from a published comparison showing REST requests taking ~7.9s and 335kb vs WPGraphQL at 67ms and 6.4kb for 100 posts. The author doubts such a 100x gap and seeks to reproduce and explain it. - He confirms the original test URLs on a VIP-hosted site and uses `httpstat` to break down timings, distinguishing network effects from server processing. - Early investigation suggests WPGraphQL’s numbers likely benefited from strong persistent object caching and a primed cache, while the REST API may have been measured uncached, producing a misleading contrast of network waterfall screenshots. - To control variables, he creates a local test site (using Studio, SQLite, FakerPress content, and only WPGraphQL installed) with hundreds of posts, taxonomies, media, and comments. - Local WPGraphQL queries for 100 posts trend around ~0.84s with a steady content length. - Equivalent REST API requests return much larger payloads (about 22.6x bigger response size) and run in ~1.1s, roughly 1.3x slower than GraphQL. - He explains why: GraphQL lets the client explicitly select fields, batch related queries (e.g., authors) efficiently, and avoids loading all `postmeta` unless requested. The REST API, by design, returns a standardized, “fatter” representation, including all associated metadata. - Pushing the same dataset to a WP.cloud-hosted preview site and testing uncached responses, he again finds WPGraphQL somewhat faster on server processing time (e.g., ~698ms vs ~821ms for REST, ~1.18x faster), reinforcing a pattern of moderate—not extreme—performance advantages. - Recognizing that barebones sites aren’t representative, he then installs a more realistic plugin stack (Astra, ACF, WooCommerce, Elementor, Jetpack, MailPoet, Yoast, etc.) and runs repeated tests: - For a basic 100-post query, WPGraphQL averages ~5.3s while REST averages ~11.2s after dropping min/max outliers, making REST about 2.1x slower. - When expanding the GraphQL query to add taxonomies and a custom ACF-backed postmeta field, he still sees average GraphQL times around ~3.9s, which is actually lower than the previous “simpler” query set—likely due to local machine variability rather than intrinsic complexity. - In the wrap-up, he summarizes that: - The default REST API has excellent tooling and ships with WordPress Core. - WPGraphQL can deliver better performance through tailored payloads and query patterns when you bring your own frameworks. - Realistic expectations should be in the 1.2–2x improvement range, not 100x. - Performance comparisons must be “like-to-like” (similar caching, tuning, and workloads), not “souped-up vs stock.” --- ### 🗒️ Notes - The article is a response to a widely-circulated WPGraphQL page asserting massive performance superiority for GraphQL over the REST API, backed by Chrome DevTools screenshots of network timings for 100-post fetches. - The claimed numbers: REST download ~335kb in ~7.91s vs WPGraphQL ~6.4kb in 67ms. The author notes that the REST API request being over 100x slower is immediately suspicious and invites closer scrutiny. - He contacts Jason Bahl (the maintainer of WPGraphQL) to confirm the test setup and URLs and finds that both endpoints come from a VIP-hosted news site (twincities.com), which likely has sophisticated caching layers. - Using `httpstat`, he decomposes HTTP transactions to understand DNS lookup, TCP connect, TLS, server processing, and transfer times, enabling a more nuanced view than simple “time in DevTools.” - Initial external tests suggest that the WPGraphQL endpoint might be served mostly from a pre-warmed cache layer, while the REST endpoint is measured “cold,” inflating the relative advantage for WPGraphQL beyond what raw backend performance would explain. - To control for environment differences, he builds a local WordPress site with only FakerPress and WPGraphQL installed, creating a moderately large dataset (hundreds of posts, terms, media, and comments) to better simulate real content size. - On this clean local stack, GraphQL’s performance advantage is present but modest: roughly 0.84s vs 1.1s, which he attributes to: - Smaller JSON response sizes due to selective fields. - Batched querying approach that loads all posts, then deduplicates related authors into a single query, instead of per-post joins. - Avoiding blanket inclusion of `postmeta` that the REST API often bundles. - He emphasizes that database choice (SQLite vs MySQL/MariaDB) and hardware can skew absolute numbers, so he focuses on ratios between REST and GraphQL rather than claiming universal timings. - On a hosted WP.cloud preview with the same content, he confirms that an uncached WPGraphQL response’s server time (~698ms) is far above the 67ms quoted in the original marketing example, reinforcing that caching must account for much of the 100x claim. - Realistic “production” sites use many plugins that add database queries, hooks, and middleware to every request. By adding popular plugins (WooCommerce, Elementor, Jetpack, ACF, etc.), he simulates an environment closer to what agencies and site builders actually ship. - Repeating tests there, the gap between WPGraphQL and REST widens in ratio terms: REST can take around twice as long as GraphQL on comparable data requests, especially once you factor in REST’s larger payloads and more generic query patterns. - Intriguingly, more complex GraphQL queries that request additional fields and ACF-based postmeta do not always produce slower times in his runs; he attributes this to local machine noise and the fact that request variability can overshadow small theoretical complexity differences in single-run tests. - The conclusions stress that: - REST has a strong ecosystem, especially with the Gutenberg/block editor and existing React-based interfaces that rely on it. - WPGraphQL shines in custom front-end stacks (React, Vue, mobile apps) where eliminating over-fetching and reducing round trips matters. - Performance comparisons must be honest about caching and tuning. Using a primed object cache for one system and not the other, then claiming an “intrinsic” 100x API difference, misleads readers. - He uses a car-tuning analogy: comparing a heavily optimized, supercharged car against a stock competitor and calling it evidence that “brand A is 100x faster” is not a fair or generalizable claim. - The closing note credits Jason Bahl for reviewing methodology and clarifying how the original benchmarks were run, underscoring that this is a technical clarification rather than an adversarial critique. --- ## 📚 References - WPGraphQL performance comparison page (original claim): https://www.wpgraphql.com/docs/wpgraphql-vs-wp-rest-api#performance - WordPress REST API Handbook: https://developer.wordpress.org/rest-api/ - WPGraphQL plugin: https://www.wpgraphql.com/ - WordPress FakerPress plugin: https://wordpress.org/plugins/fakerpress/ - httpstat utility (used for HTTP timing analysis): https://github.com/reorx/httpstat - WPGraphQL for Advanced Custom Fields: https://github.com/wp-graphql/wp-graphql-acf --- ## 🗣️ Paraphrase - The article re-examines claims that WPGraphQL blows the WordPress REST API out of the water in performance. It reconstructs tests in controlled and realistic environments and finds that although WPGraphQL is generally faster and returns smaller payloads, the gap is usually within a factor of about two, not a hundredfold. - It argues that responsible performance comparisons must control for caching, payload selection, and plugin overheads. REST remains a solid, well-integrated default, while GraphQL is a strong choice for teams that can manage their own front-end stack and want more control over data fetching efficiency. --- ## 📰 Newsletter WordPress developers keep hearing that “GraphQL is 100x faster than REST.” In this deep-dive, George Stephanis reruns those benchmarks and finds a more grounded story: WPGraphQL usually wins—but by 1.2–2x, not two orders of magnitude. The key drivers are selective fields, batched queries, and caching. If you’re building headless, this is a must-read before committing your API strategy. Pair it with the REST API Handbook and WPGraphQL docs to benchmark your own stack instead of trusting marketing screenshots. --- ## ✅ Action Items #### DevRel - Publish a reproducible benchmark repo comparing REST vs WPGraphQL, with scripts, seed data, and docs. - Run live workshops on “measuring WordPress API performance” using `httpstat` and local/hosted environments. - Produce quickstarts for headless setups showing equivalent REST and GraphQL implementations. - Create content clarifying when REST is “good enough” vs when GraphQL gives material gains. - Encourage community feedback via GitHub issues and surveys on real-world API performance pain points. #### OSPO - Document guidance for using external GraphQL plugins vs core REST API in official projects. - Add training modules on performance benchmarking and honest comparisons for contributors. - Maintain a policy that public benchmarks must disclose caching, plugins, and environment details. - Track upstream performance regressions in REST and major API-related plugins. #### Community - Host contributor sessions focused on profiling and reducing API query overhead in popular plugins. - Provide “first issue” labels for performance-related contributions (caching, query optimization). - Engage sponsors to support performance sprints on high-impact sites and APIs. - Run coordinated performance drills across agencies to compare configuration best practices. #### WordPress - **Core:** Explore ways to optionally slim REST responses (field selection, meta gating) without breaking compatibility. - **Core Performance:** Maintain shared dashboards tracking REST and GraphQL patterns across typical workloads. - **Core AI:** Ensure any AI integrations respect performance budgets for API calls. - **Core Program Team:** Align release criteria with measurable performance baselines for API endpoints. - **Mobile:** Document best practices for mobile clients consuming REST vs GraphQL for offline-first scenarios. - **Playground:** Add pre-configured API performance labs to quickly reproduce tests. - **Community:** Include performance benchmarking topics in meetups and WordCamps. - **Training:** Build lesson plans on “Reading DevTools and httpstat for WordPress performance.” - **Marketing:** Avoid overselling any single API technology; highlight “pick the right tool” messaging. - **Support:** Add KB articles explaining common REST vs GraphQL performance misconceptions. - **Design:** Improve DevTools-like profiling surfaces in wp-admin for API calls. - **Documentation:** Expand DevHub examples for efficient REST usage (custom endpoints, field limiting). - **Photos / TV / Polyglots / Accessibility / Meta / CLI / Hosting / Tide / Openverse / Themes / Plugins:** - Integrate API performance notes into respective contribution docs (e.g., plugin authorship guidelines, hosting performance checklists, Tide scoring transparency around remote calls). #### The WPOCC - Fund repeatable benchmarking initiatives across multiple hosts and configurations. - Sponsor maintainers working on REST field selection, caching strategies, and GraphQL integrations. - Run documentation sprints to make performance tradeoffs clear to non-specialist devs. ### FAIR - Encourage transparent publication of benchmark configurations, datasets, and code. - Codify governance expectations that performance claims must be reproducible and caveated. - Provide shared scorecards for comparing REST and GraphQL setups across projects. --- ## 🧪 Hypotheses - H1: When payload fields are aligned, WPGraphQL’s uncached response times are typically 1.2–2x faster than REST, not 100x. - H2: The majority of extreme performance gains attributed to WPGraphQL in some benchmarks are due to caching differences rather than protocol differences. - H3: On “bloaty,” plugin-heavy sites, the ratio between GraphQL and REST performance widens, but absolute times are dominated by plugin overhead. - H4: Custom REST endpoints with explicit field limiting can close much of the gap with WPGraphQL on typical content queries. - H5: Developers systematically underestimate the role of response size in perceived API performance. --- ### 📊 Methodology - Build identical WordPress installs with scripted datasets (posts, taxonomies, media, meta). - Run REST and GraphQL queries that return equivalent logical data; measure with `httpstat` and browser DevTools. - Test across: (a) local environment, (b) low-cost host, (c) high-end managed host, each with/without persistent object caching and full-page caching. - Vary plugin stacks (barebones vs typical agency build vs WooCommerce-heavy) and compare ratios. - Record min/mean/max over multiple runs; exclude clear outliers; publish scripts and configs. --- ### ❓ Questions - How close can REST performance get to GraphQL with well-designed custom endpoints and field projections? - In real production traffic, how often are uncached responses the true bottleneck vs network, TLS, or client-side rendering? - How do different object cache backends (Redis, Memcached, APCu) affect GraphQL vs REST ratios? - What guidance should core provide to plugin authors to avoid pathological query patterns on both APIs? --- ### 🔮 Future Research - Systematic benchmarking of REST vs GraphQL across multiple content sizes (small blogs to huge newsrooms). - Evaluations of developer productivity and maintainability, not just raw latency. - Measuring impact of schema design (GraphQL) and route design (REST) on cacheability and CDN friendliness. - Tooling that auto-generates minimal REST payloads mirroring GraphQL selections. --- ### 💡 Implications - Practice: Teams should not automatically rewrite REST clients in GraphQL solely based on marketing benchmarks; instead, measure their own workloads. - Policy: Public benchmarks used in marketing should disclose conditions and clarify that extreme results often hinge on caching. - Security: Additional API layers (plugins, gateways) may widen attack surfaces; performance tuning must be balanced with hardening. - Education: Dev curricula should teach how to design efficient REST endpoints and GraphQL queries, plus how to interpret HTTP timings. - Funding: Performance sprints and benchmarking infrastructure are high-leverage investments for large WordPress ecosystems. --- ### 🧠 Learning Styles Assessment - Reading level estimate: around “technical blog for intermediate devs” (roughly Flesch–Kincaid grade 9–11; not formally computed here). #### 👀 Visual learners - Present: Conceptual contrast via numbers (timings, sizes), informal “before/after” scenarios. - Improve: Add simple charts of response times and payload sizes; diagrams of REST vs GraphQL query flows; screenshots annotated for DevTools / httpstat. #### 🔊 Aural learners - Present: None explicit. - Improve: 3–5 minute audio summary or podcast snippet walking through the benchmarks and conclusions. #### 🗣️ Verbal learners - Present: Clear narrative structure, definitions, and analogies (e.g., car tuning). - Improve: Glossary of terms (object cache, payload, postmeta, batching); more concrete “story” examples of actual client projects. #### 🧩 Kinesthetic learners - Present: Implicit how-to via described steps (build local site, run httpstat). - Improve: Step-by-step lab instructions and checklists; downloadable scripts to reproduce tests; small “try it yourself” experiments. #### 🧠 Logical learners - Present: Quantitative comparisons, averaged timings, elimination of outliers, cause-effect reasoning about caching and payload size. - Improve: Tables summarizing all runs; structured formulas linking payload size, queries, and response time; basic models predicting impact of additional plugins. #### 🧑‍🤝‍🧑 Social learners - Present: Collaboration with WPGraphQL maintainer; implied dialogue around methodology. - Improve: Guided discussion prompts for meetups; example Slack/Discord threads; community benchmarking challenges. #### 🧘‍♀️ Solitary learners - Present: Self-paced, linear article suitable for quiet reading. - Improve: Reflection prompts (e.g., “Benchmark your current site before choosing a new API stack”); self-check quiz on key concepts. #### 🌿 Naturalistic learners - Present: None. - Improve: Light analogies to ecosystems (e.g., caching layers as habitats); discussion of resource efficiency (bandwidth, CPU) as part of sustainability. --- ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Standard blog structure likely with headings and paragraphs. - Improve: Ensure clear heading hierarchy (H1–H3), descriptive link text, and language attributes set. #### Keyboard navigation - Present: Default WordPress theme behavior is generally keyboard-friendly. - Improve: Confirm visible focus styles, skip links, and no keyboard traps in theme or embedded code. #### Contrast and readability - Present: Depends on theme; WordPress defaults often meet basic contrast. - Improve: Check 4.5:1 contrast, line-height, and font size for long technical content. #### Text resizing and reflow - Present: Responsive layout typical of WordPress themes. - Improve: Validate at 200% zoom; honor `prefers-reduced-motion`; avoid horizontal scrolling where possible. #### Media and captions - Present: Primarily text; few or no images. - Improve: If screenshots are added, include alt text and captions; avoid auto-playing media. #### Forms and interactions - Present: Standard comment form only. - Improve: Clear labels, error messaging, and sufficient hit targets. #### Standards reference - Map any gaps to WCAG 2.2 AA criteria, especially 1.4.x (contrast, resizing), 2.1.x (keyboard), 2.4.x (navigation). --- ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focused on technical WordPress performance; not culture-specific. - Improve: Include examples from diverse hosting contexts (global bandwidth constraints, low-resource environments). #### Inclusive language - Present: Neutral, technical tone, minimal jargon beyond developer terms. - Improve: Add plain-language summaries and mini-glossary for less experienced devs. #### Neurodiversity support - Present: Reasonable structure, sections, and clear sequences. - Improve: More subheadings, bullet lists for complex comparisons, consistent pattern for presenting numbers. #### Representation - Present: Primarily a single-author narrative with a named collaborator. - Improve: Highlight performance experiences from a range of contributors (agencies, freelancers, product teams). #### Psychological safety - Present: Respectful tone toward WPGraphQL and its author; no shaming. - Improve: Explicitly frame critique as about methods/claims, not people; encourage open correction and replication. --- ### ✅ Logical Validity #### Strong reasoning - Uses inductive reasoning from multiple measurements (local and hosted) to infer that WPGraphQL’s advantage is moderate, not 100x. - Causal reasoning correctly assigns some performance gains to caching and payload size rather than API paradigm alone. - Acknowledges uncertainty (noise in timings, differing environments) and focuses on ratios and patterns instead of single-run absolutes. #### Fallacies - No major fallacies evident. The author avoids hasty generalization by stating that results are indicative, not universal, and by clarifying test conditions. #### Tone of voice - Analytical, skeptical yet fair. Uses collegial language about Jason Bahl and WPGraphQL, frames article as methodological clarification rather than takedown. --- ### 🛡️ DARVO Analysis - Deny: The article does not deny issues; instead, it questions and re-examines evidence behind a claim. - Attack: It does not attack individuals; critiques focus on methodology and interpretation of data. - Reverse victim/offender: No attempt is made to portray the author or REST API as “victims” of WPGraphQL; the tone aims for balanced technical analysis. --- ## 🎯 Conclusion The article shows that WPGraphQL generally outperforms the WordPress REST API, but usually by a factor of about 1.2–2x rather than 100x. Much of the dramatic marketing gap stems from caching and payload differences. For most teams, REST remains a solid default, while GraphQL is a strong option when you own the front-end stack and can exploit fine-grained queries. The practical next step is to benchmark your own site, under realistic conditions, before choosing or switching API strategies. --- ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ```markdown ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [{Title or entity}](https://georgestephanis.wordpress.com/2025/12/28/wp-rest-api-vs-graphql-performance/) by [[George Stephanis]] via [[georgestephanis.wordpress.com]]. Published 2025-12-28. > “Short quote, verbatim, ≤25 words.” Two lines: context and use. Cite data if relevant. [view highlight](https://georgestephanis.wordpress.com/2025/12/28/wp-rest-api-vs-graphql-performance/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [{Title or entity}](https://georgestephanis.wordpress.com/2025/12/28/wp-rest-api-vs-graphql-performance/) > “Short quote, verbatim, ≤25 words.” Two lines: context and use. [view highlight](https://georgestephanis.wordpress.com/2025/12/28/wp-rest-api-vs-graphql-performance/#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] #### [Z2] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Short action — context/https://georgestephanis.wordpress.com/2025/12/28/wp-rest-api-vs-graphql-performance/ #fleeting #inbox - [F2] Short action — context/https://georgestephanis.wordpress.com/2025/12/28/wp-rest-api-vs-graphql-performance/ #fleeting #inbox - [F3] Short action — context/https://georgestephanis.wordpress.com/2025/12/28/wp-rest-api-vs-graphql-performance/ #fleeting #inbox --- <!-- deep-read:sections end -->