As habilidades de desenvolvedor WordPress que mais pesam em 2026 são as que ferramentas de IA não entregam sozinhas: diagnosticar performance com dados de campo, entender a requisição inteira do navegador ao banco de dados, conhecer o funcionamento interno do WordPress (hooks, consultas, opções autoload), construir com o core moderno, como temas de bloco e a Interactivity API, cuidar de segurança e manutenção, acertar o SEO técnico já na resposta do servidor e explicar decisões técnicas para quem não programa. PHP, JavaScript e CSS continuam sendo a base. O que vem em cima dessa base é o que o cliente paga hoje.
Reviso muito código WordPress e muitos sites WordPress, e a lacuna que mais vejo não é de sintaxe. Quase todo desenvolvedor consegue escrever um plugin que funciona. Bem menos gente consegue me dizer por que uma página está lenta para o usuário real, ou o que um plugin faz no banco a cada requisição. A lista abaixo está ordenada pela frequência com que a habilidade que falta vira problema de verdade nos projetos que audito. É o lado prático do argumento que defendo em engenheiro WordPress vs desenvolvedor.
Quais habilidades de desenvolvedor WordPress ainda importam em 2026?
Primeiro a versão curta, depois cada uma com mais detalhe.
| Habilidade | O que cobre | Como saber se você tem |
|---|---|---|
| — | — | — |
| Diagnóstico de performance | Core Web Vitals, dados de campo vs laboratório, profiling | Você aponta a camada lenta antes de propor a correção |
| Ciclo da requisição | Servidor, PHP-FPM, OPcache, banco, caches, CDN | Você explica onde uma requisição sem cache gasta o tempo |
| Funcionamento interno do WordPress | Hooks, WP_Query, opções, transients, cron, REST API | Você prevê o que um plugin faz em cada carregamento de página |
| Core moderno | Temas de bloco, theme.json, blocos, Interactivity API | Você cria funcionalidades sem somar uma biblioteca para cada uma |
| Segurança e manutenção | Atualizações, permissões, escape, backups | O último backup que você restaurou funcionou de verdade |
| SEO técnico | Códigos de status, redirecionamentos, canonicals, HTML renderizado | Uma migração que você fez manteve o ranking |
| Comunicação | Auditorias, estimativas, trade-offs | Um gestor que não é técnico consegue agir com o que você escreveu |
Por que diagnóstico de performance vem primeiro?
Porque encosta em todas as outras habilidades da lista, e porque dá para medir. O Google reporta os Core Web Vitals no percentil 75 das visitas reais: LCP bom até 2,5 segundos, INP bom até 200 milissegundos e CLS bom até 0,1. O INP substituiu o FID em março de 2024, e muito site WordPress que passava antes agora reprova na interação, quase sempre por causa do JavaScript de page builders e de tags de terceiros.
A habilidade não é rodar o PageSpeed Insights. É ler os dados de campo no CrUX ou no Search Console, descobrir qual métrica reprova em qual template e rastrear até a causa. LCP lento com TTFB rápido aponta para arquivos que bloqueiam a renderização ou para a imagem principal. LCP lento com TTFB lento aponta para o servidor. INP ruim aponta para a thread principal. Quem faz essa leitura rápido já está à frente de boa parte do mercado. O método completo está em Core Web Vitals no WordPress.
O que saber sobre o ciclo da requisição?
O suficiente para acompanhar uma requisição do começo ao fim. O navegador resolve o DNS e abre a conexão TLS. A CDN responde do cache ou repassa a requisição. O servidor web entrega para o PHP-FPM, que roda o WordPress com o bytecode guardado pelo OPcache. O WordPress carrega as opções autoload, executa plugins e tema, consulta o banco, talvez passe por um object cache persistente e monta o HTML. Aí o navegador interpreta esse HTML e começa a buscar o resto.
Qualquer etapa pode ser o gargalo. Quando vejo alguém instalar um plugin de otimização de front-end enquanto o servidor leva dois segundos para mandar o primeiro byte, a habilidade que falta é esta. Comece por como reduzir o TTFB no WordPress.
Que partes internas do WordPress vale estudar a fundo?
As que rodam em toda requisição, porque é ali que erro pequeno se multiplica.
- O sistema de hooks: quando actions e filters disparam, e quanto custa pendurar trabalho pesado no
initou nowp_head. - WP_Query e a consulta principal: como alterá-la com
pre_get_postsem vez de rodar uma segunda consulta, e quais argumentos evitam contagens caras. - Opções e autoload: o que os plugins gravam com autoload ligado, e por que um autoload grande deixa toda página sem cache mais lenta. O Site Health verifica o tamanho do autoload desde o WordPress 6.6.
- Transients e object cache: como se comportam com e sem Redis ou Memcached.
- WP-Cron: por que depende de visita, e quando trocar por um cron de verdade no servidor.
- REST API: permission callbacks, schema e o que fica exposto por padrão.
O Query Monitor (wordpress.org/plugins/query-monitor/) é a ferramenta que eu daria para todo desenvolvedor no primeiro dia. Ele mostra consultas, hooks, chamadas HTTP e qual plugin ou tema disparou cada uma. A documentação oficial para desenvolvedores cobre o resto.
Quanto do core moderno você precisa dominar?
Mais do que muita gente usa. O core já traz o que antes exigia plugin ou framework: temas de bloco e theme.json para tokens de design e layout, as APIs do editor de blocos, a Interactivity API (WordPress 6.5) para comportamento no front-end sem carregar um framework inteiro, a Font Library (6.5), estratégias de carregamento de script com defer e async (6.3), fetchpriority em imagens (6.3) e speculative loading (6.8).
Conto isso como habilidade de performance tanto quanto de desenvolvimento. Cada funcionalidade feita com o core em vez de uma biblioteca de terceiros é uma dependência a menos para carregar, atualizar e auditar. Quem ainda faz tudo com page builder e uma dúzia de add-ons muitas vezes está entregando site lento sem perceber.
O que segurança e manutenção significam na prática?
Hábitos chatos, feitos sempre. Escapar saída, sanitizar entrada, verificar capabilities e nonces. Manter core, plugins e PHP em versões com suporte. Dar a cada usuário e a cada serviço só o acesso de que ele precisa. Guardar backup fora do servidor e restaurar um de vez em quando para provar que funciona. Remover os plugins que ninguém usa, em vez de só desativar.
Nada disso dá palco, e o cliente quase nunca pede até algo quebrar. É justamente por isso que quem faz sem ser pedido acaba recebendo projetos maiores.
Por que o desenvolvedor deveria se importar com SEO técnico?
Porque a maior parte dos problemas de SEO técnico nasce na mão de desenvolvedor. Staging aberto para robôs, cadeia de redirecionamento depois da migração, canonical apontando para a URL errada, template que responde 200 em página vazia, conteúdo importante que só aparece via JavaScript. O marketing acha isso nos relatórios meses depois, e um desenvolvedor tem que corrigir.
Você não precisa virar especialista em SEO. Precisa saber o que buscadores, e agora sistemas de IA, leem na resposta do seu servidor, e por que isso importa. A visão de desenvolvedor está em SEO técnico começa na resposta do servidor, e migração está em como migrar um site WordPress sem perder ranking.
Comunicação é mesmo uma habilidade técnica?
Em projeto real, é. Já vi trabalho técnico bom ser recusado porque quem fez não soube explicar, e trabalho mediano ser aprovado porque alguém explicou bem. As habilidades de que falo são específicas:
- Escrever uma auditoria com o problema, a evidência, a correção e o efeito esperado, nessa ordem.
- Estimar com faixas e dizer o que você ainda não sabe.
- Explicar um trade-off em dinheiro, risco ou prazo, e não em nome de ferramenta.
- Dizer não a um pedido e propor o que você faria no lugar.
Se quiser treinar em público, a comunidade WordPress é um bom lugar. Escrever posts, responder no fórum e, mais adiante, palestrar em meetups ou WordCamps treina exatamente isso. Minhas palestras estão na página de palestras.
Como essas habilidades se encaixam?
Formam mais um caminho do que um checklist. O diagnóstico de performance obriga você a aprender o ciclo da requisição. O ciclo da requisição leva ao funcionamento interno do WordPress. Conhecer o funcionamento interno melhora a escolha entre core e plugin. E a comunicação é o que faz você ser pago por tudo isso. Para um plano passo a passo, leia como se tornar desenvolvedor WordPress e chegar a engenheiro. Se você trabalha com sites grandes, WordPress enterprise mostra onde essas habilidades são mais testadas.
Se você lidera um time e quer um olhar de fora sobre onde as habilidades dele ficam curtas num projeto real, veja como trabalho na página de especialista WordPress.