Leer el proceso actual

Un presupuesto de rendimiento marca límites para una experiencia definida, no para una puntuación vistosa. Empiece por tareas y dispositivos importantes: abrir servicios en un móvil modesto, filtrar una lista o enviar una solicitud. Mida el comportamiento actual antes de fijar límites y registre las condiciones.

Un límite que conviene mantener

Combine experiencia y costes controlables. Carga, respuesta a interacción y estabilidad describen lo que vive la persona; tamaño de scripts, imágenes y fuentes ayuda a explicarlo. web.dev plantea los presupuestos como límites para decidir. Asócielos a una página o tarea, con responsable y reacción al excederlos.

Seguir una tarea real

Suponga que una página añade una comparación interactiva. Mida producción antes y después con el mismo dispositivo y conexión. Revise código transferido y aparición del texto principal. Si retrasa sin ayudar a decidir, simplifique o cargue cuando haga falta. Si es esencial, retire otro coste menos útil en vez de ocultar la regresión.

Proteger las excepciones

No compare escritorio con caché y móvil sin caché ni presente el mejor ensayo como típico. Separe laboratorio y visitantes reales. Incluya fallos, contenido largo, fuentes traducidas y scripts externos. El presupuesto no debe fomentar texto ilegible, funciones ausentes o pruebas que excluyan la ruta difícil.

Convertir el presupuesto en una decisión repetible

Elija rutas representativas, incluida la página útil más pesada, no solo la portada. Registre build, dispositivo, conexión, caché y tarea junto al resultado inicial. Antes de frenar una entrega, distinga cambios del producto y cambios de prueba.

Asigne motivo a cada límite. Limitar scripts iniciales protege una conexión lenta; limitar respuesta protege el filtrado repetido. Si falla, revise tarea y desglose de costes. Código grande, imágenes, fuentes tardías y consultas lentas piden remedios distintos. Quitar funciones útiles para mejorar una puntuación puede empeorar el producto; evalúe la consecuencia real.

Documente excepciones. Si una visualización necesaria añade carga a una página especializada, registre necesidad, efecto medido, alternativas y responsable que acepta. Mantenga la excepción en esa ruta, no relaje todo. Fije revisión, especialmente para dependencias temporales. Tras publicar, contraste laboratorio con uso real disponible y estudie diferencias. Si no hay observación real, declare el alcance: estas rutas, bajo estas condiciones. Sigue siendo evidencia útil sin garantía universal.

Hoja de revisión del presupuesto

PreguntaPrueba necesaria
¿Qué se volvió lento?Ruta y tarea con ensayos comparables antes y después, no puntuaciones ajenas.
¿Qué coste cambió?Contribución de transferencia, renderizado o dependencia relevante, sin adivinar por el global.
¿Se justifica el coste?Beneficio y alternativas más ligeras realmente consideradas o probadas.
¿Cómo termina la excepción?Responsable, ruta y desencadenante de revisión para no convertir lo temporal en hábito.

Antes de decidir

¿Qué tarea empeora al superar el límite? ¿Se reproduce la medición? ¿Quién acepta una excepción y cuándo se revisa? Lleve una ruta y dispositivo representativos a la evaluación, y añada una comprobación pequeña y repetible al lanzamiento.

Fuentes y otras lecturas

  1. web.dev — Performance budgets
Servicios

Aplicaciones web

Un espacio claro para trabajo complejo.

Hablemos de este servicio