Una página de 14 kB puede cargar mucho más rápido que una de 15 kB (2022)

• Mantener el tamaño de un sitio web por debajo de 14 kB puede reducir significativamente el tiempo de carga en comparación con 15 kB
• Este fenómeno se debe al algoritmo de slow start de TCP, y la diferencia de velocidad percibida aparece por el límite de datos en la primera transmisión
• 14 kB corresponde a la capacidad de 10 paquetes TCP que la mayoría de los servidores envían al inicio
• En entornos de alta latencia como internet satelital, un viaje de ida y vuelta adicional (RTT) puede causar una demora de 612 ms o más
• En la práctica, incluir el contenido principal en menos de 14 kB, o ubicar los recursos críticos dentro de los primeros 14 kB, es efectivo para optimizar el rendimiento web

---

Descripción general y principios clave

• Es bien sabido que mientras más pequeño sea un sitio web, más rápido cargará
• Pero el hecho de que al pasar de 14 kB a 15 kB se produzca una diferencia drástica en la velocidad de la primera respuesta no es algo intuitivo
• La diferencia de velocidad entre una página de 15 kB y una de 16 kB es mínima, pero entre 14 kB y 15 kB puede haber hasta 612 ms de diferencia

Qué es TCP

• Transmission Control Protocol (TCP) funciona sobre IP (Internet Protocol) y se encarga de garantizar la confiabilidad de los paquetes
• Al hacer una solicitud HTTP, el navegador web envía varios paquetes TCP
• Si solo se usara IP, no habría forma de confirmar si los paquetes llegaron, por lo que TCP proporciona la función de acuse de recibo de paquetes (ACK)
• El servidor envía primero una pequeña cantidad de paquetes y, cuando recibe el ACK del navegador, transmite paquetes adicionales
• Si no hay ACK, se ejecuta el procedimiento de retransmisión de paquetes

Qué es TCP slow start

• TCP slow start es un algoritmo mediante el cual el servidor aumenta gradualmente la cantidad de paquetes enviados para detectar la calidad de la conexión de red (ancho de banda)
• Al inicio de la conexión, el servidor envía solo una pequeña cantidad de paquetes (por lo general 10)
• Si la computadora del visitante envía correctamente el ACK, la cantidad de paquetes transmitidos se duplica
• Si se pierde un ACK, después de eso los paquetes se envían a una velocidad más lenta
• El algoritmo real puede variar en detalles según la implementación, pero el concepto es el mismo

Base del umbral de 14 kB

• La mayoría de los servidores envían 10 paquetes TCP de una sola vez durante slow start
• El tamaño máximo de un paquete TCP es de 1500 bytes, pero excluyendo el encabezado (40 bytes), quedan 1460 bytes de datos útiles
• Por lo tanto, 10 x 1460 = 14600 bytes (aprox. 14 kB) es el límite máximo de la primera transmisión
• Si el sitio web o los recursos críticos se mantienen por debajo de 14 kB (o varias decenas de kB de datos originales cuando hay compresión), pueden mostrarse sin retraso adicional de ida y vuelta al inicio

Cuánto retraso puede causar un solo viaje de ida y vuelta

Ejemplo de internet satelital

• Un ejemplo representativo de entorno de alta latencia es el usuario de internet satelital (plataformas petroleras, cruceros, etc.)
• Cuando se solicita la página principal desde un teléfono, el trayecto router → antena satelital → satélite en el espacio → estación terrestre → servidor requiere decenas a cientos de ms en cada tramo
• El viaje completo de ida y vuelta de la transmisión incluye dos trayectos espaciales de ida y vuelta, el movimiento por los segmentos de red y el procesamiento del servidor, lo que añade unos 612 ms de retraso
• Si se usa HTTPS, puede aumentar hasta 1836 ms por el handshake adicional

Latencia en redes terrestres

• En redes móviles como 2G y 3G también puede haber una latencia de 100~1000 ms
• En situaciones de congestión, sobrecarga del servidor, pérdida de paquetes y otros entornos, pueden producirse retrasos adicionales

