Project Speed: Owner reconstrói infraestrutura de mais de 10 mil sites de restaurantes com Astro e edge caching

A Owner trocou o stack de renderização em Next.js, apelidado de Mercury, por um stack em Astro chamado Apollo. O Mercury buscava dados no backend (Olympus), renderizava e respondia, num round trip lento. Empilhar caches não resolveu: havia atrasos imprevisíveis, publicação lenta de mudanças e o cache era limpo a cada deploy. Ainda carregava todas as localizações e menus de uma marca, e o Google Tag Manager e o pixel do Facebook pesavam em todas as páginas.

O Apollo renderiza páginas para markup e cacheia o resultado. A interatividade fica em ilhas React, hidratadas com diretivas como client:load (menu e carrinho), client:visible e client:idle. Roda em Cloudflare Workers, com um gateway Worker, Workers Cache em camadas, R2 como armazenamento do HTML e o renderizador Astro como fallback. Há stale while revalidate, headers x-owner-source e Server-Timing, e revalidação por push do Olympus. Mover a busca de marca para o edge cortou cerca de 50 ms de TTFB, e o HTTP 103 Early Hints levou algumas páginas a LCP de cerca de 600 ms.

Para quem opera sites multi-tenant, o caso sugere que o ganho veio menos do framework e mais da combinação: markup por padrão, cache próprio no edge e invalidação por push. Também mostra um custo real: cada feature flag binária dobra as variantes em cache, e a Owner precisou agrupar clientes em segmentos para conter isso.