Página Bio Fast: Porque el peso decide los clics

Publica una historia, miles de personas la ven, unos cientos tocan el enlace bio. Y luego hay un número que no te muestra ningún panel: ¿Cuántos han cerrado la página antes de que se abra? En una pantalla en blanco, en el medidor, con una barra de red, tres segundos parecen diez. La persona regresa al feed y su clic ha muerto sin dejar un registro.

El peso de su página de bio no es un detalle técnico. Es un filtro en la entrada de todo lo que haces: cada gramo más es una porción de la audiencia que nunca llega a tu contenido.

Los números, medidos por nosotros

El 14 de agosto de 2026, medimos las páginas bio-públicas en las tres plataformas, todas por el mismo método: el HTML más todos los scripts y las hojas de estilo que envía, es decir, lo que un teléfono celular con caché vacío realmente tiene para descargar antes de poder dibujar el página, ya comprimida como viajando en la red.

Una página de Linktree hace once veces más pedidos y transfiere dieciocho veces más bytes que el nuestro. Y la columna que más duele no es la del total: es la de JavaScript, de cada diez bytes que envía Linktree al teléfono celular, más de nueve son un programa, no son tu página. Repetimos la medida en varias páginas de cada plataforma y los números se mueven poco: no es una página infeliz, es la arquitectura.

El peso que no puedes ver: el celular tiene que leerlo todo

Ese mega y poco llega comprimido. Sin comprimir, que es como el celular tiene que leer, ejecutar y guardar en la memoria, la cuenta es diferente:

• kortilink: 0.04 MB JavaScript, en 3 archivos;
• balizas: 0,7 MB, en 14 archivos;
• linktree: 3.9 MB, en 51 archivos.

La descarga de 1 MB en una red decente lleva poco tiempo. Interpretar 3.9 MB de JavaScript en un teléfono móvil de 150 euros lleva mucho tiempo — y es tiempo de procesador, que no mejora porque la señal es buena. Es por eso que una página como esta permanece lenta en Wi-Fi en un teléfono antiguo, y es la parte que casi nunca aparece en las comparaciones.

Lo que cuesta una solicitud en una red débil

En una buena conexión de fibra, la latencia, el tiempo para un viaje de ida y vuelta al servidor, funciona entre 10 y 20 milisegundos. En un 4G débil, en un tren o en un campo, se eleva fácilmente a 300 a 400 milisegundos por viaje. Incluso puede existir el ancho de banda; Es la latencia lo que mata.

Una nota de honestidad, porque este argumento está desactualizado: el viejo límite de «seis enlaces por dominio» ya no se aplica. Las tres plataformas sirven por HTTP/2, lo que hace que muchos archivos pasen a través de una sola conexión. Cincuenta y cinco solicitudes al mismo dominio ya no son cincuenta y cinco viajes en línea.

Lo que sigue costando es otra cosa, y éste no ha desaparecido:

• Cada dominio nuevo paga la entrada completa. El HTTP/2 comparte un enlace, pero solo dentro del mismo dominio. Los cuatro dominios de Linktree son cuatro resoluciones DNS y cuatro presentaciones TLS, varias rondas y rondas cada una, antes del primer byte útil. Nuestra página vive en un solo dominio.
• solicitudes se descubren en cadena. El navegador no sabe que necesita el archivo C hasta que haya leído el archivo B, que solo se preguntó después de leer A. Cada eslabón de la cadena paga toda la latencia, multiplexado o no.
• bytes son bytes. A 1.5 Mbps reales, un 4G débil en serio, un mega y poco tarda cerca de seis segundos simplemente pasando el cable.

Una página de 5 solicitudes, 60 KB y un solo dominio no tiene nada que pagar. Incluso con 400 ms de latencia, está en la pantalla en aproximadamente un segundo.

2.5 segundos: la línea que se separa de Open de rendirse

El punto de referencia de la industria es claro: el web.dev, en el núcleo web vitales, define que el contenido principal de una página debe aparecer en menos de 2,5 segundos a la experiencia se considera buena. Por encima de eso, la probabilidad de abandono crece cada segundo, y el tráfico de una biografía es casi todo móvil, el escenario donde las páginas pesadas son las que más sufren. Los datos públicos del archivo http Los datos públicos muestran la misma tendencia durante años: las páginas engordan más rápido que las redes.

En una buena red, todas las plataformas parecen rápidas, incluidas las pesadas. La diferencia aparece exactamente donde no estás mirando: en el celular de tu seguidor con una red débil. Nunca ves tu página lenta, porque la tienes en caché. Él siempre ve.

¿De dónde viene el peso?

Una lista de diez botones no necesita un megabyte de JavaScript. El peso no es tu contenido, es lo que agrega la plataforma:

