Page Size Checker

Cole qualquer URL no campo Page URL acima e clique em verificar. O verificador de tamanho de página busca a URL, lê os cabeçalhos de resposta e retorna o tamanho bruto do documento HTML, o tamanho da rede gzip ou brotli, tempo de resposta em milissegundos, os valores de Content-Encoding e Cache-Control, e uma contagem de todos os CSS, JS, imagem, fonte e iframe externos declarados. Estima o peso total da página usando medianas do Web Almanac 2024 (2,4 MB mediana, 5 MB no p75) e marca se você está leve, média ou pesado. O Chrome DevTools mostra os mesmos números na aba Network, mas você tem que carregar a página, limpar o cache, hard reload e ler entre vários painéis. Esta ferramenta dá a mesma resposta em dois segundos para qualquer URL pública.

O tamanho da página é a soma de todos os bytes que o navegador baixa para renderizar a página: o documento HTML mais todos os arquivos CSS, arquivos JS, imagens, fontes, vídeos e ativos iframe. O número mais útil é o tamanho comprimido na rede, pois é o que atravessa a rede. Para calcular manualmente, abra o Chrome DevTools, mude para Network, hard-reload com cache desabilitado e leia a barra inferior onde o Chrome imprime requisições e bytes transferidos totais. O verificador acima faz a mesma aritmética para o documento HTML diretamente e estima o peso total a partir de ativos declarados usando medianas do Web Almanac 2024, então você não precisa esperar que todo sub-recurso seja concluído.

Use o campo acima. Solte a URL em Page URL, clique em verificar e leia o cartão de resposta. O verificador relata bytes do documento HTML, bytes de rede gzip, tempo de resposta, codificação, cabeçalhos de cache e o inventário de requisições de ativos por tipo. Faz benchmark do total estimado em relação às medianas do Web Almanac 2024 e marca a página em verde, âmbar ou vermelho. Para uma auditoria de renderização mais profunda, execute o google-crawler-simulator que executa JavaScript e mostra o DOM pós-renderização, depois execute o alt-text-checker no inventário de imagens. A combinação diz exatamente quais ativos comprimir, diferir ou remover primeiro.

Aim para menos de 1,5 MB de peso total em páginas de landing e conversão. O Web Almanac 2024 mediu a página mediana em 2,4 MB e o p75 em 5 MB, com o p90 acima de 9 MB. Páginas abaixo de 1 MB passam no limite de LCP de 2,5 segundos 82% das vezes em 4G móvel. Páginas acima de 3 MB passam apenas 38% das vezes. Dentro do orçamento, mantenha HTML abaixo de 100 KB comprimido, JS abaixo de 300 KB comprimido, CSS abaixo de 60 KB comprimido e a maior imagem única abaixo de 200 KB. O verificador marca páginas que excedem esses limites. Verifique novamente após cada deploy porque scripts de terceiros e plugins CMS rotineiramente adicionam peso sem que ninguém perceba.

LCP mede quanto tempo leva o maior elemento visível para renderizar. Na maioria das páginas esse elemento é uma imagem de herói, um frame de vídeo em banner ou um grande bloco de título. Páginas pesadas atrasam o LCP porque CSS e JS render-blocking na head empurram a pintura mais tarde, a imagem LCP em si é frequentemente não otimizada e contenção de rede priva a requisição LCP de largura de banda. O limite do Google é 2,5 segundos. Os dados do HTTP Archive de 2024 mostram que páginas acima de 3 MB a perdem 62% das vezes em móvel. Corrija LCP pré-carregando a imagem de herói, servindo-a como AVIF ou WebP, diferindo JS não crítico com defer ou async e aparando CSS crítico. Execute novamente o verificador após cada mudança.

Ambos são algoritmos de compressão de texto aplicados na camada HTTP. Gzip é o padrão da web desde os anos 1990 e é suportado por todos os navegadores. Brotli foi lançado pelo Google em 2015 e é enviado em 96% dos navegadores a partir de 2026. Brotli comprime texto 15-25% menor do que gzip em média para HTML, CSS e JS, com a lacuna mais ampla na markup altamente repetitiva. A maioria dos CDNs (Cloudflare, Fastly, CloudFront) habilitam brotli por padrão para texto estático e caem de volta para gzip para clientes antigos. O verificador relata o Content-Encoding real que seu servidor retornou. Se mostrar gzip ou vazio, mude seu CDN para brotli para uma queda imediata de 15-25% no peso de texto sem mudança de código.

Aborde as categorias mais pesadas primeiro. Imagens geralmente são o item de maior linha: converta fotos de herói para AVIF com fallback WebP (AVIF é em média 50% menor do que JPEG com a mesma qualidade), redimensione para dimensões de exibição reais e lazy-load qualquer coisa abaixo da dobra com loading="lazy". JavaScript é o próximo: code-split por rota, diferencie scripts de terceiros até após first paint e remova dependências não utilizadas. CSS: purge seletores não utilizados com PurgeCSS ou JIT do Tailwind, inline CSS crítico na head e carregue o resto async. Fontes: subset para os glifos que você usa e auto-hospede com font-display: swap. Uma auditoria de bloat típica reduz o peso total em 40-60% na primeira passagem.

Sim, severamente. Em uma conexão rápida 4G (12 Mbps), uma página de 5 MB leva cerca de 3,5 segundos para baixar antes da renderização começar. Em uma conexão lenta 3G (1,6 Mbps), a mesma página leva 25 segundos. O Lighthouse do Google simula um perfil "Slow 4G" precisamente porque redes móveis do mundo real são mais lentas do que o marketing das operadoras sugere. O Web Almanac de 2024 descobriu que 53% dos usuários móveis abandonam páginas que levam mais de 3 segundos para carregar. Páginas pesadas também drenam planos de dados medidos em uma única visita. Aim para menos de 1 MB em templates mobile-first e combine o verificador com o google-crawler-simulator para confirmar que o bot móvel vê a mesma carga útil leve.

