En este momento estás viendo Cómo medir la velocidad de tu página web ¿Eres un Dacia o un Ferrari?

Cómo medir la velocidad de tu página web ¿Eres un Dacia o un Ferrari?

El presente artículo es el segundo de la serie de contenidos sobre velocidad web, para leer el primero donde detallamos la importancia mayúscula de la optimización de la velocidad web para cualquier negocio digital, puedes hacerlo en el enlace que dejo aquí:

Como ocurre con cualquier sistema "complejo", una parte importante del proceso de optimización requiere en primer lugar una comprensión detallada del sistema y de sus partes, capa por capa.

Por hacer una analogía, como si fuera un cuerpo humano o un vehículo, un sistema complejo donde todos los órganos o partes del mismo interaccionan entre ellos, en este artículo vamos a intentar desmenuzar los principales factores que afectan a la velocidad de carga de tú página web, cómo medirlo para realizar un diagnóstico adecuado y llegar a una solución personalizada, porque aunque es frecuente observar muchos consejos "genéricos" por Internet, la realidad es que no existe una única hoja de ruta que vaya a ser útil para todos los casos.

Radiografía de una página web moderna 

Hoy en día, el aspecto visual de la mayoría de las páginas web suele estar más cuidado, gracias en gran parte a la mayor accesibilidad y variedad de herramientas que facilitan el diseño web.

Dejando de lado las subjetividades propias del diseño —y sin restar importancia a la apariencia de una web —, vamos a hacer un análisis o radiografía de una página web moderna en 2025.

Los datos reportados recogidos del último raspado (junio de 2024), disponibles para consulta mediante BigQuery en las tablas httparchive.all.* incluyen un conjunto de datos de 16,935,953 sitios web.

Filtremos y veamos aquellos que tienen cierta relación con el tema que estamos tratando:

  • Peso de la página: El peso de una página web en 2024 es de 2,652 KB en escritorio y 2,311 KB en móvil.
  • JavaScript: JavaScript contribuye significativamente al peso total de la página: 613 KB en escritorio y 558 KB en móvil.
  • Imágenes: Las imágenes son uno de los componentes que más contribuyen al peso de la página, la mediana para la home en versión escritorio es de 1,054 KB y en versión móvil 900 KB.
  • CSS: La mediana para el CSS es de 76 KB.
  • HTML: La mediana es de 33 KB en versión escritorio y 32 KB en versión móvil.
  • Fuentes: La mediana del peso de las fuentes por página es de 131 KB en escritorio y 111 KB en móvil.
  • Total de request: 71 solicitudes en versión escritorio y 66 en versión móvil.
  • Tecnologías más usadas: React y Vue.js destacan entre los Frameworks más populares. En cuanto a CMS, WordPress domina con más del 35% de adopción seguido por Shopify, Wix, Joomla, Squarespace y Drupal.
  • Web performance: El porcentaje de sitios web que cumplen con los estándares de rendimiento bajo el Core Web Vitals (más adelante hablaremos un poco más de esto aunque merece un artículo específico) es del 68% en versión escritorio y del 51% en versión móvil.

Si representamos estos datos de forma gráfica (percentil 50) observamos que lo que más contribuye al peso web son las imágenes, aunque es para tener en cuenta que el valor se dispara considerablemente si nos fijamos en el percentil 75, se puede consultar aquí.

radiografia web

Peso web 2,652 KB (percentil 50) y repartición entre sus componentes

Si lo comparamos con el tamaño promedio de una página web en versión escritorio en 2015 observaremos un aumento de 1.4 MB, es decir, un 120%, lo que refleja una clara tendencia.

En cambio, en versión móvil el incremento ha sido aún más dramático, un 357% o 1.8 MB durante el mismo período.

La evolución hacia una mayor complejidad de las páginas web tanto en versión escritorio como en versión móvil subraya la necesidad de dedicar más esfuerzo a las tareas de optimización web de forma más agresiva con el fin de mejorar la velocidad web, la experiencia de usuario y los resultados de los negocios.

Cómo carga tu página web: Ancho de banda y Latencia

Cuando la temática es la velocidad web es importante y fundamental hablar de latencia.

Digamos que puede ser el enemigo invisible.

La latencia puede ser el cuello de botella en muchos casos.

