WordPress sem cabeça: o que é e você precisa?

Na Servebolt, somos grandes defensores do WordPress e seu ecossistema. Também o usamos para nossos próprios sites porque realmente o consideramos o melhor sistema de gerenciamento de conteúdo, conforme as estatísticas continuam a mostrar ano após ano. É de código aberto, versátil e simples, é incrivelmente fácil ver por que ele alimenta mais de 40% de todos os sites na Internet.

Com o tamanho do ecossistema e da comunidade de desenvolvedores que cerca o WordPress, não é surpresa que as pessoas usem o WordPress de maneiras diferentes. Uma dessas abordagens é usar o WordPress como um CMS sem cabeça – em resumo, conhecido como WordPress sem cabeça, que está crescendo em popularidade.

Neste guia, detalharemos tudo o que você precisa saber sobre o WordPress sem cabeça, suas vantagens, desvantagens e muito mais da experiência em primeira mão de nossa equipe.

O que é o WordPress sem Cabeça?

Para entender o WordPress sem cabeça, você precisa saber o que é o WordPress monolítico. Monolithic , ou WordPress em sua forma tradicional, é o WordPress como você o conhece. É um sistema de gerenciamento de conteúdo que você pode usar para gerenciar todo o conteúdo do seu site.

Geralmente, o WordPress tem o backend (o sistema de gerenciamento de conteúdo) e a camada de apresentação, que permite projetar seu site. No entanto, os sites sem cabeça do WordPress são aqueles que simplesmente confiam no WordPress como um sistema de gerenciamento de conteúdo e usam uma pilha de front-end diferente para exibir o conteúdo.

Isso permite uma maior flexibilidade em termos de desenvolvimento. Essencialmente, com a ajuda da API REST, você pode usar o WordPress para sua funcionalidade de gerenciamento de conteúdo ao emparelhá-lo com um frontend construído separadamente em uma estrutura como Vue.js ou React (só para citar alguns, há toda uma gama de outros frameworks e ferramentas frontend disponíveis).

O WordPress é considerado arquitetura CMS acoplada porque todas as ferramentas de edição de front-end e funcionalidade de gerenciamento de conteúdo (edição) de back-end são acopladas. Isso permite que equipes de desenvolvedores, editores, redatores e muito mais gerenciem a camada de apresentação e o conteúdo. Ao contrário de sites WordPress sem cabeça que seguem uma arquitetura desacoplada em que a camada de apresentação e o conteúdo são - como o nome sugere - desacoplados.

REST, GraphQL e integração de arquivos simples

Uma configuração de CMS headless usa APIs e CDNs para renderizar conteúdo. E, no momento, existem três opções disponíveis – a API REST, a integração de arquivos simples e o GraphQL.

O WordPress usa a API REST para permitir que você conecte o frontend ao CMS. Uma API REST é simplesmente uma interface de programação de aplicativos que segue as restrições da arquitetura REST, fornecendo uma interface uniforme que permite que servidores e clientes transfiram dados entre si. REST permite que os desenvolvedores exponham e usem dados específicos, se o endpoint REST não tiver os dados diretamente disponíveis, ele precisará de desenvolvimento adicional.

Outra alternativa é o GraphQL (QL é a abreviação de Query Language). O GraphQL facilita a consulta de APIs com campos e relacionamentos específicos, assim como você faria com um banco de dados. Esta é uma melhoria significativa, e há um plugin que disponibiliza uma API GraphQL no WordPress . Isso pode significar que o desenvolvimento extra não é necessário para explorar o conteúdo do CMS, pois o GraphQL já tem acesso a ele, a parte mais complexa é fazer as consultas eficientes certas para obtê-lo.

A outra opção é a integração de arquivo simples. A integração de arquivos simples permite exportar os dados que normalmente são fornecidos via REST ou GraphQL como um arquivo .JSON, permitindo que o servidor os armazene em cache e não precise ser gerado em cada solicitação, tornando-o muito mais rápido. O uso desse método gerará automaticamente um novo conjunto de arquivos .JSON com cada alteração no banco de dados. Esta é normalmente uma implementação sob medida e não apenas um plugin. Portanto, um desenvolvedor é necessário para configurá-lo.

As vantagens e desvantagens do WordPress sem cabeça

Agora que você sabe o que é o WordPress sem cabeça e como ele é diferente de uma configuração convencional do WordPress, aqui estão as vantagens e desvantagens que você deve saber antes de tomar uma decisão.