Estrategias de optimización web aplicando la regla de 14 kB

• La clave es hacer que el sitio web o la página sea lo más pequeño posible
• Lo ideal es diseñar cada página para que su tamaño comprimido transmitido sea de 14 kB o menos
  • Con compresión, el contenido real puede llegar hasta ~50 kB
• Reduciendo la mayoría de los elementos innecesarios, como videos con reproducción automática, pop-ups, rastreadores y JS/CSS innecesarios, esto es perfectamente alcanzable
• Si es difícil implementar todo dentro de 14 kB, es importante priorizar los recursos críticos y el contenido principal (CSS, JS, texto principal, etc.) dentro de los primeros 14 kB
• Los encabezados HTTP (no comprimibles) y las imágenes (cargar solo lo mínimo necesario o la parte visible, o usar placeholders) también cuentan dentro de esos 14 kB

Excepciones a la regla de 14 kB y temas de protocolos modernos

• La regla de 14 kB no es una simplificación excesiva, pero sí tiene algunas excepciones
  • Algunos servidores amplían la ventana inicial a 30 paquetes
  • Mediante el handshake de TLS puede permitirse una ventana mayor
  • Se puede hacer caché de la cantidad de paquetes transmisibles por ruta para enviar más en conexiones posteriores
• Incluso en HTTP/2, la práctica de que el servidor comience con 10 paquetes por el slow start de TCP en general no cambia
• En HTTP/3 y QUIC, la regla de 14 kB también se recomienda oficialmente

Resumen y materiales de referencia

• Los fundamentos técnicos y materiales adicionales de explicación pueden consultarse en cada enlace
• Publicación original: 2022-08-25, última modificación: 2022-08-26, autor: Nathaniel, etiquetas relacionadas: rendimiento web, HTTP, TCP

Enlaces de referencia

• Estructura de tramas Ethernet y encabezados TCP, materiales adicionales sobre latencia y ancho de banda, especificaciones de TCP/QUIC, etc.

[GN⁺]

Opiniones de Hacker News

• Los desarrolladores de software necesitan prestar un poco más de atención a la capa de medios; en particular, fue impresionante lo que el autor señaló sobre la confiabilidad y la latencia de 3G/5G. En radio casi siempre hay retransmisiones, y en la mayoría de las comunicaciones HTTP los paquetes deben llegar en orden para que la UI se actualice. En la práctica, incluso una sola solicitud REST solo se procesa como un único paquete real cuando la solicitud y la respuesta son menores de 1400 bytes. Si supera eso, esa solicitud “única” en realidad se divide en varios paquetes. Si uno de ellos falla, la pantalla solo se actualiza correctamente cuando todos los paquetes llegan en orden. Si quieren experimentarlo, pueden activar el modo 3G y la pérdida de paquetes en las herramientas de desarrollo de Chrome y verán que incluso una optimización pequeña puede mejorar mucho la capacidad de respuesta de la UI. Por eso hay una razón convincente para mantener API y UI lo más pequeñas posible

