Core Web Vitals: Las Métricas de Optimización Web

29 Noviembre, 2021 - 13 minutos de lectura

Cuándo empezamos a desarrollar un sitio web, muchas veces no tomamos en cuenta cuánto tiempo va a tardar en cargar. Desde hace muchos años medir el rendimiento y optimización fue muy complicado normalmente se media por tiempo de carga, es decir, si un sitio web dura de 1 a 3 segundos es rápido, de 3 a 6 es lento y de 6 segundos a más, es preocupante.

Pero existen variedades de condiciones que afectan esta percepción tanto para un visitante en nuestra página web como para otro, ya que para un usuario la carga puede ser rápida y para otro puede parecer lenta, hay tantos factores que entran en juego, para el primero puede que tenga un dispositivo potente y buena conexión a internet y para el segundo caso, lo contario, la verdad es que el rendimiento web es relativo.

Es por eso, que desde hace unos pocos años se crearon las métricas Core Web Vitals, con el fin de “estándarizar” como medimos el rendimiento para mejorar la optimización web. El performance es muy importante para el éxito de cualquier página ya que no solamente es una de la prácticas que Google toma en cuenta posicionar tu sitio web, sino porque no brindar atención a la optimización impacta negativamente la experiencia de las personas que visitan tu página.

¿Qué son las Core Web Vitals?

Las Core Web Vitals, es una iniciativa de Google para brindar una guía unificada del tipo de métricas necesarias para indicar a los desarrolladores los aspectos necesarios para optimizar la experiencia de los usuarios en los sitios web. Se componen por un conjunto de métricas totalmente centradas para los usuarios, que se encargan de medir aspectos importantes de todas las páginas web como el tiempo de carga, el tiempo para interactuar y la estabilidad visual.

Si quieres optimizar tu sitio web es importante que conozcas todas estás métricas:

  • Largest Contentful Paint (LCP).
  • First Input Delay (FID).
  • Cumulative Layout Shift (CLS).

Las principales métricas Core Web Vitals son Lagest Contentful Paint, First Input Delay y Cumulative Layout Shift Las principales métricas Core Web Vitals son Largest Contentful Paint, First Input Delay y Cumulative Layout Shift.

Desde el 2020 son las 3 principales métricas ya que engloban los indicadores de los aspectos antes mencionados: tiempo de carga, tiempo para interactuar y estabilidad visual, esenciales para comprender y brindar una excelente experiencia de usuario. Pero existen otros tipos de métricas, que se denominan Web Vitals:

  • Time To First Byte (TTFB).
  • First Contentful Paint (FCP).
  • Speed Index (SI).
  • Max Potential First Input Delay (mFID).
  • Total Blocking Time (TBT).
  • Time To Interactive (TTI).

Estas son otros tipos de métricas que no forman parte de las Core Web Vitals ya que algunas no se pueden medir con usuarios reales de una página web, sino que analizan aspectos más técnicos y no reflejan un resultado centrado en el usuario, pero a veces sirven como complementarias para ayudar a diágnosticar un problema en específico.

Las Core Web Vitals y las Web Vitals son los mejores indicadores disponibles para los desarrolladores para analizar el impacto del rendimiento en la calidad de experiencia de los usuarios en una página web, pero evolucionan con el tiempo, si quieres conocer los cambios que se documentan lee este directorio de cambios de web performance para las Web Vitals.

Tipos de métricas de optimización

Podemos dividir este tipo de métricas en las siguientes categorías:

  1. Velocidad de carga: Son el conjunto de métricas que se encargan de medir la rapidez con la que carga una página y renderiza todos los elementos visuales en la pantalla.
  2. Capacidad de respuesta de la carga: Además de también medir la rapidez de un sitio web, miden que tan optimizado está el código para responder fácilmente a las interacciones de los usuarios, es decir, si no hay muchas tareas largas que ralenticen la página.
  3. Capacidad de respues del tiempo de ejecución: Después de que la página está cargada por completo, se analiza qué tan rápido puede el usuario empezar a navegar por nuestro sitio.
  4. Estabilidad visual: Mide cuántos elementos cambian de manera inesperada, como cambios de diseño de elementos que cargan lentamente, y afectan a la navegación y a la experiencia de los usuarios.
  5. Fluidez: Si los elementos y las animaciones existentes en la página, se renderizan con una frecuencia constante y con fluidez de un momento a otro.

Largest Contentful Paint (LCP)

Largest Contentful Paint del sitio web de Comtech Largest Contentful Paint del sitio web de Comtech.