Hace ya más de una década, Mike Belshe, co-inventor del protocolo SPDY que posteriormente se convirtió en la base del protocolo HTTP 2.0, publicó los resultados de su análisis cuantitativo sobre el impacto que tenía la variación de la banda ancha frente a la latencia en la velocidad de carga de las páginas web.

ancho de banda y latencia

En la primera imagen superior, la latencia se mantiene fija y como podemos observar, pasar de un ancho de banda de 1 Mbps a 2 Mbps tiene un efecto notable sobre el tiempo de carga ya que disminuye casi hasta la mitad, sin embargo, cada incremento adicional en el ancho de banda produce mejorías decrecientes, hasta el punto de que casi no se puede apreciar diferencia.

En cambio, en la imagen inferior del gráfico podemos observar una relación lineal, cada mejora en la latencia produce resultados significativos en los tiempos de carga: incluso una diferencia de 20 milisegundos en la latencia es relevante.

La inmensa mayoría de la población Española tiene anchos de banda superiores a los reflejados en el gráfico superior de la imagen, por lo que no es un factor especialmente relevante a la hora de cargar una página web.

rango velocidad banda ancha españa

Low level Layers: ¿Qué es la latencia?

La latencia es, de forma resumida, el tiempo que tarda un mensaje o un paquete de datos en viajar desde su punto de origen a su destino.

En términos de optimización de velocidad web la latencia es importante porque una latencia alta implicará más delay.

Cada sistema contiene múltiples "sources" o componentes que contribuyen al tiempo total que tarda en entregarse un mensaje o un paquete de datos, por lo que influyen directamente sobre el rendimiento, veamos:

  • Delay de cola (queuing): El tiempo de espera hasta que un paquete entrante se trasmite.
  • Delay de procesamiento: Tiempo requerido para analizar la cabeza de un paquete, verificar errores a nivel de bits y determinar el destino (por ejemplo una decisión de enrutamiento).
  • Delay de transmisión: Tiempo requerido para entregar todos los bits de un paquete. Si N= número de bits, S= tamaño de paquete y d= retraso de transmisión d=S/N, para trasmitir 1024 bits a 100Mbps 1024/1x10e8 = 10.24 microsegundos.
  • Delay de propagación: Tiempo requerido para se propague un bit que ha sido entregado al medio de transmisión. En fibra óptica el índice de refracción efectivo es de 1.45, por lo que viaja aproximadamente a 200.000 - 210.000km/s, el delay de propagación (DP) es DP= d(distanica)/s(velocidad de propagación). 

Enter your text here...

El delay de propagación se ve influido por la distancia y el medio a través del cuál viaja la señal.

El delay de transmisión se ve más influido por la tasa de datos disponible y la distancia entre el cliente y el servidor es un aspecto menos relevante.

Una vez el paquete llega al destino (enrutador) este debe examinar el encabezado para determinar la ruta de salida, algo que también consume algo más de tiempo y es dependiente de varios factores como el número de entradas en la tabla de enrutamiento, implementación de estructuras, la velocidad de procesamiento del Hardware...

En definitiva, cada mensaje o paquete que viaja a través de la red pasará por múltiples componentes donde estos factores entrarán en juego: cuantos más enrutadores intermedios, mayor sea la carga de tráfico en el sistema y la distancia entre el origen y el destino, mayor será la latencia.

High Level Layers: ¿Qué es la latencia?

Enter your text here...

Hasta ahora hemos visto los Low Level Layers, que se encargan de la transmisión física de datos y el enrutamiento a través de la red.

Ahora, veamos los High level Layers, donde entran en juego otra serie de protocolos y procesos que gestionan la interacción entre el servidor, el cliente y el mensaje o paquete de datos.

Los navegadores de red modernos no son meros Sockets de red, debido a que la velocidad web es un aspecto tan fundamental y los navegadores juegan un papel en el proceso, cada día se están volviendo más sofisticados: pre-resuelven búsquedas de DNS, pre-conectan a sitios de destino probables y pre-cargan y priorizan recursos relevantes de la página web, entre otros.

