Página bio rápida: porque o peso decide os cliques

Publicas um story, milhares de pessoas veem, umas centenas tocam no link da bio. E depois há um número que nenhum dashboard te mostra: quantas fecharam a página antes de ela abrir. Num ecrã em branco, no metro, com uma barra de rede, três segundos parecem dez. A pessoa volta para o feed e o teu clique morreu sem deixar registo.

O peso da tua página bio não é um detalhe técnico. É um filtro à entrada de tudo o que fazes: cada grama a mais é uma fatia da audiência que nunca chega ao teu conteúdo.

Os números, medidos por nós

A 14 de agosto de 2026 medimos páginas bio públicas nas três plataformas, todas pelo mesmo método: o HTML mais todos os scripts e folhas de estilo que ele manda buscar — ou seja, o que um telemóvel com a cache vazia tem mesmo de descarregar antes de conseguir desenhar a página, já comprimido como viaja na rede.

Uma página da maior delas faz onze vezes mais pedidos e transfere dezoito vezes mais bytes do que a nossa. E a coluna que mais dói não é a do total: é a do JavaScript — de cada dez bytes que a maior delas manda para o telemóvel, cerca de seis são programa, não são a tua página. Repetimos a medição em várias páginas de cada plataforma e os números mexem-se pouco: não é uma página infeliz, é a arquitetura.

O peso que não se vê: o telemóvel tem de ler tudo aquilo

Aquele mega e pouco chega comprimido. Descomprimido, que é como o telemóvel o tem de ler, executar e manter em memória, a conta é outra:

• Kortilink: 0,017 MB de JavaScript, em 3 ficheiros;
• a mais leve das outras: 0,03 MB;
• as duas maiores: 1,1 MB e 2,2 MB — sessenta a cento e trinta vezes o nosso.

Descarregar 1 MB numa rede decente demora pouco. Interpretar um megabyte de JavaScript num telemóvel de 150 euros demora muito — e é tempo de processador, que não melhora por o sinal estar bom. É por isso que uma página destas continua lenta em Wi-Fi num telemóvel antigo, e é a parte que quase nunca aparece nas comparações.

O que um pedido custa numa rede fraca

Numa boa ligação de fibra, a latência — o tempo de uma viagem de ida e volta ao servidor — anda nos 10 a 20 milissegundos. Num 4G fraco, num comboio ou numa zona rural, sobe facilmente para 300 a 400 milissegundos por viagem. A largura de banda até pode existir; é a latência que mata.

Uma nota de honestidade, porque este argumento anda por aí desatualizado: o velho limite de «seis ligações por domínio» já não se aplica. As três plataformas servem por HTTP/2, que faz passar muitos ficheiros por uma única ligação. Cinquenta e cinco pedidos ao mesmo domínio já não são cinquenta e cinco viagens em fila.

O que continua a custar é outra coisa, e essa não desapareceu:

• Cada domínio novo paga a entrada inteira. O HTTP/2 partilha uma ligação, mas só dentro do mesmo domínio. Os oito a dezasseis domínios das maiores são outras tantas resoluções de DNS e apresentações de TLS — várias idas e voltas cada uma, antes do primeiro byte útil. A nossa página vive num domínio só.
• Os pedidos descobrem-se em cadeia. O browser não sabe que precisa do ficheiro C até ter lido o ficheiro B, que só pediu depois de ler o A. Cada elo da corrente paga a latência inteira, multiplexado ou não.
• Os bytes são bytes. A 1,5 Mbps reais — um 4G fraco a sério —, um mega e pouco leva perto de seis segundos só a passar pelo cabo.

Uma página de 14 pedidos, 200 KB e três domínios paga muito menos disto do que uma de 80 pedidos e 1,5 MB. Medido a partir de Portugal, a primeira tinta das nossas fica entre 300 e 510 ms.

2,5 segundos: a linha que separa abrir de desistir

A referência da indústria é clara: o web.dev, nos Core Web Vitals, define que o conteúdo principal de uma página deve aparecer em menos de 2,5 segundos para a experiência ser considerada boa. Acima disso, a probabilidade de abandono cresce a cada segundo — e o tráfego de uma bio é quase todo móvel, o cenário onde as páginas pesadas mais sofrem. Os dados públicos do HTTP Archive mostram há anos a mesma tendência: as páginas engordam mais depressa do que as redes melhoram.

Numa rede boa, todas as plataformas parecem rápidas — incluindo as pesadas. A diferença aparece exatamente onde não estás a olhar: no telemóvel do teu seguidor com rede fraca. Tu nunca vês a tua página lenta, porque a tens em cache. Ele vê sempre.

De onde vem o peso

Uma lista de dez botões não precisa de um megabyte de JavaScript. O peso não é o teu conteúdo — é o que a plataforma acrescenta:

• Scripts de tracking e publicidade, que servem o modelo de negócio da plataforma, não o teu;
• Frameworks de JavaScript que constroem a página no telemóvel do visitante em vez de a entregarem pronta;
• Fontes e widgets externos, cada um com o seu domínio e a sua portagem de latência.

É por isso que a bio do Kortilink usa renderização no servidor: o servidor entrega o HTML já construído, e o telemóvel só tem de o mostrar. Sem framework a arrancar, sem centenas de kilobytes de JavaScript a interpretar antes de aparecer o primeiro botão. Repara na tabela lá em cima: dos nossos 200 KB, 38 são o HTML — é conteúdo, é a tua página. Nos 1,9 MB da segunda maior, o HTML é uma fatia pequena e o resto é maquinaria.

E não somos puros: a nossa página também traz coisas que nem toda a gente usa — os ícones das redes sociais, as seis línguas. A diferença é que o que é raro só se vai buscar quando faz falta. Uma bio com stories pede mais dois ficheiros, cerca de 11 KB; uma com blocos pouco usados, mais 6 KB. No pior dos casos são 77 KB — ainda uma fracção do que as maiores carregam em toda e qualquer página.

O que podes fazer já, em qualquer plataforma

Sejamos justos: parte do peso está nas tuas mãos, seja qual for a ferramenta.

1. Testa como os teus seguidores veem. No Chrome, abre as DevTools, ativa a limitação de rede «Slow 4G» e carrega a tua bio com cache desativado. É a experiência real de muita da tua audiência.
2. Comprime as imagens. Uma foto de capa de 2 MB destrói qualquer otimização da plataforma.
3. Evita widgets embutidos. Um player incorporado pode custar mais pedidos do que a página inteira. Um botão que abre a app nativa converte melhor e pesa quase nada.
4. Corta blocos. Menos blocos é menos peso e menos hesitação — dois ganhos pelo preço de um.

E uma nota honesta: velocidade não salva uma bio mal construída. Uma página instantânea com o link errado no topo converte mal na mesma. A velocidade decide quantos chegam; a estrutura decide quantos clicam. Para a segunda parte, vê os sete erros que custam cliques numa bio.

Porque insistimos nisto

Podíamos competir em número de funcionalidades — é a corrida do costume nesta categoria, e há sempre quem a corra melhor do que nós em cada frente. Escolhemos competir noutra coisa: a tua página abre. Sempre. Também no telemóvel com uma barra de rede, também no 4G do interior, também na diáspora onde a ligação nem sempre ajuda.

Porque cada visitante que desiste no ecrã em branco era um stream, uma venda ou um contacto que já tinhas conquistado — e que perdeste no último metro do caminho.

Perguntas frequentes

Como meço a velocidade da minha página bio?

Usa o PageSpeed Insights do Google ou o separador Network das DevTools do Chrome com limitação «Slow 4G» e cache desativado. Olha para três números: quantos pedidos, quantos KB transferidos e quanto tempo até o conteúdo principal aparecer. Compara com a linha dos 2,5 segundos.

Então 200 KB não é assim tão pouco?

Não é, e é bom dizê-lo. Desses 200 KB, mais de metade é o fundo do tema e o avatar — o teu conteúdo, não a nossa maquinaria. O HTML da página são 38 KB comprimidos, e o programa que a faz funcionar são 17. Uma página nossa sem fundo de tema fica perto dos 100 KB. Quem escolhe um fundo pesado paga-o, e isso é verdade em qualquer plataforma. As tuas imagens somam-se a isso, e é por isso que a compressão importa. A diferença é o ponto de partida: quem começa em 1,1 MB já gastou o orçamento todo antes de chegar à tua foto de perfil.

Como é que mediram, e posso repetir?

Podes. Descarregámos o HTML de cada página e, a seguir, todos os ficheiros de JavaScript e de estilos que ele nomeia, somando os bytes tal como viajam comprimidos — nada de estimativas. Não contámos as fotografias (mudam de página para página) nem os pedidos que cada plataforma faz depois de desenhar, como as estatísticas. Essa última decisão beneficia a concorrência, não nós: os números deles são um mínimo, e o real é maior. No teu lado, as DevTools do Chrome no separador Network, com «Disable cache» ligado, dão-te o mesmo tipo de leitura para qualquer página.

Mudar de plataforma por causa da velocidade vale o trabalho?

Se os teus analytics mostram muitas visitas e poucos cliques, e o teu público está em redes móveis, provavelmente sim — e o trabalho é menor do que parece: o nosso importador lê a tua página pública noutra plataforma e recria os blocos sem pedires nada ao suporte deles. Mais artigos sobre o tema no nosso blog.