La métrica Largest Contentful Paint, se encarga de medir el despliegue del contenido más extenso (LCP) y el tiempo que este tarda en renderizarse dentro de la pantalla del dispositivo, esto es en relación desde el momento en que la página web comenzó a cargarse.

Para tener una buena puntuación, es recomendable que el elemento que se mida como LCP tarde menos de 2.5 segundos en cargarse o renderizarse, de 2.5 a 4 segundos se considera moderado y finalmente mayor a 4 segundos es demasido lento.

Valores menores a 2.5 segundos es recomendable para un buen puntaje de LCP, entre 2.5 y 4 segundos se consideran regulares y mayores a 4 segundos son malos Valores menores a 2.5 segundos es recomendable para un buen puntaje de LCP, entre 2.5 y 4 segundos se consideran regulares y mayores a 4 segundos son malos.

¿Qué elementos afectan la métrica LCP?

Los principales elementos que pueden afectar el rendimiento son:

  • Imágenes
  • Videos
  • Vectores en línea o SVG
  • Fondos de imágenes cargados mediante CSS
  • En caso de no existir en el viewport ningún elemento de los anteriores, un última instancia se toman en cuenta elementos de texto

Si existe un elemento que se extiende fuera de la pantalla de visualización, si está recortado o tiene un desbordamiento que no es visible, no se tomará en cuenta para la métrica LCP. Los datos de esta métrica se pueden extraer desde datos de laboratorio y desde datos de campo.

First Input Delay (FID)

FID, mide la capacidad de respuesta de una página web con el usuario cuándo este interactúa por primera vez hasta cuando el navegador o el sitio web responde a esa interacción, es decir, mientras carga la página web un usuario puede empezar a desplazarse, hacer click en un botón o enlace, escribir en un campo de búsqueda, mientras más rápida sea la respuesta a la acción solicitada del usuario mejor será el puntaje del First Input Delay.

El valor recomendado para FID es que tarde menos de 100 milisegundos, para así brindar una buena experiencia a los visitantes de nuestra página web.

Una medida menor a 100 milisegundos es un buen puntaje para FID, entre 100 y 300 milisegundos es regular y mayor a 300 milisegundos es un mal resultado Una medida menor a 100 milisegundos es un buen puntaje para FID, entre 100 y 300 milisegundos es regular y mayor a 300 milisegundos es un mal resultado.

¿Qué afecta a la métrica FID?

Cargar archivos CSS y JavaScript muy pesados son la principal causa para tener un puntaje de First Input Delay deficiente, ya que el navegador utilizara más recursos para procesarlos y ejecutarlos, y no podrá responder rápidamente a las interacciones de los usuarios.

Esta métrica solamente se puede medir con datos de campo, ya que requiere que un usuario real sea quién interactúe con el sitio, pero otras métricas como Total Blocking Time (TBT) y Time To Interactive (TTI), que se miden con datos de laboratorio se correlacionan con FID, por que lo que tener una buena optimización en estas métricas debería ayudar al First Input Delay.

Cumulative Layout Shift (CLS)

Cumulative Layout shift en el sitio web de Cargotrans Cumulative Layout shift en el sitio web de Cargotrans.

Se encarga de medir el cambio acumulativo del diseño (CLS), que es la inestabilidad del contenido cuando un elemento que está visible cambia su posición repentinamente, lo que puede provocar acciones involuntarias para los usuarios, por ejemplo cuando quieren hacer click en un botón pero este es desplazado por otro elemento que no se había terminado de cargar completamente, definitivamente es algo frustante para cualquier visitante de una página web.

¿Qué aspectos afectan al CLS?

Las causas más comunes que provocan un Cumulative Layout Shift deficiente son:

  • Imágenes que no tienen dimensiones explícitas mediante HTML con los atributos width y height o CSS.
  • Iframes sin dimensiones.
  • Contenido incrustado dinámicamente con JavaScript.
  • Fuentes web que provocan cambios de diseño, por ejemplo, cuándo se carga la fuente alternativa y se cambia por otra (se denomina FOUT) y cuándo el texto es “invisible” hasta que se descarga y aplica el estilo de la fuente que la utiliza (se denomina FOIT).
  • Alguna acción que esperan una respuesta de red, cuando momentanéamente perdemos conexión y la recuperamos repentinamente se muestra el contenido de manera brusca provocando el desplazamiento de otros elementos.
  • Animar propiedades CSS que afectan diseño como por ejemplo, animar el ancho (width) y el alto (height) de un elemento.

