Nómada Tareas funciona y está probada: 124 pruebas en cuatro segundos y tres recorridos E2E confirman que hace lo que debe. Pero Taller Nómada lleva dos años usándola y el tablero ya no tiene seis tareas: tiene seiscientas. Marta dice que «va lenta». Iván dice que «al escribir en el buscador se atasca». Lucía dice que «tarda mucho en cargar». Tres frases, tres problemas posiblemente distintos, y ninguna de las tres es accionable. Antes de tocar una sola línea hay que convertir «va lenta» en un número, ese número en un objetivo, y ese objetivo en una prueba que falle cuando se incumpla. Esta lección enseña esa disciplina: qué significa «rápido» para una persona, qué métricas lo capturan (los Web Vitals), con qué herramientas se obtienen (Lighthouse, el panel Performance, el panel Network, la User Timing API), cómo se hace una medición honesta que no se deja engañar por el ruido ni por la máquina del desarrollador, y cómo se fija un presupuesto de rendimiento que la integración continua vigile sola. Al terminar tendrás la línea base de Nómada Tareas con 600 tareas: la tabla de números que las cuatro lecciones siguientes van a mejorar.

1. Por qué la intuición falla (y qué dijo Knuth de verdad)
2. Qué percibe una persona: 100 ms, 1 s y 16,7 ms
3. Los Web Vitals, uno a uno
4. Datos de laboratorio y datos de campo
5. Lighthouse: leer el informe sin obsesionarse con la puntuación
6. El panel Performance, paso a paso
7. El panel Network y el estrangulamiento de red y CPU
8. Instrumentar tu propio código: performance.now() y la User Timing API
9. Medir en producción: PerformanceObserver y web-vitals
10. Cómo se hace un benchmark honesto
11. Tu máquina miente: simular un móvil modesto
12. La línea base de Nómada Tareas con 600 tareas
13. El presupuesto de rendimiento y la integración continua
14. Errores Comunes y Consejos
15. Ejercicios
16. Conclusión

En 08-01 aprendiste que depurar por intuición no converge: cambias cosas, algunas parecen funcionar, y acabas con un código peor y un error que sigue ahí. El rendimiento es idéntico, pero peor, porque el error al menos se manifiesta y la lentitud se puede negar («a mí me va bien»).

Hay una frase que se cita constantemente y casi siempre mal:

«La optimización prematura es la raíz de todos los males.»

La frase es de Donald Knuth, en Structured Programming with go to Statements (1974), y completa dice algo bastante distinto:

«Deberíamos olvidarnos de las pequeñas eficiencias, digamos el 97 % del tiempo: la optimización prematura es la raíz de todos los males. Pero no deberíamos dejar pasar nuestras oportunidades en ese 3 % crítico.»

Y unas líneas antes, el párrafo que nadie cita y que es el que importa aquí:

«A menudo es un error hacer juicios a priori sobre qué partes de un programa son realmente críticas, ya que la experiencia universal de los programadores que han usado herramientas de medición es que sus suposiciones intuitivas fallan.»

Knuth no estaba diciendo «no optimices». Estaba diciendo «no optimices lo que no has medido», que es exactamente lo contrario de como se suele usar la cita. Su recomendación explícita era instrumentar el programa, encontrar el 3 % que consume el tiempo y trabajar ahí con todo el cuidado del mundo.

¿Por qué falla la intuición? Por tres motivos concretos:

La consecuencia práctica es una regla de trabajo que vas a aplicar en todo el módulo:

El paso 4 —cambiar una sola cosa— es el que casi todo el mundo se salta, y es el mismo que en depuración: si cambias cinco cosas y mejora, no sabes cuál sirvió, y probablemente cuatro de ellas solo han añadido complejidad. El paso Revertir tampoco es opcional: una optimización que no mejora es deuda técnica pura.