• Seguimiento y publicidad Scripts, que sirven al modelo de negocio de la plataforma, no al suyo;
• Marcos de JavaScript que construyen la página del teléfono celular del visitante en lugar de entregarla lista;
• fuentes y widgets externos, cada uno con su propio dominio y peaje de la latencia.

Es por eso que la biografía de Kortilink usa rendering en el servidor: el servidor entrega el HTML ya construido y el teléfono solo necesita mostrarlo. No hay marco para arrancar, sin cientos de kilobytes de JavaScript para interpretar antes de que aparezca el primer botón. Observe la tabla anterior: de nuestros 60 KB, 36 son los HTML — su contenido, es su página. A 1,1 MB de Linktree, el HTML es de 35 KB y el resto es maquinaria.

Y no somos puros: nuestra página también trae cosas que no todos usan: los iconos de las redes sociales, los seis idiomas. La diferencia es que lo que es raro solo se buscará cuando sea necesario. Una biografía con historias pide dos archivos más, unos 11 KB; Uno con bloques poco usados, más 6 KB. En el peor de los casos, son 77 KB: todavía una cuarta parte de lo que se carga en todas y cada una de las páginas, y una quinceava de Linktree.

¿Qué puedes hacer ahora, en cualquier plataforma?

Seamos justos: parte del peso está en tus manos, sea cual sea la herramienta.

1. pruebas como ven tus seguidores. En Chrome, abre las DevTools, activa la limitación de red «4G lento» y carga tu biografía con caché desactivado. Es la verdadera experiencia de mucha de su audiencia.
2. comprimir las imágenes. Una foto de portada de 2 MB destruye cualquier optimización de plataforma.
3. Evite los widgets incorporados. Un jugador incrustado puede costar más pedidos que toda la página. Un botón que abre la aplicación nativa se convierte mejor y no pesa casi nada.
4. Bloques de corte. Menos bloques es menos peso y menos vacilación, dos ganancias por el precio de uno.

Y una nota honesta: velocidad no salva una bio mal construida. Una página instantánea con el enlace incorrecto en la parte superior la convierte mal. La velocidad decide cuántos llegan; La estructura decide cuántos clics. Para la segunda parte, consulte los siete errores que cuestan clics en un bio.

Porque insistimos en esto

Podríamos competir en varias funciones: es la carrera personalizada en esta categoría, y explicamos en nuestra comparación de alternativas a Linktree, quien lo maneja mejor que nosotros en cada frente. Elegimos competir en otra cosa: se abre tu página. Siempre. También en el celular con barra de red, también en el 4G del interior, también en la diáspora donde la conexión no siempre ayuda.

Porque cada visitante que se da por vencido en la pantalla en blanco era una corriente, una venta o un contacto que ya habías hecho, y que perdiste en el último metro del camino.

Preguntas frecuentes

¿Cómo mido la velocidad de mi página biológica?

Utiliza la página de Google Speed Insights o la pestaña Red de DevTools de Chrome con la limitación '4G lento' y la caché deshabilitada. Mire tres números: cuántos pedidos, cuántos KB transferidos y cuánto tiempo hasta que aparece el contenido principal. Se compara con la línea de 2,5 segundos.

¿Realmente llega 60 KB para una página con imágenes?

Los 60 kb es la página en sí: estructura, estilos, el código que lo hace funcionar y su contenido, medido en cuatro de nuestras páginas bio en serio, con resultados entre 60,5 y 61,9 KB. Sus imágenes se suman a eso, y es por eso que la compresión importa. La diferencia es el punto de partida: los que comienzan en 1.1 MB ya han gastado todo su presupuesto antes de llegar a su foto de perfil.

¿Cómo lo midiste y puedo repetirlo?

PUEDES. Descargamos el HTML de cada página, y luego todos los archivos de JavaScript y Style que nombra, agregando los bytes a medida que viajan comprimidos, sin estimaciones. No contamos las fotografías (cambiar de página a página) ni las solicitudes que hace cada plataforma después de de dibujo, como las estadísticas. Esta última decisión beneficia a la competencia, no a nosotros: sus números son mínimos, y lo real es mayor. Por su parte, los DevTools de Chrome en la pestaña Red, con 'Deshabilitar caché', le brindan el mismo tipo de lectura para cualquier página.

¿Vale la pena el trabajo de cambiar de plataforma debido a la velocidad?

Si sus análisis muestran muchas visitas y pocos clics, y su audiencia está en las redes móviles, probablemente lo haga, y el trabajo es más pequeño de lo que parece: nuestro importador lee su página de enlaces públicos o balizas y recrea los bloques sin pedir nada de su soporte. Más artículos sobre el tema en nuestro blog.