Uma página de 14 kB pode carregar muito mais rápido do que uma página de 15 kB (2022)

 (endtimes.dev)
2 pontos por GN⁺ 2025-07-20 | 1 comentários | Compartilhar no WhatsApp
  • Manter o tamanho do site em até 14 kB pode reduzir muito o tempo de carregamento em comparação com 15 kB
  • Esse fenômeno ocorre por causa do algoritmo de slow start do TCP, e a diferença de velocidade percebida aparece por causa do limite da quantidade de dados na primeira transmissão
  • 14 kB correspondem à capacidade dos 10 pacotes TCP que a maioria dos servidores envia inicialmente
  • Em ambientes de alta latência, como internet via satélite, uma volta adicional de ida e volta (RTT) pode causar mais de 612 ms de atraso
  • Na prática, colocar o conteúdo principal abaixo de 14 kB ou posicionar recursos críticos dentro dos primeiros 14 kB é eficaz para otimizar a performance web

Visão geral e princípios principais

  • É um fato bem conhecido que, quanto menor o tamanho de um site, mais rápido ele carrega
  • Mas o fato de que, ao passar de 14 kB para 15 kB, surge uma diferença drástica na velocidade da primeira resposta é algo menos intuitivo
  • A diferença de velocidade entre uma página de 15 kB e uma de 16 kB é pequena, mas entre 14 kB e 15 kB pode haver uma diferença de até 612 ms

O que é TCP

  • Transmission Control Protocol (TCP) funciona sobre o IP (Internet Protocol) e é responsável por garantir a confiabilidade dos pacotes
  • Ao fazer uma requisição HTTP, o navegador envia vários pacotes TCP
  • Se usasse apenas IP, não haveria como confirmar se os pacotes chegaram, então o TCP fornece a função de confirmação de recebimento de pacotes (ACK)
  • O servidor envia primeiro uma pequena quantidade de pacotes e, ao receber um ACK do navegador, transmite mais pacotes
  • Se não houver ACK, entra em ação o procedimento de retransmissão de pacotes

O que é o slow start do TCP

  • O slow start do TCP é um algoritmo em que o servidor aumenta gradualmente a quantidade de pacotes enviados para descobrir a qualidade da conexão de rede (largura de banda)
  • No início da conexão, o servidor envia apenas uma pequena quantidade de pacotes, normalmente 10
  • Se o computador do visitante enviar o ACK corretamente, a quantidade de pacotes transmitidos dobra
  • Se houver perda de ACK, depois disso os pacotes passam a ser enviados em velocidade mais lenta
  • O algoritmo real varia em detalhes conforme a implementação, mas o conceito é o mesmo

Base para o limite de 14 kB

  • Na maioria dos servidores, o slow start envia de uma vez 10 pacotes TCP
  • O tamanho máximo de um pacote TCP é 1500 bytes, mas, excluindo o cabeçalho (40 bytes), sobram 1460 bytes de dados úteis
  • Portanto, 10 x 1460 = 14600 bytes (cerca de 14 kB) é o limite da primeira transmissão
  • Se o site ou os recursos importantes ficarem abaixo de 14 kB (com compressão, isso pode significar dezenas de kB no dado original), eles podem ser exibidos sem atraso adicional de ida e volta no início

Quanto atraso uma única ida e volta pode causar

Exemplo de internet via satélite

  • Um exemplo representativo de ambiente de alta latência é o usuário de internet via satélite (plataformas de perfuração de petróleo, navios de cruzeiro etc.)
  • Ao solicitar a página inicial no celular, o trajeto roteador → antena satelital → satélite no espaço → estação terrestre → servidor consome dezenas a centenas de ms em cada trecho
  • A ida e volta total da transmissão inclui dois trajetos espaciais de ida e volta, deslocamento pelos trechos de rede e processamento no servidor, resultando em cerca de 612 ms de atraso adicional
  • Ao usar HTTPS, isso pode aumentar para 1836 ms por causa do handshake adicional

Latência em redes terrestres

  • Mesmo em redes móveis como 2G e 3G, a latência pode chegar a 100~1000 ms
  • Em situações de congestionamento, sobrecarga do servidor, perda de pacotes e outros cenários, atrasos adicionais também podem surgir

Estratégias de otimização de sites com a regra dos 14 kB

  • O ponto principal é tornar o site ou página o menor possível
  • O ideal é projetar cada página para que o volume comprimido transmitido fique em até 14 kB
    • Com compressão, o conteúdo real pode chegar a ~50 kB
  • Isso costuma ser perfeitamente viável ao reduzir vídeos em autoplay, pop-ups, rastreadores e JS/CSS desnecessários, entre outros elementos supérfluos
  • Se for difícil implementar a página inteira em 14 kB, é importante priorizar, nos primeiros 14 kB, os recursos críticos e o conteúdo principal (CSS, JS, texto principal etc.)
  • Cabeçalhos HTTP (não comprimíveis) e imagens (carregando só o mínimo necessário/a parte visível ou usando placeholders) também entram nesses 14 kB

