Desempenho de um site em Astro: o que o dardo.studio mede

A resposta curta

O dardo.studio é um site em Astro servido por um Cloudflare Worker, com o conteúdo em um CMS headless e todas as páginas em inglês, espanhol e português. Em 28 dias, de 24 de setembro a 22 de outubro de 2026, o percentil 75 das visualizações reais foi 1.114 ms de Largest Contentful Paint (LCP), 80 ms de Interaction to Next Paint (INP) e 0,08 de Cumulative Layout Shift (CLS). Os limites bons do Google são 2,5 segundos, 200 ms e 0,1, então o site como um todo passa.

As médias escondem dois problemas. Em telas grandes, o CLS p75 da home foi 0,239, mais que o dobro do limite, porque um efeito de hover reorganizava uma grade; corrigimos em 22 de outubro. Nos celulares, o INP p75 da home foi exatamente 200 ms, bom sem nenhuma margem, e ainda sem explicação. No laboratório, nossas páginas fizeram de 90 a 99 pontos no mobile, e o ponto fraco é o JavaScript: em uma página de conteúdo, cerca de dois terços dele são analytics.

Como o site é construído, e por que cada peça

• Astro 7.3.2 com saída estática, porque uma página de marketing deve ser HTML primeiro: o Astro remove o JavaScript de cliente dos componentes, a menos que um deles seja marcado como ilha interativa. Uma rota, /preview/, é renderizada na requisição para o CMS mostrar rascunhos.
• Um Cloudflare Worker, por meio do adaptador @astrojs/cloudflare 14.3.4, para que redirecionamentos, roteamento por idioma, a API do formulário de contato e as verificações de servidor das nossas ferramentas gratuitas fiquem ao lado dos arquivos que ele serve.
• EmDash, um CMS headless na Cloudflare, para que a equipe publique sem um desenvolvedor e o visitante nunca espere uma consulta ao CMS. Ele guarda as páginas, 41 páginas de serviço, estudos de caso, artigos, ferramentas, textos da interface e configurações; uma publicação dispara um novo build pelo Workers Builds, que vai ao ar alguns minutos depois. Mais em desenvolvimento de CMS headless.
• Cloudflare D1, um banco SQLite, para os contatos e as nossas leituras de Core Web Vitals (guardadas por 35 dias), para que os dados de campo sejam nossos; R2 para a mídia.
• Três idiomas, para os Estados Unidos, a América Latina e o Brasil, com alternativas hreflang: 418 URLs no sitemap em 22 de outubro de 2026, 145 em inglês. Veja sites multilíngues.

Tudo, menos a pré-visualização de rascunhos, muda quando alguém publica, não quando um visitante chega, então é construído uma vez e servido como arquivos. Nosso comparativo Astro vs Next.js mostra quando essa troca vale ao contrário.

Dados de campo: o que os visitantes reais receberam

Estes números vêm da nossa própria medição, não do Chrome UX Report do Google. Cada visualização de página envia as Core Web Vitals, o Time to First Byte (TTFB) e o First Contentful Paint (FCP) para uma tabela no D1. Informamos o percentil 75, como orienta o Google, separado em telas de celular e telas grandes (tablet e desktop). A coleta segue a escolha do visitante sobre analytics, e quem recusa ou envia Do Not Track ou Global Privacy Control fica fora da amostra. As amostras são pequenas: leia as linhas com n baixo como direção, não como prova.

O LCP é o resultado mais forte: 90% das leituras foram boas, e a linha mais lenta, todas as páginas em telas grandes, fica em 1.192 ms. O TTFB p75 foi 457 ms, abaixo dos 0,8 segundo que o web.dev considera bom, e o FCP p75 foi 1.068 ms, contra uma marca boa de 1,8 segundo. Das seis linhas de tipo de página e tela, cinco passam nas três Core Web Vitals; a home em telas grandes falha no CLS. O INP se divide por dispositivo, 64 ms em telas grandes e 184 ms nos celulares, e 148 das 183 leituras de INP em celulares vieram da home, a única página com arte pesada.

O que falhou e o que mudamos em 22 de outubro

Nossa tabela no D1 guarda os valores sem atribuição, então em 21 e 22 de outubro encontramos cada causa reproduzindo-a em um navegador com traces de performance.

Mudança de layout na home em telas grandes

O CLS p75 foi 0,239 (n=574), com só 65% de leituras boas; um recorte de 21 dias marcou 0,306. Passar o mouse sobre um card do mosaico de serviços o expandia mudando as colunas da grade, então todos os cards em volta se moviam, e cada hover deslocava o layout em 0,13 a 0,26. Um hover não é uma entrada discreta como um clique, então o navegador não perdoa os seus deslocamentos como perdoa os que ocorrem até 500 ms após um clique. Celulares não têm hover, o que bate com o 0,0 deles.

Agora os cards mantêm uma única origem e se movem com transforms de CSS, que não mudam o layout. Uma varredura em laboratório que passa o mouse por todos os cards foi de 0,331 para 0,0008. A contrapartida: a arte do mosaico pode ficar até 1 px fora da posição de repouso. O número de campo precisa de algumas semanas de dados novos para mudar.