Desenvolvimento flexível, Embora ainda use o WordPress como seu sistema de gerenciamento de conteúdo, a dissociação do WordPress oferece a seus desenvolvedores a flexibilidade de construir com as tecnologias de front-end de sua escolha – ou seja, estruturas como Next.js . Em um nível de superfície, isso significa muito mais liberdade para construir.

Na superfície, isso é ótimo. Mas também significa que você acaba reinventando a roda para funcionalidades básicas, como sitemaps e permalinks, garantindo que as visualizações ao vivo do conteúdo da postagem e da página funcionem.

E você perde a maior parte do fluxo de trabalho editorial pelo qual o WordPress é conhecido. A configuração de novas páginas geralmente se torna significativamente mais complicada e exige que os desenvolvedores estejam em espera para depurar quando as coisas não funcionam apenas .

Criando aplicativos móveis com um back-end do WordPress

Um caso de uso frequentemente negligenciado é que, quando você dissocia o WordPress, usando-o apenas para o back-end, você pode criar aplicativos móveis.

Os aplicativos são complexos, significativamente mais do que criar sites do zero (ou seja, com ou sem WordPress) – então, se você acabar seguindo esse caminho, enquanto o conteúdo será orientado por API, grande parte do resto dependerá dos recursos nativos do dispositivo com a ajuda de frameworks como React Native. Aqui está uma ótima comparação de diferentes maneiras de criar aplicativos móveis de Scott Bollinger do AppPresser. Um deles é, como você deve ter adivinhado, o AppPresser, que é uma ótima implementação disso para aqueles que querem começar fora da caixa. É – é claro – desenvolvido pelo WordPress, usando plugins, temas e a API REST do WordPress para alimentar aplicativos móveis iOS e Android nativos/híbridos.

Começar com uma solução como essa economizará semanas, se não meses, de tempo de desenvolvimento e, em última análise, é baseado nos anos de experiência de sua equipe internamente, trabalhando em projetos de clientes por anos e testando a plataforma em produção para refiná-la.

Melhor desempenho, com compensações.

Existem três maneiras principais que o headless pode ser desenvolvido

1. Lado do cliente : Tudo é construído no navegador usando javascript com o conteúdo carregado do servidor ao acessá-lo. Por exemplo, usar o React como o mecanismo obtém os dados por meio, por exemplo, da API REST. Quando a página é alterada, há uma solicitação de mais dados para a API e uma nova página é criada no cliente. Mais frequentemente usado em aplicativos de página única (SPA)
2. Publicado estático : tudo já está compilado e exportado como HTML, CSS e JS no servidor. Como está servindo apenas arquivos estáticos, não gerando a página dinamicamente, isso pode ser armazenado em um servidor ou CDN de baixa potência. Este método é extremamente rápido. Isso geralmente é feito com algo como Next.js. Quando a página é alterada, uma nova página HTML é baixada do servidor e exibida. Usado com mais frequência em sites que não mudam com frequência, como sites de folhetos ou documentação.
3. Páginas isomórficas : A primeira página da Web acessada é Server Side Rendered (SSR) como HTML, mas todas as outras páginas subsequentes são geradas no lado do cliente, se o cliente puder. Se o cliente não puder gerar a página, ele a solicitará ao servidor. Usado com mais frequência em Progressive Web Apps (PWA), sites altamente dinâmicos ou aqueles que precisam atender a navegadores da Web mais antigos. Muitas vezes, um framework como o Svelte.kit é usado para isso.

Os métodos 1 e 3 podem usar arquivos de dados simples para gerar o HTML, tornando-os comparáveis ​​a um site publicado estático, mas usar REST ou GraphQL os atrasará um pouco, pois pode ser necessário gerar o conteúdo JSON a cada solicitação.

Se forem necessárias coisas como conteúdo gerado pelo usuário (formulários ou comentários), essas três formas de trabalho se tornarão muito mais complexas do que o WordPress padrão.

Vamos pegar um formulário de contato como exemplo, o formulário precisa ser construído para funcionar no lado do cliente e ser capaz de enviar suas informações via Javascript/AJAX de volta ao servidor, onde é então verificada, higienizada e inserida no contato sistema de gerenciamento de plugins de formulário. Como essa é uma maneira totalmente diferente de trabalhar, ele não pode confiar no criador do plug-in do formulário de contato para fornecer isso ou que coisas como potes de mel e outras proteções contra spam continuarão funcionando. Pode ser necessário que um desenvolvedor crie um endpoint REST e faça tudo funcionar conforme necessário. Muito mais complexo.