«Rápido» no es un número absoluto: es lo que el sistema perceptivo humano tolera. Hay tres umbrales que conviene tener memorizados porque gobiernan todas las decisiones del módulo.

El de 16,7 ms merece explicación. Una pantalla a 60 Hz se refresca 60 veces por segundo: 1000 / 60 = 16,7 ms por fotograma. En ese tiempo el navegador tiene que ejecutar tu JavaScript, recalcular estilos, hacer el layout, pintar y componer. Si tu manejador de scroll tarda 20 ms, el fotograma no llega a tiempo y se pierde. Y en pantallas de 120 Hz el presupuesto baja a 8,3 ms.

Como el navegador necesita parte de ese tiempo para lo suyo, la regla práctica es dejar menos de 10 ms de JavaScript por fotograma cuando algo se está moviendo.

Traducido a Nómada Tareas, esto ya da tres objetivos concretos antes incluso de medir nada:

• Pulsar «Empezar» en una tarjeta debe verse reflejado en menos de 100 ms.
• El tablero debe estar visible en menos de 1 s con conexión decente.
• Desplazar la columna de pendientes no debe gastar más de 10 ms de JavaScript por fotograma.

Fíjate en el cambio de lenguaje: hemos pasado de «va lenta» a tres afirmaciones falsables. Eso ya es la mitad del trabajo.

Los umbrales del apartado anterior son psicología. Los Web Vitals son la forma estandarizada de medirlos en una página real: un conjunto pequeño de métricas definidas por Google que capturan carga, interactividad y estabilidad visual. Son las que miden Lighthouse, PageSpeed Insights, Search Console y prácticamente cualquier herramienta de monitorización.

Hay tres principales (los Core Web Vitals) y dos complementarios que sirven para diagnosticar.

Cuatro precisiones que evitan la mayoría de los malentendidos:

LCP no es «cuándo carga la página». Es cuándo aparece el elemento más grande del área visible: normalmente la imagen de cabecera, un bloque de texto grande o —en Nómada Tareas— el contenedor .tablero con las primeras tarjetas. Si tu aplicación pinta un esqueleto gris rapidísimo y las tarjetas reales tardan tres segundos, el LCP será malo, y con razón: el esqueleto no es contenido.

INP sustituyó a FID. La métrica antigua, First Input Delay, medía solo el retraso hasta que empezaba a ejecutarse el manejador de la primera interacción; era demasiado benévola. INP mide todas las interacciones de la sesión, de principio a fin —retraso de entrada, ejecución del manejador y pintado del resultado— y se queda con (aproximadamente) la peor. Es la métrica que Nómada Tareas va a suspender: escribir en el buscador dispara un render completo de 600 tarjetas.

CLS no tiene unidad. Es un producto de la fracción de pantalla afectada por la distancia recorrida, acumulado en ventanas de sesión. Un 0,21 significa «el contenido salta de forma claramente perceptible». En Nómada Tareas el culpable es previsible: las tarjetas se insertan cuando llegan los datos y empujan hacia abajo lo que había.

TTFB y FCP no son objetivos, son diagnóstico. No se optimizan por sí mismos: se miran para saber dónde está el problema de LCP. Si TTFB es 1,4 s de los 4,1 s de LCP, el problema es del servidor y no vas a arreglarlo tocando JavaScript.

Una advertencia importante: los Web Vitals miden la experiencia, no la calidad de tu código. Una página con un LCP de 1,2 s puede tener un JavaScript horrible, y una página impecable puede suspender por culpa de una fuente. Son la primera pregunta, no la última.

Vas a ver dos veces la misma métrica con valores completamente distintos, y conviene entender por qué antes de volverte loco.

Que se use el percentil 75 es la clave de por qué no coinciden. Cuando Search Console dice que tu LCP es de 3,8 s, no dice que el usuario medio espere 3,8 s: dice que el 25 % de las visitas esperan más de eso. Tu Lighthouse local puede marcar 1,9 s sin mentir; simplemente estás midiendo el percentil de un usuario con fibra, un portátil potente y la caché caliente.

