Rendimiento y Core Web Vitals
La página Rendimiento mide los Core Web Vitals reales (PageSpeed Insights), muestra datos CrUX de usuarios reales, diagnósticos Lighthouse por página y genera el ticket de desarrollo.
La página Rendimiento (menú lateral Análisis del sitio → Rendimiento) mide la velocidad real de tu sitio con los Core Web Vitals de Google y convierte el diagnóstico en indicaciones accionables para el desarrollador. Se alimenta del SEO audit: cada escaneo muestrea algunas páginas y mide su rendimiento; mientras un audit está en curso, la página muestra el progreso en tiempo real. La pestaña Core Web Vitals del informe muestra solo la tabla resumen, con un botón para abrir esta página.
Plan necesario: incluido con el SEO Audit desde el plan Solo en adelante. La generación de tickets de desarrollo tiene un presupuesto mensual independiente (ver la tabla abajo).
Cómo se miden los Core Web Vitals
Los datos son mediciones reales de Google PageSpeed Insights (Lighthouse móvil), no estimaciones: cada audit muestrea la home + una página por tipo/ruta, hasta el tope del plan, y mide Performance score, CLS, LCP y TBT para cada una.
| Plan | Páginas muestreadas por audit |
|---|---|
| Solo | 3 |
| Starter | 5 |
| Pro | 10 |
| Agency | 20 |
Qué mide cada columna, y los umbrales con los que la app los colorea (verde = bien, amarillo = mejorable, rojo = deficiente):
| Métrica | Qué mide | Bien | Deficiente |
|---|---|---|---|
| Performance score | Puntuación global de Lighthouse (0-100) | ≥ 90 | < 50 |
| LCP — Largest Contentful Paint | Tiempo de renderizado del elemento visible más grande | ≤ 2500 ms | > 4000 ms |
| CLS — Cumulative Layout Shift | Cuánto se desplazan los elementos durante la carga | ≤ 0,1 | > 0,25 |
| TBT — Total Blocking Time | Cuánto tiempo permanece bloqueado el hilo principal y sin responder a la entrada | ≤ 200 ms | > 600 ms |
| INP — Interaction to Next Paint | Capacidad de respuesta a la entrada real (solo tarjeta CrUX) | ≤ 200 ms | > 500 ms |
| TTFB — Time To First Byte | Cuánto tarda el servidor en responder (columna de diagnóstico LCP) | ≤ 600 ms | por encima: hosting/caché |
Las puntuaciones de Lighthouse pueden variar entre audits aunque el sitio no haya cambiado (hasta un 20-30%): es la variabilidad normal de las pruebas de laboratorio, documentada por Google. Fíjate en la tendencia a lo largo de los audits, no en el número aislado.
Experiencia real de usuario (Chrome UX Report)
Si el sitio tiene suficiente tráfico, aparece una tarjeta con datos CrUX: LCP, INP y CLS en el percentil 75, medidos en visitantes reales de Chrome durante los últimos 28 días, con un veredicto Bien / Mejorable / Deficiente. A diferencia de las puntuaciones de Lighthouse son estables, y son las que usa Google para el ranking. La insignia “todo el sitio” significa que la página individual no tiene suficiente tráfico y el dato se refiere a todo el dominio.
Diagnóstico Lighthouse por página
Debajo de las métricas encontrarás los diagnósticos en bruto de Lighthouse por página muestreada: un mapa de layout-shift (captura de la página muestreada con los desplazamientos más visibles, con recuadros sobre los elementos que se mueven durante la carga — un borde discontinuo alrededor de toda la página indica un reflow global, p. ej. por fuentes web, con las zonas causantes resaltadas en sólido), el diagnóstico LCP, los elementos que causan CLS con una columna Causa (imagen sin dimensiones, fuente web, iframe inyectado — etiquetas en inglés, tal como las proporciona Lighthouse), las fuentes no optimizadas (FOUT), las imágenes sin dimensiones y los recursos que bloquean el renderizado.
La tabla de diagnóstico LCP muestra, para cada página muestreada, qué elemento es el visible más grande (el que determina el LCP), sus fases de carga — la fase dominante indica dónde actuar: un TTFB alto = servidor o caché, Load Delay = elemento descubierto tarde o con lazy-load, Render Delay = CSS o fuentes bloqueantes — y el tiempo de respuesta del servidor. Solo aparece para audits iniciados después de activarse la función: si no la ves, ejecuta un nuevo audit.
Fuentes no optimizadas (FOUT) lista las fuentes web que causan un Flash of Unstyled Text: la página primero muestra el texto con una fuente de reserva y luego lo cambia al llegar la fuente web, con un salto visible que también puede contar como layout shift. Normalmente se corrige añadiendo font-display: swap y un preload para la fuente, o sirviéndola desde el mismo dominio.
Una tabla vacía no es un error. El valor de CLS y la lista de “elementos que causan CLS” provienen de dos mecanismos independientes de Lighthouse: un CLS alto sin elementos listados es normal, típicamente en páginas con widgets/comentarios/embeds de terceros que Lighthouse no puede atribuir a un nodo específico. Del mismo modo, las tablas vacías de imágenes sin dimensiones o recursos que bloquean el renderizado solo significan que Lighthouse no detectó ninguno en esa muestra.
Generar ticket de desarrollo
Generar ticket de desarrollo convierte el diagnóstico en un ticket en lenguaje sencillo para cada página muestreada, listo para entregar a un desarrollador. El ticket empieza con la causa raíz inferida de las fases de carga y cruza los datos de Lighthouse con el HTML real de la página: indica los archivos y atributos exactos a cambiar (por ejemplo un loading=lazy que eliminar de la imagen principal, o un preload ausente) y adapta el consejo a la plataforma detectada, como el tema o los plugins de WordPress instalados. Es bajo demanda pero se genera una vez por audit (se reactiva al volver a ejecutar el audit), con un presupuesto mensual independiente del muestreo de páginas — el contador es visible debajo del título de la página Rendimiento y en Suscripción:
| Plan | Tickets de Core Web Vitals con IA / mes |
|---|---|
| Solo | 4 |
| Starter | 13 |
| Pro | 40 |
| Agency | 200 |
¿Quieres revisar el informe técnico completo? Vuelve a Ejecuta tu primer SEO audit →
Última actualización: 5 de septiembre de 2026