Pilar de serviço

Implementação Cloudflare edge

Senior B2B, jurisdição da UE, âmbito definido por projeto.

Tarifação individual. Respondemos no prazo de um dia útil.

O que entregamos

WordPress num host PHP gerido na UE como backend editorial. Astro 5+ ou Next.js 15 como front-end, implementado em Cloudflare Pages. Rotas de Worker para a superfície dinâmica (autenticação, A/B, personalização no edge, endpoints de API transacionais). R2 para media, KV para leituras quentes, Durable Objects quando o estado tem de viver junto do utilizador.

Porque o edge ganha para WordPress

Um WordPress clássico em PHP-VPS paga o custo de render PHP em cada pedido público. Os plugins de cache ajudam, mas as falhas de cache atingem na mesma o origin e o utilizador paga a latência. Mover a superfície pública para o edge significa que o pedido médio nunca toca em PHP. O backend torna-se um sistema de publicação; o front torna-se um sistema de entrega.

A forma do custo também muda. Um único VPS dimensionado para picos de tráfego está sobredimensionado para a cauda longa. A faturação por pedido alinha o custo de servir com a contagem real de pedidos, com o edge a absorver picos que antes obrigavam a escalonamento manual.

Para quem é

  • Lojas WooCommerce em que os Core Web Vitals em mobile limitam a conversão
  • Editores e sites de conteúdos com picos de tráfego em ciclos noticiosos
  • Sites enterprise que precisam de encaminhamento de dados apenas na UE sob RGPD + NIS2 + DORA
  • Marcas multi-região que querem um origin a alimentar várias regiões edge

Modelo de colaboração

Contratos B2B sénior em jurisdição da UE. Auditoria, arquitetura, migração, afinação. Tarifação individual.

Caminho de leitura no edge, escrita na origem. Cache invalidado por tags via webhook. Leitor / agente sends a request to Cloudflare Workers (edge). On cache hit the Cache no edge (por tag) returns HTML with almost no CPU. On cache miss Workers calls REST API /wp-json/ on the Origem WordPress and renders. Editorial work happens in Block Editor + WP Admin on the origin and triggers a Webhook ao publicar that invalidates relevant cache tags. Leitor / agente Cloudflare Workers (edge) Cache no edge (por tag) acerto no cache (quase zero CPU) falha no cache → render no edge Origem WordPress Block Editor + WP Admin REST API /wp-json/ Publicação / mudança de slug / stock Read Read Webhook ao publicar Write
Caminho de leitura no edge, escrita na origem. Cache invalidado por tags via webhook.
O edge não é uma funcionalidade; é o pressuposto sobre o qual se constrói o resto da stack.
Matthew Prince , CEO da Cloudflare , Cloudflare Connect 2025 , 2025-09-15 , source

Perguntas frequentes

Porquê implementar WordPress em Cloudflare em vez de num host PHP tradicional?

Três razões. Desempenho, porque o front renderiza a partir do mais próximo de mais de 300 localizações edge. Custo, porque o runtime é faturado por pedido em vez de por servidor. Resiliência, porque o edge absorve picos de tráfego que derrubariam um único VPS. O backend do WordPress pode continuar num host PHP gerido; o edge é a superfície pública.

O Cloudflare Workers suporta o checkout do WooCommerce?

Sim, com a arquitetura certa. Catálogo e detalhe de produto renderizam a partir do edge com cache; carrinho e checkout correm como SSR ou como rotas Worker separadas que leem em direto do WooCommerce. Separamos as rotas deliberadamente para que as páginas comerciais se mantenham rápidas e as páginas transacionais se mantenham corretas.

Como é o modelo de custo de Cloudflare edge na prática?

Por pedido, não por servidor. O plano Workers Paid cobre a maioria dos sites em produção até dezenas de milhões de pedidos mensais com um custo mensal previsível. A largura de banda é ilimitada para respostas em cache. A superfície de custo relevante são pedidos, milissegundos de CPU por Worker e armazenamento em R2 ou KV. Dimensionamos isso na fase de arquitetura, não depois.

Como funciona isto com a jurisdição da UE e o RGPD?

A Cloudflare oferece encaminhamento de dados apenas na UE em planos Enterprise, e o origin do WordPress mantém-se onde o colocar (normalmente um host PHP na UE). Para efeitos de RGPD tratamos a Cloudflare como subcontratante, o origin na UE como localização dos dados do responsável pelo tratamento, e documentamos o fluxo de pedidos no registo das atividades de tratamento. Os controlos de NIS2 e DORA acumulam-se sobre essa decisão.

Conseguem migrar uma implementação Vercel ou Netlify para Cloudflare?

Sim. O output de build de Astro e Next.js é compatível com Cloudflare Pages com pequenas alterações de adapter. As edge functions e middleware portam, na maioria dos casos, do Vercel Edge Runtime para Workers. Definimos o âmbito da migração após uma auditoria de uma hora; tarifação individual.

Leitura em cluster

Arquitetura e padrões

Comparações

Migração e prazos

Conformidade e risco

Referência

Mova o seu front para o edge

Diga-nos o âmbito e o calendário. Respondemos no prazo de um dia útil.

Contacte-nos