La regla operativa:

• Campo para saber si hay un problema y a quién le pasa.
• Laboratorio para encontrar la causa y para verificar que un cambio la arregla.

Usar solo laboratorio lleva a optimizar problemas que nadie tiene. Usar solo campo lleva a saber que algo va mal sin poder averiguar qué.

Lighthouse está integrado en DevTools (pestaña Lighthouse), en la línea de comandos (npx lighthouse) y en PageSpeed Insights. Genera un informe de laboratorio con cinco categorías; aquí solo nos interesa Performance.

Por defecto Lighthouse simula un móvil de gama media: estrangula la CPU a 4× más lenta que la tuya y aplica una red lenta. Eso explica por qué la puntuación móvil siempre sale mucho peor que la de escritorio, y por qué la móvil es la que hay que mirar.

Ahora, la parte importante: cómo leer el informe.

1. Ignora el número grande. La puntuación de 0 a 100 es una media ponderada de las métricas, comprimida en una curva log-normal. Subir de 50 a 60 puede ser un cambio enorme o un ruido de medición; y perseguir el 100 lleva a decisiones absurdas. Lo que importa son las métricas individuales.
2. Lee las métricas en la parte superior, con sus colores. Ahí están FCP, LCP, TBT, CLS y Speed Index.
3. TBT (Total Blocking Time) es tu sustituto de INP en laboratorio. Suma, de todas las tareas largas, los milisegundos que exceden de 50 ms. Es lo único que Lighthouse puede decirte sobre interactividad sin que haya un usuario interactuando. Si el TBT es alto, el INP de campo va a ser malo.
4. Baja a Diagnostics y a las oportunidades. Ahí están las acciones concretas, con el ahorro estimado. Trátalas como pistas, no como órdenes: el «ahorro estimado» es un modelo, no una medición.
5. Busca el elemento LCP. El informe lo señala explícitamente. Saber qué elemento es cambia por completo el diagnóstico.
6. Ejecútalo tres veces. Lighthouse tiene una varianza notable. Una sola ejecución no es un dato.
7. Ejecútalo en modo incógnito y sin extensiones. Las extensiones inyectan scripts y falsean el resultado; es el error de medición más común.

Un extracto real del informe de Nómada Tareas con 600 tareas (perfil móvil, tres ejecuciones, mediana):

Ese TBT de 1.240 ms es la señal más fuerte del informe: hay más de un segundo en el que el hilo principal está ocupado y la interfaz no responde. Lighthouse no te dice por qué. Para eso está el panel siguiente.

El panel Performance de DevTools es la herramienta central del módulo. Graba todo lo que hace el navegador durante un intervalo y lo presenta en una línea de tiempo. Es intimidante la primera vez; con un procedimiento fijo deja de serlo.

Procedimiento de grabación

1. Abre la aplicación en una ventana de incógnito (sin extensiones).
2. Abre DevTools → pestaña Performance.
3. Marca Screenshots y activa el estrangulamiento: CPU: 4× slowdown y, si la carga te interesa, Network: Slow 4G.
4. Para medir la carga: pulsa el botón de recarga con círculo (Start profiling and reload page). Para medir una interacción: pulsa el círculo de grabar, haz la interacción, y para en cuanto acabe.
5. Graba poco. Tres segundos de grabación son analizables; treinta, no.

Cómo leer lo grabado, de arriba abajo:

El diagrama de llamas (flame chart) del carril Main se lee así: el eje horizontal es el tiempo; cada barra es una llamada a función; una barra debajo de otra es una función llamada por la de arriba. La anchura es el tiempo total (propio + descendientes). Los colores tienen significado fijo:

Las tareas largas son lo primero que hay que buscar. Una tarea es una unidad de trabajo que el bucle de eventos (05-07) ejecuta sin interrupción; si dura más de 50 ms se considera larga y DevTools la marca con un triángulo rojo en la esquina y una franja roja rayada. Mientras dura, el navegador no puede atender clics ni pintar. Esa es la traducción visual exacta de lo que estudiaste en 05-07: un bucle pesado congela la interfaz, y await no lo arregla.

Bottom-Up frente a Call Tree. Selecciona un intervalo en la línea de tiempo y mira las pestañas de abajo:

La distinción self time / total time es la que más confunde al principio. Total incluye lo que tarda todo lo que la función llama; self es solo el tiempo dentro de su propio cuerpo. render() puede tener un total de 310 ms y un self de 2 ms: no es que render sea lenta, es que llama a algo que lo es. Bottom-Up ordenado por self time es la vista que encuentra al culpable.

Al abrir la primera grabación de Nómada Tareas con 600 tareas, ordenando Bottom-Up por self time, aparece esto:

Eso ya no es «va lenta»: es «600 llamadas a pintarTarjeta cuestan 186 ms de tiempo propio, y hay 41 recálculos de estilo donde debería haber uno». Las lecciones 09-02 y 09-04 atacan exactamente esas filas.

Ya usaste Network en 08-01 para depurar peticiones. Aquí lo usas para otra cosa: saber cuánto se descarga, en qué orden y qué está bloqueando el renderizado.

Cuatro columnas que hay que mirar siempre:

Y tres ajustes de la barra superior:

• Disable cache: obligatorio para medir la primera visita. Sin esto mides tu caché, no la de tus usuarios.
• Throttling de red: Slow 4G es el perfil realista para móvil.
• Estrangulamiento de CPU: está en la pestaña Performance y en Rendering; 4× slowdown aproxima un móvil de gama media, 6× uno modesto.

Al pie del panel, la barra de resumen da el dato que importa para 09-05: peticiones, kB transferidos, kB de recursos y tiempos de DOMContentLoaded y Load. Para Nómada Tareas, con módulos ES sin empaquetar (05-04), esa barra dice hoy:

Treinta y una peticiones porque cada módulo ES es un fichero (07-05 ya lo avisó al escribir la lista de precaché). Ese número es un problema de 09-05, no de hoy; hoy solo lo anotamos.

Las herramientas anteriores miden la página. Para medir tu código —una función concreta, una fase concreta— hay que instrumentarlo.

Date.now() devuelve milisegundos enteros desde 1970 y puede saltar hacia atrás si el reloj del sistema se ajusta. performance.now() devuelve milisegundos desde que se abrió la página, es monótono (nunca retrocede) y tiene resolución de fracción de milisegundo (reducida deliberadamente por seguridad: en la práctica, granularidad de decenas de microsegundos).

console.time/console.timeEnd valen para un vistazo rápido, pero solo salen por consola. La User Timing API hace algo mucho mejor: las medidas aparecen en el panel Performance, en un carril propio (Timings), alineadas con el diagrama de llamas.

Tres detalles del código que conviene entender:

• performance.measure devuelve el objeto PerformanceMeasure desde hace años, así que no hace falta buscarlo con getEntriesByName.
• El finally garantiza que la medición se cierra aunque la función lance una excepción; sin él, una marca huérfana rompe la siguiente medida.
• La limpieza importa: el búfer de entradas de rendimiento tiene un tamaño limitado y las marcas viejas desplazan a las nuevas.

Instrumentando TableroVista.render con esto y grabando con el panel abierto, el carril Timings muestra una barra render de 310 ms perfectamente alineada con el bloque amarillo del hilo principal. Ya no hay que adivinar qué parte del diagrama de llamas es tuya.

Con fases anidadas obtienes el desglose sin tener que interpretar el diagrama de llamas:

Deja la instrumentación fuera de producción o detrás de una bandera. Las marcas cuestan poco, pero los console.log dentro de bucles cuestan muchísimo, y además falsean la propia medición.