• Mi página principal pesa 7.0kB transferidos con compresión

  • /
  • main.css
  • favicon.png
  • Total 7.0kB La lista del blog y todo el sitio están hechos con mi generador de sitios estáticos personalizado (público: site.lisp, hecho con Common Lisp). En las publicaciones de matemáticas uso KaTeX con renderizado del lado del cliente, y eso agrega otros 347.5kB
  • katex.min.css 23.6kB
  • katex.min.js 277.0kB
  • auto-render.min.js 3.7kB
  • KaTeX_Main-Regular.woff2 26.5kB
  • KaTeX_Main-Italic.woff2 16.7kB
  • Total adicional 347.5kB Algún día estoy pensando en cambiar KaTeX a renderizado del lado del servidor. Este blog es mi proyecto de pasión personal desde mis días en la residencia universitaria. Escribí todo yo mismo, desde el HTML y las plantillas hasta el CSS, y siempre lo estructuro con cuidado para incluir solo lo estrictamente necesario en cada página y así mantener el peso bajo
  • Mi página principal
  • Colección de publicaciones de matemáticas
    • No digo que no se deba usar un enfoque mejor, pero la latencia que produce el renderizado del lado del cliente cuando cargan componentes dinámicos como expresiones LaTeX es casi imposible de notar para un usuario normal. La sobreoptimización también es un problema. Toda esta búsqueda de rendimiento impulsada por SEO no da mucho beneficio en relación con el tiempo invertido, a menos que se trate de un servicio con millones de vistas. Es como preocuparse por la aerodinámica mientras diriges un bote no tripulado por el mar usando las mareas. Cuando los recursos son limitados, considerando costo y beneficio total, optimizar no siempre es la mejor opción
    • Si tienes poco contenido matemático y aun así quieres usar KaTeX, también podrías considerar en su lugar MathML(mathml-core) en la mayoría de los casos
    • No entiendo por qué habría que renderizar fórmulas matemáticas o expresiones LaTeX con js del cliente. Me pregunto por qué no convertirlas de antemano a HTML/CSS e incluirlas ya prerenderizadas
    • Otra idea sería cargar las librerías pesadas después del renderizado inicial de la página, o cargar los gráficos de las fórmulas como SVG solo cuando entren al viewport. Esa es mi opinión

• El objetivo de 14kB es algo desafiante, pero también es interesante la idea de limitarse a las primeras 10 paquetes iniciales. Existe un proyecto enfocado en el tamaño de los sitios web, como el mío, llamado 512kb.club. Es un lugar donde comparan el tamaño de los sitios como si fuera un puntaje de golf. Mi sitio(anderegg.ca) dio 71kB sumando todos los recursos antes de registrarlo. Gracias a este proyecto también conocí Cloudflare Radar, que tiene una buena herramienta para analizar sitios y medir el tamaño de las páginas. Su objetivo principal es ser un dashboard de todo internet, pero también incluye una herramienta de análisis de tamaño de página

  • Quiero preguntar desde la perspectiva del usuario: ¿para qué se usan los 500kB restantes? Yo solo necesito 90% texto, y para el resto basta con gráficos vectoriales. Incluso con 14 kB cabe bastante texto y gráficos, así que ¿en qué se usan los otros 500?
  • 512kb es una referencia realista. Yo también aplico ese criterio a mi sitio web. Un sitio al nivel de 14kb ya está más allá del estándar de la web
  • Para un sitio personal, 512kb es totalmente alcanzable. Mi próximo objetivo es 99kb (menos de 100kb). Con dedicarle unos cuantos fines de semana basta. Mi sitio está en categoría Orange dentro de 512kb

• Si quieren experimentar con esto de forma más divertida, el tamaño de la ventana inicial (IW) se puede configurar del lado del servidor. Por ejemplo, se puede ajustar así

  • ip route change default via <gw> dev <if> initcwnd 20 initrwnd 20 Si buscan, verán que ahora hay casos donde los CDN dan una ventana inicial de hasta 30 paquetes (45kb)
  • Hace 13 años, incluso 10 paquetes se consideraban “hacer trampa”. Para más contexto, vean esto y el blog de Ben Strong (archivo)
  • Me pregunto si hay alguna fuente que respalde eso de que el CDN tiene una ventana inicial de 30 paquetes
  • También podrías simplemente configurarlo en 1000 paquetes como un “mal ciudadano”... aunque la desventaja es que a alguien con dial-up o una conexión con bufferbloat podría convertirse en un cuello de botella

• También aplica lo explicado en este artículo: Blog de Cloudflare - El fenómeno por el cual los ISP rusos solo permiten hasta 16KB y eso vuelve imposible la mayoría de la navegación web. Según el análisis de Cloudflare, los ISP rusos están limitando la velocidad del internet de sus usuarios locales para que solo carguen los primeros 16KB por recurso web

