Un podcast reciente de Google llamó la atención sobre el hecho de que los sitios web son cada vez más grandes que nunca. Gary Illyes y Martin Splitt de Google explicaron que la idea de que los sitios web se están volviendo “más grandes” es algo malo no es necesariamente cierta. La conclusión para los editores y los SEO es que el peso de la página no es una métrica confiable porque la causa del “exceso” de peso bien podría ser algo útil.
El tamaño de la página depende de lo que se está midiendo
Martin Splitt de Google explicó que lo que mucha gente considera tamaño de página depende de lo que se mide.
- ¿Se mide solo por el HTML?
- ¿O estás hablando del tamaño total de la página, incluidas imágenes, CSS y JavaScript?
Es una distinción importante. Por ejemplo, muchos SEO se asustaron cuando escucharon que el robot de Google estaba limitando el rastreo de sus páginas a solo 2 megabytes de HTML por página. Para poner esto en perspectiva, dos megabytes de HTML equivalen a unos dos millones de caracteres (letras, números y símbolos). Eso es el equivalente a una página HTML con la misma cantidad de letras que dos libros de Harry Potter.
Pero cuando incluyes CSS, imágenes y JavaScript junto con HTML, ahora estamos teniendo una conversación diferente relacionada con la velocidad de la página para los usuarios, no para el rastreador del robot de Google.
Martin analizó un artículo sobre Web Almanac de HTTPArchive, que es un resumen de las tendencias de los sitios web. El artículo parecía estar mezclando diferentes tipos de peso de página, y eso lo hace confuso porque hay al menos dos versiones de peso de página.
Señaló:
“Mira, ahí es donde no tengo tan clara su definición de peso de página.
…tienen un párrafo en el que intentan explicar lo que quieren decir con peso de página. …No entiendo las diferencias en lo que son estas cosas. Entonces dicen que el peso de la página (también llamado tamaño de página) es el volumen total de datos medido en kilobytes o megabytes que un usuario debe descargar para ver una página específica. En mi libro eso incluye imágenes y todo eso porque tengo que descargarlo para verlo.
Y por eso me sorprendió escuchar que en 2015 eran 845 kilobytes. Eso para mí fue sorprendente. …Porque hubiera supuesto que con imágenes serían más de 800 kilobytes.
… En julio de 2025, la misma página mediana ahora tiene 2,3 megabytes”.
Los datos se comprimen
Pero esa es sólo una forma de entender el tamaño de la página. Otra forma de considerar el tamaño de la página es centrarse en lo que se transfiere a través de la red, que puede ser más pequeño debido a la compresión. La compresión es un algoritmo del lado del servidor que minimiza el tamaño del archivo que se envía desde el servidor y se descarga mediante el navegador. La mayoría de los servidores utilizan un algoritmo de compresión llamado Brotli.
Martín Splitt explica:
“Hago esta pregunta públicamente: diferentes personas tenían nociones muy diferentes sobre cómo entendían el tamaño de página. Dependiendo de la capa que estés mirando, también se vuelve confuso
porque también hay compresión.… Entonces algunas personas dicen, ah, pero este sitio web descarga 10 megabytes en mi disco.
Y yo digo, sí. …pero tal vez si observas lo que realmente pasa por el cable, podrías encontrar que son cinco o seis megabytes, no los 10 megabytes completos. Porque puedes comprimir cosas en el nivel de red y luego descomprimirlas en el nivel del lado del cliente…”
Técnicamente, el tamaño de la página en el ejemplo de Martin es en realidad de cinco o seis megabytes debido a la compresión y se puede descargar más rápido. Pero del lado del usuario, esos cinco o seis megabytes se descomprimen y vuelven a convertirse en diez megabytes, lo que ocupa esa misma cantidad de espacio en el teléfono, el escritorio o cualquier otro lugar del usuario.
Y eso introduce una ambigüedad. ¿Tu página web tiene diez megas o cinco megas?
Esto ilustra un problema más amplio: diferentes personas hablan de cosas diferentes cuando hablan del tamaño de página.
Incluso las definiciones más utilizadas no resuelven completamente la ambigüedad. El peso de la página se describe como “el volumen total de datos medido en kilobytes o megabytes que un usuario debe descargar”, pero como deja claro la discusión, no existe una definición clara.
Martín afirma:
“Cuando preguntas a la gente qué piensan, si esto es grande o no, empiezas a obtener respuestas muy diferentes dependiendo de cómo piensan sobre el tamaño de la página. Y no existe una definición única al respecto”.
¿Qué pasa con la relación entre el marcado y el contenido?
Una de las distinciones más interesantes que se hacen en el podcast es que una página grande no es necesariamente ineficiente. Por ejemplo, un documento HTML de 15 MB se considera aceptable porque “prácticamente la mayoría de estos 15 megabytes son en realidad contenido útil”. El tamaño refleja el valor que se entrega.
Por el contrario, ¿qué pasaría si la proporción entre contenido y marcas fuera al revés, donde hubiera un poco de contenido pero la abrumadora cantidad del peso de la página fuera marcas?
Martin analizó el ejemplo de la proporción:
“… ¿Qué pasa si el marcado es el único costo adicional? Y quiero decir, ¿qué quieres decir? Es como, bueno, ya sabes, si son como cinco megabytes pero es solo muy poco contenido, ¿es eso malo? Es peor, como en este caso, los 15 megabytes.
Y yo digo, eso es complicado porque entonces entramos en este extraño territorio de la relación entre contenido y marcado. Sí.
Y dije, bueno, pero ¿qué pasa si mucho de eso es marcado, es decir, metadatos para alguna herramienta de terceros o para algún servicio o por razones regulatorias o de licencia o lo que sea? Entonces ese es contenido útil, pero no necesariamente para el usuario final, pero aun así es necesario tenerlo.
Sería extraño decir que eso es peor que la página donde el peso es principalmente el contenido”.
Lo que Martin está haciendo aquí es cambiar la idea del peso de la página del tamaño sin formato hacia lo que realmente representan los datos.
Por qué las páginas incluyen datos que los usuarios nunca ven
Un factor importante que contribuye al peso de la página es el contenido que los usuarios nunca ven.
Gary Illyes señala los datos estructurados como un ejemplo de contenido destinado específicamente a máquinas y no a usuarios. Si bien puede resultar útil para los motores de búsqueda, también aumenta el tamaño general de la página. Si un editor agrega una gran cantidad de datos estructurados a su página para aprovechar todas las diferentes opciones disponibles, eso aumentará el tamaño de la página aunque el usuario nunca la vea.
Esto llama la atención sobre una realidad estructural de la web: las páginas no están diseñadas sólo para lectores humanos. También están diseñados para motores de búsqueda, herramientas, agentes de inteligencia artificial y otros sistemas, todos los cuales añaden sus propios requisitos al peso de una página web.
Cuando los gastos generales están justificados
No todo el contenido que no está dirigido al usuario es innecesario.
Martin habló de cómo el marcado puede incluir “metadatos” o una herramienta, un propósito regulatorio o de licencia, creando una especie de área gris. Incluso si los datos adicionales no mejoran la experiencia del usuario directamente, sí tienen un propósito, incluido ayudar al usuario a encontrar la página a través de un motor de búsqueda.
El punto al que se refería Martin es que estas consideraciones sobre el peso de la página complican los intentos de etiquetar el peso de la página como bueno si está por debajo de este umbral o como malo si el peso de la página lo excede.
Por qué no funciona separar contenido y metadatos
Una posible solución que discutió Gary Illyes es separar el contenido para humanos de los datos para máquinas. Si bien Gary no mencionó específicamente la propuesta LLMs.txt, lo que discutió se parece un poco a ella en el sentido de que entrega contenido a una máquina menos todos los demás gastos generales que conlleva el contenido orientado al usuario.
Lo que realmente discutió fue una manera de separar todos los datos de la máquina de lo que el usuario descargará, haciendo así, en teoría, que la versión del usuario de una página web sea más pequeña.
Gary rápidamente descarta esa idea como “utópica” porque siempre habrá hordas de spammers que encontrarán una manera de aprovechar eso.
Él explicó:
“Pero, lamentablemente, esto es algo utópico, porque no todo el mundo en Internet se comporta bien.
Sabemos con cuánto spam tenemos que lidiar. En nuestro blog decimos en alguna parte que detectamos como 40 mil millones de URL por día que son spam o algún número demencial, no lo recuerdo exactamente, pero es un número demencial y definitivamente miles de millones. Eso simplemente exacerbará la cantidad de spam que reciben los motores de búsqueda y otras máquinas, tal vez como si apostaría $1 y 5 centavos a que en realidad aumentará la cantidad de spam que ingieren los motores de búsqueda, los LLM y otros”.
Gary también dijo que la experiencia de Google es que, históricamente, cuando tienes distintos tipos de contenido, siempre habrá diferencias entre los dos tipos. Usó el ejemplo de cuando los sitios web tenían páginas móviles y de escritorio, donde las dos versiones de contenido eran generalmente diferentes, lo que a su vez causaba problemas de búsqueda y también de usabilidad cuando un sitio clasifica una página web por contenido en una versión de una página y luego envía al usuario a una versión diferente de la página donde ese contenido no existe.
Aunque no lo mencionó explícitamente, esa explicación de la experiencia de Google puede arrojar más luz sobre por qué Google no adoptará LLMS.txt.
Como resultado, los motores de búsqueda se han decidido en gran medida por un modelo de documento único, aunque sea ineficiente.
El tamaño del sitio web frente al tamaño de la página es el mundo real
En última instancia, la discusión desafía el concepto original del problema, que las páginas web pesadas son malas.
Gary observa:
“La primera pregunta es: ¿están engordando los sitios web? Creo que esta pregunta ni siquiera tiene sentido.
Porque en el contexto de un sitio web no importa si es gordo. En el contexto de una sola página, sí.
Pero en el contexto de un sitio web, realmente no importa”.
Así que ahora Gary y Martin cambian el enfoque hacia las páginas web que se están volviendo más pesadas, una manera más significativa de ver la cuestión de cómo las páginas web y los sitios web están evolucionando.
Esto hace que la discusión pase de una idea abstracta a algo más mensurable y viable.
Las páginas más pesadas aún conllevan costos reales
Incluso con conexiones más rápidas y una mejor infraestructura, las páginas más grandes todavía tienen consecuencias y las páginas más pequeñas tienen beneficios positivos.
Martín explica:
“Creo que estamos desperdiciando muchos recursos. Y quiero decir, tuvimos eso en otro episodio donde dijimos que sabemos que hay estudios que muestran que los sitios web que son más rápidos tienen una mejor retención y mejores tasas de conversión. Sí. Y la velocidad también se basa en parte en el tamaño. Porque cuantos más datos envío, más tiempo le toma a la red transferir esos datos y más tiempo le toma al procesador de cualquier dispositivo en el que esté procesarlos y mostrárselos”.
Desde una perspectiva más amplia, la cuestión no es sólo el rendimiento sino la eficiencia. Como dice Illyes, “estamos desperdiciando muchos recursos”.
Puede que la red se esté volviendo más pesada, pero lo más importante es el por qué. Las páginas contienen algo más que contenido para el usuario, y esa elección de diseño determina tanto su tamaño como su impacto.
Imagen destacada de Shutterstock/May_Chanikran