Los datos de CLS se pueden medir en laboratorio y desde datos de campo.

¿Cómo se mide el CLS?

Esta no es una métrica que se mida por tiempo como las demás sino que para calcular la puntuación, el navegador mide el tamaño de la pantalla de visualización del usuario lo que se denomina la fracción de impacto y el desplazamiento de los elementos inestables en la pantalla de visualización lo que es la fracción de distancia y se calcula el productos de ambos, siendo la fórmula:

CLS = fracción de impacto * fracción de distancia

Entonces si hay un elemento en nuestra página que se desplaza un 35% hacia abajo de la altura de la pantalla de visualización, la fracción de distancia será de 0.35 y la fracción de impacto será de un 65%, ya que por defecto es de 100% y se sustrae del anterior, lo que será igual a 0.65. Entonces si multiplicamos 0.65 * 0.35, el CLS será igual a 0.2275.

Para tener un buenta puntaje de Cumulative Layout Shift, debemos lograr menos de 0.1, así que debes de asegurarte de lograr menos de un 20% para la fracción de distancia.

Un buen puntaje para CLS es menor a 0.1, entre 0.1 y 0.25 es regular y mayor a 0.25 es malo Un buen puntaje para CLS es menor a 0.1, entre 0.1 y 0.25 es regular y mayor a 0.25 es malo.

Time To First Byte (TTFB)

El Time To First Byte en el sitio de IHN Grupo es de 484.63ms, casi supera el máximo recomendado El Time To First Byte en el sitio de IHN Grupo es de 484.63ms, casi supera el máximo recomendado.

Quizás te sorprenda saber que esta es la métrica más importante, eso es debido a que tener un mal puntaje en ésta afectará algunas métricas en consecuencia. Time To First Byte se encarga de medir la velocidad de respuesta del servidor dónde alojamos nuestra página web, cuándo un visitante hace la solicitud para ver nuestro sitio y así identificar si el servidor es demasido lento.

Es recomendable lograr menos de 600 milisegundos para tener un TTFB bueno y ya que precede a las métricas First Contentful Paint (FCP) y Largest Contentful Paint (LCP) las afectará. Es una métrica que se puede medir tanto en el campo como en laboratorio.

Menos de 600 milisegundos de respuesta del sevidor es un buen puntaje para TTFB, entre 600 y 800 milisegundos es regular y mayor a 800 milisegundos es un mal puntaje Menos de 600 milisegundos de respuesta del sevidor es un buen puntaje para TTFB, entre 600 y 800 milisegundos es regular y mayor a 800 milisegundos es un mal puntaje.

¿Qué afecta al TTFB?

Time To First Byte se compone de una serie de fases en la solicitud desde que el navegador de los usuarios hace la solicitud a nuestro sitio web:

  • Tiempo de redireccionamiento (si corresponse).
  • Búsquedas DNS.
  • Conexión y negociación del certificado TLS.
  • Por último, el tiempo de la solicitud hasta que ha llegado el primer byte de la respuesta.

Por lo que contratar un buen proveedor de hosting, ayudará a reducir la latencia en el tiempo de respuesta del servidor.

First Contentful Paint (FCP)

First Contentful Paint en el sitio web de Omega Industrial First Contentful Paint en el sitio web de Omega Industrial.

Es la métrica que precede al LCP, y mide el primer despliegue de contenido (FCP) se representa en la pantalla del usuario. El contenido que se mide es texto, imágenes que son cargadas en segundo plano, elementos <svg> y elementos <canvas> que no estén en blanco. Los <iframe> no están incluidos.

Un tiempo recomendado de FCP para brindar una buena experiencia de usuario es lograr menos de 1.8 segundos. Es una métrica de laboratorio y también se puede medir en el campo.

Mostrar el contenido en menos de 1.8 segundos te hará tener buen puntaje de FCP, entre 1.8 y 3 segundos es un resultado regular y mayor a 3 segundos es un resultado malo Mostrar el contenido en menos de 1.8 segundos te hará tener buen puntaje de FCP, entre 1.8 y 3 segundos es un resultado regular y mayor a 3 segundos es un resultado malo.

Speed Index (SI)

El Speed Index de la página web de Concretera Total El Speed Index de la página web de Concretera Total.

El índice de velocidad (SI), mide la rapidez que se muestra el contenido del sitio web durante el intervalo de tiempo de carga, es decir, si el sitio carga todo el contenido de golpe o si se carga progresivamente y puede ser una ayuda para los usuarios para indicar si la página web está cargándose o no. No es lo mismo que un sitio que tarde 5 segundos se muestre en blanco todo ese período de tiempo y cargue todo el contenido a la vez, a que éste se vaya cargando de manera progresiva.