Use AVIF como formato principal com fallback WebP para os 4% de navegadores que carecem de suporte AVIF. AVIF comprime fotos 50% menor do que JPEG com qualidade visual equivalente e 20-30% menor do que WebP. Para um herói JPEG de 400 KB, a versão AVIF normalmente pesa 90-130 KB. Use o elemento <picture> com <source type="image/avif"> e <source type="image/webp"> depois um fallback JPEG <img>. Para ícones e gráficos simples, use SVG: dimensiona infinitamente, pesa menos de 5 KB para a maioria dos ícones e comprime bem com brotli. Evite PNG exceto para screenshots que precisam de transparência sem perda. Substitua GIF por um MP4 ou WebM silencioso com autoplay, que pesa 90% menos.

Sim. Um peso de fonte completo do Google Fonts ou Adobe Fonts frequentemente pesa 80-120 KB porque inclui todos os glifos Latin, Cyrillic, Greek e Vietnamese mais o conjunto de pontuação completo. A maioria dos sites usa apenas Latin básico. Subsetting reduz o arquivo para 18-25 KB, uma economia de 75-85% por fonte. Ferramentas como glyphhanger ou Fontsource lidam com subsetting automaticamente. Auto-hospede o arquivo com subset com font-display: swap para que o texto seja renderizado imediatamente em uma fonte fallback e re-pintado quando a fonte customizada carrega. Limite pesos totais para dois ou três (um corpo, um cabeçalho, opcionalmente um display). Cada peso extra é outro 18-25 KB mais uma requisição render-blocking a menos que pré-carregada.

Execute uma ferramenta CSS purge contra sua build de produção. PurgeCSS escaneia modelos HTML e JS para nomes de classe e deleta qualquer seletor no seu CSS que nunca é referenciado. O compilador JIT do Tailwind faz isso automaticamente. Para CSS escrito à mão, frameworks como Next.js, Astro e SvelteKit executam uma etapa de purge no momento da build. A economia é normalmente dramática: um site Bootstrap que envia o framework completo de 200 KB pode cair para 8-15 KB após purge. Inline CSS crítico para conteúdo above-the-fold na head (normalmente 10-15 KB) e carregue o resto com <link rel="stylesheet" media="print" onload="this.media='all'">. Verifique novamente com o verificador de tamanho, depois execute o h1-checker para confirmar que o HTML mais leve ainda tem uma estrutura de cabeçalho válida.

Lazy loading difere o download de ativos fora da tela até o usuário rolar perto deles. O atributo HTML nativo loading="lazy" funciona em <img> e <iframe> em 95% dos navegadores e requer zero JavaScript. Em uma página de artigo longa com 30 imagens, lazy loading normalmente adia 25 delas, reduzindo a carga inicial em 60-80% e caindo LCP em 1-2 segundos. Aplique a cada imagem e iframe abaixo da dobra, mas nunca para a imagem LCP em si, pois lazy loading o herói atrasa a métrica que você está tentando melhorar. Combine com conversão de formato de imagem (AVIF ou WebP) para ganhos compostos. O verificador marca páginas com contagens altas de imagens; se você vê 40+ imagens em uma única página, lazy loading é seu maior ganho disponível.

O tamanho do documento HTML é o número de bytes da resposta HTML em si: a markup que o servidor retornou antes do navegador buscar qualquer sub-recurso. Peso total da página é a soma do documento HTML mais todos os arquivos CSS, arquivos JS, imagens, fontes, vídeos e iframes que a página carrega. Uma página pode ter um documento HTML de 8 KB e um peso total de 6 MB se carregar imagens e scripts pesados. Ou pode ter um documento de 250 KB cheio de conteúdo inline e um total de 400 KB. O verificador relata tamanho do documento HTML diretamente da resposta e estima peso total a partir da contagem de ativos declarados usando medianas do Web Almanac 2024. O número do documento HTML importa mais para crawl budget; peso total importa mais para LCP.

Cabeçalhos cache-control dizem ao navegador quanto tempo manter um ativo antes de re-requisitá-lo. Um cabeçalho de cache-control: public, max-age=31536000, immutable diz ao navegador manter o arquivo por um ano e nunca revalidar. Visitantes repetidos baixam zero bytes para esse ativo. O verificador relata o valor de Cache-Control na resposta HTML para que você possa verificar sua configuração de CDN. O próprio HTML deve geralmente ser short-cached (300-600 segundos) pois conteúdo atualiza frequentemente. Ativos estáticos (JS, CSS, fontes, imagens) com nomes de arquivo com hash devem ser cached um ano porque uma mudança de conteúdo cria um novo nome de arquivo. Sem cache apropriado, cada carregamento de página é um carregamento frio.

Content-Encoding é o cabeçalho de resposta HTTP que diz ao navegador como o corpo foi comprimido. Valores comuns são gzip, br (brotli), deflate, zstd ou vazio (não comprimido). O verificador relata o que quer que seu servidor tenha retornado. Se mostrar gzip em uma resposta de texto, você está economizando 70-80% da largura de banda versus não comprimido. Se mostrar br, você economiza 15-25% adicionais em cima de gzip. Se estiver vazio em uma resposta HTML, CSS ou JS acima de 5 KB, seu servidor ou CDN está mal configurado e cada visitante paga o peso total não comprimido. Formatos binários (JPEG, PNG, WebP, AVIF, MP4) já estão comprimidos no nível de formato e normalmente retornam Content-Encoding vazio.