Joan León Una auditoría de web performance tiene dos fases con naturalezas muy distintas. La primera es recopilar datos: medir LCP, CLS, INP, TTFB, analizar recursos, detectar antipatrones. La segunda es interpretar esos datos: identificar qué problemas importan más, explicar el mecanismo detrás de cada uno y proponer soluciones priorizadas por impacto.
La IA ayuda en ambas fases, pero de formas completamente distintas. Confundirlas lleva a resultados poco fiables.
La medición no improvisa
En artículos anteriores hablé de los Agent SKILLs de WebPerf Snippets y de los retornos estructurados para agentes. La idea central es que el agente no genera JavaScript en el momento: lee un script predefinido, testado y validado, y lo ejecuta vía Chrome DevTools MCP.
skills/webperf-core-web-vitals/
├── SKILL.md
└── scripts/
├── LCP.js # Retorna { value, rating, element, url }
├── CLS.js # Retorna { value, rating, sources[] }
├── INP.js # Retorna { value, rating, interaction }
└── ...
El resultado de LCP.js no es texto de consola formateado para un humano. Es un objeto JSON estructurado que el agente procesa directamente:
{
"metric": "LCP",
"value": 3840,
"rating": "needs-improvement",
"element": "IMG",
"url": "https://cdn.perf.reviews/hero.jpg",
"renderTime": 3840,
"loadTime": 2100
}
El agente sabe que rating: "needs-improvement" activa el workflow de LCP. Ese workflow le dice que el siguiente paso es ejecutar LCP-Sub-Parts.js para desglosar el tiempo en TTFB, load delay, load time y render delay. La lógica de decisión está en el SKILL, no en el LLM.
Esto importa porque una medición que varía según cómo el modelo interprete el código ese día no es una medición. Es una estimación. En diagnóstico de rendimiento, necesitamos la primera.
Del dato al diagnóstico
Con las métricas recogidas de forma fiable, empieza el trabajo donde la IA sí tiene libertad: interpretar, conectar y priorizar.
El agente recibe, por ejemplo, estos resultados tras analizar una página de producto:
{
"LCP": { "value": 4200, "rating": "poor", "element": "IMG" },
"CLS": { "value": 0.08, "rating": "needs-improvement" },
"INP": { "value": 180, "rating": "good" },
"TTFB": { "value": 820, "rating": "poor" },
"render_blocking": ["fonts.googleapis.com/css2", "vendor.min.css"],
"preload_async_conflicts": 3
}
A partir de aquí, la IA no está midiendo: está razonando. El TTFB elevado explica parte del LCP malo. Los recursos render-blocking añaden latencia antes de que empiece a pintar. Los conflictos preload + async generan presión de prioridad en recursos que no la merecen. El CLS elevado probablemente está relacionado con los recursos de fuentes bloqueantes.
Este tipo de análisis cruzado, donde un dato explica otro, es exactamente donde un agente bien contextualizado aporta valor real: conecta información dispersa y genera un diagnóstico coherente que de otra forma requiere varias iteraciones manuales.
El prompt para este paso es sencillo:
Analiza los resultados de auditoría de https://perf.reviews/products/item-123
y genera un informe con los problemas encontrados, ordenados por impacto en
la experiencia de usuario, con una solución concreta para cada uno.
El agente tiene los datos estructurados, los umbrales de los SKILLs como referencia y el contexto de cómo se relacionan las métricas entre sí. El informe resultante no es genérico: es específico a los datos de esa página.
El flujo de auditoría completo
Con Claude Code o Gemini, Chrome DevTools MCP y los WebPerf SKILLs instalados, el flujo completo de una auditoría pasa de ser una serie de acciones manuales dispersas a un proceso que el agente ejecuta de principio a fin:
1. Navegar a la URL (navigate_page)
2. Medir Core Web Vitals → ejecutar LCP.js, CLS.js, INP.js
3. Si LCP > umbral → ejecutar LCP-Sub-Parts.js
4. Si TTFB > umbral → ejecutar TTFB-Sub-Parts.js
5. Analizar recursos → ejecutar Render-Blocking.js, Preload-Async-Conflicts.js
6. Recopilar todos los resultados JSON
7. Generar informe con diagnóstico, priorización y soluciones concretas
8. Exportar en el formato necesario (markdown, PDF, Slack)
Los pasos 1 al 6 son determinísticos: el agente ejecuta scripts fijos. Los pasos 7 y 8 son donde la IA genera contenido a partir de datos fiables. La separación no es arbitraria: garantiza que el informe final refleja lo que realmente hay en la página, no lo que el modelo cree que podría haber.
El formato de salida del informe es donde más libertad tiene el agente. El mismo conjunto de métricas puede convertirse en un documento técnico para el equipo de ingeniería, un resumen ejecutivo para negocio, o una alerta en Slack cuando una métrica cruza un umbral. El contenido es el mismo; la presentación la adapta el agente a quien lo lee.
Test de regresión: de la auditoría puntual a la monitorización continua
Una auditoría puntual captura el estado de una página en un momento dado. El valor real llega cuando esa auditoría se convierte en una línea base contra la que comparar cambios futuros.
El flujo de regresión parte del mismo conjunto de scripts determinísticos:
1. Auditoría inicial → guardar métricas como baseline (baseline.json)
2. Tras cada despliegue → ejecutar los mismos scripts sobre el mismo entorno
3. Comparar nuevos valores con baseline
4. Si hay una regresión en alguna métrica → identificar qué cambió y en qué dirección
5. Generar alerta con diagnóstico del cambio
El punto clave está en el paso 4. El agente no se limita a detectar que el LCP empeoró de 2.1s a 3.8s: cruza esa información con los cambios recientes (git log, PR recientes, despliegues) y genera un diagnóstico del tipo “el LCP empeoró 1.7s tras introducir un nuevo recurso de fuente sin font-display: swap en el commit abc123”.
// baseline.json
{
"url": "https://perf.reviews/",
"date": "2026-03-01",
"metrics": {
"LCP": 2100,
"CLS": 0.04,
"INP": 120,
"TTFB": 380
}
}
// audit-2026-03-23.json
{
"url": "https://perf.reviews/",
"date": "2026-03-23",
"metrics": {
"LCP": 3800,
"CLS": 0.04,
"INP": 125,
"TTFB": 390
},
"regressions": [
{
"metric": "LCP",
"baseline": 2100,
"current": 3800,
"delta": "+1700ms",
"severity": "critical"
}
]
}
El prompt para el análisis de regresión:
Compara la auditoría actual de https://perf.reviews con el baseline en
baseline.json. Identifica regresiones, estima su impacto en Core Web Vitals
y sugiere qué cambios recientes pueden haberlas causado.
Este enfoque convierte la auditoría en un proceso continuo: no una revisión trimestral, sino una verificación automática que actúa como red de seguridad antes de que un problema llegue a producción.
La IA como auditor junior que nunca improvisa las mediciones
Hay una distinción que vale la pena hacer explícita: el agente no reemplaza el criterio de quien hace la auditoría. Reemplaza las partes repetitivas y mecánicas que consumen tiempo sin añadir valor analítico.
Navegar a ocho URLs distintas y ejecutar los mismos scripts en cada una es trabajo mecánico. Detectar que en cuatro de ellas hay conflictos preload + async y que todos vienen del mismo origen es trabajo analítico que el agente hace bien cuando tiene datos fiables. Decidir si la solución es eliminar los preloads o añadir fetchpriority="low" según el rol de esos recursos en cada página específica es trabajo de quien conoce el producto.
La combinación de Gemini CLI con Chrome DevTools MCP para debugging de Long Tasks sigue la misma lógica: el agente conecta al navegador directamente, no improvisa sobre gráficos visuales. Los Source Maps le dan el contexto del código fuente para que el diagnóstico sea preciso. El criterio de qué fix aplica sigue siendo humano.
La IA acelera la recopilación de datos y la generación de informes. La interpretación de qué importa más en el contexto de cada producto sigue requiriendo conocimiento del dominio. Con las herramientas correctas, quien hace la auditoría dedica el tiempo al análisis y priorización, no a ejecutar scripts repetitivos.
Conclusión
Separar la medición (determinística, basada en scripts) del análisis (contextual, generado por IA) es la distinción que hace que este enfoque funcione. Los scripts garantizan que el agente mide lo mismo cada vez, de la misma forma, independientemente del modelo o la sesión. Los datos estructurados que producen son la entrada que permite al agente razonar sobre ellos con precisión.
El test de regresión continuo es la extensión natural: una vez tienes un baseline fiable y scripts reproducibles, automatizar la comparación es trivial. El agente pasa de herramienta de auditoría puntual a sistema de alerta temprana.
Los WebPerf SKILLs están disponibles vía npx -y skills add nucliweb/webperf-snippets. El repositorio del workshop de debugging con Gemini está en nucliweb/webperf-debugging-devtools-mcp.
Si quieres que implementemos este flujo en tu producto, en perf.reviews hacemos auditorías de web performance con este mismo enfoque.