Es una métrica relacionada con las demás consideradas de carga, ya que tener elementos que bloqueen el renderizado del sitio, te hará tener peor puntuación. Es recomendable obtener un Speed Index menos de 3.4 segundos y el sitio web se cargue poco a poco.

Mientras el contenido se muestre rápidamente en menos de 3.4 segundos será un buen resultado para SI, entre 3.4 y 5.8 segundos será un resultado regular y mayor a 5.8 segundoes será un muy mal resultado Mientras el contenido se muestre rápidamente en menos de 3.4 segundos será un buen resultado para SI, entre 3.4 y 5.8 segundos será un resultado regular y mayor a 5.8 segundoes será un muy mal resultado.

Los datos de este métrica se extraen de laboratorio y de campo.

Max Potential First Input Delay (mFID)

Esta métrica es muy similar a First Input Delay (FID), pero se encarga de medir el potencial retardo máximo de la primera entrada (mFID) del usuario. Es la continuación al FID, porque calcula la duración de la tarea más larga después del FID, ya que las tareas posteriores son excluidas por que es poco probable que un usuario interactúe con un sitio web antes del renderizado del contenido en la pantalla, que es lo que mide el FID, y cualquier interacción consecuente es analizada por mFID.

También está un poco relacionada con la métrica Time To Interactive (TTI), por lo que lograr mejoras en esta ayudará a mejorar el TTI. El puntaje de mFID es mayor al FID, llegando a ser de 130 el máximo recomendado para tener una buena puntuación.

Los resultados recomendados difieren con FID, menor a 130 milisegundos es un buen resultado, entre 130 a 250 milisegundos es regular y mayor a 250 milisegundos en malo Los resultados recomendados difieren con FID, menor a 130 milisegundos es un buen resultado, entre 130 a 250 milisegundos es regular y mayor a 250 milisegundos en malo.

Al igual que el FID, esta métrica de extrae de datos de campo.

Total Blocking Time (TBT)

El Total Blocking Time en Comtech donde se señala el tiempo de ejecución de las tareas largas y la duración total El Total Blocking Time en Comtech. Las flechas de la parte superior señalan el tiempo de ejecución de las tareas largas y la flecha inferior la duración total.

El tiempo de bloqueo total (TBT), mide el tiempo entre la métrica First Contentful Paint (FCP) y Time To Interactive (TTI), dónde determina cuánto ha estado una página bloqueada para no responder a las entradas de los usuarios, como empezar a desplazarse en el sitio web, hacer click en un botón, empezar a escribir con el teclado, etc.

El promedio para ejecutar cualquier tarea es de 50 milisegundos, por lo que al sobrepasarse se considera una tarea de ejecución larga. Por ejemplo si hay un proceso que sura 80 milisegundos, el tiempo de bloqueo sería de 30 milisegundos. Si hay tareas suficientemente largas el usuario empezará a notar la página web lenta o poco funcional, por que el navegador tendrá que esperar a que la tarea termine para empezar a responder.

¿Cómo se relaciona Total Blocking Time (TBT) con Time To Interactive (TTI)?

TBT se considera la métrica complementaria para TTI, porque determina la gravedad de falta de interactividad de una página. Si el subproceso principal, ha estado libre de tareas largas por un período de al menos 5 segundos la métrica TTI la considera como confiablemente interactiva.

Por ejemplo, si suponemos que tenemos 3 tareas que duran 51 milisegundos pueden llegar a demorar el TTI tanto como una sola tarea de 10 segundos, pero las 3 tareas tendrían un TBT de 3 milisegundos (el excedente de 50 milisegundos), mientras que la tareas de 10 segundos tendría un TBT de 9,950 milisegundos, entonces en este segundo caso sería la peor experiencia para la métrica TBT.

Para tener una buena puntuación de TBT es recomendable lograr menos de 300 milisegundos en el total del bloqueo de las tareas del sitio.

Para tener un buen puntaje de TBT, se debe lograr en menos de 200 milisegundos, entre 300 y 600 milisegundos se obtiene un puntaje regular y mayor a 600 milisegundos un mal resultado Para tener un buen puntaje de TBT, se debe lograr en menos de 200 milisegundos, entre 300 y 600 milisegundos se obtiene un puntaje regular y mayor a 600 milisegundos un mal resultado.

