Las métricas de rendimiento evolucionan. Las Core Web Vitals se presentaron en 2020. Sustituyeron a métricas más antiguas (FCP, FID). Dentro de cinco años, nuevas métricas sustituirán a las Core Web Vitals.
Las métricas del futuro medirán: la carga de la IA (cuánto tardan en responder las funciones de IA), la respuesta en tiempo real (cuánto tardan en aparecer las respuestas en streaming), el rendimiento percibido por el usuario (cómo se siente la página, no solo las métricas técnicas).
La pregunta de ahora: cómo nos preparamos para métricas futuras sin saber cuáles serán. Respuesta: mide lo que importa para tu negocio. Las Core Web Vitals miden la experiencia general del usuario. Las métricas personalizadas miden resultados propios de tu negocio. Prepárate para el futuro creando flexibilidad en tus sistemas de medición.
Cómo evolucionan las métricas
Las Core Web Vitals son el estándar actual. Pero no son permanentes.
Cronología:
- 2020: se presentan las Core Web Vitals (LCP, CLS, FID)
- 2022: FID se sustituye por INP (se afina la métrica de capacidad de respuesta)
- 2024: se debate sobre las siguientes métricas (tiempo de espera de interacción, tiempo de respuesta en streaming)
- Futuro: aparecen métricas nuevas
Patrón: cuando cambia la tecnología, cambian las métricas. Cuando las páginas se volvieron interactivas, las métricas de interactividad (INP) cobraron importancia. A medida que la integración de IA se generalice, el tiempo de respuesta de la IA puede convertirse en una métrica importante.
Lección: céntrate en los principios (el usuario percibe una página rápida, que responde y es estable), no en las métricas en sí. Los principios se mantienen estables aunque cambien las métricas.
IA y rendimiento en tiempo real
Las funciones de IA se están generalizando. Un chatbot de la web tarda dos segundos en responder. El usuario espera algo más rápido.
Métrica emergente: tiempo de respuesta de la IA (tiempo desde la pregunta del usuario hasta el primer token de la respuesta de la IA).
Ejemplo: un chatbot de atención al cliente en la página de soporte. El usuario hace una pregunta. El chatbot tarda dos segundos en devolver el primer token de respuesta. Percepción del usuario: el chatbot es lento y no responde.
Optimización: respuesta en streaming. Devuelve el primer token en quinientos milisegundos y transmite el resto de la respuesta. El usuario percibe la respuesta como instantánea, aunque la respuesta completa tarde dos segundos.
Métrica futura: mide el tiempo hasta el primer token (TTF), no el tiempo total de respuesta. Un TTF por debajo de quinientos milisegundos es bueno.
Ejemplo real: un SaaS con un asistente de IA integrado.
Experiencia actual del usuario:
- El usuario hace clic en el icono del asistente
- El asistente tarda uno coma cinco segundos en aparecer
- El usuario espera y percibe lentitud
- La experiencia del chat resulta lenta
Optimización futura:
- El usuario hace clic en el icono del asistente
- El icono se anima de inmediato (respuesta instantánea, cien milisegundos)
- Se abre la ventana del chat (doscientos milisegundos)
- Aparece la primera respuesta de la IA (quinientos milisegundos)
- El resto de la respuesta de la IA llega en streaming (de uno a dos segundos)
Percepción del usuario: respuesta instantánea (la animación y la apertura de la ventana se ven de inmediato).
Computación en el borde y rendimiento distribuido
La computación en el borde acerca el cálculo a los usuarios. El servidor pasa de Nueva York a un nodo de borde en Los Ángeles. El TTFB mejora de forma drástica.
Futuro: el cálculo ocurre en el borde. La generación del HTML ocurre en el borde. La ejecución del JavaScript ocurre en el borde. Las consultas a la base de datos se distribuyen hacia el borde.
Impacto en las métricas: el TTFB se vuelve insignificante (la latencia de red tiende a cero). El LCP depende del pintado, no de la respuesta del servidor.
Foco de optimización del futuro: el rendimiento del pintado, no el de la respuesta del servidor.
Ejemplo: una página de inicio del futuro basada en el borde.
Situación actual:
- TTFB: doscientos milisegundos (servidor en Nueva York, usuario en Los Ángeles)
- LCP: dos segundos (LCP = TTFB + tiempo de pintado)
Situación futura (computación en el borde):
- TTFB: veinte milisegundos (servidor en el borde de Los Ángeles)
- LCP: uno coma cinco segundos (el cuello de botella es el tiempo de pintado, no la respuesta del servidor)
Optimización: mejorar el rendimiento del pintado (CSS, JavaScript) pasa a ser más importante que mejorar la respuesta del servidor.
Rendimiento percibido y métricas subjetivas
Métricas objetivas: el LCP es de dos segundos (medible, objetivo).
Métricas subjetivas: la página se siente ágil (subjetivo, percibido).
La investigación muestra: una página que se siente ágil puede tener las mismas métricas técnicas que una que se siente lenta. La diferencia está en la animación, la respuesta visual y la carga percibida.
Métrica futura: capacidad de respuesta percibida. Mide la percepción del usuario, no solo la métrica técnica.
Ejemplo: dos páginas con el mismo LCP (dos segundos).
Página uno: carga al instante una página en blanco y el contenido aparece a los dos segundos. El usuario percibe lentitud.
Página dos: muestra de inmediato una pantalla esqueleto (doscientos milisegundos) y va rellenando el contenido hasta los dos segundos. El usuario la percibe más rápida (la pantalla esqueleto crea la ilusión de una carga más rápida).
Métricas técnicas (LCP): iguales en ambas (dos segundos).
Percepción del usuario: la página dos se siente más rápida.
Métrica futura: puntuación de percepción del usuario (medir la experiencia subjetiva junto a las métricas técnicas).
Streaming y pintado progresivo
Enfoque actual: se genera la página entera y se envía al cliente. El cliente pinta la página. La página es interactiva.
Enfoque con streaming: se envían las partes de la página según se generan. El cliente las recibe y las pinta de forma progresiva. La página es interactiva en parte antes de cargar por completo.
Impacto: una página que tarda dos segundos en cargar por completo puede ser interactiva en cero coma cinco segundos si se transmite en streaming.
Métrica futura: tiempo hasta la interactividad (TTI). Cuánto tarda el usuario en poder interactuar con la página.
Ejemplo: una página de producto con recomendaciones.
Enfoque actual:
- Carga el HTML (cero coma cinco segundos)
- Carga el CSS (cero coma tres segundos)
- Carga el JavaScript (cero coma cinco segundos)
- Llamada a la API de recomendaciones (un segundo)
- La página es interactiva a los dos coma tres segundos
Enfoque con streaming:
- El HTML se transmite (cero coma uno segundos): la estructura de la página es visible
- El CSS se transmite (cero coma dos segundos): la página tiene estilo
- El JavaScript se transmite (cero coma tres segundos): la página es interactiva
- La llamada a la API de recomendaciones sigue en segundo plano
- La página es interactiva a los cero coma cinco segundos
- Las recomendaciones aparecen al segundo y después
El usuario puede interactuar (añadir al carrito, hacer clic en botones) a los cero coma cinco segundos. El contenido completo aparece al segundo y después.
Métrica futura (TTI): cero coma cinco segundos (antes dos coma tres segundos). Una mejora enorme en la percepción del usuario.
Preguntas frecuentes
¿Debemos empezar a medir ya el tiempo de respuesta de la IA?
Sí, si tu web tiene funciones de IA. Mide el tiempo hasta el primer token. Sigue el dato a diario. Fija objetivos (por debajo de quinientos milisegundos es bueno). Prepárate para un futuro en que sea una métrica estándar. Aunque todavía no sea una métrica oficial, medir lo que importa a tus usuarios te prepara para el futuro. Con el creador de webs de WEMASY, puedes configurarlo directamente en tu web.
¿Cómo nos preparamos para métricas de rendimiento futuras que aún no conocemos?
Crea un sistema de medición flexible. Mide las Core Web Vitals (el estándar actual). Mide también métricas personalizadas (lo que importa a tu negocio). Cuando aparezcan métricas nuevas, podrás añadirlas junto a las existentes. La flexibilidad es la clave.
¿Debemos invertir en computación en el borde para mejorar el rendimiento?
Sí, si tienes usuarios en todo el mundo. La computación en el borde reduce el TTFB de forma drástica (se elimina la latencia de red). Merece la inversión. Si tus usuarios se concentran en una sola zona geográfica, basta con una CDN. Las audiencias globales se benefician de la computación en el borde.
¿Cómo medimos el rendimiento percibido por el usuario?
Haz encuestas a los usuarios. Pregunta: la página se siente rápida, ágil y estable. Relaciona los resultados de la encuesta con las métricas técnicas. Quizá descubras que los usuarios perciben la página como más rápida aunque las métricas técnicas sean iguales. Usa esa opinión para orientar el diseño (añade pantallas esqueleto, animaciones y respuesta visual).
¿Se está convirtiendo el tiempo hasta la interactividad (TTI) en la nueva métrica estándar?
Es posible. El TTI es más significativo que el LCP en páginas interactivas (el usuario puede actuar antes de que la página cargue por completo). Pero por ahora, las Core Web Vitals (LCP, CLS, INP) son el estándar. El TTI está emergiendo, pero aún no es oficial. Vigila ambas.
¿Cómo nos mantenemos al día de las nuevas métricas y estándares de rendimiento?
Sigue las fuentes oficiales: las novedades de rendimiento de Google, el blog de web.dev y los grupos de estándares del W3C. Sigue también el sector: revistas y blogs especializados en desarrollo web y charlas de congresos de ingeniería. Las métricas nuevas llegan por estos canales. Mantente informado. Adóptalas pronto cuando un estándar nuevo sea relevante para tu web.