• La intersección entre la gente que no sabe qué es TCP Slow Start y la gente a la que le importa tanto la latencia de carga de un sitio web como para afinarla al máximo es muy pequeña. Las startups deberían concentrarse primero en ser startups, y solo las grandes empresas tienen margen para obsesionarse con este tipo de optimizaciones

  • Si lo abordas con la idea de “estoy concentrado en lo importante, así que no tengo tiempo para preocuparme por la optimización de rendimiento”, entonces nunca te vas a preocupar por ello. Por eso hoy la mayoría de las apps y sitios son lentos y mediocres
  • Si eso fuera cierto, entonces el software de lugares como Microsoft siempre debería funcionar de la mejor manera posible y con máxima eficiencia
  • Conceptualmente suena correcto. Pero si Evan Wallace de Figma no se hubiera obsesionado con el rendimiento, Figma no sería lo que es hoy. A veces el “rendimiento” en sí mismo se convierte en una funcionalidad principal del producto
  • Esto no tiene por qué ser una elección; también se puede hacer que venga por defecto. Yo usé datastar tanto para la demo de mil millones de celdas como para la de checkboxes, y apenas pasa un poco de 10kb. En redes móviles y 3G la diferencia es grande. En mis pruebas, pasar de 14kb agregaba 3 segundos en conexiones de baja calidad. Gracias a que el mantenedor de datastar se preocupó incluso por TCP slow start, yo terminé beneficiándome sin tener que esforzarme
    • checkboxes.andersmurphy.com
  • No creo que el tamaño de una empresa tenga mucha relación con la optimización de rendimiento. De hecho, muchas veces las empresas grandes son más lentas

• ¡Mi página principal pesa 17.2KB! (sin contar dependencias). De verdad me esforcé mucho optimizando mi página personal y hasta logré un puntaje perfecto de 100 en Lighthouse. Antes pensaba que era imposible, pero lo conseguí. Por cierto, está hecha con Rails. Este tipo de optimización sí vale la pena en la práctica. La experiencia de una página que aparece como un rayo, sin sentirse torpe ni poco responsiva, es muy satisfactoria por sí misma

  • Cuando experimentas que news.ycombinator.com carga al instante, se siente tan agradable a nivel psicológico que terminas abriéndolo automáticamente en cada descanso
  • Optimicé muchísimo el código de plantilla para miles de sitios y logré 100/100/100/100 en Lighthouse. También 100 perfecto en móvil. La carga inicial es bastante mayor que 17.2kB, ronda los 120kB, pero el truco fue eliminar todas las solicitudes HTTP innecesarias, ejecutar JS solo en la zona "above-the-fold", y dejar todo lo demás para lazy eval, defer y otras formas de carga diferida tanto como fuera posible. JS/CSS van inline, e incluso los widgets de terceros usan un enfoque de “fachada”, como un ícono emergente, para posponer la solicitud real. También ayudó bastante el backend SSR. Incluso con un video de fondo de Vimeo seguía sacando 100, pero con Youtube era imposible. La forma de obtener una puntuación perfecta fue reinterpretar los resultados de Lighthouse y reescribir por completo la base de código. Gracias a eso desaparecieron por completo las quejas de clientes sobre velocidad, y se volvió una gran ventaja competitiva tanto en SEO como en la puntuación real
  • Rails no tiene relación directa con la optimización del renderizado. Felicidades por la puntuación perfecta en Lighthouse

• Creo que el artículo tiene dos debilidades lógicas

  1. Hay una fórmula que dice que en comunicación satelital tarda unos 1600ms en enviar un paquete, pero como fundamento de la regla de 14kb es débil. No compara con sitios web grandes, así que no demuestra que 10 paquetes ≠ 16 segundos
  2. Dice que las imágenes de una página web también se incluyen en la regla de 14kb, pero ¿con qué frecuencia las imágenes van inline en la carga inicial? En la práctica es un caso excepcional muy raro, así que debería dejar más claro que no aplica al 99.9% de los casos - “<i>¿Casos donde las imágenes van inline?</i>” Por ejemplo, existe la técnica de mostrar miniaturas de baja resolución solo en la pantalla inicial, aplicarles un blur por CSS y luego hacer fade in de la imagen real de forma asíncrona. Si se hace bien, solo consume entre 1 y 200 bytes extra. Yo la uso en mi blog, y plataformas como Wordpress y Medium también la adoptan bastante. Es un truco usado sobre todo para hiperoptimización de frontend comercial - Tampoco estoy de acuerdo con asumir que la mayoría de los usuarios usan conexiones satelitales de baja latencia, y que mi página en particular sería la única incapaz de soportar la realidad actual en la que casi todos los sitios pesan varios MB