La métrica TBT debe medirse en el laboratorio, aunque también es posible medirla con usuarios reales o en el campo, no es recomendable ya que la interacción de los usuarios generaría una variedad de reportes díficiles de medir correctamente, asi que para comprender la interactividad de los usuarios se comienda usar First Input Delay para extraer datos de campo.

Time To Interactive (TTI)

Mide el tiempo de una página cuándo es completamente interactiva y responde de manera confiable a las interacciones del usuario, es decir, un sitio web es completamente interactivo cuándo:

  • Finaliza la tarea más larga, después que se muestra el contenido que se mide con FCP.
  • Cualquier evento que el usuario que responda en menos de 50 milisegundos.

Muchas veces puede ocurrir que podemos tener una excelente métrica de First Contenful Paint a expensas de tener un mal puntaje de Time To Interactive, por lo que la página puede parecer rápida, pero no será completamente interactiva cuándo el usuario empiece a navegar por el sitio web, para evitar ese problema es importante minimizar las tareas largas de FCP.

El valor recomendado para TTI es que sea menor a 3.8 segundos.

Que tu sitio web sea interactivo en menos de 3.8 segundos te hará tener un buen puntaje de TTI, entre 3.8 y 6.2 segundos un puntaje regular y mayor a 6.2 segundos un mal puntaje Que tu sitio web sea interactivo en menos de 3.8 segundos te hará tener un buen puntaje de TTI, entre 3.8 y 6.2 segundos un puntaje regular y mayor a 6.2 segundos un mal puntaje.

Es una métrica que se mide en el laboratorio, ya que al igual con TBT, si se mide en el campo se pueden generar muchas variaciones de datos.

¿Cómo se miden las métricas?

A lo largo del artículo habrás notado que algunas métricas se pueden medir de 2 maneras, con datos de laboratorio y/o de campo, a continuación entenderemos cuál es la diferencia:

¿Qué son los datos de laboratorio?

Se trata en realizar pruebas en un entorno controlado por nosotros, por ejemplo, las herramientos para desarrolladores de nuestro navegador, dónde podemos simular diferentes condiciones entre ellas, las de simular un dispositivo en específico, simular diferentes condiciones o velocidades de red, etc.

Es una forma importante para medir métricas que de otra forma serían muy complicadas para analizar con usuarios reales, por lo que realizar pruebas en el laboratorio es la mejor manera para no generar errores en nuestros análisis y estropear la experiencia de los usuarios.

¿Qué son los datos de campo?

Ya que no podemos simular todas las condiciones que experimentan nuestros visitantes, es aquí lo que llamamos datos de campo, que son los datos extraídos por usuarios reales que han interactuado con nuestra página web, ya que las métricas pueden variar drásticamente según las capacidades de los dispositivos de los usuarios así como las condiciones de red cuándo navegan por nuestro sitio.

Datos de campo de la página web de Comtech. En verde los usuarios que no tienen problemas de optimización, en naranja los que regularmente experimentan problemas y en rojo los usuarios que tienen una mala experiencia Datos de campo de la página web de Comtech. En verde los usuarios que no tienen problemas de optimización, en naranja los que regularmente experimentan problemas y en rojo los usuarios que tienen una mala experiencia.

Al analizar un sitio web con PageSpeed Insights (si hay datos suficientes) veremos una sección como la anterior, dónde el área verde es el porcentaje de los usuarios a los que nuestra página web ha tenido un buen puntaje en cada métrica, y así sucesivamente.

Métricas deprecadas

First Paint o First Meaningful Paint

Esta métrica fue deprecada en favor de First Contentful Paint (FCP), se encargaba de medir el primer pintado en la pantalla, lo que representaba cualquier cambio visual, como fondos con colores, aunque no hubiera algún tipo de contenido importante para los usuarios como textos o imágenes.

Por lo que era demasiado sensible a los cambios e inestable para tener métricas razonables, ya que algunas veces podías tener una buena puntuación de FCP y un mal puntaje de FP/FMP.

First CPU Idle

Esta métrica era muy similar a Time To Interactive, con la diferencia que analizaba la velocidad mínima que tardaba una página en volverse interactiva. Aunque algunos datos eran superiores a TTI, no eran lo suficientemente fiables en comparación, es por eso que se avandonó su uso en favor de TTI.


Si te ha gustado este artículo, podrías invitarme a un café, te lo agradecería muchísimo.

Invítame a un café

¡Comparte este artículo!

Otras publicaciones

Mira otras publicaciones