Para el dato de campo hay que recoger métricas de usuarios reales. La API base es PerformanceObserver, que notifica entradas de rendimiento según se producen.

Dos detalles nada obvios:

• buffered: true entrega también las entradas ocurridas antes de crear el observador. Sin eso te pierdes el LCP, que suele suceder antes de que tu script se ejecute.
• El LCP cambia a medida que se pinta contenido mayor. El valor definitivo es el último antes de que el usuario interactúe o la página se oculte.

Implementar bien LCP, INP y CLS a mano es sorprendentemente delicado (ventanas de sesión de CLS, agrupación de eventos de INP, páginas restauradas desde la caché de retroceso…). Para producción se usa la librería oficial web-vitals, que pesa poco más de 2 kB:

Con eso, y agregando en el servidor por percentil 75, Taller Nómada tendría el dato de campo. Recuerda: CLS e INP solo se conocen del todo al final de la visita, por eso sendBeacon (que la API de fetch con keepalive imita) es la forma correcta de enviarlos.

En 07-07 ya escribiste una función medir para comparar JavaScript con WebAssembly, y ya usaste dos de las reglas: calentamiento y mediana. Toca formalizarlas, porque el resto del módulo depende de que tus mediciones signifiquen algo.

Aquí está la utilidad completa que usaremos en todo el módulo:

El p95 merece un comentario: la mediana dice cómo va normalmente, el p95 dice cómo va en el 5 % de peores casos. Para el rendimiento percibido, el p95 a menudo importa más, porque es el que produce el tirón que el usuario recuerda.

Y una regla de oro que ahorra discusiones enteras: si la diferencia entre dos variantes es menor que la variabilidad de tu propia medición, no hay diferencia. Si la mediana es 12 ms y el rango va de 9 a 18 ms, una «mejora» a 11,4 ms es ruido.

Tu portátil de desarrollo tiene un procesador rápido, mucha RAM, disco SSD, conexión por cable y la caché caliente. Tus usuarios, no. La diferencia entre un portátil de desarrollo y un móvil de gama media típico está en torno a 4–6× en CPU de un solo hilo, y es todavía mayor en un móvil de gama baja de hace cuatro años.

Traducido: esos 310 ms de render() que mides tú son más de un segundo y medio en el móvil desde el que Iván consulta el tablero cuando está fuera del taller.

Cómo simularlo:

Dos avisos honestos sobre el estrangulamiento de CPU: es una simulación (ralentiza la ejecución de forma uniforme, mientras que un móvil real también tiene menos caché, memoria más lenta y limitación térmica), y no ralentiza la red ni el disco. Es una aproximación útil, no una verdad. Si tu producto es importante, prueba en un dispositivo real de gama media con depuración remota; es la única medida que no discute nadie.

Y la consecuencia metodológica: todas las cifras de este módulo están medidas en una máquina concreta —un portátil de desarrollo con estrangulamiento de CPU 4× y red Slow 4G, Chrome en modo incógnito— y sirven para ilustrar proporciones y órdenes de magnitud, no como valores universales. En tu equipo saldrán otros números. Lo que no cambiará es la conclusión: 600 llamadas a pintarTarjeta cuestan tres órdenes de magnitud más que un sort.

Ya tenemos método y herramientas. Vamos a establecer el número de partida de todo el módulo.

Primero, los datos. Necesitamos un tablero de 600 tareas realista y reproducible: si cada ejecución genera datos distintos, las mediciones no son comparables. Un generador con semilla fija lo resuelve.

Con la misma semilla, siempre las mismas 600 tareas. Eso es lo que permite comparar la medición de hoy con la de dentro de cuatro lecciones.

Y esta es la línea base, medida con el procedimiento del apartado 10 (mediana de 15 repeticiones tras 5 de calentamiento, CPU 4×, Slow 4G, incógnito, en el portátil de referencia):