Todas estas optimizaciones son automáticas y mejoran sustancialmente la latencia pero entender el funcionamiento más profundo nos ayudará a saber por qué tomaremos según que decisiones:

  • Pre-carga de recursos: Los navegadores pueden obtener recursos críticos para acelerar el renderizado de la página.    
  • Pre-resolución de DNS: Los nombres de host probables se resuelven por adelantado para evitar la latencia de DNS en una solicitud HTTP futura.
  • Pre-conexión TCP: Después de la resolución DNS, el navegador puede abrir especulativamente la conexión TCP en anticipación de una solicitud HTTP.
  • Pre-rendering de la página: Algunos navegadores pueden pre-renderizar toda la página en una pestaña secreta, de modo que será reemplazada de forma instantánea cuando inicies la navegación.

Aunque estos aspectos a menudo suelen ser más desconocidos e ignorados, no olvidemos que son críticos para la experiencia de usuario y pueden añadir decenas o cientos de milisegundos, por lo que sí es relevante si buscamos tener un alto grado de comprensión y optimizar al máximo la velocidad de nuestra página web.

Descarga de Recursos: Mostrando tu web

Hasta ahora hemos visto procesos que de forma general se suelen obviar más y que incluso algunos profesionales suelen desconocer.

Todavía falta que la página web se muestre en tu navegador

Cuando un usuario abre el navegador y escribe en la barra de navegación una dirección, el navegador necesitará en primer lugar obtener la dirección IP asociada al nombre de dominio utilizando el sistema DNS.

El DNS es a una página web casi como un DNI a un humano.

El navegador examinará diferentes cachés para encontrar el registro DNS (desde la caché, consulta DNS...) y cuando haya encontrado la dirección IP del dominio, enviará una solicitud HTTP, HTTPS o HTTP2 al servidor de la página web.

Como podemos observar en la siguiente imagen, el host responde devolviendo el HTML solicitado.

petición y respuesta HTTP

HTML parsing

El navegador recibirá el código HTML desde el servidor y será analizado y procesado para determinar cómo se debe presentar al visitante.

Durante el parsing del HTML el navegador romperá el HTML en varios componentes como los tags individuales, los atributos dentro de los tags y también el contenido de texto.

Una vez el HTML ha sido cargado y analizado, el navegador disparará el DOMContentLoaded (DCL), que es un evento que mide el tiempo que transcurre desde la conexión inicial hasta que se dispara el evento.

DomContentLoad

El parsing genera el Modelo de Objetos del Documento (DOM), una estructura jerárquica que representa el código HTML de una página web.

Es decir, el DOM representa un documento con un árbol lógico, cada rama termina en un nodo y cada nodo tiene objetos.

Un elemento puede ser una tag HTML específica, como por ejemplo <h1> (encabezado) o <p> (párrafo) y el nodo es un concepto más "general" que representa varios componentes del HTML, incluyendo todos los elementos, comentarios e incluso espacio en blanco.

El DOM será combinado con su primo para crear el árbol de renderizado (render tree), en este punto el navegador tendrá suficiente información para poder calcular la disposición de los elementos (realizar el layout) y mostrar luego algo en la pantalla.

representación gráfica DOM

CSSOM

Durante el parsing del HTML el navegador encontrará código CSS, que hace referencia a Hojas de Estilo en Cascada, de las siglas Cascading Style Sheets, que es el lenguaje que proporcionara las instrucciones necesarias para que el navegador sepa cómo se debe mostrar visualmente la página.

De forma frecuente, el CSS se añade haciendo referencia a una hoja de estilo externa mediante la etiqueta <link> en la sección <head> referenciando el archivo css, por ejemplo:

<link rel="stylesheet" href="miestilo.css" />

Al igual que ocurre con la generación del DOM, una vez el navegador encuentre la referencia al CSS, hará una petición y obtendrá una respuesta para poder descargarlo.

El CSSOM se construirá convirtiendo en primer lugar los bytes CSS a caracteres, sucesivamente los caracteres en tokens y, por último, los tokens en nodos.

Los nodos están vinculados a una estructura en forma de árbol que contiene atributos de estilo, que se llama CSSOM y que anulan automáticamente los estilos predeterminados del navegador, conocidos como estilos de agente de usuario.

render tree

Pipeline de procesamiento por parte del navegador: HTML, CSS y JS combinando el DOM y el CSSOM generando el árbol de renderizado

Enter your text here...

JavaScript

Durante el parsing del HTML, el navegador también encontrará JavaScript en el código HTML y por defecto es cargado de forma síncrona. 

Esto quiere decir que cuando el navegador detecta código JavaScript durante el parsing, se pausará el análisis del HTML para descargar el archivo JavaScript, procesar y ejecutar el código.

