Bom, posso falar da experiência que tenho na empresa em que estou hoje, onde trabalho majoritariamente WordPress há quase uma década, para projetos com um foco muito grande em SEO.

De uns anos pra cá, vimos o quanto o aspecto de "performance" nos sites se tornou algo cada vez mais importante e relevante para mecanismos de busca, principalmente com a chegada de iniciativas como o Lighthouse. Com isso, conseguir uma nota 90+ no Lighthouse para sites focados em SEO era quase sempre a tão desejada meta.

No nosso caso, garantir uma ótima performance com um site WordPress sempre foi custoso. Talvez não pelo WordPress em si, mas por como é trabalhoso juntar diversas funcionalidades como: entrega por CDN, Load Balancer, Cache no Servidor, Cache na CDN, Disponibilidade do Servidor, etc. E tudo isso, em projetos multinacionais, com equipes editoriais enormes e um tráfego consideravelmente alto no site.

Foi aí que entrou nossa primeira experiêcia com o headless, onde desacoplamos o front-end do WordPress e passamos a entregá-lo com Next.js na Vercel, usando o WordPress apenas como CMS e API.

Na minha experiência, tivemos melhoras significativas com:

• Static Site Generator – O fato de termos uma arquitetura pronta, que facilita entregar arquivos estáticos na CDN de forma simples, sem nos preocupar com cache, e sem perder o gerenciamento por um CMS poderoso, é algo que, se não usassemos um framework pra isso, estariamos basicamente criando um novo para possibilitar tais funcionalidades.
• Estrutura de código mais comum – Com o uso de um framework moderno, existe uma certa arquitetura pré-definida, que nos ajuda a ter escalabilidade sem dificultarmos muito a entrada de novos contribuidores no projeto;
• Infraestrutura extremamente facilitada – Com o uso de plataformas como Vercel e Netlify, temos uma infraestrutura de extrema qualidade, toda pronta a alguns cliques de distância. Claro que dá pra usá-las só com HTML, CSS e JS, mas não seria o bastante para construir algo em grande escala de forma produtiva;
• Lógica facilitada com State Management – Em casos onde precisamos de uma lógica um pouco mais complexa no front-end, como em um painel ou filtro avançado, montar scripts com JavaScript puro (ou jQuery) requer um esforço bem maior do que usando as funcionalidades de State Management de frameworks como Vue, React, ou outros, o que simplifica o código da aplicação e facilita sua manutenção.

Enfim, eu poderia ficar mais um tempo aqui descrevendo mais benefícios que essas tecnologias nos trazem, mas acho que já deu para dar uma visão superficial de como elas ajudaram no meu contexto.

O ruim é quando escolhem usar um framework específico só por que é "modinha", ou por que está todo mundo usando. Eu acho que precisamos entender a necessidade do projeto e escolher as tecnologias que melhor se adequam a isso, e também que se encaixam com a experiência de quem vai trabalhar no projeto. Afinal, adotar uma nova tecnologia requer um certo investimento de tempo, e talvez por isso muitos devs usam esses frameworks onde nem precisava, por que é o que eles sabem usar.

Mesmo depois de termos adotado a abordagem headless (com esses "novos" frameworks) para a maioria dos nossos projetos, ainda decidimos não usá-la em casos onde vimos que não seria o ideal. É tudo uma questão de contexto.