Un kilobyte de más cuesta 150 milisegundos

Solemos pensar el rendimiento de una página como una curva suave: cada byte que añades la hace un poco más lenta, en proporción. Es una idea cómoda y casi siempre equivocada. El tiempo de carga tiene escalones, y uno de ellos está en los primeros 14,6 kilobytes del documento.

Lo encontramos sin buscarlo, en nuestro propio sitio. Este artículo cuenta qué es ese escalón, cómo dimos con él, cómo comprobamos que la explicación era la correcta y cómo puedes medirlo en el tuyo.

Qué pasa cuando pides una página

Cuando el navegador pide un documento HTML, el servidor no lo manda todo de golpe. TCP, el protocolo que transporta la respuesta, arranca con cautela: envía unos diez segmentos —en torno a 14.600 bytes— y se detiene a esperar que el navegador confirme que los recibió. Solo entonces manda la siguiente tanda, más grande.

Ese primer lote se llama ventana de congestión inicial. Existe porque, al abrir una conexión, el servidor no sabe nada de la red que hay en medio. Si soltara el documento entero de una vez podría saturar un enlace lento y perder paquetes, así que empieza con poco y va creciendo a medida que comprueba que la red aguanta.

La consecuencia práctica es un corte brusco:

Documento de 13.745 bytes   →   cabe   →   1 viaje de ida y vuelta
Documento de 14.871 bytes   →   no cabe →   2 viajes

Si el documento cabe en la primera ventana, llega entero en un viaje de ida y vuelta. Si no cabe, aunque sea por pocos bytes, el resto espera a que vuelva la confirmación: un segundo viaje completo. En la red móvil simulada que usa Lighthouse, ese viaje cuesta 150 milisegundos. En una red real el coste depende de la latencia de cada conexión: es menor con fibra y cerca del servidor, y mayor en un celular con mala señal.

El valor de diez segmentos es el habitual, pero no es universal: depende de la configuración del servidor, y se puede cambiar. Mídelo, no lo supongas.

Cómo lo encontramos

No lo buscábamos. Estábamos añadiendo datos estructurados en JSON-LD a este sitio, que entonces tenía nueve páginas, y una de ellas —la ficha de uno de los casos— bajó de 97 a 96 en Lighthouse.

Un punto es ruido. Lighthouse varía de una pasada a otra, y una diferencia así no justifica investigar nada. Lo que no era ruido fue esto: el FCP y el LCP subieron exactamente 150 ms. No «unos 150». Exactamente.

Estos son los datos de esa página, medidos con 10 pasadas intercaladas entre los dos builds, para que ninguno se beneficiara de un momento más tranquilo de la máquina:

Esa exactitud es lo que convirtió una sospecha en una explicación. Un kilobyte de JSON no tarda 150 ms en procesarse. Un salto idéntico en dos métricas, y del tamaño justo de un viaje de red, apuntaba al transporte y no al contenido: el JSON-LD había empujado el documento al otro lado de la línea.

La prueba de verdad: predecir

Una explicación que solo explica lo que ya pasó vale poco: casi cualquier historia encaja con datos que ya conoces. La prueba es pedirle que prediga algo que todavía no ha ocurrido.

Dos días después construimos una página nueva. Antes de desplegarla estimamos cuánto pesaría comprimida y predijimos que quedaría por debajo del umbral, y por tanto con el FCP bajo.

Y el comportamiento observado, en mediciones independientes de las que originaron la hipótesis, fue el que la explicación anunciaba:

150 milisegundos otra vez.

De dónde salen estas cifras. Los tamaños se midieron contra producción con curl. Los dos FCP son de Lighthouse en local, sobre un build de producción: al medir el sitio ya desplegado la diferencia no sale tan limpia, porque la red real tiene variaciones que la simulada no. El umbral es real y el tamaño del documento también; lo que no sobrevive al salir del laboratorio es la exactitud del número. Medido el 19 de octubre de 2026.

Cómo medirlo en tu sitio

El tamaño que cuenta no es el del archivo en disco. Es el documento comprimido más las cabeceras, tal como lo sirve tu servidor de producción, porque eso es lo que viaja por la red y lo que tiene que caber en la primera ventana.

Con curl lo tienes en una línea:

curl -s -o /dev/null -w "%{size_download} %{size_header}\n" \
  -H "Accept-Encoding: br" \
  https://tu-sitio.com/una-pagina

El primer número es el cuerpo comprimido y el segundo, las cabeceras. Suma los dos y compáralo con 14.600.

Dos trampas

El gzip local no es el Brotli de tu CDN. Comprimen distinto, y el servidor que corres en tu máquina rara vez usa el mismo algoritmo ni el mismo nivel que producción. Nosotros calibramos la diferencia contra cuatro páginas reales y salió un factor de 1,06 a 1,07 sobre brotli -q 4. Ese factor es nuestro y depende de nuestro proveedor; calcula el tuyo antes de fiarte de una medición local.

En React Server Components todo cuenta casi dos veces. El contenido viaja en el HTML y otra vez en los datos que React necesita para hidratar la página, al final del mismo documento. Un bloque de 1.100 bytes pesa cerca de 2.200. Si trabajas con el App Router de Next.js, cada párrafo que añades lo pagas por partida doble.

Qué hacer con esto

La conclusión no es «haz páginas pequeñas». Es otra, y más útil:

Lo que importa no es cuánto añades, sino si cruzas la línea.

Añadir 3 KB a una página de 8.000 bytes no cuesta nada: sigue cabiendo en la primera ventana. Añadir 300 bytes a una de 14.500 cuesta un viaje entero.

Por eso conviene saber de qué lado está cada página antes de escribir en ella. Una página con margen admite contenido sin coste visible; una que está al borde necesita que cada añadido se mida. Y una página que ya está por encima del umbral no se encarece por crecer un poco más: el viaje extra ya lo estaba pagando. Ahí lo que pesa es el total, no la línea.

Una última aclaración, para no prometer lo que no es: esto mejora el tiempo de carga, no el posicionamiento en buscadores. Son cosas distintas, y conviene no confundirlas.