A nota mobile do PageSpeed Insights marcou 40 no site da Promovaweb já migrado para Astro. 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 do meu site. Depois da intervenção, obtive 100/100 no desktop, mas os resultados são de modalidades diferentes e não permitem comparar os dois momentos.
Direto ao ponto
A nota mobile de 40 motivou a intervenção com Claude no site já migrado. A nota de 100 obtida depois no desktop não informa o resultado do teste mobile depois das alterações. Para repetir a investigação no seu projeto, relacione cada apontamento ao recurso publicado e confira o resultado no navegador.
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.
O relatório do PageSpeed precisa manter URL, modalidade e versão
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.
Os testes mobile e desktop usam condições distintas. O resultado 100/100 no desktop confirma aquela execução depois da intervenção. Ele não informa a nota mobile depois da alteração.
Como o Lighthouse documenta variação entre execuções, repita medições em condições semelhantes antes de interpretar uma diferença pequena. Variações mais amplas nos indicadores podem 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.
Quando o relatório destaca a imagem grande do topo, confira na aba Network qual arquivo chegou à página e localize a referência no componente ou no Markdown. Compare o formato e as dimensões do arquivo com os bytes transferidos para confirmar o que a página realmente carregou.
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 pode alcançar outras rotas, por isso localize seus usos e teste as páginas afetadas antes de publicar. O artigo sobre Astro e WordPress após a migração mostra por que a revisão visual acompanha 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. Ao avaliar a infraestrutura para Vibe Coding, separe esse carregamento do trabalho executado pelo backend. Os recursos enviados ao celular influenciam o tempo até a página ficar visível e utilizável.
O Astro também oferece renderização sob demanda, então confira a configuração real para saber se a página foi pré-renderizada ou processada durante o acesso. A marca do framework, sozinha, não informa qual opção o projeto usa.
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
O Astro processa imagens usadas pelos recursos próprios de imagem. Os arquivos mantidos na pasta pública são copiados sem a mesma transformação automática, conforme a documentação oficial. No blog em Markdown com agentes, confira também o metadado que aponta para a capa: trocar o arquivo no disco não altera uma referência escrita no artigo.
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.
