Detalhamento do tamanho da página
Baixamos uma página do jeito que o navegador de um visitante de primeira viagem faria, com o cache vazio, e contamos cada byte que passa pela rede. Você recebe o total, de onde ele vem e o que poderia sair.
Todo arquivo tem dois tamanhos
Existe o tamanho que um arquivo tem na rede e o tamanho que ele tem depois de descompactado. Digamos que o seu servidor comprima um script de 400 KB para 110 KB. O visitante paga 110 KB em download e dados móveis, e o celular dele ainda precisa ler os 400 KB inteiros. Esta ferramenta dá nota ao primeiro número, os bytes transferidos, e mostra o segundo ao lado.
Bytes viram tempo de espera rapidinho. No perfil de 4G lento que o Lighthouse usa nos testes, 1,6 megabit por segundo, uma página de 2 MB leva uns dez segundos para baixar, e isso antes de qualquer script rodar.
O que é baixado
Depois de receber o HTML, a ferramenta pede o que um navegador pediria em um primeiro carregamento:
- folhas de estilo e arquivos anunciados com
rel="preload"oumodulepreload; - scripts com
src, exceto os substitutosnomodulee os tipos de script que um navegador não executa; - imagens: para
srcsete<picture>, ela pega o maior candidato que um navegador de desktop escolheria, e lêdata-srcnas imagens com carregamento lento; - pôsteres de vídeo, o favicon e imagens em atributos
styleinline; - fontes declaradas em regras
@font-face(o arquivo WOFF2 quando existe, doze fontes no máximo) e folhas de estilo puxadas com@import.
Alguns limites mantêm a verificação curta: 80 arquivos, 6 MB por arquivo, 15 MB no total. Se uma página passar de 80 arquivos, o número de requisições aparece como “≥”.
A escala de notas
| Nota | Tamanho transferido |
|---|---|
| A | até 0,5 MB |
| B | até 1 MB |
| C | até 2 MB |
| D | até 3,5 MB |
| E | até 5 MB |
| F | mais de 5 MB |
Para dar uma ideia, a página mobile mediana medida pelo HTTP Archive pesa uns 2,3 MB, o que dá um D aqui. Então uma página pode estar perfeitamente na média da web e ainda assim ser lenta no celular.
O que fazer com os resultados
- Imagens acima de 200 KB
- Quase sempre é uma imagem servida maior do que é exibida. Exporte-a na largura exibida, ou no dobro dela para telas de alta densidade, e deixe o
srcsetoferecer versões menores aos celulares. - Imagens JPEG ou PNG
- Quando o servidor permite, a ferramenta recodifica as oito imagens mais pesadas em WebP (qualidade 80) e AVIF (qualidade 55) e mostra o tamanho de cada resultado. Assim a economia é medida nas suas próprias imagens. Sirva o novo formato com uma alternativa:
<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" width="1200" height="630" alt="…"> </picture>
- Imagens sem width e height
- Esta não tem a ver com peso. É o motivo de o texto pular enquanto a página carrega. Acrescente os dois atributos.
- Arquivos de texto enviados sem compressão
- HTML, CSS, JavaScript ou SVG acima de 1,5 KB que chegaram sem gzip nem Brotli. A auditoria de compressão e cache tem as configurações do servidor.
- Mais de 1 MB de JavaScript, ou 300 KB de fontes
- Tire as bibliotecas e os plugins que ninguém usa, carregue o resto só nas páginas que precisam e fique com dois ou três pesos de fonte em WOFF2.
O número de carbono, e o que não é contado
A estimativa segue a versão 4 do modelo Sustainable Web Design. Ela conta 0,300 kWh para cada gigabyte transferido, o que cobre data centers, redes e aparelhos dos visitantes junto com a fabricação deles, e multiplica isso por uma média mundial de 494 g de CO₂e por kWh. Isso dá cerca de 0,15 g por megabyte. A comparação com um carro a gasolina usa 170 g por quilômetro. Encare como uma ordem de grandeza, boa para comparar duas versões de uma página.
Nenhum JavaScript é executado. Tudo o que os scripts carregam depois, como gerenciadores de tags, anúncios, widgets de chat e imagens adicionadas na rolagem, fica fora do total. O mesmo vale para imagens de fundo declaradas dentro das folhas de estilo e o conteúdo de vídeos incorporados. O peso real muitas vezes é maior que o número que você vê.
Perguntas frequentes
Qual é um bom tamanho de página para um site?
Menos de 1 MB transferido é uma meta confortável para uma página de conteúdo, e menos de 0,5 MB é excelente. Acima de 2 MB, visitantes em redes móveis esperam vários segundos só pelo download.
Como reduzo o tamanho de uma página da web?
Comece pelas imagens, já que costumam ser a maior parte: acerte as dimensões e depois passe para WebP ou AVIF. Em seguida, ative a compressão dos arquivos de texto, remova scripts que não são usados e diminua os arquivos de fonte. O bloco “O que cortar” do resultado lista esses itens em ordem de impacto para a sua página.
Por que o tamanho é diferente da aba Network do Chrome DevTools?
O DevTools conta tudo o que um navegador real carrega, inclusive os arquivos pedidos pelos scripts, no tamanho da sua própria janela e muitas vezes com o cache aquecido. Esta ferramenta não executa scripts e mede uma primeira visita. Desative o cache no DevTools se quiser uma comparação justa.
O tamanho da página afeta o SEO?
Não como número isolado. Mas páginas pesadas costumam ter um Largest Contentful Paint lento, e essa é uma das Core Web Vitals que o Google mede. Você pode conferir as suas com o relatório de Core Web Vitals.
AVIF é melhor que WebP?
Arquivos AVIF costumam ser menores com a mesma qualidade visual, principalmente em fotografias, e demoram mais para codificar. As versões atuais do Chrome, Firefox e Safari leem os dois. O teste de conversão mostra qual ganha em cada uma das suas imagens.
Qual é a precisão da estimativa de CO2?
É um modelo baseado em bytes transferidos e médias globais. Ninguém mediu o seu servidor nem os seus visitantes. Serve bem para comparar páginas entre si e é grosseiro demais para contabilidade de carbono.