Os comentários são, em teoria, muito mais fáceis porque os endpoints REST já existem, mas ainda assim, será necessário que um desenvolvedor possibilite recuperar os comentários aprovados e apresentá-los em um layout encadeado, fazer upload de novos comentários no processo de aprovação e, claro, lidar com spam.

Ao desenvolver sem cabeça, há mais o que fazer para atingir os mesmos objetivos que saem da caixa com o WordPress ou são possíveis com alguns plugins.

A percepção de segurança Há muita desinformação em torno da segurança do WordPress sem cabeça. A execução de uma configuração de site estático com uma CDN é uma boa medida preventiva contra ataques DDoS. Mas, em última análise, qualquer servidor pode ser vítima de um ataque DDoS se você não implementar os sistemas necessários (por exemplo, Cloudflare, etc). As configurações desacopladas do WordPress funcionam com o WordPress instalado em um domínio ou subdomínio separado, com o frontend no domínio padrão.

Por exemplo, se usássemos este site, continuaríamos usando o servebolt.com como nosso site de acesso público, enquanto o E, por exemplo, usar um front-end Next.js como exemplo significaria que você tem a opção de usar SSR (renderização do lado do servidor), em que o HTML da página é gerado a cada solicitação, ou SSG (geração estática), em que o HTML da página é gerado no momento da compilação. A geração estática permite que o HTML seja reutilizado para cada solicitação, permitindo que ele seja armazenado em cache por um CDN.

Em ambos os casos, a camada de apresentação ainda se comunica e solicita conteúdo da camada de conteúdo que executa o WordPress. Isso significa que a área em que você hospeda a camada de gerenciamento de conteúdo para sua configuração do WordPress headless ainda estaria executando o WordPress.

Para resumir, a resposta para saber se a segurança é melhor em sites WordPress headless versus sites executados na configuração convencional é que pode ser. Simplificando, porque é uma configuração menos comum. O que queremos dizer com isso é que a verdadeira razão pela qual alguns tentam pintar a percepção de que existem problemas de segurança com sites que executam o WordPress é que muitos sites executam o WordPress e as coisas são totalmente flexíveis, então é claro que você pode criar ou instalar algo que não é confiável, o mesmo é verdade se você construir com headless e virtualmente qualquer outra pilha.

Quando você trabalha com um provedor de hospedagem WordPress que traz competência em segurança, dimensionamento e desempenho do jeito que fazemos na Servebolt , ainda é possível manter seus sites seguros sem sacrificar tudo o que você pode fazer com o WordPress – tendo que arcar com um desenvolvimento caro custos para reconstruir a partir do zero.

Mais desvantagens que você provavelmente encontrará com headless

Os custos do WordPress sem cabeça

Já falamos brevemente sobre isso, mas resumindo, o WordPress sem cabeça pode ficar muito caro. Não apenas em termos de custo de desenvolvimento, mas talvez mais importante, tempo.

Sua equipe perde a capacidade de se mover rapidamente e iterar sem ter que se apoiar em engenheiros internos (ou em uma agência).

Para equipes de ritmo acelerado que não veem seus sites como estáticos, essa é uma troca que acaba não valendo a pena. Vimos em primeira mão como empresas de 8 dígitos – que claramente têm os recursos para gerenciar o WordPress sem cabeça internamente – fazem a escolha de migrar para uma configuração sem cabeça e, finalmente, voltar porque o que eles não podiam suportar era o perda de tempo, flexibilidade para se mover rapidamente e, em última análise, dar a mais do que apenas um punhado de pessoas em sua equipe o controle para trabalhar em seu site.

Bons desenvolvedores que sabem o que estão fazendo podem ser difíceis de encontrar

Headless WordPress ainda é uma configuração relativamente nova. Portanto, embora encontrar desenvolvedores JavaScript familiarizados com JavaScript (e frameworks como React, Vue, Svelte, Gatsby) não seja particularmente difícil – e talvez até mais fácil do que encontrar ótimos desenvolvedores WordPress agora, aqueles que estão realmente familiarizados com a integração da camada frontend com WordPress de uma forma convencional que adere a todas as melhores práticas tendem a ser mais difíceis de encontrar.

Nem sempre mais rápido que o cache de borda de página inteira

Existem caminhos mais fáceis – e possivelmente melhores – para um site mais rápido.