El navegador detiene el parsing del HTML para ejecutar el código JavaScript porque este puede manipular el DOM: puede añadir o quitar elementos HTML, modificar los existentes o actualizar texto dentro de ellos, por lo que si el navegador esperase a finalizar el parsing del HTML antes de ejecutar el código JavaScript, acabaría modificándolo múltiples veces para tener en cuenta dichos cambios en el DOM.

Algunas partes del código de JavaScript no manipula el DOM, lo que puede resultar en incremento en el tiempo de carga.

Optimizar este punto puede requerir de diferir archivos con el atributo defer o cargar el código JavaScript asincrónicamente con el atributo async.

Layout

Como hemos visto en el gráfico de la imagen que adjunte un poco más arriba, cuando el árbol de renderizado está listo, el siguiente paso es el layout.

El Layout es totalmente dependiente del tamaño de la pantalla y determina cómo y donde se posicionan los elementos en la página web, el width y el height de cada uno de ellos y cómo se ubican entre ellos.

El rendimiento del Layout, evidentemente, se ve impactado por los pasos anteriores como por ejemplo el DOM, cuanto mayor sea el número de nodos, más tiempo puede llevar el proceso.

Print

El último paso, una vez el árbol de renderizado haya sido creado y ya se haya procesado el layout, es "pintar" los píxeles en la pantalla.

Este proceso es relativamente rápido y no es un área en el que debamos de finarnos demasiado con el fin de optimizar o mejorar el rendimiento de nuestra página web, los estilos que se aplican a cada nodo pueden impactar el tiempo que tarda en mostrarse los píxeles en pantalla, pero no de forma dramática.

Web Core Vitals

Las Web Core Vitals van a ir evolucionando con el paso del tiempo.

El conjunto actual se centra en tres aspectos principales de la experiencia de usuario: carga, interactividad y estabilidad visual.

¿Qué son los Web  Core Vitals?

Las Web Core Vitals o métricas web esenciales son un conjunto de métricas web propuestas por Google a principios de 2020.

Todos los propietarios de los sitios web deben medirlas, ya que cada una de las métricas incluidas representa según Google una faceta distintiva de la experiencia de usuario.

Procesamiento de imagen con contenido más grande (LCP)

larges content painful

El procesamiento de imagen con contenido más grande (LCP) mide el rendimiento de carga web.

De forma resumida, mide el tiempo en que el elemento de contenido más grande de la página web se pinta en la primera ventana de visualización del visitante.

El LCP debe ocurrir en un plazo de 2,5 segundos desde el momento en el que la web empieza a cargarse, sino será catalogado como "needs improvement" o "poor".

Interaction to next Paint (INP)

interaction to next paint

El Interaction to Next Paint (INP) es una métrica que evalúa la capacidad de respuesta general de una página ante las interacciones del usuario mediante la observación de la latencia.

El valor final de la INP es la más larga que se ha observado y se considera que la interactividad es buena si la página web tiene un INP de 200 milisegundos o menos.

Cambio de diseño acumulado (CLS)

cumulative layout shift

El Cumulative Layour Shift (CLS) mide el aumento de actividad más grande en las puntuaciones de cambio de diseño para cada cambio de diseño no esperado que ocurre durante todo el ciclo de carga de la página web.

Se considera según Google que la experiencia de usuario es buena cuando el CLS del sitio web obtiene una puntuación de 0.1 o menos.

Herramientas de medición

Enter your text here...

PageSpeed Insights

