Presupuesto de rendimiento web con Core Web Vitals

Un presupuesto convierte rendimiento en una decisión de producto#

Un presupuesto de rendimiento fija límites observables para que una página siga respondiendo a las necesidades de usuarios y negocio. No es un número universal: debe considerar tipo de página, dispositivos, conectividad, contenido y funciones críticas.

Core Web Vitals aporta tres medidas de campo: LCP para carga percibida, INP para respuesta a interacciones y CLS para estabilidad visual. Google clasifica como buenos, en el percentil 75 de visitas, LCP de hasta 2,5 segundos, INP de hasta 200 milisegundos y CLS de hasta 0,1. Son umbrales de evaluación de experiencia, no una garantía de posicionamiento ni una meta suficiente para todos los recorridos.

Define el presupuesto por plantilla#

Agrupa rutas con comportamiento similar: página de servicio, listado, artículo, formulario o área autenticada. Para cada una define:

• métrica de usuario y fuente de datos que se revisará;
• objetivo y límite de alerta;
• dispositivo, mercado o segmento prioritario;
• peso transferido y número de recursos críticos;
• presupuesto de JavaScript y trabajo en hilo principal;
• responsable y proceso para aceptar temporalmente una excepción.

Los límites técnicos —por ejemplo tamaño de imágenes o paquetes— son indicadores adelantados que el equipo puede controlar. No reemplazan las métricas de usuario. Registra también dependencias externas, porque widgets, etiquetas y fuentes pueden contribuir al coste total.

Mide laboratorio y producción por separado#

Las pruebas de laboratorio permiten comparar cambios bajo condiciones repetibles y localizar regresiones durante el desarrollo. Los datos de campo muestran experiencias reales agregadas y pueden variar por dispositivo, red, región y composición de visitas.

INP requiere interacción; un test de carga inicial no representa por sí solo la respuesta que percibe el usuario. CLS también puede cambiar después de la carga inicial. Por eso combina pruebas automatizadas de rutas representativas con observabilidad real, y analiza tendencias en una ventana suficiente antes de atribuir una causa.

Incorpora el control al ciclo de entrega#

1. Establece una línea base por plantilla y registra commit, entorno y configuración de prueba.
2. Ejecuta pruebas de laboratorio en cambios de interfaz, dependencias, medios o scripts de terceros.
3. Bloquea regresiones repetibles que superen límites técnicos acordados; exige revisión para excepciones.
4. Tras desplegar, comprueba datos de campo y errores reales antes de cerrar la entrega.
5. Revisa mensualmente qué rutas incumplen, su impacto y la prioridad de corrección.

No optimices un score agregado si el formulario, búsqueda o compra principal sigue lento para usuarios reales. Consulta la lista de aceptación de accesibilidad web WCAG 2.2 como parte de una calidad que no se reduce a velocidad.

Referencias#

• web.dev: umbrales de Core Web Vitals
• web.dev: cómo medir Web Vitals
• web.dev: optimizar LCP
• web.dev: optimizar CLS