A nota mobile do PageSpeed Insights marcou 40 no site da Promovaweb já migrado para Astro. Eu esperava um resultado melhor, mas o relatório mostrou que trocar de framework não encerra o trabalho feito pelo navegador.
Levei o relatório ao Claude para localizar alterações na implementação. Depois da intervenção e do deploy, obtive 100/100 no desktop. Os dois números pertencem a modalidades diferentes, portanto não servem como comparação direta de antes e depois.
Direto ao ponto
A nota mobile de 40 serviu para abrir uma investigação, não para condenar o Astro. O relatório apontou recursos carregados pela página, e o agente trabalhou nos arquivos relacionados. Eu ainda precisei conferir o deploy e a interface.
Ao repetir esse trabalho no seu site, mantenha a mesma URL, a mesma modalidade e a versão publicada. Compare os indicadores além da pontuação. Uma execução isolada pode variar por rede, processamento e ambiente do teste.
A nota mobile precisa manter URL, modalidade e versão
PageSpeed Insights combina uma análise de laboratório do Lighthouse com medições de acessos reais quando elas estão disponíveis. A documentação do Google separa essas duas origens.
Registre a URL, o horário, a modalidade mobile e os itens apontados. Anote também o commit que estava publicado. Esses campos impedem a comparação de uma versão nova com um relatório antigo atribuído à alteração errada.
Mobile e desktop usam condições distintas. O resultado 100/100 no desktop confirma aquela execução depois da intervenção. Ele não prova que o mobile saiu de 40 para 100, pois a fonte não registra essa nota final.
O Lighthouse documenta variação entre execuções. Uma diferença pequena merece várias medições sob condições semelhantes. Uma mudança ampla nos indicadores pode orientar a inspeção do recurso correspondente.
Cada apontamento precisa levar a um arquivo
Entregue ao agente o relatório junto do repositório e da URL testada. A resposta precisa identificar o recurso, mostrar onde ele é produzido e explicar o efeito esperado da alteração. “Otimizei a página” não oferece material suficiente para revisão.
Se o relatório destaca uma imagem grande no topo, abra a aba Network do navegador e confira qual arquivo chegou à página. Observe formato, dimensões e bytes transferidos. Em seguida, localize a referência no componente ou no Markdown.
O agente pode reduzir a imagem ou gerar outra versão. Compare os arquivos alterados e abra a página numa largura mobile. A fotografia precisa continuar legível e o espaço reservado deve evitar deslocamentos durante o carregamento.
Uma mudança num componente compartilhado alcança outras rotas. Procure os usos do componente e teste as páginas afetadas. O artigo sobre Astro e WordPress após a migração mostra por que a revisão visual precisa acompanhar a edição por arquivos.
HTML pronto não elimina imagens e JavaScript
Na configuração estática que uso, o Astro produz o HTML durante o build. O navegador ainda baixa fontes, imagens, estilos e qualquer JavaScript enviado pelos componentes interativos. Esses recursos influenciam o tempo até a página ficar visível e utilizável.
Astro também oferece renderização sob demanda. Por isso, associe o comportamento à configuração real do projeto. A marca do framework não informa sozinha se a página foi pré-renderizada ou processada durante o acesso.
Componentes React podem gerar HTML sem carregar toda a biblioteca no cliente. As diretivas de cliente definem quando a interatividade chega ao navegador. Retire JavaScript somente depois de confirmar que o botão, o menu ou o formulário continua executando sua função.
Eu uso React na Promovaweb porque ele faz parte da implementação escolhida. Ele não é requisito para um site Astro. O relatório deve levar você ao componente que realmente executa no navegador, não a uma remoção genérica da integração.
A pasta da imagem muda o tratamento recebido
Astro processa imagens usadas pelos recursos próprios de imagem. Arquivos mantidos na pasta pública são copiados sem a mesma transformação automática, conforme a documentação oficial.
Abra a requisição no navegador e compare o endereço recebido com o caminho usado no projeto. Uma versão otimizada pode existir no repositório enquanto a página continua apontando para o arquivo original da pasta pública.
Depois da correção, confira o tamanho transferido e as dimensões exibidas. Verifique também o build. Um conjunto grande de fotografias pode aumentar o processamento durante a compilação, e a hospedagem precisa terminar essa etapa antes de publicar o conteúdo novo.
Na escolha de hospedagem para o primeiro projeto, o ambiente precisa executar e recuperar a publicação. Uma imagem menor não chega ao visitante se o deploy falhou e a página ainda serve a versão anterior.
Feche a investigação na página publicada
Depois de enviar a alteração, acompanhe o build até o fim. Abra a URL pública, navegue pelo celular e repita o PageSpeed na modalidade mobile. Compare os mesmos indicadores com o relatório preservado.
Teste também o comportamento alterado. Abra o menu, envie o formulário e percorra os links principais. Uma página pode ganhar pontos ao retirar código necessário e perder a ação que levava o visitante ao conteúdo.
O Vibe Coding exige essa passagem entre instrução, alteração e teste. No Plano IA Makers, você aprende a revisar o trabalho do agente e publicar sistemas com uma forma explícita de conferência.
Quando o relatório aponta um recurso que você não consegue relacionar aos arquivos, o Desenvolvimento Colaborativo da Dev Side Studio permite investigar a página com você operando o editor e o terminal.
Minha nota 40 mostrou uma página concreta que precisava de trabalho. O valor do relatório apareceu quando eu o liguei aos arquivos, publiquei a alteração e voltei ao navegador. Astro tornou esse percurso compatível com meu fluxo, e o teste continuou indispensável.