A maioria das empresas que consideram a arquitetura headless deve corrigir sua hospedagem primeiro antes de tomar uma decisão significativamente mais complicada. Não só é muito mais fácil fazer isso, mas você também verá rapidamente melhorias significativas sem um grande investimento inicial. Sem investir na reconstrução do seu site e trocar todos os benefícios da sua instalação do WordPress em seu estado atual.

Quando você deve evitar o WordPress sem cabeça?

Como regra geral, o WordPress sem cabeça não é adequado para a maioria das empresas que constroem com o WordPress. Em suma, aqueles que:

• Deseja evitar a manutenção de duas camadas separadas (a camada de conteúdo e apresentação).
• Não queira desistir do fluxo de trabalho editorial e de gerenciamento de conteúdo pelo qual o WordPress é conhecido.
• Permita que a equipe deles tenha controle e flexibilidade para trabalhar sem precisar depender constantemente de seus desenvolvedores.
• Quer economizar recursos (tempo e dinheiro).
• Não tenha desenvolvedores experientes disponíveis para fazer as escolhas corretas sobre como o sistema é feito.
• Pretende contratar trabalhadores temporários ou ter uma agência para desenvolver o seu site de olho nos desenvolvimentos futuros subsequentes?

Para quem o WordPress sem cabeça é bom?

O WordPress sem cabeça pode ser uma boa opção para sua equipe se:

• Sua equipe de desenvolvimento é habilidosa em construir com frameworks JavaScript, e encontrar um desenvolvedor WordPress não é uma opção (seja qual for o motivo). Mas também quer continuar usando o WordPress como sistema de gerenciamento de conteúdo, o WordPress sem cabeça pode ser uma boa opção.
• Sua equipe deseja alcançar coisas específicas, como a continuidade entre o design de uma plataforma SaaS que já está construída, o que tornaria mais trabalhosa a reconstrução e a manutenção no WordPress. Nesse caso, separar a camada de conteúdo e apresentação pode ser uma boa opção.
• Você está determinado a não construir dentro dos limites dos temas do WordPress e não depende especificamente de nenhuma funcionalidade adicional que os plugins oferecem.
• Como empregador, você deseja treinar continuamente sua equipe técnica com as habilidades mais recentes e saber, dando a eles esse conhecimento, é mais provável que eles permaneçam com você por mais tempo.
• Seu objetivo é realizar otimizações de grau n em todas as partes da pilha.

Exemplos de sites criados com WordPress sem cabeça

Linha de saúde

TechCrunch

Fronteira

Backlink

Rudis

Relatório pós-ação - Avaliando o Headless como uma solução

Alguns querem explorar sem cabeça porque é a coisa nova e brilhante com a qual poucos outros estão trabalhando. Não porque é realmente a melhor solução para um problema específico que não seria alcançável de outra forma. Como subproduto, a maioria dos sites que adotam a abordagem sem cabeça se enquadram na categoria de engenharia excessiva sem a necessidade.

Escusado será dizer que também existem implementações interessantes do WordPress sem cabeça e cenários em que pode ser uma ótima escolha. Aqueles em que a escolha é o que permite que as equipes criem sites incríveis que conduzam ao resultado que desejam alcançar.

Ainda se perguntando se o WordPress headless se alinha com o que sua equipe está procurando? Sinta-se à vontade para agendar uma ligação conosco e ficaremos felizes em conversar sobre os problemas que você está enfrentando e está pensando em implementar o WordPress headless para resolver.

Ou, se este guia já respondeu a todas as suas perguntas e você está pronto para experimentar a abordagem Servebolt:

Interessado em hospedagem gerenciada que é empiricamente mais rápida? Experimente nossa abordagem para hospedagem WordPress :

• Escalabilidade: Nos testes de carga de trabalho do usuário real, o Servebolt forneceu tempos médios de resposta de 65 ms, tempos de resposta 4,9 vezes mais rápidos do que o segundo melhor.
• Os tempos de carregamento globais mais rápidos: tempos médios de carregamento de página de 1,26 segundos nos colocam no topo da lista de resultados globais do WebPageTest.
• A velocidade de computação mais rápida: os servidores Servebolt fornecem velocidades de banco de dados inéditas, processando 2,44 vezes mais consultas por segundo do que a média e executando PHP 2,6 vezes mais rápido do que o segundo melhor!
• Segurança e tempo de atividade perfeitos: Com 100% de tempo de atividade em todos os monitores e uma classificação A+ em nossa implementação SSL, você pode ter certeza de que seu site está online e seguro.