Diez números. Ninguna opinión. Esta tabla es el contrato del módulo: la última lección la repetirá con la columna «después».

Fíjate en que la tabla también contiene un diagnóstico implícito: hay cuatro problemas distintos —código que tarda, memoria que se retiene, DOM que se maltrata y descarga excesiva— y cada uno tiene su lección. Eso no se sabía antes de medir; era perfectamente posible que todo fuera un único problema de red.

Una medición puntual se degrada. Dentro de tres meses alguien añadirá una librería de gráficos de 90 kB y nadie se dará cuenta hasta que un usuario se queje. Un presupuesto de rendimiento es un conjunto de umbrales que, al superarse, rompen la compilación: exactamente igual que una prueba de Jest que falla en 08-03.

Hay tres tipos de presupuesto y conviene tener de los tres:

Lighthouse CI hace lo de en medio con muy poca configuración:

Tres decisiones de ese fichero que no son cosméticas:

• numberOfRuns: 3. Aplica la regla de repetir; Lighthouse CI se queda con la mediana.
• error frente a warn. Solo lo que estás dispuesto a bloquear va como error. Un presupuesto que rompe la compilación todos los días acaba desactivado.
• "uses-responsive-images": "off". Desactivar explícitamente lo que no aplica es mejor que ignorarlo: deja constancia de la decisión.

Y el paso en el flujo de trabajo de GitHub Actions, siguiendo el mismo orden barato-primero de 08-06:

Dos advertencias importantes sobre medir rendimiento en CI. La primera: los ejecutores compartidos son ruidosos; sus tiempos varían mucho más que tu máquina, así que pon los umbrales con margen y desconfía de una regresión de un 5 %. La segunda: los presupuestos de cantidad (kilobytes, número de peticiones, número de módulos) son mucho más estables que los de tiempo, y por eso son la primera línea de defensa. Los verás aplicados en 09-05.

• Optimizar sin medir. Es el error madre. Produce código más complicado, a veces más lento, y siempre más difícil de mantener.
• Medir una sola vez. Una medición es una anécdota. Mínimo siete repeticiones, y mediana.
• Usar la media en lugar de la mediana. Una sola pausa del recolector de basura la dispara y te lleva a una conclusión falsa.
• Medir sin calentamiento. La primera ejecución no está optimizada por el JIT y puede ser diez veces más lenta.
• Medir con extensiones activas. Inyectan scripts y observadores. Mide siempre en incógnito.
• Medir con la caché caliente. Sin Disable cache estás midiendo tu segunda visita, no la primera de tu usuario.
• Medir solo en tu portátil. Estrangula la CPU al menos 4×, o estarás optimizando para ti.
• Perseguir el 100 de Lighthouse. La puntuación es una media ponderada comprimida; los últimos puntos cuestan muchísimo y no aportan nada perceptible.
• Confundir laboratorio con campo. Si tu Lighthouse dice 1,9 s y Search Console dice 3,8 s, ninguno miente: uno es tu máquina y el otro el percentil 75 de la realidad.
• Optimizar el TTFB tocando JavaScript. TTFB es del servidor. Diagnostica antes de actuar.
• Cambiar cinco cosas a la vez. Si mejora, no sabrás cuál sirvió; si empeora, tampoco.
• Dejar los console.log de instrumentación en producción. Cuestan, y dentro de un bucle cuestan muchísimo.
• Consejo: guarda las grabaciones. El panel Performance permite exportar la traza como .json. Guarda la del «antes»: es la única forma de comparar de verdad.
• Consejo: mira siempre el self time en Bottom-Up. El total time señala al que llama; el self time señala al culpable.
• Consejo: escribe el objetivo antes de medir. «Que el filtrado responda en menos de 200 ms» es una meta; «que vaya más rápido» no.
• Consejo: si una optimización no mejora la medición, revierte. Complejidad sin beneficio es deuda pura.

