Cómo establecer un presupuesto de rendimiento web que los equipos puedan cumplir

Empieza por los recorridos, no por un promedio de todo el sitio

Enumera de tres a cinco recorridos donde la demora tenga un coste claro para el cliente u operativo: aterrizar en una página de campaña, encontrar un producto, enviar un formulario de captación, iniciar sesión o completar una solicitud de soporte. Para cada uno, escribe el inicio, el resultado útil, la clase de dispositivo principal y la página o interacción que debe funcionar bien.

Da a cada recorrido su propia fila en el presupuesto. Un panel puede llevar más código que un artículo público, pero su acción de filtrado necesita un objetivo de capacidad de respuesta. Una página de producto rica en medios puede aceptar imágenes más grandes, pero necesita un límite para la imagen principal visible. Esto evita que una ruta crítica débil se pierda en un promedio por origen.

Elige resultados e insumos controlables

Usa tanto métricas de resultado como límites de insumo. Google describe Largest Contentful Paint (LCP) como rendimiento de carga; Interaction to Next Paint (INP) como capacidad de respuesta en interacción; y Cumulative Layout Shift (CLS) como estabilidad visual. Sus umbrales recomendados son LCP a 2.5 segundos o menos, INP a 200 milisegundos o menos y CLS a 0.1 o menos en el percentil 75, considerados por separado para móvil y escritorio.

Añade límites que expongan una causa de forma temprana: JavaScript inicial, imágenes necesarias antes del contenido principal, transferencia total para la ruta, solicitudes a terceros y un widget conocido como costoso. Haz seguimiento consistente de los tamaños en transferencia comprimida. Un diagnóstico como Time to First Byte puede ayudar a investigar una carga lenta, pero no es en sí mismo el resultado que percibe el cliente.

Fija números a partir de tu línea base

Captura una línea base para cada recorrido. En PageSpeed Insights, distingue los datos de campo de Chrome User Experience Report (CrUX), que agregan experiencias reales de usuarios de Chrome, de los datos de laboratorio de Lighthouse, que son una prueba controlada. Los datos de campo verifican la experiencia que alcanzan los usuarios; las pruebas de laboratorio hacen un cambio repetible antes del lanzamiento.

Segmenta al menos por móvil y escritorio y, cuando sea posible, por plantilla crítica o URL. PageSpeed Insights puede retroceder de datos por URL a datos por origen, y algunas páginas no tienen datos CrUX. Etiqueta ese caso como línea base de laboratorio y añade medición de usuario real para los recorridos importantes. Conserva la URL de prueba, el dispositivo y el perfil de red, el estado de caché, la fecha y la versión de la herramienta con cada línea base.

Elige un objetivo que mejore la línea base en un paso planificado y, luego, pruébalo en condiciones representativas. Un presupuesto que bloquee las versiones normales se sortea; uno por encima de la experiencia actual no protege a nadie.

Convierte el presupuesto en una regla de lanzamiento

Mantén el presupuesto en un lugar versionado y revisable junto al código o la lista de verificación de lanzamiento. Cada fila necesita el recorrido, la métrica, el perfil de prueba o población, el umbral de advertencia, el umbral de error, el propietario, el método de medición y la vía de excepción. MDN recomienda niveles de advertencia y error: la advertencia apoya la planificación proactiva, mientras que el error es un límite superior con efecto negativo perceptible.

Automatiza comprobaciones fiables. Un empaquetador puede rechazar un recurso sobredimensionado o un punto de entrada inicial; webpack soporta límites máximos de activos y puntos de entrada y sugerencias de error en producción. Ejecuta pruebas de laboratorio repetibles para el recorrido afectado en pull requests o candidatos de lanzamiento. Conserva métricas de campo para verificación y priorización post-lanzamiento en lugar de un bloqueo de compilación poco fiable.

Cuando un límite falle, reduce un recurso, pospone código no esencial, altera la experiencia, divide el lanzamiento o aprueba una excepción. No subas silenciosamente el umbral para pasar la compilación.

Verifica y remedia tras el lanzamiento

El peso de la página no predice por sí solo la experiencia completa. El orden de solicitudes, trabajo que bloquea el renderizado, capacidad del dispositivo, condiciones de red, cachés y terceros también importan. Mantén límites de insumo para detectar crecimiento y medidas de resultado para probar si la ruta es usable. La interfaz W3C Resource Timing expone los tiempos de recursos y los tamaños en transferencia, codificados y decodificados para un diagnóstico más profundo. El detalle de tiempos de origen cruzado puede estar restringido por permisos de timing, por lo que una cascada incompleta no demuestra que no haya coste de terceros.

Revisa los resultados de campo tras cambios importantes de plantilla, plataforma, etiquetas de marketing o tráfico. Si LCP empeora, inspecciona la respuesta del servidor, el recurso LCP y el trabajo que bloquea el renderizado. Si INP empeora, inspecciona interacciones reales; Lighthouse no puede medir INP porque no hay entrada de usuario, aunque Total Blocking Time sea un proxy de laboratorio. Usa el flujo de trabajo proactivo de optimización de SIU para priorizar un incumplimiento, estabilizar la ruta crítica y verificar la corrección en el mismo contexto de medición.