Una de las opciones que tenemos para medir la velocidad web de nuestra página web es utilizando el conocido PageSpeed Insights (https://pagespeed.web.dev/).

PageSpeed Insights (PSI) genera un informe sobre la experiencia de usuario de nuestra página web en dispositivos de escritorio y móvil y nos ofrece sugerencias para optimizarla.

Los datos de la experiencia real en PSI están basados en el conjunto de datos del Informe sobre la experiencia de usuario de Chrome (CrUX) en los últimos 28 días, aunque también ofrece datos de laboratorio.

PSI calcula la calidad de la experiencia de usuario de una página web en tres categorías particionadas en un score que va de 0 a 100:

  • Buena: Puntuación igual a 90 o superior, indica que el resultado es "excelente". 
  • Necesita mejorar: Puntuación 50 - 89, se necesita hacer algunas mejoras.
  • Deficiente: Puntuación igual a 49 o inferior, básicamente estás en la mierda (es bromita, pero la cosa está chunga).

Esta puntuación, de forma algo "infantil" (aunque realmente es muy visual y fácilmente comprensible) se mostrará en una escala de colores tipo semáforo (verde, naranja y rojo) y aquí radica uno de sus principales problemas y beneficios en mi opinión: es simple y, por lo tanto, puede ser engañoso, ya que estará pensando por ti y en su cálculo de rendimiento decidirá qué es importante y cuánto lo es por ti.

Esta puntuación es un composite (esto también ocurre con otras herramientas de uso general como el Nutriscore en los alimentos) de diferentes componentes que influyen en la "nota" global y su posterior categorización con todas las limitaciones que eso implica, aunque los componentes están alineados con Web Core Vitals.

Dado que el objetivo principal del artículo no es realizar un análisis detallado de estas cuestiones, si la gente tiene interés en los comentarios, haremos un artículo específico sobre ello.

calculadora composite pagespeed insights

De todas formas, en la imagen de arriba podemos observar los componentes aislados y el weighting de cada uno de ellos que conforman el composite de PSI (PageSpeed Insights).

Recordemos que PSI utiliza el motor de LightHouse para la puntuación de rendimiento, puedes echar un vistazo a los componentes haciendo clic en este enlace (es una calculadora) y ver como interaccionan con el resultado final según los vas modificando.

WebPageTest

Otra de las opciones que hay disponibles para medir la velocidad web de nuestra página web es utilizar https://www.webpagetest.org/.

En comparación a PageSpeed Insights y GTmetrix que la detallaremos brevemente después, Webpagetest ofrece un análisis técnico mucho más profundo y detallado del proceso de carga de nuestra página web, por lo que es mucho más apropiado para realizar un diagnóstico exhaustivo.

Las opciones de configuración son amplias.

Los resultados principales de una ejecución estándar comienzan en un resumen del performance respondiendo tres preguntas:

  • ¿Es la página web rápida?
  • ¿Es la página web usable?
  • ¿Es la página web resiliente?

Debajo del Performance Summary encontraremos otras métricas de interés (high level metrics) de nuestra página web que nos aportará mucha más información.

webpagetest métricas web

Más abajo podremos acceder al Waterfall o un gráfico de cascada que es un diagrama que representa los datos que se van generando de forma acumulativa y secuencial en el proceso de carga de la página web, donde podremos observar todos los detalles de forma minuciosa.

gráfico de cascada waterfall view

Enter your text here...

Gráfico de cascada de Amazon

GTmetrix

La última opción que destacaré como disponible en este artículo para medir la velocidad de nuestra página web (aunque hay más, evidentemente) es GTmetrix, que también es una de las más conocidas.

El sistema de puntuación de GTmetrix se basa libremente en el sistema de puntuación de Lightouse, aunque con algunas modificaciones.

En la imagen inferior podemos observar el GTmetrix "Grade" para Amazon y los resultados de Performance y Structure.

velocidad web GTmetrix

La clasificación de grado va desde la letra A hasta la F:

  • Grado A: Se obtiene una clasificación A si el grado porcentual es igual a 90 o superior.
  • Grado B: Se obtiene una clasificación B si el grado porcentual es de 80 a 89%.
  • Grado C: Se obtiene una clasificación C si el grado porcentual es de 70 a 79%.
  • Grado D: Se obtiene una clasificación D si el grado porcentual es de 60 a 69%.
  • Grado E: Se obtiene una clasificación E si el grado porcentual es de 50 a 59%.
  • Grado F: Por último, se obtiene una clasificación F si el grado es igual a 49% o inferior.

En definitiva, algunas de las opciones que tenemos disponibles para medir la velocidad de nuestra página web son PageSpeed Insights, WebPageTest y GTmetrix y tendremos que utilizar una u otra dependiendo de nuestras necesidades y de lo que busquemos.

Cada una nos ofrece una serie de desventajas e inconvenientes, aunque en general en lo personal siempre suelo decantarme por WebPageTest y PSI, como he dicho anteriormente la finalidad de este este artículo no es realizar ninguna "comparativa", simplemente ofrecer información sobre algunas de las opciones más conocidas.

Deja una respuesta