Exceções da regra dos 14 kB e questões dos protocolos mais novos

  • A regra dos 14 kB não é um exagero, mas há algumas exceções
    • Alguns servidores ampliam a janela inicial para 30 pacotes
    • O handshake TLS pode permitir uma janela maior
    • O número de pacotes transmissíveis por rota pode ser armazenado em cache, permitindo enviar mais na conexão seguinte
  • Mesmo no HTTP/2, a prática de o servidor começar com 10 pacotes por causa do slow start do TCP em geral não muda
  • Em HTTP/3 e QUIC, a regra dos 14 kB também é oficialmente recomendada

Resumo e materiais de referência

  • Os fundamentos técnicos e materiais adicionais de explicação podem ser conferidos em cada link
  • Publicação inicial: 2022-08-25, última revisão: 2022-08-26, autor: Nathaniel, tags relacionadas: performance web, HTTP, TCP

Links de referência

  • Estrutura de frame Ethernet e cabeçalho TCP, materiais adicionais sobre latência e largura de banda, especificações de TCP/QUIC etc.

Leituras relacionadas

1 comentários

 
GN⁺ 2025-07-20
Comentários do Hacker News

  • Desenvolvedores de software precisam prestar mais atenção à camada de mídia, especialmente aos pontos que o autor destacou sobre confiabilidade e latência em 3G/5G. No rádio, quase sempre há retransmissão, e na maioria das comunicações HTTP os pacotes precisam chegar em ordem para a UI ser atualizada. Na prática, até uma única requisição REST só cabe de fato em um único pacote quando requisição e resposta têm menos de 1400 bytes. Acima disso, essa requisição “única” na verdade é dividida em vários pacotes. Se qualquer um deles tiver problema, a tela só será atualizada corretamente quando todos chegarem em ordem. Se quiser testar, ative o modo 3G e perda de pacotes nas ferramentas de desenvolvedor do Chrome; você verá que até uma pequena otimização já melhora bastante a responsividade da UI. Por isso faz muito sentido manter API e UI o menores possível

  • Minha homepage transfere 7,0 kB comprimidos

    • /
    • main.css
    • favicon.png
    • total 7,0 kB A lista do blog e o site inteiro são feitos com meu gerador de site estático customizado (público: site.lisp, usando Common Lisp). Em posts de matemática, uso KaTeX com renderização no cliente, e isso adiciona mais 347,5 kB
    • katex.min.css 23,6 kB
    • katex.min.js 277,0 kB
    • auto-render.min.js 3,7 kB
    • KaTeX_Main-Regular.woff2 26,5 kB
    • KaTeX_Main-Italic.woff2 16,7 kB
    • total adicional 347,5 kB Estou pensando em algum dia trocar o KaTeX para renderização no servidor. Esse blog é meu projeto de paixão desde a época da moradia estudantil na universidade. Escrevi todo o HTML, os templates e o CSS à mão, e sempre monto cada página com cuidado para incluir só o que é realmente necessário, mantendo o tamanho pequeno
    • Minha homepage
    • Coleção de posts de matemática
      • Não que você não deva usar uma abordagem melhor, mas a latência da renderização no cliente quando componentes dinâmicos como expressões LaTeX carregam é quase nunca (ou literalmente nunca) perceptível para usuários comuns. Otimização excessiva também é um problema. Toda essa busca por performance guiada por SEO não traz tanto retorno pelo tempo investido a menos que seja um serviço com milhões de visualizações. É como se preocupar com aerodinâmica ao tentar conduzir um barco sem tripulação no mar usando as marés. Com recursos limitados, olhando custo total e benefício, otimizar nem sempre é a melhor escolha
      • Se o conteúdo matemático é pouco e ainda assim você quer usar KaTeX, talvez valha considerar MathML(mathml-core) como alternativa
      • Não entendo por que fórmulas matemáticas ou expressões LaTeX precisam ser renderizadas por js no cliente. Por que não converter antes para HTML/CSS e já entregar pré-renderizado?
      • Outra ideia é carregar bibliotecas pesadas depois da renderização inicial da página, ou carregar gráficos das fórmulas em SVG só quando entrarem no viewport. Só uma opinião minha

  • A meta de 14 kB é um pouco agressiva, mas a ideia de limitar à janela inicial de 10 pacotes também é interessante. Há um projeto focado em tamanho de site como o meu, o 512kb.club. É um lugar que compara tamanhos de sites como se fossem placares de golfe. Meu site(anderegg.ca) deu 71 kB somando todos os recursos antes do cadastro. Graças a esse projeto descobri também o Cloudflare Radar, que tem uma boa ferramenta para análise de sites e medição de tamanho de página. O foco principal é um dashboard da internet como um todo, mas ele também inclui uma ferramenta de análise de tamanho de página

    • Como usuário, quero perguntar: para que servem os 500 kB restantes? Eu só preciso de 90% texto, e no resto gráficos vetoriais já bastam. Com 14 kB já dá para ter bastante texto e gráficos; para que servem os outros 500?
    • 512 kB é um padrão realista. Eu também aplico esse padrão ao meu site. Sites na faixa de 14 kB já passaram do ponto para a web
    • Para um site pessoal, 512 kB é totalmente atingível. Meu próximo alvo é 99 kB (menos de 100 kB). Dá para fazer tranquilamente investindo alguns fins de semana. Meu site está na faixa Orange dentro do limite de 512 kB

  • Se quiser experimentar isso de forma mais divertida, o tamanho da janela inicial (IW) pode ser configurado no lado do servidor. Por exemplo, dá para ajustar assim

    • ip route change default via <gw> dev <if> initcwnd 20 initrwnd 20 Procurando por aí, dizem que hoje alguns CDNs já usam janela inicial de 30 pacotes (45 kB)
    • Há 13 anos, até 10 pacotes eram vistos como “trapaça”. Veja aqui e o blog do Ben Strong (arquivo)
    • Queria saber se existe alguma fonte que comprove essa janela inicial de 30 pacotes em CDN
    • Também dá para simplesmente configurar como um “mau cidadão” e pôr 1000 pacotes... só que a desvantagem é criar gargalo para alguém em conexão discada ou com bufferbloat

  • O que foi explicado no texto abaixo também se aplica: Blog da Cloudflare - o fenômeno em que ISPs russos passaram a permitir só até 16 KB, tornando a maior parte da navegação impossível. Segundo a análise da Cloudflare, ISPs da Rússia estão limitando a internet de usuários locais para que apenas os primeiros 16 KB de cada recurso web sejam carregados

  • A interseção entre quem não sabe o que é TCP Slow Start e quem se importa o bastante com atraso no carregamento de sites para pensar nisso em detalhe é muito pequena. Startup tem que focar primeiro em ser startup, e só empresas grandes têm folga para ficar obcecadas com esse tipo de otimização

    • Se a abordagem for “estamos focando no que importa, então não dá para pensar em otimização de performance”, então você nunca vai pensar nisso. É por isso que hoje a maioria dos apps e sites é lenta e ruim
    • Se isso fosse verdade, então software de lugares como a Microsoft deveria sempre funcionar com perfeição e máxima eficiência
    • Conceitualmente isso parece correto. Mas, se Evan Wallace da Figma não fosse obcecado por performance, a Figma não seria o que é hoje. Às vezes, “performance” em si vira um recurso central do produto
    • Isso nem precisa ser uma escolha; pode vir por padrão. Eu uso datastar tanto no demo de 1 bilhão de células quanto no demo de checkboxes e ambos ficam com pouco mais de 10 kB. Em rede móvel e 3G a diferença é grande. Nos meus testes, passar de 14 kB adicionava 3 segundos em conexões ruins. Como o mantenedor do datastar já cuidou até de TCP slow start, eu acabei me beneficiando sem nem precisar fazer esforço
    • Não acho que o tamanho da empresa tenha muita relação com otimização de performance. Na verdade, empresas grandes muitas vezes são mais lentas

  • Minha homepage tem 17,2 KB! (sem contar dependências) Otimizei muito minha página pessoal e consegui até nota máxima 100 no Lighthouse. Antes eu achava que era impossível, mas consegui. E, para referência, foi feita em Rails. Esse tipo de otimização realmente vale a pena. A sensação de uma página aparecer como um relâmpago, sem parecer travada, é muito satisfatória por si só

    • Quando você experimenta o news.ycombinator.com carregando instantaneamente, o conforto psicológico é tão grande que você acaba abrindo o site automaticamente em toda pausa
    • Otimizei de forma extrema o código de template para milhares de sites e consegui 100/100/100/100 no Lighthouse. Inclusive 100 perfeito no mobile. A carga inicial é bem maior que 17,2 kB, algo perto de 120 kB, mas o truque foi eliminar todas as requisições HTTP desnecessárias, executar JS só na área "above-the-fold", e no resto usar lazy eval, defer e todo tipo de carregamento adiado. JS/CSS foram inline, e widgets de terceiros também ficaram em esquema de “fachada”, como ícone de popup, deixando a requisição real para depois. O backend SSR também ajudou bastante. Até com vídeo de fundo do Vimeo eu conseguia 100, mas com Youtube era impossível. O jeito de chegar à pontuação perfeita foi interpretar o resultado do Lighthouse e reescrever completamente a base de código. Como resultado, sumiram totalmente as reclamações de clientes sobre velocidade, e isso virou uma grande vantagem competitiva tanto em SEO quanto na pontuação em si
    • Rails não tem relação direta com otimização de renderização. Parabéns pela pontuação perfeita no Lighthouse

  • Acho que o texto tem duas fraquezas lógicas

    1. Há uma fórmula dizendo que em comunicação via satélite leva cerca de 1600 ms para enviar um pacote, mas isso é fraco como base para a regra dos 14 kB. Não há comparação com sites grandes, então não demonstra que 10 pacotes ≠ 16 s
    2. Foi dito que imagens também entram na regra dos 14 kB de uma página, mas com que frequência imagens ficam inline no carregamento inicial? Na prática é um caso raro, então deveria ficar mais claro que isso não se aplica em 99,9% dos casos - “<i>Casos em que imagens ficam inline?</i>” Um exemplo típico é usar thumbnails de baixa resolução apenas na tela inicial, aplicar blur com CSS e depois fazer fade in assíncrono da imagem real. Se bem feito, isso consome só algo como 100~200 bytes adicionais. Eu uso no meu blog, e plataformas como Wordpress e Medium também adotam bastante. É um truque mais comum em frontend comercial hiperotimizado - Também não concordo com a premissa de agir como se a maioria dos usuários estivesse em conexão via satélite de baixa latência, e como se, num mundo em que todos os sites têm vários MB, só a minha página não pudesse suportar isso

  • A geração atual tende a fazer até site estático simples com frameworks como Next.js. Dá uma certa tristeza ver a era de HTML+CSS+js desaparecendo

    • Concordo. Eu também já fiz sites com recurso mínimo, JavaScript otimizado manualmente e a regra dos 14 kB, mas essa abordagem acaba impondo restrições de design e arquitetura. Quando as funcionalidades aumentam, todas aquelas decisões de “minimização” viram dívida técnica. A maioria romantiza a “web pura sem framework”, mas em algum momento isso passa a ser mais sofrimento do que solução. Já com frameworks JS isomórficos, você pode começar com página estática, otimizar até certo ponto, e depois migrar para um thick client JS se precisar
    • Na verdade, a tendência já está mudando de novo. Hoje a maioria dos frameworks dá bom suporte a site estático. O Astro, por exemplo, nasceu justamente para site estático
    • Parece novidade só agora, mas na verdade isso já acontece desde antes da explosão do jQuery por volta de 2010
    • O Next.js otimiza o bundle de forma muito agressiva, então é ótimo para lançar em lambdas ou servidores pequenos. Sites estáticos feitos com Next também ficam com bundles bem pequenos

  • Além da latência, minimizar consumo de recursos é condição essencial para um futuro sustentável. O impacto ambiental da rede também está longe de ser pequeno. É uma pena que o tom dos comentários pareça meio sarcástico. Talvez essa otimização não seja a solução definitiva, mas eu gostaria que o efeito de redução de consumo de energia fosse mais enfatizado

    • A maior parte do tráfego da internet é streaming de vídeo. Otimizar alguns megas em páginas web mal aparece. Vale discutir eficiência, mas tentar otimizar tudo pode acabar gastando recursos justamente em áreas que mais precisam de otimização
    • Isso nem é fruto baixo. Enquanto você otimiza para economizar 1~2 mWh em uma página, uma única busca em mecanismo de pesquisa gasta 100 vezes mais, e uma única interação com chatbot gasta 10 mil vezes mais. Cache e lazy loading já mitigam bastante disso
    • Ficar se preocupando com tamanho de página é quase perda de tempo. Mesmo multiplicando por 10, por segurança, a eletricidade usada por ano em navegação web ainda é muito menor do que a energia gasta para fazer um único hambúrguer. O impacto ambiental seria maior se o desenvolvedor, em vez de otimizar por uma semana, comesse uma salada a menos nesse período
    • Concordo totalmente. Uma vez fui à BBC e fiquei chocado ao ver um artigo textual pequeno ocupando 120 MB no cache. Isso estimula uma cultura de energia e desperdício desnecessários. Também deixo meu site o mais minimalista possível e, no YouTube, só envio em 1080p em vez de 4K. 4K e 8K nem precisariam existir. As pessoas costumam falar em adicionar mais alguns MW de energia solar, mas deveríamos imaginar o quão bom seria simplesmente “produzir menos”. Sinto falta da escala pequena da web na época do modem 56K; em algum ponto havia um meio-termo, mas já passamos muito dele
    • As pessoas só passam a se importar quando isso começa a afetá-las diretamente. Eu também me preocupo com o meio ambiente. Há quem responda dizendo que AI é pior, mas na prática a própria AI também rastreia essas páginas pesadas. E o padrão de 14 kB representa menos de 1% da carga média de página no mobile