INP em celulares na home

O INP p75 em celulares foi 200 ms (n=148), 75% bom. Um recorte de 21 dias marcou 232 ms (n=126); desde 15 de outubro, 128 ms, em 32 leituras. A pior interação que conseguimos produzir em laboratório leva 64 ms. A única interação lenta que capturamos caiu em um frame de inicialização de 295 ms sem script longo, o que aponta para a GPU ou a compilação de um shader da arte em WebGL. Limitar cinco escritas de atributos por frame aos momentos de mudança reduziu as mutações do DOM em 23%, mas deixou o laboratório em 64 ms. O caso continua aberto. Acrescentar atribuição à nossa própria medição, como descreve o nosso guia para melhorar o INP, apontaria o frame ou o script responsável.

Deslocamentos nas páginas de serviço e uma página de projetos lenta

As páginas de serviço em telas grandes tiveram CLS p75 de 0,089, mas quatro leituras em três minutos, em 21 de outubro, chegaram a 0,223. As capas usavam aspect-ratio: auto, então o texto pulava cerca de 435 px quando a imagem chegava, e as introduções dimensionadas em unidades ch ficavam 24% mais largas quando a fonte da marca carregava. Agora as capas reservam a proporção, essas larguras têm um piso em em e as fontes de fallback são ajustadas às fontes da marca. Em laboratório, as páginas de serviço foram de 0,03–0,21 para 0,04 ou menos, e os layouts de tablet de até 0,50 para 0,004 ou menos.

O LCP p75 da página de projetos no desktop foi 4.740 ms em um recorte de 21 dias (n=36; 2.868 ms em 28 dias, em um tipo de página que também inclui os estudos de caso). O maior elemento, um fundo desfocado, não tinha fetchpriority, enquanto as imagens de linhas ocultas recebiam a prioridade. Agora as imagens principais carregam com prioridade alta, o resto com baixa, e um vídeo de 4,4 MB espera o seu pôster. O LCP de laboratório caiu de 1,80 para 1,45 segundo com densidade de pixels 1x e de 2,20 para 1,57 com 2x, em um servidor HTTP/2 que respeita a prioridade.

Dados de laboratório e peso das páginas contra as medianas das plataformas

Rodamos o Lighthouse 12.8.2 localmente em 22 de outubro de 2026 e informamos a segunda execução mobile, porque a primeira depois de um build encontra o cache frio. A documentação do Lighthouse observa que boa parte da variação entre execuções vem de fora da ferramenta.

O LCP mobile de 3,5 segundos da página de serviço e o de 2,8 do artigo passam da linha de 2,5 segundos, enquanto as visitas reais a esses tipos de página tiveram LCP p75 entre 640 e 1.076 ms. A execução mobile do Lighthouse simula um celular lento em uma conexão limitada, mais lenta do que os nossos dados de campo sugerem para a maioria dos visitantes, então a tratamos como alarme de regressão e os dados de campo como o veredito. O CLS de laboratório foi 0,000 em todas, e é por isso que o deslocamento do hover passou despercebido: um teste de carregamento não passa o mouse.

Peso das páginas contra sites típicos de cada plataforma

O HTTP Archive mede as home pages dos sites que detecta em cada plataforma. Os públicos das plataformas são diferentes, então as medianas descrevem sites típicos, não o que uma construção cuidadosa consegue. Os nossos números são tamanhos de transferência do Lighthouse, uma execução por página.

Cada uma das nossas páginas pesa menos no total que a home mediana em Astro e menos da metade das medianas do Framer, do Webflow e do WordPress, e carrega menos bytes de imagem que qualquer uma delas. O JavaScript é a exceção: todas as páginas enviam mais que os 399 KB da mediana do Astro.

As taxas de aprovação contam uma história mais discreta. Em setembro de 2026, 71,1% das origens em Astro passaram nas três Core Web Vitals no mobile, perto do Framer (70,8%) e do Webflow (71,3%), e bem acima do WordPress (48,3%). No desktop, os números foram 84,6%, 87,9%, 82,6% e 53,7%. Uma página mediana mais leve não garante a aprovação; quem decide é a construção.

Para onde vai o JavaScript

As páginas de conteúdo carregam cerca de 432 KB de JavaScript. Cerca de 287 KB são analytics, carregados de terceiros ou pelo nosso proxy: a tag do Google (gtag.js, 160 KB) e os módulos de gravação, pesquisas, autocapture e web-vitals do PostHog (cerca de 127 KB). Nossos próprios scripts somam cerca de 145 KB, um bundle de interface compartilhado de 96 KB mais pequenos módulos por página. As fontes acrescentam 126 KB. A home carrega 709 KB por causa da arte interativa, um voo de dardo em WebGL conduzido pelo scroll.

