JavaScript
Explica cómo medir antes de optimizar, usar profiling para localizar cuellos de botella y comprobar que una mejora realmente reduce costo sin introducir errores.
Optimizar consiste en mejorar una métrica relevante sin romper comportamiento, mantenibilidad u otras restricciones.
problema observado
↓
métrica
↓
perfil
↓
hipótesis
↓
cambio
↓
comparaciónEjemplos:
“Que sea más rápido” no permite saber si el cambio funcionó.
const start = performance.now();
operation();
const duration = performance.now() - start;Es monotónico y apropiado para medir duraciones dentro de una sesión.
Una sola ejecución incluye ruido de:
performance.mark("checkout:start");
await checkout();
performance.mark("checkout:end");
performance.measure(
"checkout",
"checkout:start",
"checkout:end",
);Permite registrar hitos y observarlos con herramientas.
console.time("load");
await load();
console.timeEnd("load");Útil para una inspección rápida, pero no sustituye un perfil completo.
En DevTools puedes observar:
Busca dónde se consume tiempo, no solo dónde termina el síntoma.
Un perfil de CPU muestrea o instrumenta stacks para mostrar funciones costosas.
Muestra la ruta desde llamadas superiores.
Agrupa costo por función sin importar desde dónde se llamó.
Tiempo dentro de la función excluyendo llamadas hijas.
Incluye funciones llamadas.
Una función con total alto y self bajo puede ser solo la coordinadora de trabajo costoso.
Revisa:
No atribuyas a JavaScript una latencia que pertenece al servidor o red.
Permiten comparar objetos y rutas de retención.
Conceptos:
Una gran retained size indica cuánto podría liberarse si ese objeto dejara de ser alcanzable.
Muestra qué rutas crean objetos y cuáles permanecen.
Útil cuando el problema es:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
reportMetric(entry);
}
});
observer.observe({
type: "longtask",
buffered: true,
});Los entry types disponibles dependen del navegador y contexto.
performance.mark("search:start", {
detail: {
queryLength: query.length,
},
});No incluyas datos sensibles en marcas o telemetría.
for (let index = 0; index < 1_000_000; index++) {
operation();
}Pueden medir algo distinto al uso real por:
Úsalos para preguntas estrechas y valida después en el flujo real.
Las primeras ejecuciones pueden incluir compilación e inicialización. Las posteriores pueden utilizar código optimizado.
No descartes siempre el warm-up: la experiencia inicial también importa para usuarios.
Una prueba puede parecer más lenta porque coincide con una pausa de GC. Eso puede ser parte real del costo si el flujo crea mucha basura.
No fuerces GC en producción ni lo uses para “arreglar” una fuga.
p50 → experiencia mediana
p75 → mayoría de usuarios
p95 → cola lenta
p99 → casos extremosEl promedio puede ocultar una parte de usuarios con experiencia muy mala.
Control, reproducibilidad y profiling detallado.
Dispositivos, redes y datos reales.
Necesitas ambas: el laboratorio explica; el campo muestra impacto.
Define límites:
bundle < 200 KB gzip
interaction p75 < 200 ms
memory after navigation < thresholdUn presupuesto vuelve detectable una regresión antes de acumularse.
Si modificas algoritmo, caché, worker y rendering al mismo tiempo, no sabrás qué produjo la mejora o regresión.
Cambia una hipótesis y compara.
performance.mark("load:start");
const products = await loadProducts();
performance.mark("load:end");
performance.mark("render:start");
renderProducts(products);
performance.mark("render:end");
performance.measure(
"load-products",
"load:start",
"load:end",
);
performance.measure(
"render-products",
"render:start",
"render:end",
);Separar fases muestra si el costo está en red o renderizado.
¿Por qué una función con self time bajo puede aparecer como muy costosa en total time?
Porque coordina llamadas a otras funciones costosas. Su propio cuerpo consume poco, pero el trabajo descendiente se suma a su total.
Motores JavaScript, interpretación y JIT explica cómo un motor lleva el código fuente hasta ejecución optimizada.