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 del mayor de ellos hace once veces más solicitudes y transfiere dieciocho veces más bytes que el nuestro. Y la columna que más duele no es la del total: es de JavaScript, de cada diez bytes que el más grande envía al teléfono celular, unos seis son un programa, no es 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,017 MB de JavaScript, en 3 archivos;
• la más ligera de las otras: 0,03 MB;
• las dos más grandes: 1,1 MB y 2,2 MB — sesenta a ciento treinta veces el nuestro.

La descarga de 1 MB en una red decente lleva poco tiempo. Interpretar 2,2 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 ocho a dieciséis dominios de los más grandes son tantas resoluciones DNS y presentaciones TLS, varias de ida y vuelta 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 14 peticiones, 200 KB y tres dominios paga mucho menos de esto que una de 80 peticiones y 1,5 MB. Medido desde Portugal, la primera pintura de las nuestras queda entre 300 y 510 ms.

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 200 KB, 38 son HTML — su contenido, es su página. A 1,9 MB del segundo más grande, el HTML es una pequeña porción 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 fracción de lo que llevan los más grandes en cualquier página.

¿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 número de funciones: es la carrera de siempre en esta categoría, y siempre hay quien la corre mejor que nosotros en cada frente. Elegimos competir en otra cosa: tu página abre. Siempre. También en el móvil con una raya de cobertura, 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.

¿Entonces 200 KB no es tan poco?

No lo es, y conviene decirlo. De esos 200 KB, más de la mitad es el fondo del tema y el avatar: tu contenido, no nuestra maquinaria. El HTML de la página son 38 KB comprimidos, y el programa que la hace funcionar son 17. Una página nuestra sin fondo de tema queda cerca de los 100 KB. Quien elige un fondo pesado lo paga, y eso es verdad en cualquier plataforma.

¿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 la más ligera y recrea los bloques sin pedir nada de su soporte. Más artículos sobre el tema en nuestro blog.