Métricas de rendimiento útiles para web apps y webs comerciales

Las métricas de rendimiento útiles son las que miden lo que nota quien usa tu web: cuánto tarda en ver el contenido principal, cuánto tarda la página en reaccionar cuando toca algo y si las cosas se mueven mientras carga. En una web comercial, esas tres (las Core Web Vitals de Google) y el tiempo de respuesta del servidor cubren casi todo; en una web app hay que sumar lo que pasa detrás, en el servidor: cuánto tardan las peticiones y cuántas fallan.

Datos de campo y datos de laboratorio

Antes de mirar ninguna cifra conviene saber de dónde sale, porque hay dos fuentes y no miden lo mismo.

Los datos de campo vienen de visitas reales. Los que enseñan PageSpeed Insights y Search Console salen del informe de experiencia de usuario de Chrome (CrUX), que recoge las visitas de los últimos 28 días y da el percentil 75 de cada métrica: el valor que igualan o mejoran tres de cada cuatro visitas.

Los datos de laboratorio salen de una prueba simulada: Lighthouse carga la página en un solo dispositivo y con una red fija. Sirven para encontrar la causa de un problema, porque la prueba se puede repetir, pero no dicen qué viven tus usuarios con sus móviles y sus conexiones.

Hay un matiz que pilla a muchas empresas. CrUX solo incluye páginas públicas e indexables que superan un mínimo de visitas, y Google no publica ese mínimo. Una web recién estrenada, o con pocas visitas, no tendrá datos de campo de Google. En una web app pasa algo parecido: las pantallas que más te importan (el panel, el buscador, el pedido) suelen estar detrás del inicio de sesión, y esas no son páginas públicas. En los dos casos, la medición de campo la pones tú.

Las tres Core Web Vitals y sus umbrales

Google mide tres cosas y fija para cada una un umbral de «bueno» y otro de «malo»; lo que queda entre los dos necesita mejorar. Se evalúan en el percentil 75 de las visitas, por separado en móvil y en ordenador.

INP sustituyó a FID (First Input Delay) como Core Web Vital el 12 de marzo de 2024. Si una auditoría te habla todavía de FID, está desfasada.

En una web comercial, el LCP manda

En una página de servicio o de producto, el elemento más grande suele ser la imagen de cabecera o el titular. Google descompone el LCP en cuatro tramos, y cada uno tiene su culpable habitual: el servidor que tarda en mandar la página, la imagen principal que el navegador descubre tarde, la imagen que pesa demasiado y las hojas de estilo o los scripts que retrasan el pintado. Es la métrica que más se nota en la primera visita, que es la que decide si alguien se queda.

En una web app, el INP pesa más

En una aplicación, el usuario no solo mira: filtra, abre fichas, rellena formularios. Si cada clic tarda en reaccionar, la aplicación se siente torpe aunque haya cargado rápido. El INP no se puede medir en laboratorio, porque allí nadie hace clic: Lighthouse usa en su lugar el tiempo total de bloqueo (TBT) como aproximación. Para conocer el INP real hacen falta datos de campo.

El CLS es el más fácil de arreglar

Las causas que recoge Google son cuatro: imágenes sin medidas declaradas, anuncios y contenidos incrustados que llegan tarde, animaciones y letras web que cambian el tamaño del texto al cargar. Casi siempre basta con reservar el hueco de cada elemento antes de que llegue.

TTFB: lo que tarda el servidor en empezar a contestar

El TTFB (Time to First Byte) mide el tiempo desde que empieza la navegación hasta que llega el primer byte de la respuesta. Suma las redirecciones, la consulta DNS, la conexión y la negociación TLS, y la propia petición. Google propone como orientación 0,8 s o menos y considera malo pasar de 1,8 s. No es una Core Web Vital, pero va antes que todo lo demás: si el servidor tarda en contestar, el LCP no puede ser rápido.

Lo que hay que medir además en una web app

Una web app sigue pidiendo datos al servidor después de cargar: cada búsqueda, cada guardado y cada listado es una petición más. Esa parte no la ven las Core Web Vitals, y se mide en el servidor.