Ejercicio 1 — El diagnóstico de tres frases. Marta dice «va lenta», Iván «al escribir se atasca» y Lucía «tarda en cargar». Para cada frase, indica: (a) qué Web Vital la captura, (b) qué herramienta usarías para confirmarla, (c) qué ajuste de estrangulamiento aplicarías y (d) qué medida concreta de la tabla de línea base corresponde. Después explica por qué las tres frases no pueden arreglarse con el mismo cambio.

Ejercicio 2 — Un banco de pruebas honesto. Usando banco() del apartado 10, escribe un script que compare dos formas de calcular las horas abiertas de las 600 tareas: (a) tareas.filter(t => t.estaAbierta()).reduce((s, t) => s + t.horasEstimadas, 0) y (b) un único for con acumulador. Ejecuta con 5 de calentamiento y 15 repeticiones, y responde con honestidad: ¿hay diferencia significativa? Justifica la respuesta con los números de mediana y p95, y di qué versión pondrías en el código.

Ejercicio 3 — Presupuesto para el buscador. El INP al escribir en el buscador es de 480 ms. Escribe (a) el objetivo numérico y su justificación perceptiva, (b) el fragmento de instrumentación con performance.mark/measure que mediría exactamente el trayecto «pulsación de tecla → tablero repintado», y (c) una aserción de Lighthouse CI que rompa la compilación si la interactividad se degrada. Explica por qué la aserción no puede usar directamente INP.

Solución 1

No pueden arreglarse con el mismo cambio porque suceden en momentos distintos y tienen causas distintas: la de Lucía ocurre antes de que se ejecute una línea de tu código de render —es un problema de cuánto se descarga y en qué orden (09-05)—, mientras que la de Iván ocurre con todo ya cargado y es puro trabajo del hilo principal (09-02 y 09-04). Optimizar el paquete no arreglará el atasco al escribir, y trocear el render no hará que la primera carga sea más rápida. La de Marta es la percepción agregada de las otras dos y desaparecerá cuando desaparezcan ambas.

Solución 2

Resultado en el portátil de referencia (sin estrangulamiento, porque aquí comparamos código, no experiencia):

No hay diferencia significativa a efectos prácticos. Sí, el for es un 1,6× más rápido en la mediana, pero la diferencia absoluta es de 0,023 ms: veinte microsegundos, frente a los 310 ms que cuesta el render de la misma pantalla. Es 13.000 veces menos que el problema real. Además, el rango de las mediciones (0,052–0,094 frente a 0,031–0,071) se solapa parcialmente, señal de que hay ruido del mismo orden que el efecto.

Yo pondría filter/reduce en el código: se lee mejor, expresa la intención y su coste es irrelevante. Este ejercicio es, precisamente, la demostración experimental de por qué el mito «for es más rápido que los métodos de array» no debe guiar decisiones de diseño. Volveremos a él en 09-02 con la tabla completa de mitos.

Solución 3

(a) Objetivo: INP ≤ 200 ms, y dentro de eso el trayecto tecla → repintado ≤ 100 ms. La justificación es el umbral perceptivo del apartado 2: por debajo de ~100 ms la respuesta se siente instantánea; 200 ms es el límite que la métrica INP considera «bueno» porque incluye también el retraso de entrada y el pintado, que no controlas del todo.

(b) Instrumentación. La clave es que la medida no puede acabar cuando termina render(): tiene que acabar cuando el navegador ha pintado. Eso se consigue con un requestAnimationFrame anidado (07-06): el primero se ejecuta antes del pintado, el segundo justo después.

(c) Aserción de CI:

