Google explica por que não importa que os sites estejam cada vez maiores

Um podcast recente do Google chamou a atenção para o fato de que os sites estão cada vez maiores. Gary Illyes e Martin Splitt, do Google, explicaram que a ideia de que os sites estão ficando “maiores” é algo ruim não é necessariamente verdade. A conclusão para editores e SEOs é que o peso da página não é uma métrica confiável porque a causa do peso “excesso” pode muito bem ser algo útil.

O tamanho da página depende do que está sendo medido

Martin Splitt, do Google, explicou que o que muitas pessoas consideram tamanho de página depende do que está sendo medido.

• É medido apenas pelo HTML?
• Ou você está falando sobre o tamanho total da página, incluindo imagens, CSS e JavaScript?

É uma distinção importante. Por exemplo, muitos SEOs ficaram assustados quando souberam que o Googlebot estava limitando o rastreamento de suas páginas a apenas 2 megabytes de HTML por página. Para colocar isso em perspectiva, dois megabytes de HTML equivalem a cerca de dois milhões de caracteres (letras, números e símbolos). Isso equivale a uma página HTML com o mesmo número de letras de dois livros de Harry Potter.

Mas quando você inclui CSS, imagens e JavaScript junto com o HTML, agora temos uma conversa diferente relacionada à velocidade da página para os usuários, não para o rastreador do Googlebot.

Martin discutiu um artigo sobre o Web Almanac do HTTPArchive, que é um resumo das tendências de sites. O artigo parecia misturar diferentes tipos de peso de página, o que o torna confuso porque existem pelo menos duas versões de peso de página.

Ele observou:

“Veja, é aí que não estou tão claro sobre a definição de peso da página.

…eles têm um parágrafo onde tentam explicar o que querem dizer com peso da página. …Eu não entendo as diferenças no que são essas coisas. Então, dizem que o peso da página (também chamado de tamanho da página) é o volume total de dados medido em kilobytes ou megabytes que um usuário deve baixar para visualizar uma página específica. No meu livro isso inclui imagens e outras coisas porque tenho que fazer o download para ver.

E é por isso que fiquei surpreso ao saber que em 2015 eram 845 kilobytes. Isso para mim foi surpreendente. …Porque eu teria assumido que com imagens seriam mais de 800 kilobytes.

… Em julho de 2025, a mesma página média agora tem 2,3 megabytes.”

Os dados são compactados

Mas essa é apenas uma maneira de entender o tamanho da página. Outra forma de considerar o tamanho da página é focar no que é transferido pela rede, que pode ser menor devido à compactação. A compactação é um algoritmo do lado do servidor que minimiza o tamanho do arquivo enviado do servidor e baixado pelo navegador. A maioria dos servidores usa um algoritmo de compactação chamado Brotli.

Martin Splitt explica:

“Eu faço essa pergunta publicamente: pessoas diferentes tinham noções muito diferentes sobre como entendiam o tamanho da página. Dependendo da camada que você está olhando, também fica confuso
porque também há compressão.

… Então, algumas pessoas pensam, ah, mas este site baixa 10 megabytes no meu disco.

E eu digo, sim. …mas talvez se você observar o que realmente passa pela rede, poderá descobrir que são cinco ou seis megabytes, e não os 10 megabytes inteiros. Porque você pode compactar coisas no nível da rede e depois descompactá-las no nível do cliente…”

Tecnicamente, o tamanho da página no exemplo de Martin é, na verdade, cinco ou seis megabytes por causa da compactação e o download é mais rápido. Mas do lado do usuário, esses cinco ou seis megabytes são descompactados e voltam a ser dez megabytes, o que ocupa tanto espaço no telefone, desktop ou qualquer outro lugar do usuário.

E isso introduz uma ambiguidade. A sua página da web tem dez megabytes ou cinco megabytes?

Isso ilustra um problema mais amplo: pessoas diferentes falam sobre coisas diferentes quando falam sobre tamanho de página.

Mesmo as definições amplamente utilizadas não resolvem totalmente a ambiguidade. O peso da página é descrito como “o volume total de dados medido em kilobytes ou megabytes que um usuário deve baixar”, mas como a discussão deixa claro, não existe uma definição clara.

Martinho afirma:

“Quando você pergunta às pessoas o que elas acham, se isso é grande ou não, você começa a receber respostas muito diferentes dependendo de como elas pensam sobre o tamanho da página. E não existe uma definição verdadeira disso.”

E quanto à proporção entre marcação e conteúdo?

Uma das distinções mais interessantes feitas no podcast é que uma página grande não é necessariamente ineficiente. Por exemplo, um documento HTML de 15 MB é considerado aceitável porque “praticamente a maior parte desses 15 megabytes são, na verdade, conteúdo útil”. O tamanho reflete o valor que está sendo entregue.

Por outro lado, e se a proporção entre conteúdo e marcação fosse o contrário, onde houvesse um pouco de conteúdo, mas a maior parte do peso da página fosse marcação.

Martin discutiu o exemplo da proporção:

“… e se a marcação for a única sobrecarga? E quero dizer, o que você quer dizer? É tipo, bem, você sabe, se tiver cinco megabytes, mas for muito pouco conteúdo, isso é ruim? É pior do que neste caso, os 15 megabytes.

E eu penso, isso é complicado porque então chegamos a esse território estranho da proporção entre conteúdo e marcação. Sim.

E eu disse, bem, mas e se muito disso for marcação que são metadados para alguma ferramenta de terceiros ou para algum serviço ou por motivos regulatórios ou de licenciamento ou qualquer outra coisa. Então esse é um conteúdo útil, mas não necessariamente para o usuário final, mas você ainda precisa tê-lo.

