Se você pretende usar o WordPress como backend de uma aplicação, especialmente em uma arquitetura headless, provavelmente vai chegar a uma decisão: consumir os dados pela REST API do WordPress ou adicionar o WPGraphQL ao projeto?
É tentador resumir a comparação dizendo que REST é mais simples e GraphQL é mais moderno. Também é comum encontrar a ideia de que GraphQL é naturalmente mais rápido porque retorna apenas os campos solicitados. As duas afirmações têm algum fundamento, mas são simplificações.
A REST API e o WPGraphQL partem de modelos diferentes para resolver o mesmo problema: permitir que outra aplicação converse com o WordPress. A melhor escolha depende menos de qual tecnologia parece mais sofisticada e mais de como sua aplicação precisa consumir, combinar e atualizar os dados.
Se os conceitos ainda não forem familiares, vale consultar antes os verbetes REST API no WordPress e GraphQL e WPGraphQL no nosso glossário. Aqui o objetivo é outro: entender as diferenças práticas entre as duas abordagens.
A diferença começa no modelo da API
A REST API do WordPress é organizada em torno de recursos.
Para consultar posts:
GET /wp-json/wp/v2/postsPara buscar um post específico:
GET /wp-json/wp/v2/posts/123Usuários, categorias, mídias, comentários e outros recursos possuem suas próprias rotas.
É um modelo que aproveita conceitos já existentes no HTTP, como URLs, métodos como GET, POST e DELETE, códigos de status e mecanismos tradicionais de cache. A documentação do WordPress descreve sua REST API justamente como orientada a recursos e com URLs previsíveis.
O WPGraphQL parte de outra abordagem. Normalmente existe um ponto de entrada GraphQL e o cliente envia uma consulta descrevendo o formato dos dados que deseja receber.
Por exemplo:
query {
posts(first: 10) {
nodes {
title
date
author {
node {
name
avatar {
url
}
}
}
}
}
}Aqui a interface não pediu simplesmente “posts”. Ela pediu dez posts e, de cada um, solicitou título, data, nome do autor e URL de seu avatar.
Essa diferença entre solicitar um recurso e descrever uma estrutura de dados influencia praticamente todo o restante da comparação.
GraphQL entrega ao cliente mais controle sobre a resposta
Imagine uma interface que mostre uma lista de artigos. Ela precisa apenas de título, data, permalink, nome do autor e avatar. Uma query GraphQL pode representar exatamente isso.
Essa é uma das principais vantagens de seu modelo: o frontend consegue especificar os campos e navegar pelas relações disponíveis no schema. Além de reduzir dados desnecessários, isso pode aproximar bastante a estrutura da API da estrutura utilizada pelos componentes da interface.
Mas é importante evitar uma comparação injusta.
Às vezes vemos REST descrito como uma tecnologia em que o servidor sempre devolve tudo, enquanto GraphQL devolve apenas o necessário. Não é exatamente assim na REST API do WordPress.
REST também consegue limitar os campos retornados
O WordPress oferece o parâmetro global _fields.
Em vez de:
/wp-json/wp/v2/postspodemos fazer:
/wp-json/wp/v2/posts?_fields=id,title,date,linkO resultado passa a conter apenas essas propriedades.
Existe ainda um detalhe importante: segundo a documentação oficial, quando _fields é utilizado, o WordPress pode deixar de gerar campos que não foram solicitados, evitando inclusive processamento interno ou consultas desnecessárias em determinados casos.
Portanto, a diferença não é simplesmente que GraphQL escolhe os campos enquanto REST devolve tudo. A diferença mais precisa é que a seleção de campos faz parte do modelo fundamental do GraphQL, enquanto no WordPress REST API ela é uma possibilidade adicional oferecida através de parâmetros como _fields.
Relacionamentos também não são exclusivos do GraphQL
GraphQL fica particularmente interessante quando começamos a atravessar relações.
Podemos sair de um Post e chegar ao autor e ao avatar desse autor dentro da mesma query. Também é possível combinar diferentes tipos de dados em uma única operação, desde que esses relacionamentos façam parte do schema.
Essa capacidade é natural ao modelo de grafo do GraphQL.
Mas também é comum encontrar comparações dizendo que, com REST, buscar dez posts e seus autores necessariamente exige onze requisições: uma para os posts e outras dez para os autores.
No WordPress isso também não é necessariamente verdade.
A REST API suporta _embed, permitindo incluir determinados recursos relacionados na própria resposta:
/wp-json/wp/v2/posts?_embed=authorDesde o WordPress 5.4, também é possível especificar quais relações devem ser incorporadas. Apenas relações marcadas como embeddable podem participar desse mecanismo.
GraphQL continua sendo mais expressivo para navegar arbitrariamente por relações definidas no schema, mas REST não deve ser reduzido ao cenário em que cada relação obrigatoriamente exige outra requisição.
O schema é uma vantagem importante do GraphQL
Performance costuma dominar a discussão, mas existe uma diferença que pode ser mais importante para equipes desenvolvendo aplicações complexas: o schema fortemente tipado.
Em GraphQL, o consumidor consegue saber antecipadamente que determinado campo existe, qual tipo retorna, quais argumentos aceita e com quais outros objetos se relaciona.
Isso permite ferramentas com autocomplete, validação de queries, introspection e geração automática de tipos para linguagens como TypeScript.
O WPGraphQL destaca essa previsibilidade do schema e o ecossistema de ferramentas como uma de suas principais vantagens para desenvolvimento.
A REST API do WordPress também possui schema e mecanismos de descoberta. Sua documentação define estruturas de entrada e saída e disponibiliza informações sobre endpoints e parâmetros. Ainda assim, a experiência oferecida por uma API cuja arquitetura inteira gira em torno de um schema tipado é diferente.
Em projetos grandes, especialmente com uma equipe dedicada ao frontend, isso pode pesar mais na decisão do que diferenças pequenas de tempo de resposta.
Então WPGraphQL é mais rápido?
Pode ser, mas essa é justamente a parte da discussão em que precisamos tomar mais cuidado.
A documentação do WPGraphQL apresenta um benchmark bastante impressionante entre as duas APIs.
Solicitando 100 posts do mesmo site, os resultados mostrados são:
| REST API | WPGraphQL | |
|---|---|---|
| Dados transferidos | 335 KB | 6,4 KB |
| Tempo | 7,91 s | 67 ms |
São números que sugerem uma diferença de mais de cem vezes no tempo de resposta.
Foi justamente esse resultado que chamou a atenção do colega George Stephanis (e falo colega pois já trabalhamos na mesma empresa e num mesmo período, na Automattic).
Em dezembro de 2025, ele publicou WP REST API vs GraphQL Performance (em inglês), tentando reproduzir o teste e entender de onde vinha uma diferença tão grande.
E é aí que a comparação fica muito mais interessante.
Tentando reproduzir o benchmark
George entrou em contato com Jason Bahl, criador do WPGraphQL, e conseguiu identificar as requisições utilizadas originalmente no teste.
A chamada REST era essencialmente:
/wp-json/wp/v2/posts?per_page=100Já a consulta GraphQL solicitava:
posts(first: 100) {
nodes {
id
title
date
author {
node {
avatar {
url
}
}
}
}
}As duas pedem 100 posts, mas não pedem exatamente a mesma representação desses posts.
A REST request solicita a representação padrão completa dos recursos, enquanto a GraphQL query seleciona explicitamente um conjunto bastante pequeno de campos.
Esse detalhe é importante para interpretar qualquer benchmark entre as duas abordagens.
O resultado continuou favorecendo WPGraphQL, mas não em 100 vezes
Quando George testou o mesmo site, encontrou aproximadamente 705 ms para uma resposta WPGraphQL sem cache. A REST API levou cerca de 7,92 segundos.
Considerando apenas o processamento reportado, eram aproximadamente 680 ms contra 7.437 ms, uma diferença de cerca de 10,94 vezes. Ainda muito grande, mas uma ordem de magnitude abaixo do resultado de mais de 100 vezes que motivou a investigação.
Em chamadas seguintes atendidas pelo cache da infraestrutura, WPGraphQL respondeu em aproximadamente 33 ms e a REST API em cerca de 91 ms.
Esse comportamento mostra por que benchmarks de APIs precisam ser interpretados com cuidado. O resultado final não depende apenas da tecnologia escolhida, mas também do estado do cache, da infraestrutura, do tamanho do payload, dos plugins instalados, do banco de dados, dos campos solicitados e da forma como cada requisição foi construída.
No ambiente local, a diferença diminuiu bastante
George então montou um ambiente próprio para tentar reproduzir os testes.Nesse cenário, a diferença no tamanho das respostas continuou enorme.
WPGraphQL retornou aproximadamente 25,8 KB, enquanto a REST API retornou aproximadamente 583 KB.
O payload REST era cerca de 22,6 vezes maior, mas o tempo de resposta não acompanhou essa proporção.
As chamadas GraphQL ficaram geralmente na faixa de aproximadamente 0,8 a 0,9 segundo, enquanto REST ficou próximo de 1,1 segundo, algo em torno de 1,3 vez mais lento naquele conjunto de testes.
Esse resultado mostra uma distinção importante: tamanho do payload e tempo de execução não são a mesma métrica.
Reduzir drasticamente a quantidade de JSON transferido pode ser muito útil, especialmente em redes lentas, dispositivos móveis ou aplicações que executam muitas consultas. Isso, porém, não significa que uma resposta vinte vezes menor será processada vinte vezes mais rápido pelo servidor.
E quando o WordPress ficou mais próximo de um site real?
George também adicionou ao ambiente vários plugins comuns em projetos WordPress.
Nesse cenário mais carregado, descartando os valores mínimo e máximo dos testes como possíveis outliers, ele encontrou:
| API | Tempo médio |
|---|---|
| WPGraphQL | 5,333 s |
| REST API | 11,185 s |
A REST API levou aproximadamente 2,097 vezes o tempo do WPGraphQL naquele teste.
A conclusão de George não foi que a vantagem de WPGraphQL não existe. Pelo contrário: se performance for prioridade e o projeto estiver confortável em adicionar seu próprio conjunto de ferramentas, ele considera possível conseguir resultados melhores com WPGraphQL.
O ponto é que, a partir dos testes realizados, expectativas próximas de 1,2 a 2 vezes de melhoria parecem mais realistas do que assumir uma diferença de 100 vezes como regra.
O benchmark também favorece GraphQL pela forma como a consulta foi construída
Existe outro ponto importante ao interpretar esses resultados.
A REST request utilizada:
/wp-json/wp/v2/posts?per_page=100não utiliza _fields.
Seria possível reduzir a resposta para algo mais próximo dos dados solicitados pelo GraphQL:
/wp-json/wp/v2/posts?per_page=100&_fields=id,title,date,authorA própria documentação do WordPress recomenda utilizar _fields para evitar geração, transferência e processamento de propriedades que a aplicação não utiliza.
Isso não significa que repetir o teste dessa maneira faria REST vencer GraphQL. Não temos dados para afirmar isso.
O que podemos dizer é que o benchmark original não isola perfeitamente “o custo de REST” contra “o custo de GraphQL”. Ele também compara uma REST response padrão com uma GraphQL query cuidadosamente selecionada.
Esse tipo de detalhe precisa ser considerado antes de transformar benchmarks específicos em afirmações gerais sobre as tecnologias.
Payload menor também não torna qualquer query GraphQL eficiente
Existe ainda o erro inverso: assumir que GraphQL é automaticamente eficiente porque o cliente seleciona os campos.
Uma query pode atravessar vários níveis de relacionamentos e exigir bastante trabalho do servidor. A própria documentação do WPGraphQL recomenda solicitar apenas os campos realmente necessários e chama atenção para os custos de queries grandes ou muito aninhadas.
Ela também sugere avaliar quando vale mais uma grande query e quando múltiplas queries independentes podem proporcionar melhor cache e carregamento paralelo.
WPGraphQL possui otimizações para carregamento de recursos relacionados e mecanismos que ajudam a reduzir problemas como N+1, mas isso não transforma uma consulta mal projetada em uma consulta barata.
GraphQL oferece boas ferramentas para construir consultas eficientes, mas continua dependendo de boas decisões de implementação.
Cache também funciona de maneira diferente
REST combina naturalmente com o modelo tradicional do HTTP.
Uma requisição como:
GET /wp-json/wp/v2/posts/123possui uma URL claramente associada a determinado recurso e funciona muito bem com vários mecanismos convencionais de cache HTTP e CDN.
GraphQL frequentemente concentra diferentes operações no mesmo endpoint e muitas implementações utilizam POST, o que muda a estratégia tradicional baseada simplesmente em URL.
Isso não significa que GraphQL não possa ser cacheado.
O próprio teste de George encontrou respostas WPGraphQL sendo servidas pelo cache de rede, e a documentação atual do WPGraphQL descreve estratégias envolvendo requests GET, persisted operations e o WPGraphQL Smart Cache.
A diferença está mais no modelo: REST tende a se encaixar diretamente em mecanismos tradicionais baseados em recurso e URL, enquanto GraphQL normalmente exige uma estratégia mais consciente sobre operações, resultados e invalidação.
REST já faz parte do WordPress; WPGraphQL é uma dependência adicional
Existe também uma diferença operacional.
A REST API faz parte do WordPress. Ela já está disponível e é utilizada pela própria plataforma, inclusive como infraestrutura para interfaces modernas do WordPress.
WPGraphQL é um plugin adicional que fornece um schema GraphQL extensível ao WordPress.
Isso significa adicionar outra peça importante à arquitetura.
Dependendo dos plugins e tipos de dados utilizados pelo projeto, também pode ser necessário instalar ou desenvolver integrações adicionais para expô-los corretamente no schema.
Isso não é necessariamente uma desvantagem. Em um frontend headless complexo, os benefícios de GraphQL podem justificar perfeitamente essa camada adicional.
Mas ela precisa entrar na conta.
O equilíbrio entre cliente e servidor também muda
Talvez esta seja uma das maneiras mais úteis de enxergar a diferença.
Com REST, o backend possui maior influência sobre a representação de cada recurso. Com GraphQL, o backend define o universo do que pode ser consultado através do schema, mas o cliente possui muito mais liberdade para decidir quais partes desse universo deseja combinar.
Isso é especialmente útil em aplicações com muitas telas diferentes.
Um componente pode precisar apenas do título de um post. Outro pode precisar do título, autor, avatar, categorias e imagem destacada. Uma terceira tela pode precisar combinar posts, categorias e configurações da aplicação.
GraphQL permite que cada consumidor expresse essas necessidades através de suas próprias queries.
Essa liberdade, porém, também aumenta a responsabilidade do servidor. Uma API pública GraphQL precisa considerar queries excessivamente profundas ou caras. WPGraphQL, por exemplo, oferece limitação de profundidade e atualmente habilita esse mecanismo por padrão em novas instalações, com profundidade máxima inicial de 15.
Então qual escolher?
Uma comparação resumida ajuda a visualizar os principais trade-offs:
| Critério | REST API | WPGraphQL |
|---|---|---|
| Disponibilidade | Faz parte do WordPress | Plugin adicional |
| Modelo principal | Recursos e endpoints | Schema e grafo |
| Seleção de campos | _fields | Parte nativa da query |
| Relações | Links e _embed | Navegação pelo schema |
| Combinar tipos diferentes | Pode exigir mais de uma operação | Natural em uma única query |
| Tipagem | Schema REST | Schema GraphQL fortemente tipado |
| Ferramentas de desenvolvimento | Ecossistema HTTP/REST | Forte ecossistema baseado no schema |
| Cache HTTP tradicional | Muito natural | Normalmente exige mais estratégia |
| Controle do formato da resposta | Maior influência do servidor | Maior controle do cliente |
| Dependência adicional | Não | Sim |
| Frontend headless complexo | Funciona | Frequentemente muito conveniente |
Para uma integração relativamente simples, um plugin expondo algumas operações, uma automação ou uma aplicação consumindo recursos bem definidos, a REST API continua sendo uma excelente escolha.
Ela já está no WordPress, é baseada em conceitos amplamente conhecidos do HTTP e possui recursos como _fields e _embed que permitem otimizar bastante o consumo de dados.
Quando o WordPress funciona como backend de uma aplicação headless mais complexa, especialmente quando diferentes telas precisam combinar vários tipos de dados e relacionamentos, WPGraphQL começa a apresentar vantagens importantes.
O schema tipado, a capacidade de navegar pelas relações e a liberdade para o frontend definir precisamente sua necessidade de dados podem melhorar bastante a experiência de desenvolvimento.
Não escolha apenas pelo benchmark
Talvez essa seja a principal conclusão.
Os testes do George não demonstram que as vantagens de performance do WPGraphQL são falsas. Pelo contrário: WPGraphQL foi mais rápido em vários dos cenários testados.
O que eles mostram é que não dá para transformar um resultado de 67 ms contra 7,91 segundos em uma afirmação genérica como “GraphQL é mais de cem vezes mais rápido que REST”. O desempenho depende de uma combinação de fatores, como o estado do cache, o tamanho do payload, os plugins instalados, o banco de dados, os campos solicitados e, principalmente, a forma como cada requisição foi construída.
Uma REST request que retorna a representação completa de 100 posts não está necessariamente sendo comparada em condições equivalentes com uma query GraphQL que seleciona apenas alguns campos desses mesmos posts. Da mesma forma, uma query GraphQL excessivamente complexa pode acabar exigindo muito mais processamento do servidor do que uma chamada REST bem otimizada.
A conclusão do próprio George reforça esse cuidado: benchmarks desse tipo precisam comparar soluções equivalentes e igualmente otimizadas, em vez de colocar uma configuração cuidadosamente ajustada de um lado e uma implementação padrão do outro.
A pergunta mais útil, portanto, não é: “WPGraphQL ou REST API: qual é mais rápido?” mas sim “Qual modelo faz mais sentido para a maneira como minha aplicação precisa consumir os dados do WordPress?”
Em alguns projetos, a simplicidade, disponibilidade e integração natural com HTTP tornam REST a escolha mais racional.
Em outros, especialmente em aplicações headless com relações complexas e um frontend que precisa controlar precisamente o formato dos dados, WPGraphQL pode oferecer uma arquitetura muito melhor.
E nada impede que as duas abordagens coexistam no mesmo WordPress quando isso fizer sentido.
Fontes e referências
- WPGraphQL — WPGraphQL vs. WP REST API – Comparação oficial do projeto, incluindo o benchmark que motivou os testes de Stephanis.
https://www.wpgraphql.com/docs/wpgraphql-vs-wp-rest-api - WPGraphQL — Performance – Recomendações oficiais sobre seleção de campos, tamanho e organização de queries, cache e monitoramento.
https://www.wpgraphql.com/docs/performance - WPGraphQL — Security – Documentação sobre introspection, profundidade de queries e proteções da API.
https://www.wpgraphql.com/docs/security - WordPress REST API Handbook — Global Parameters – Documentação sobre
_fields,_embede outros parâmetros globais da REST API.
https://developer.wordpress.org/rest-api/using-the-rest-api/global-parameters/ - WordPress REST API Handbook — Linking and Embedding – Documentação sobre relações entre recursos e incorporação de dados relacionados.
https://developer.wordpress.org/rest-api/using-the-rest-api/linking-and-embedding/ - WordPress REST API Handbook — Reference – Referência oficial dos recursos e endpoints disponíveis no WordPress.
https://developer.wordpress.org/rest-api/reference/ - WordPress.org — WPGraphQL – Página oficial do plugin WPGraphQL no diretório do WordPress.
https://wordpress.org/plugins/wp-graphql/
Discussão & Respostas (0)