El libro de Google sobre ingeniería de fiabilidad (SRE) da dos ideas que aplicamos siempre. La primera: medir los tiempos de respuesta con percentiles y no con la media, porque la media esconde las peticiones lentas; un percentil alto, como el 99, enseña el peor caso plausible. La segunda: elegir pocas métricas del servicio y ponerle a cada una un objetivo. Las que solemos proponer son estas:

• El tiempo de respuesta de las peticiones importantes (búsqueda, guardado, pago), en percentiles.
• La tasa de errores: qué fracción de las peticiones falla.
• La disponibilidad: qué fracción del tiempo se puede usar la aplicación.

Un objetivo útil dice qué se mide, en qué punto y con qué umbral: qué percentil de las búsquedas tiene que responder por debajo de qué tiempo, medido en el servidor y durante qué periodo. Los umbrales los fija cada proyecto según lo que necesitan sus usuarios.

Cómo montar la medición sin complicarte

Para una web comercial con visitas suficientes, Google te da casi todo hecho:

• El informe «Core Web Vitals» de Search Console agrupa tus URL con los datos de campo de CrUX. Si un grupo no tiene datos suficientes, no aparece.
• PageSpeed Insights enseña, para una URL concreta, los datos de campo y la prueba de laboratorio juntos.

Para una web app, o para una web que aún no llega al mínimo de visitas:

• La librería web-vitals, que publica el equipo de Chrome, mide LCP, INP y CLS (y también FCP y TTFB) en los navegadores de tus propios usuarios. Los valores se envían a tu analítica o a tu servidor. No hace falta guardar datos personales: basta la métrica, la página y el tipo de dispositivo.
• Los registros del servidor, o una herramienta de monitorización, para los tiempos de las peticiones, los errores y la disponibilidad.

Y una costumbre que ahorra sustos: revisar las cifras cada mes y después de cada cambio importante, que es cuando suelen empeorar.

Preguntas frecuentes

¿Una nota alta en PageSpeed significa que mi web es rápida?

La nota de rendimiento sale de la prueba de laboratorio: un dispositivo simulado con una red fija. Es útil para encontrar problemas, pero lo que viven tus usuarios está en los datos de campo, que PageSpeed enseña aparte cuando los hay. Pueden no coincidir, y cuando no coinciden, mandan los de campo.

¿Por qué Search Console no me enseña datos de Core Web Vitals?

Porque esos datos salen de CrUX, que solo incluye páginas públicas e indexables con visitas suficientes. Mientras tu web no llegue a ese mínimo, mide con la prueba de laboratorio de PageSpeed Insights y con la librería web-vitals en tus propios usuarios.

¿Qué métricas pedir al encargar una web app?

Las tres Core Web Vitals en el percentil 75 de los datos de campo, los tiempos de respuesta de las peticiones importantes en percentiles, la tasa de errores y la disponibilidad. Y, sobre todo, cómo y dónde se van a medir, porque una cifra sin método no se puede comprobar.

El siguiente paso

Si tu web o tu aplicación va lenta y no sabes por dónde empezar, cuéntanos qué te pasa y te decimos qué medir primero. Si estás pensando en una web app nueva, en nuestro servicio de software a medida explicamos cómo la construimos.

Fuentes

• web.dev, Web Vitals: las tres métricas, sus umbrales de «bueno» y la medición en el percentil 75, por separado en móvil y en ordenador.
• web.dev, Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS): umbrales de «bueno» y de «malo».
• web.dev, anuncio de INP como Core Web Vital: sustituye a FID el 12 de marzo de 2024.
• web.dev, Optimize Largest Contentful Paint y Optimize Cumulative Layout Shift: los tramos del LCP y las causas habituales del CLS.
• web.dev, Time to First Byte (TTFB): las fases que suma y sus umbrales orientativos.
• Google, Acerca de PageSpeed Insights: datos de campo de CrUX (28 días, percentil 75) y datos de laboratorio de Lighthouse.
• Chrome for Developers, metodología de CrUX: páginas públicas, indexables y con un mínimo de visitas que no se publica.
• Ayuda de Search Console, informe «Core Web Vitals»: datos de uso reales de CrUX; sin datos suficientes, el grupo no aparece.
• GoogleChrome, librería web-vitals: medición en usuarios reales.
• Google, Site Reliability Engineering, «Service Level Objectives»: percentiles frente a medias, tasa de errores y disponibilidad.