INP no se puede usar directamente porque es una métrica de campo: necesita que un usuario real interactúe, y en Lighthouse CI nadie interactúa. Lo que sí se puede vigilar es el TBT, que mide el tiempo total en que el hilo principal está bloqueado y que correlaciona bien con un INP malo: si no hay tareas largas, no hay forma de que una interacción tarde 480 ms. Para vigilar el INP de verdad hace falta el web-vitals del apartado 9 enviando datos desde producción, con alerta si el percentil 75 supera los 200 ms.

Has cambiado el punto de partida de todo el módulo. «Nómada Tareas va lenta» ya no es una frase: es una tabla de diez números medidos con un procedimiento repetible sobre un tablero de 600 tareas generado con semilla fija.

Sabes por qué la intuición falla y qué decía Knuth de verdad: no «no optimices», sino «no optimices lo que no has medido, porque las suposiciones intuitivas de los programadores fallan». Conoces los umbrales que definen «rápido» para una persona —100 ms para sentir respuesta, 1 s para no perder el hilo, 16,7 ms por fotograma a 60 Hz, con menos de 10 ms de JavaScript dentro— y sabes traducirlos a objetivos falsables.

Dominas los Web Vitals: LCP (2,5 s) como medida de cuándo aparece el contenido principal, INP (200 ms) como medida de todas las interacciones de la sesión —no solo la primera, como el antiguo FID—, CLS (0,1) como medida de estabilidad visual, y TTFB y FCP como instrumentos de diagnóstico que dicen dónde está el problema de LCP. Y entiendes por qué tu Lighthouse local y los datos de campo nunca coinciden: uno es tu máquina con caché caliente, el otro el percentil 75 de móviles reales en redes reales.

Tienes el instrumental completo: Lighthouse leído por métricas y no por puntuación, con el TBT como sustituto de laboratorio del INP; el panel Performance con su procedimiento fijo —incógnito, estrangular, grabar poco— y su lectura por capas, con las tareas largas marcadas en rojo y la distinción entre Call Tree (quién lo provocó) y Bottom-Up ordenado por self time (quién lo consume); el panel Network con Disable cache y Slow 4G; la User Timing API con performance.mark/measure para que tus propias fases aparezcan en la línea de tiempo; y PerformanceObserver con la librería web-vitals y sendBeacon para el dato de campo. Y sabes hacer un benchmark honesto: calentar, repetir, mediana y p95, comparar contra una referencia, cambiar una sola variable, y descartar como ruido toda diferencia menor que la variabilidad de la propia medición.

Sobre todo, tienes el contrato del módulo: 4,1 s de LCP, 480 ms de INP, 0,21 de CLS, una tarea larga de 1.180 ms, 310 ms de render, 96 ms de recálculos, 940 ms de informe bloqueante, 37,7 MB retenidos, 7.812 nodos y 214 kB en 28 peticiones. Con su presupuesto de rendimiento correspondiente y un lhci autorun que rompe la integración continua cuando alguien lo incumple, porque un presupuesto que nadie vigila deja de existir en tres meses.

La tabla también reparte el trabajo. Las filas 2, 4, 6 y 7 —INP, tarea larga, recálculos y el informe de 940 ms que congela la pantalla— son código tuyo que tarda demasiado en ejecutarse: algoritmos con el coste equivocado, cálculos repetidos que podrían hacerse una vez, manejadores que se disparan sesenta veces por segundo y un trabajo pesado que se obstina en ocupar el único hilo que pinta la interfaz. Ahí está la mayor parte del segundo perdido, y ahí empieza la siguiente lección: Optimización del Rendimiento de JavaScript, donde verás cómo trabaja el motor por dentro lo justo para no sabotearlo, cambiarás una búsqueda cuadrática por un índice con Map, pondrás una caché bien invalidada en Tablero, aprenderás cuándo toca debounce y cuándo throttle, trocearás el trabajo largo para dejar respirar al bucle de eventos y, por fin, sacarás el informe de planificación del hilo principal metiéndolo en un Web Worker. Todo ello con la misma disciplina: medición antes, medición después, y revertir lo que no mejore.