• La generación actual tiende a hacer incluso sitios web estáticos simples con frameworks como Next.js. Da un poco de pena pensar que la era de HTML+CSS+js ya se está yendo

  • De acuerdo. Yo también he hecho sitios de recursos mínimos, optimización manual de JavaScript y sitios con la regla de 14kb, pero este enfoque termina imponiendo restricciones de diseño y arquitectura. Cuando aumentan las funciones, todas esas decisiones de “minimización” se convierten en deuda técnica. Muchos idealizan la “web pura sin frameworks”, hasta que en algún momento descubren que puede ser todavía más sufrida. En cambio, si usas un framework JS isomórfico, puedes empezar con una página estática, optimizarla razonablemente y luego pasar a un thick client JS si hace falta
  • De hecho, la tendencia ya se está moviendo de vuelta. La mayoría de los frameworks actuales ya soportan muy bien sitios estáticos. Astro, por ejemplo, nació precisamente para sitios estáticos
  • Apenas te estás dando cuenta, pero en realidad esto ha sido así desde antes del auge de popularidad de jQuery, antes de 2010
  • Next.js optimiza el código empaquetado de forma muy agresiva, así que es ideal para lanzar lambdas o servidores pequeños. Incluso los sitios estáticos hechos con Next generan bundles muy pequeños

• Además de la latencia, minimizar el consumo de recursos es una condición esencial para un futuro sostenible. El impacto de la red sobre el medio ambiente tampoco es nada pequeño. Da pena que el tono de los comentarios suene burlón. Esta optimización no es la solución definitiva de una era, pero me habría gustado que se enfatizara más el efecto de reducir el consumo energético

  • La mayor parte del tráfico de internet es streaming de video. Optimizar unos cuantos megas en páginas web ni se nota. Vale la pena discutir la eficiencia en sí, pero intentar optimizarlo todo puede terminar consumiendo recursos que deberían ir a áreas donde la optimización sí hace más falta
  • Ni siquiera es fruta al alcance de la mano. Mientras optimizas para ahorrar 1 o 2mWh por página, una sola consulta a un motor de búsqueda usa 100 veces más, y una sola interacción con un chatbot 10 mil veces más. Caching y lazy loading ya están mitigando una parte considerable de esto
  • Preocuparse por reducir el tamaño de una página es casi una pérdida de tiempo. Incluso si multiplicas por 10, por seguridad, la electricidad anual usada en navegar por la web, sigue siendo muchísimo menor que la energía necesaria para hacer una sola hamburguesa. De hecho, si un desarrollador en vez de optimizar durante una semana se comiera una ensalada una vez, el impacto ambiental sería mayor
  • Totalmente de acuerdo. Una vez fui a la BBC y me sorprendió ver que un solo artículo de texto pequeño guardaba 120MB en caché. Eso fomenta una cultura de desperdicio y consumo de energía innecesarios. Yo también hago mi sitio lo más minimalista posible y subo videos a YouTube en 1080P en vez de 4K. 4K y 8K ni siquiera deberían existir. La gente suele hablar de agregar unos cuantos MW de solar, pero en realidad habría que imaginar lo bueno que sería “producir menos”. Extraño la escala pequeña de la web en la era del módem de 56K; en algún punto hubo un equilibrio intermedio, pero ya lo sobrepasamos por mucho
  • La gente solo empieza a prestar atención cuando el impacto les pega directamente. Yo también considero el tema ambiental. Algunos responden que la IA es peor, pero en realidad la IA también rastrea estas páginas pesadas. Y el criterio de 14kb sigue siendo menos del 1% del payload promedio de una página móvil