Ou seja, dois terços do script de um artigo ou de uma página de serviço são medição, não a página. Isso custa transferência, além de parsing e execução na thread principal do celular, a thread de que o INP depende. As páginas de conteúdo ainda respondem rápido nos nossos dados de campo, com INP p75 de 40 a 64 ms em amostras pequenas. Mantemos os analytics porque mostram quais páginas e ferramentas levam a contatos; se os números piorarem, os passos mais baratos são menos módulos do PostHog, carregá-los mais tarde ou abrir mão de uma ferramenta. Um projeto de otimização de velocidade de sites deveria começar do mesmo jeito: listar cada script, o seu tamanho e quem precisa dele.

Quanto custa manter o site no ar

O custo fixo da plataforma é US$ 5 por mês, o plano Workers Paid da conta da Cloudflare, conferido nas assinaturas da conta em 22 de outubro de 2026. R2 e Stream estão em planos por uso, sem taxa base, a zona está no plano gratuito da Cloudflare, e o domínio e o CMS rodam na mesma conta.

Em outubro de 2026, o Workers Paid inclui 10 milhões de requisições e 30 milhões de milissegundos de CPU por mês, e depois cobra US$ 0,30 por milhão adicional de requisições e US$ 0,02 por milhão adicional de milissegundos de CPU. As requisições a arquivos estáticos são gratuitas e ilimitadas, o que pesa em um site quase todo estático. O D1 inclui 25 bilhões de linhas lidas, 50 milhões de linhas gravadas e 5 GB de armazenamento por mês, e a saída de dados do R2 é gratuita.

Os US$ 5 não incluem o uso acima desses limites, o uso do R2 e do Stream, o registro do domínio, serviços fora da Cloudflare, como analytics, nem o tempo das pessoas. Não publicamos as faturas da conta, então leia esse valor como o piso, não como a nossa conta mensal.

Como o site atende crawlers e agentes de IA

• O robots.txt permite crawlers de busca e de IA, com as preferências de Content-Signal search=yes e ai-input=yes.
• /llms.txt (42 KB) e /llms-full.txt (cerca de 877 KB), gerados a partir do CMS.
• Uma cópia em Markdown de cada página: acrescente index.md ao endereço ou envie Accept: text/markdown.
• Um endpoint MCP público e somente leitura em /mcp e um agent card A2A em /.well-known/agent-card.json, que respondem perguntas sobre os nossos serviços publicados a partir do mesmo conteúdo das páginas.

O que não podemos afirmar: não conhecemos nenhum fornecedor de busca com IA que documente efeito do llms.txt, das cópias em Markdown ou de um endpoint MCP sobre as citações de uma página. Publicamos porque são baratos de gerar a partir de conteúdo estruturado e úteis para os agentes que os leem. Nosso guia sobre llms.txt explica o que é o arquivo e quem o lê, e o verificador de visibilidade em IA mostra como o seu robots.txt trata cada crawler de IA. Esperamos que HTML rastreável, fatos específicos e fontes citadas pesem mais.

O que isso significa se você está considerando o Astro

O Astro facilitou manter as páginas de conteúdo leves: nosso próprio código em um artigo é cerca de 145 KB de JavaScript, e nada roda a menos que a gente acrescente. Ele não evitou os nossos dois problemas. Um efeito de hover quebrou o CLS e a arte em WebGL é a suspeita do INP nos celulares; os dois foram decisões de design que causariam o mesmo problema em qualquer plataforma.

O Astro serve quando o site é sobretudo conteúdo que muda ao publicar, você quer o código, a hospedagem e os dados nas suas próprias contas e tem desenvolvedores para cuidar dos templates. É a escolha errada quando a sua equipe de marketing edita layouts visualmente toda semana e o site atual já passa nas Core Web Vitals; as taxas de aprovação do Framer e do Webflow estão perto das do Astro. Uma migração deve comprar algo específico: código que é seu, um backend que o construtor não oferece ou controle sobre cada script.

Astro no Cloudflare Workers é a nossa stack padrão para desenvolvimento em Astro, e fazemos migrações do Framer para o Astro, do Webflow para o Astro e do WordPress para o Astro.

Como medir o seu próprio site

1. Comece pelo contexto: o nosso relatório de velocidade de plataformas web mostra o último mês do HTTP Archive para a sua plataforma.
2. Obtenha dados de campo. O Chrome UX Report do Google só cobre páginas e origens com visitantes suficientes no Chrome; se o seu site não chega lá, envie as Core Web Vitals do navegador para um armazenamento próprio, como fazemos com o D1.
3. Informe o p75 com o tamanho da amostra, por tipo de página e tamanho de tela. Os nossos números do site inteiro passaram e esconderam os dois problemas.
4. Rode o Lighthouse duas vezes, fique com a segunda execução e use-a para pegar regressões, não como veredito.
5. Teste o que um teste de carregamento pula: hover, menus, arte que reage ao scroll. Nosso pior deslocamento de layout estava ali.
6. Corrija uma causa de cada vez e espere dados de campo novos antes de dar o problema por resolvido.

Nosso guia para passar nas Core Web Vitals cobre as causas e as correções usuais de cada métrica.