Sites feitos com IA são rápidos? O que decide a velocidade

Sites feitos com IA são rápidos? O que decide a velocidade

A velocidade vem do que a página entrega ao navegador, não de quem escreveu o código. Uma página de marketing gerada é quase toda texto, algumas imagens e um pouco de script, então ela carrega como qualquer página pequena. O que deixa site de IA lento é o mesmo de sempre: imagem pesada, fonte demais e script inútil.

Essa moldura importa, porque "código de IA é rápido?" não tem resposta possível. Velocidade é propriedade do resultado, e o resultado é uma página dentro de um navegador. O resto deste texto trata do que a página carrega, do que custa segundos e de como medir em vez de discutir.

O que decide de verdade a velocidade de uma página?

Três coisas, mais ou menos nessa ordem de impacto. Quantos bytes o navegador precisa baixar, quantas requisições separadas ele faz para conseguir esses bytes, e quanto trabalho o processador tem antes de a página ficar utilizável. Quase toda discussão de desempenho é uma dessas três com outra roupa.

Imagem domina a primeira em praticamente todo site institucional. Uma foto de capa jogada direto da câmera pesa mais que o resto da página inteira somada, e nenhuma esperteza de código compensa isso. Comprimir um arquivo costuma ser o maior ganho isolado disponível para você.

A terceira, trabalho de processador, é onde caem embeds, players e tags de medição. Cada script de terceiro é uma requisição, depois uma leitura, depois uma execução, e tudo isso disputa espaço com o seu conteúdo. É por isso que uma página visualmente modesta ainda pode arrastar num celular intermediário.

Nenhuma das três se importa com quem escreveu a marcação. Uma página gerada e uma página escrita à mão carregando os mesmos arquivos se comportam igual, porque o navegador não sabe qual é qual e não tem motivo para saber.

Código gerado é mais lento que código escrito à mão?

Não por natureza, e a comparação abstrata não leva a lugar nenhum. A versão honesta da pergunta é mais estreita: esta construção específica entrega mais coisa do que precisava? Isso é respondível, e você responde olhando, não raciocinando sobre a ferramenta que produziu o arquivo.

Onde saída gerada erra é no excesso de inclusão. Peça uma página com galeria, mapa, chat de atendimento e capa animada, e você recebe os quatro, cada um com o próprio peso. O gerador fez o que foi pedido. Ninguém estava atrás dele perguntando se o mapa merecia estar ali.

Onde código feito à mão erra é no mesmo lugar, só que mais devagar. Site tocado por gente acumula plugin, tag e experimento esquecido ao longo de anos. A diferença é que uma página gerada começa pequena e cresce por pedidos explícitos seus, o que torna o peso rastreável até uma decisão.

O que entra numa página construída no Zugo?

Um projeto que funciona, conferido antes de chegar. Cada construção é aberta em uma sandbox primeiro, então a que não carrega é relatada como falha em vez de ser entregue como página em branco. Isso reduz o risco de publicar coisa quebrada. Não diz nada sobre peso.

Leia essa tabela como lista de conferência, não como veredito. As duas linhas que você controla mais diretamente, imagens e fontes, são também as duas que decidem o resultado na maioria dos sites simples.

Quais escolhas deixam uma página gerada lenta?

Quatro, e elas se repetem em quase toda página lenta que aparece para análise.

Imagem sem compressão. Foto em resolução cheia usada como fundo é a causa mais comum de todas. Redimensione para o tamanho em que ela realmente aparece antes de enviar, e o problema some sozinho.

Excesso de fontes. Cada família e cada peso a mais é outro arquivo para buscar e outro momento em que o texto pode pular de lugar. Dois pesos de uma família só costumam bastar para uma página institucional inteira.

Embed de terceiro. Chat, mapa, feed de rede social e player de vídeo são aplicações inteiras carregadas dentro da sua página. Cada um é uma escolha razoável sozinho, e quatro juntos são uma decisão que você nunca tomou conscientemente.

Tudo numa página só. Uma página que carrega loja, blog e formulário de agendamento entrega os três para quem queria um. Separar em uma plataforma multipágina custa 12 créditos nas três primeiras páginas e 3 por página depois, o que muitas vezes sai mais barato que o tráfego perdido.

Como medir em vez de discutir?

Abrindo a página, não opinando sobre ela. Três medições cobrem quase tudo, e nenhuma delas exige conhecimento técnico além de saber ler um número.

Publique e rode o teste público de desempenho do Google no endereço final, não no rascunho local. O relatório aponta imagem pesada e script bloqueante com nome e tamanho de arquivo, que é exatamente a lista de tarefas que você precisa.

Abra o painel de rede do navegador e recarregue. Ordene por tamanho e olhe as cinco primeiras linhas. Se três delas forem fotos suas, você já sabe o que fazer antes de tocar em qualquer outra coisa.

Depois faça a medição que mais engana quando é pulada: abra o site no seu celular, com dados móveis, longe do escritório. Desempenho medido em desktop com fibra é uma ficção agradável.

O celular na rede móvel muda a conta?

Muda, e por aqui essa é a conta que vale. A maior parte do tráfego de site pequeno chega por celular, muitas vezes em aparelho intermediário e em rede que oscila entre ótima e sofrível no mesmo quarteirão.

Isso desloca as prioridades. Numa rede rápida, uma foto de capa pesada custa um piscar. No 4G de fim de tarde, ela custa a visita inteira, e o visitante não volta para conferir se hoje melhorou. Peso vira a métrica que decide, e não o refinamento visual.

O outro efeito é o layout. Página que estica bem no desktop e empurra o botão para o terceiro rolar no celular perde conversão por um motivo que não aparece em nenhuma medição de velocidade. Isso é assunto de seu site fica bom no celular, e vale conferir junto.

O que a sandbox verifica e o que ela não verifica?

Ela verifica que a construção abre e roda sem erro antes de chegar às suas mãos. Se a página não subir, ela não é entregue, e é por isso que você raramente encontra tela branca depois de uma construção. Essa é uma garantia real e limitada.

O que ela não verifica é peso, gosto e acerto. Uma página pode abrir perfeitamente e ainda assim carregar uma foto de dez megabytes, seis fontes e três embeds. Nada disso é erro de execução, então nada disso é barrado.

Por isso a conferência de desempenho continua sendo sua e continua sendo depois de publicar. O construtor garante que a página funciona, e você garante que ela vale o download de quem está no ponto de ônibus.

O que continua sendo trabalho seu?

Três coisas que nenhum construtor resolve, e dizer o contrário seria propaganda.

Preparar as imagens. Ninguém corta e comprime as suas fotos por você. É o item mais chato da lista e o de maior retorno, e o caminho para subir arquivos seus está em posso usar minhas próprias imagens.

Decidir o que entra na página. Cada embed pedido é peso aceito. A pergunta "isso vale o segundo que custa?" é sua, e o gerador não vai fazê-la no seu lugar.

Medir depois de publicar. Velocidade não é estado, é hábito. Uma página rápida em junho vira lenta em setembro depois de três pedidos de "acrescenta só mais isso aqui". O efeito disso na busca está em site feito com IA é bom para SEO.

Por onde começar?

Pelo experimento mais barato: uma construção custa 6 créditos, o plano gratuito dá 5 e o Pro custa $25 por mês com 200 créditos. Construa uma página real em zugo.dev, publique no endereço no formato seuprojeto.zugo.run, rode o teste de desempenho e conserte a maior imagem. Esse ciclo vale mais que qualquer promessa de velocidade escrita em página de vendas.