Seria estranho dizer que isso é pior do que a página onde o peso é principalmente o conteúdo.”

O que Martin está fazendo aqui é mudar a ideia de peso da página do tamanho bruto para o que os dados realmente representam.

Por que as páginas incluem dados que os usuários nunca veem

Um dos principais contribuintes para o peso da página é o conteúdo que os usuários nunca veem.

Gary Illyes aponta os dados estruturados como um exemplo de conteúdo destinado especificamente a máquinas e não a usuários. Embora possa ser útil para mecanismos de pesquisa, também aumenta o tamanho geral da página. Se um editor adicionar muitos dados estruturados à sua página para aproveitar todas as diferentes opções disponíveis, isso aumentará o tamanho da página, mesmo que o usuário nunca a veja.

Isto chama a atenção para uma realidade estrutural da web: as páginas não são construídas apenas para leitores humanos. Eles também são desenvolvidos para mecanismos de pesquisa, ferramentas, agentes de IA e outros sistemas, todos os quais acrescentam seus próprios requisitos ao peso de uma página da web.

Quando as despesas gerais são justificadas

Nem todo conteúdo não voltado ao usuário é desnecessário.

Martin falou sobre como a marcação pode incluir “metadados” ou uma ferramenta, regulamentação ou finalidade de licenciamento, criando uma espécie de área cinzenta. Mesmo que os dados adicionais não melhorem diretamente a experiência do usuário, eles servem a um propósito, inclusive ajudar o usuário a encontrar a página por meio de um mecanismo de busca.

O que Martin queria dizer é que essas considerações sobre o peso da página complicam as tentativas de rotular o peso da página como bom se estiver abaixo desse limite ou ruim se o peso da página o exceder.

Por que separar conteúdo e metadados não funciona

Uma solução possível discutida por Gary Illyes é separar o conteúdo voltado para humanos dos dados voltados para máquina. Embora Gary não tenha mencionado especificamente a proposta do LLMs.txt, o que ele discutiu se parece com ela, pois fornece conteúdo para uma máquina, menos todas as outras despesas gerais que acompanham o conteúdo voltado para o usuário.

O que ele realmente discutiu foi uma maneira de separar todos os dados voltados para a máquina daqueles que o usuário irá baixar, tornando assim, em teoria, a versão de uma página da web do usuário menor.

Gary rapidamente descarta essa ideia como “utópica” porque sempre haverá hordas de spammers que encontrarão uma maneira de tirar vantagem disso.

Ele explicou:

“Mas infelizmente isso é uma coisa utópica, porque nem todo mundo na internet está jogando bem.

Sabemos com quanto spam temos que lidar. Em nosso blog dizemos em algum lugar que pegamos cerca de 40 bilhões de URLs por dia que são spam ou algum número maluco, não me lembro exatamente, mas é um número maluco e definitivamente bilhões. Isso apenas agravará a quantidade de spam que os mecanismos de pesquisa recebem e outras máquinas recebem, talvez como eu apostaria US$ 1 e 5 centavos que realmente aumentaria a quantidade de spam que os mecanismos de pesquisa, LLMs e outros ingerem.

Gary também disse que a experiência do Google é que, historicamente, quando você tem tipos separados de conteúdo, sempre haverá diferenças entre os dois tipos. Ele usou o exemplo de quando os sites tinham páginas para dispositivos móveis e computadores, onde as duas versões de conteúdo eram geralmente diferentes, o que por sua vez causava problemas de pesquisa e também de usabilidade quando um site classifica uma página da Web quanto ao conteúdo de uma versão de uma página e, em seguida, envia o usuário para uma versão diferente da página onde esse conteúdo não existe.

Embora ele não tenha mencionado isso explicitamente, essa explicação da experiência do Google pode esclarecer por que o Google não adotará o LLMS.txt.

Como resultado, os motores de busca optaram em grande parte por um modelo de documento único, mesmo que seja ineficiente.

Tamanho do site versus tamanho da página é o mundo real

Em última análise, a discussão desafia o conceito original do problema, de que páginas web pesadas são ruins.

Gary observa:

“A primeira pergunta é: os sites estão engordando? Acho que essa pergunta nem faz sentido.

Porque não importa no contexto de um site se ele é gordo. No contexto de uma única página, sim.

Mas no contexto de um site, isso realmente não importa.”

Então agora Gary e Martin mudam o foco para páginas da web que estão ficando mais pesadas, uma maneira mais significativa de analisar a questão de como as páginas da web e os sites estão evoluindo.

Isso move a discussão de uma ideia abstrata para algo mais mensurável e acionável.

Páginas mais pesadas ainda acarretam custos reais

Mesmo com conexões mais rápidas e melhor infraestrutura, páginas maiores ainda trazem consequências, e páginas menores têm benefícios positivos.

Martin explica:

“Acho que estamos desperdiçando muitos recursos. E quero dizer, tivemos isso em outro episódio em que dissemos que sabemos que existem estudos que mostram que sites que são mais rápidos têm melhor retenção e melhores taxas de conversão. Sim. E a velocidade também se baseia em parte no tamanho. Porque quanto mais dados eu envio, mais tempo leva para a rede realmente transferir esses dados e mais tempo leva para o processador de qualquer dispositivo em que você estiver realmente processá-los e exibi-los para você.”

Numa perspectiva mais ampla, a questão não é apenas o desempenho, mas também a eficiência. Como diz Illyes, “estamos desperdiçando muitos recursos”.

A web pode estar ficando mais pesada, mas a conclusão mais importante é o porquê. As páginas carregam mais do que apenas conteúdo voltado para o usuário, e essa escolha de design molda tanto seu tamanho quanto seu impacto.

Imagem em destaque por Shutterstock/May_Chanikran