Qué medir: métricas clave para el rendimiento centrado en el usuario (Que Medir Metricas Clave Para El Rendimiento Centrado EN El Usuario)

Medición del rendimiento centrada en el usuario

La medición del rendimiento centrada en el usuario no se basa en si el sistema genera tráfico o está técnicamente cargado; Analiza si las personas logran sus objetivos de forma rápida, sencilla, fiable y satisfactoria. Los sistemas de medición más potentes leen juntos datos de comportamiento, percepción del usuario, resultados comerciales y desempeño técnico.

1. Métricas de comportamiento del usuario

Estos muestran lo que realmente hacen los usuarios:

• Tasa de finalización de tareas: El porcentaje de usuarios que completaron con éxito una tarea definida.
• Duración de la tarea: El tiempo necesario para alcanzar la meta.
• Tasa de error: Frecuencia de acciones fallidas, errores de validación o errores del sistema.
• Tasa de recuperación de errores: Porcentaje de usuarios que se recuperaron después del error y finalizaron la tarea.
• Adopción de funciones: La tasa a la que los usuarios elegibles utilizan la función en un período determinado.
• Abandono del embudo: Donde los usuarios abandonan el proceso de varios pasos.
• Tiempo de valoración: Tiempo entre el registro o ingreso y el primer resultado significativo.

Las métricas de comportamiento funcionan mejor cuando se vinculan a un objetivo de usuario específico; por ejemplo, "completar el pago" en lugar de simplemente "aumentar los clics". El marco UX de GitLab considera la finalización de tareas, el tiempo de tarea, los errores, la precisión del primer clic y la adopción de funciones como métricas de comportamiento clave. handbook.gitlab

2. Métricas de percepción del usuario

Analytics muestra qué sucede; Las métricas de actitud ayudan a explicar por qué:

• Satisfacción del cliente (CSAT): Qué tan satisfechos quedaron con la experiencia.
• Facilidad de uso percibida: Qué tan fácil se siente el producto al usarlo.
• Puntuación de esfuerzo del cliente (CES): El esfuerzo que creen que han realizado.- Eficiencia percibida: Si el producto ahorra tiempo.
• Net Promoter Score (NPS): Probabilidad de recomendar el producto.
• Utilidad percibida: Si resuelve un problema significativo.

Un producto puede tener una alta tasa de finalización de tareas pero aun así resultar frustrante o innecesariamente difícil. Por lo tanto, las medidas conductuales y actitudinales deben evaluarse juntas. handbook.gitlab

3. Métricas de retención y valor

Estos muestran si el producto proporciona valor continuo:

• Tasa de activación: El porcentaje de nuevos usuarios que completan la primera acción significativa.
• Tasa de retención: El porcentaje de usuarios que regresan y permanecen activos después de un cierto período de tiempo.
• Tasa de abandono: Porcentaje de usuarios que dejan de usar el producto.
• DAU/WAU/MAU: Usuarios activos diarios, semanales y mensuales.
• Adhesividad: Generalmente se aproxima como la relación DAU÷MAU.
• Retención de cohortes: Seguimiento separado de grupos por fecha de registro o característica común.
• Tasa de recomendación: La frecuencia con la que los usuarios recomiendan o invitan a otros.

Una estructura funcional: defina una Métrica North Star que represente el valor entregado al usuario, luego elija dos o tres métricas de entrada en las que los equipos puedan influir. Por ejemplo, un producto de colaboración enumera “colaboraciones semanales exitosas” como su estrella polar; Puede utilizar la activación, la adopción de funciones y la retención como promotores. youtube

4. Métricas de desempeño técnico

En los productos digitales, la velocidad técnica debe medirse desde la perspectiva del usuario:

Experiencia de usuario	Métricas útiles
Primera visibilidad	Primera pintura con contenido (FCP), pintura con contenido más grande (LCP)
Determinación	Cambio de diseño acumulativo (CLS)
Respuesta del servidor	Tiempo hasta el primer byte (TTFB)
Fluidez	Consistencia de fotogramas y respuesta de animación
Fiabilidad	Tasas de fallos, solicitudes fallidas, interrupciones y errores

El rendimiento web debe medirse tanto en pruebas de laboratorio controladas como en monitoreo de usuarios reales (RUM); porque el dispositivo, la red, la personalización y la interacción cambian fundamentalmente la experiencia. web

5. Un conjunto práctico de medidas.

La mayoría de los equipos pueden comenzar con cinco métricas:

1. Una métrica de valor: El resultado principal es el motivo por el que acuden los usuarios.
2. Una métrica de comportamiento: Tasa de finalización de tareas o duración de la tarea.
3. Una métrica de percepción: CSAT, CES o facilidad de uso percibida.
4. Una métrica de retención: Retención o reutilización de cohortes.
5. Una métrica de confiabilidad o rendimiento: Tasa de error, INP, LCP o tiempo de actividad.

Las buenas métricas deben ser claras, normalizadas, comparables a lo largo del tiempo, divididas en grupos de usuarios significativos y procesables. No confíe únicamente en las visitas totales a la página, las descargas, los usuarios registrados o la duración de la sesión; estos pueden crecer sin producir valor significativo. youtube

Ejemplo

Para un servicio de reembolso en línea:

• North Star: Reclamaciones devueltas exitosamente por empleado activo.
• Comportamiento: Tasa de finalización de solicitudes y tiempo medio de envío.
• Percepción: Puntuación de facilidad de uso posterior al envío.
• Retención: Porcentaje de empleados que presentan una segunda solicitud dentro de los 90 días.
• Técnico: Tasa de error e INP durante la carga del enchufe.
• Diagnóstico: Tasa de abandono en el paso de verificación del comprobante.Esta combinación no sólo determina cuántas personas ingresan al proceso; si pudieron completarlo, cómo se sintió la experiencia, si regresaron y si problemas técnicos obstaculizaron el éxito.

Conceptos recurrentes en esta sección```text

📦 Laboratuvar vs saha Kontrollü, tekrarlanabilir teşhis ile gerçek kullanıcı ortamındaki doğrulama.

📦 Core Web Vitals (CWV) LCP, INP ve CLS—yükleme, yanıt ve görsel kararlılık; gerçek kullanıcıların 75. yüzdeliğinde.

📦 FID → INP (Mart 2024) FID yalnızca ilk girdi gecikmesini ölçüyordu; INP ziyaret boyunca etkileşim yanıtını ölçer.

📦 RUM Gerçek kullanıcı izleme: cihaz, ağ, rota ve özellik boyutlarında production ölçümü.

📦 CrUX Chrome kullanıcı deneyimi raporu—uygun siteler için kamuya açık saha verisi.

📦 Performans bütçesi LCP/INP/CLS, JS ağırlığı, üçüncü taraf maliyeti ve iş akışı başarı limitleri.

📦 Attribution (ilişkilendirme) web-vitals attribution build: LCP öğesi, INP hedefi, LoAF ve alt faz süreleri.

## Pruebas de laboratorio y mediciones de campo.

**Las pruebas de laboratorio** en el desempeño centrado en el usuario miden el producto bajo condiciones controladas y repetibles; La **medición de campo** observa el desempeño en el entorno real de los usuarios. Los resultados de laboratorio generalmente son mejores para encontrar la causa del problema; Los resultados de campo permiten comprender mejor si el producto funciona en el uso diario. [web.mit](https://web.mit.edu/6.813/www/sp16/classes/11-experiment-design/)

### Prueba de laboratorio

Las pruebas de laboratorio colocan a los usuarios, tareas, dispositivos y condiciones en un protocolo definido.

Dimensiones típicas:

- Tasa de finalización de tareas.
- Duración del mandato.
- Frecuencia de errores y recuperación.
- Rutas de navegación o clic.
- Precisión del primer clic.
- Disponibilidad y carga de trabajo percibidas.
- Satisfacción post-tarea.
- Comparación entre versiones de diseño.

**Fortalezas:** alto control y repetibilidad; es fácil comparar diseños competidores; aísla problemas específicos de la interfaz; Adecuado para creación de prototipos y experimentos controlados de estilo A/B.

**Límites:** los participantes pueden comportarse de manera diferente porque saben que están siendo observados; las tareas artificiales pueden no reflejar prioridades reales; Una sala de pruebas silenciosa no puede reproducir todos los lugares de trabajo, redes o condiciones técnicas. Lab puede sobreestimar la usabilidad si el contexto real es más desafiante.

Los estudios que comparan pruebas de usabilidad de laboratorio y de campo no encuentran un ganador universal: cuando las condiciones son favorables, los resultados pueden ser similares; Las diferencias surgen en condiciones difíciles, poca disponibilidad o tareas competitivas. [pubmed.ncbi.nlm.nih](https://pubmed.ncbi.nlm.nih.gov/30487113/)

### Mediciones de campoLa medición de campo se realiza donde los usuarios normalmente trabajan, viajan, compran u operan el producto. Puede incluir observación directa, entrevistas contextuales, estudio diario, telemetría remota o pruebas de usabilidad en campo.

Métricas de campo útiles: éxito de la misión en el mundo real; duración, incluidas las interrupciones; condiciones ambientales y de red; diferencias de dispositivo/plataforma; frecuencia y gravedad de los errores; soluciones alternativas; reutilización y retención; retrasos, fallas y solicitudes fallidas; Comentarios de usuarios sobre el cumplimiento del flujo de trabajo.

**Fortalezas:** comportamiento y contexto auténticos; La distracción revela problemas causados ​​por infraestructura o herramientas ambientales; Muestra si el producto está integrado en rutinas reales. Es especialmente valioso en productos móviles, laborales, industriales, sanitarios y basados ​​en la localización.

**Limitaciones:** menos control sobre las variables; difícil comparar directamente a los participantes; los datos pueden ser más ruidosos; Los requisitos de privacidad y consentimiento son más severos.

El campo es fuerte en realismo, el laboratorio es fuerte en precisión y control. [web.mit](https://web.mit.edu/6.813/www/sp16/classes/11-experiment-design/)

### ¿Qué se mide?

| Pregunta | Mediciones de laboratorio | Dimensiones del campo |
|---|---|---|
| ¿Pueden los usuarios completar la tarea? | Tasa de finalización en el escenario definido | Tasa de finalización durante el trabajo real |
| ¿Qué tan eficientemente funcionan? | Duración de la tarea, clics, pulsaciones de teclas | Duración, incluidas interrupciones, transiciones y soluciones alternativas |
| ¿Qué sale mal? | Errores observados e interacciones fallidas | Errores de producción, solicitudes de soporte, tareas abandonadas |
| ¿Cómo se siente? | Satisfacción, carga de trabajo, usabilidad percibida | Satisfacción a largo plazo, confianza, frustración, valor percibido |
| ¿Es confiable? | Tiempo de respuesta controlado y pruebas de dispositivos | Latencia real, variación de conexión, caídas y fallos || ¿Produce valor? | Resultado instantáneo de la misión | Reutilización, retención, adopción y resultados empresariales/usuarios |

### Enfoque recomendado

Utilice los dos como bucles; No elijas solo uno:

1. **Comience en el laboratorio**: encuentre problemas de usabilidad obvios y compare alternativas.
2. **Medir en el campo**: probar el comportamiento en condiciones auténticas.
3. **Regresar al laboratorio**: investigar la causa de problemas importantes en el campo.
4. **Verificar en producción**: con análisis, comentarios y monitoreo del desempeño.
5. **Desglose los resultados**: dispositivo, experiencia, necesidad de accesibilidad, ubicación, conexión y tipo de tarea.

Ejemplo: una aplicación de gastos móvil podría obtener una tarifa de envío del 95 % en el laboratorio. El campo puede revelar interrupciones al fotografiar chips con poca luz o en una red móvil deficiente. Lab indica problema de interfaz; El campo revela las condiciones ambientales y técnicas que lo hacen importante.

Principio básico: **describe la habilidad de laboratorio; El campo valida el rendimiento en el mundo real**. Una evaluación creíble centrada en el usuario normalmente requiere ambas cosas.

## Core Web Vitals: métricas clave

**Core Web Vitals (CWV)** son métricas centradas en el usuario de Google que evalúan tres partes de la experiencia de una página: carga, capacidad de respuesta y estabilidad visual. El conjunto actual es **LCP, INP y CLS**. [web](https://web.dev/articles/vitals)

| Métrica | Que medidas | Buen objetivo |
|---|---|---:|
| **Pintura con contenido más grande (LCP)** | Qué tan rápido aparece el contenido visible principal (imagen principal, título o bloque grande de texto) | ≤ 2,5 segundos |
| **Interacción con la siguiente pintura (INP)** | ¿Qué tan rápida es la respuesta visual a los clics, toques e interacciones del teclado durante la visita? ≤ 200 milisegundos |
| **Cambio de diseño acumulativo (CLS)** | Cuánto contenido visible cambia inesperadamente mientras se carga o utiliza la página | ≤ 0,1 |

### ¿Qué dice cada métrica?- **LCP — cargando:** "¿Pueden los usuarios ver contenido importante rápidamente?"
- **INP — respuesta:** "¿La interfaz responde inmediatamente cuando los usuarios interactúan?"
- **CLS — estabilidad:** "¿Pueden leer y hacer clic en la página sin tener que desplazarse inesperadamente?"

INP reemplaza al **Retraso de la primera entrada (FID)** en 2024: transición oficial **12 de marzo de 2024**. FID midió sólo la interacción inicial; El INP evalúa la respuesta de interacción durante toda la visita. La compatibilidad con FID en las herramientas del navegador se suspendió a partir de septiembre de 2024. [dynatrace](https://www.dynatrace.com/knowledge-base/core-web-vitals/) · [developer.chrome](https://developer.chrome.com/docs/crux/release-notes)

### ¿Cómo se evalúa el CWV?

Datos reales del usuario **75. En porcentaje**, mida por separado para dispositivos móviles y computadoras de escritorio. Para que una página reciba una calificación CWV "buena" general, las tres métricas deben alcanzar el umbral de "buena". [web](https://web.dev/articles/vitals)

Lighthouse y Chrome DevTools son útiles para el diagnóstico de problemas; Los datos de campo del usuario real muestran el rendimiento real en todos los dispositivos, redes y ubicaciones. PageSpeed ​​​​Insights, CrUX y Search Console ayudan a realizar un seguimiento de estos resultados. [web](https://web.dev/articles/vitals)

### Acciones de remediación típicas

- **LCP:** optimiza los elementos visuales, reduce los recursos de bloqueo de renderizado, mejora la respuesta del servidor y prioriza el contenido de la mitad superior de la página.
- **INP:** divide tareas largas de JavaScript, limita el trabajo del hilo principal, acelera los controladores de eventos.
- **CLS:** Asigne espacio para imágenes y anuncios, no agregue contenido encima del contenido existente, corrija fuentes y tamaños.

Los CWV son indicadores técnicos valiosos; pero debe combinarse con resultados centrados en el usuario, como la finalización de tareas, el abandono, la satisfacción y la conversión. Una página rápida no es necesariamente una página útil o exitosa.## Pintura con contenido más grande (LCP)

**LCP mide la rapidez con la que aparece el contenido visible principal después de que el usuario abre una página.** Registra el momento en que se completa la representación de la imagen, fotograma de vídeo o bloque de texto más grande en la ventana gráfica; es un fuerte indicador de la velocidad de carga percibida. [web](https://web.dev/articles/lcp)

### ¿Qué cuenta como LCP?

Elemento LCP a menudo: imagen de héroe o banner; título o bloque de texto destacado; imagen del producto; póster de vídeo o primer fotograma de vídeo visible; Es una imagen grande cargada con CSS.

LCP se diferencia de **First Contentful Paint (FCP)**: FCP mide el primer momento en que aparece cualquier contenido; LCP estima el momento en que el contenido principal se vuelve visible. [web](https://web.dev/articles/lcp)

### Umbrales de LCP

| Resultado LCP | Experiencia |
|---|---|
| **2,5 segundos o menos** | Bueno |
| **Más de 2,5 – 4 segundos** | Debería mejorarse |
| **Más de 4 segundos** | Débil |

**75% de las cargas de página. Considere el porcentaje**, al menos por separado de los dispositivos móviles y de escritorio, para que el resultado sea representativo de la mayoría de los usuarios, no solo del promedio. [web](https://web.dev/articles/lcp)

### ¿Qué causa la lentitud del LCP?

LCP normalmente consta de **cuatro retrasos**:

1. **Retraso en la respuesta del servidor:** El navegador espera la primera respuesta HTML (TTFB).
2. **Retraso en la carga:** El navegador descubre el recurso LCP tarde o comienza a solicitarlo tarde.
3. **Tiempo de carga de recursos:** Las imágenes, videos, fuentes u otro contenido tardan mucho en descargarse.
4. **Retraso en el procesamiento:** La fuente está lista, pero JavaScript, CSS u otros trabajos retrasan el procesamiento en la pantalla. [desarrollador.chrome](https://developer.chrome.com/docs/performance/insights/lcp-breakdown)Según HTTP Archive Web Almanac 2024, en aproximadamente el 73% de las páginas móviles, el elemento LCP es una imagen; El LCP basado en imágenes tiende a ser aproximadamente dos veces más lento que el basado en texto. Desactivar la carga diferida en la imagen LCP de la mitad superior de la página y dar prioridad a la red con `fetchpriority="high"` cuando sea necesario preserva el presupuesto crítico.

### ¿Cómo mejorar el LCP?

- Mejorar la respuesta del servidor; Utilice almacenamiento en caché o CDN efectivo.
- Optimizar y dimensionar correctamente la imagen LCP.
- Utilizar formatos modernos y compresión adecuada.
- Cuando el descubrimiento se retrasa, precargue solo el recurso LCP crítico.
- No cargue de forma diferida la imagen LCP de la mitad superior de la página.
- Elimine el CSS que bloquea el procesamiento y el JavaScript innecesario.
- Reducir las tareas largas del hilo principal.
- Haga que el texto importante aparezca rápidamente al cargar fuentes web.
- Evite redirecciones excesivas y cadenas de solicitudes críticas.

Utilice herramientas de laboratorio como Lighthouse para diagnosticar la causa; Validar la mejora con datos reales de campo del usuario. Una página que se ve bien en las pruebas controladas aún puede producir un LCP deficiente para los usuarios de un dispositivo o red lentos.

## FID, INP y CLS

Estas métricas cubren dos partes diferentes de la experiencia: **capacidad de respuesta** (qué tan rápido responde la página a la entrada) y **estabilidad visual** (si el contenido permanece donde los usuarios esperan que esté).

### Retraso de la primera entrada (FID)

**FID midió el retraso entre la primera interacción del usuario y el navegador comenzó a procesarla.** Solo capturó el retraso de entrada inicial, por ejemplo, entre un toque de botón y el inicio del controlador de eventos.Inicialmente, FID fue útil para detectar páginas bloqueadas por JavaScript; pero no midió la interacción completa ni las interacciones posteriores. FID ahora se retiró como **Core Web Vital y se reemplazó por INP**. [desarrollador.chrome](https://developer.chrome.com/docs/crux/release-notes)

La deficiencia arquitectónica de FID fue que permitió a los desarrolladores mejorar artificialmente la puntuación asincronizando eventos; El usuario podía sentir la página aburrida mientras se ejecutaban tareas largas en segundo plano. El INP cierra este punto ciego.

### Interacción con la siguiente pintura (INP)

**INP mide qué tan rápida es la respuesta visual a las interacciones del usuario durante la visita.** La latencia de entrada incluye el procesamiento del controlador de eventos, el trabajo de renderizado y el tiempo hasta la siguiente actualización de la pantalla. [web](https://web.dev/articles/inp)

Ejemplos: hacer clic en el menú de navegación; escribiendo en el campo de búsqueda; no toques agregar al carrito; abrir un cuadro de diálogo o menú emergente; seleccionando un filtro o pestaña.

| Puntuación INP | Capacidad de respuesta |
|---|---|
| **≤ 200 ms** | Bueno |
| **> 200 – 500 ms** | Debería mejorarse |
| **> 500 ms** | Débil |

Un buen INP es **75% de las visitas reales a la página. porcentaje**: por lo general, los dispositivos móviles y de escritorio se evalúan por separado. [web](https://web.dev/articles/optimize-inp)

INP se divide en tres subfases: **latencia de entrada** (si el hilo principal está ocupado), **tiempo de renderizado** (controladores de eventos pesados), **latencia de presentación** (estilo/diseño/pintura y DOM grande). La optimización depende de qué fase es dominante.

#### Mejorando el INP

- Dividir tareas largas de JavaScript (`scheduler.yield()` o API del programador).
- Reducir JavaScript innecesario y scripts de terceros.
- Mantenga los controladores de eventos pequeños y eficientes.
- Posponer los trabajos no esenciales hasta después de la interacción.
- Evite actualizaciones excesivas de DOM.- Utilizar técnicas eficientes de renderizado y animación.
- Reducir el bloqueo del hilo principal durante la carga de la página.

La API **Long Animation Frames (LoAF)** expone actualizaciones de visualización que superan los 50 ms para diagnosticar INP: marca el código culpable por invocador, tipo de script y `sourceURL`/posición de carácter.

### Cambio de diseño acumulativo (CLS)

**CLS mide el movimiento inesperado del contenido visible.** CLS alto significa que los botones, el texto o las imágenes cambian después de aparecer; los usuarios pueden perder su lugar o hacer clic en el control incorrecto. [web](https://web.dev/articles/cls)

Causas comunes: imagen/vídeo de gran tamaño; publicidad o banner colocado encima del contenido existente; las fuentes de carga diferida cambian el tamaño del texto; notificaciones dinámicas; JavaScript que cambia el diseño una vez que se vuelve visible.

| Puntuación CLS | Estabilidad visual |
|---|---|
| **≤ 0,1** | Bueno |
| **> 0,1 – 0,25** | Debería mejorarse |
| **> 0,25** | Débil |

CLS es una puntuación sin unidades, no una medida de tiempo. Tiene en cuenta tanto la relación de la ventana gráfica afectada como la distancia de desplazamiento. [docs.newrelic](https://docs.newrelic.com/docs/new-relic-solutions/observability-maturity/digital-experience/l2-cwv-cls/)

#### Mejorando CLS

- Dar abierto `width` y `height` a imágenes y videos.
- Destinar espacio para publicidad, embed y contenido dinámico.
- No insertar contenido encima de contenido ya visible.
- Precargar o fijar fuentes importantes.
- Prefiere `transform` y `opacity` en lugar de funciones de diseño en las animaciones.
- Utilice marcadores de posición con las mismas dimensiones que el contenido final.
- Si usas `content-visibility: auto`, reserva espacio con `contain-intrinsic-size` para evitar el desplazamiento.

### Distinción práctica- **FID:** ¿El navegador procesó rápidamente la primera interacción? (histórico)
- **INP:** ¿La página responde rápidamente a las interacciones durante la visita?
- **CLS:** ¿La página es visualmente estable mientras los usuarios leen e interactúan?

Centrarse en **INP y CLS** en los informes actuales de Core Web Vitals; FID es sobre todo significativo cuando se interpretan informes antiguos o datos históricos.

## Más allá de los elementos básicos de la Web

LCP, INP y CLS son obligatorios; pero no explica todos los problemas de rendimiento. Las métricas de apoyo diagnostican las causas; Las métricas de productos y negocios muestran si las mejoras técnicas realmente funcionan para el usuario.

### Interpretar métricas e informes de apoyo

| Métrica | Lo que ayuda a explicar |
|---|---|
| **Primera pintura con contenido (FCP)** | La primera vez que los usuarios ven el contenido de cualquier página |
| **Tiempo hasta el primer byte (TTFB)** | Latencia de respuesta del servidor, la red y el backend |
| **Tiempo total de bloqueo (TBT)** | Bloqueo del hilo principal en pruebas de laboratorio |
| **Índice de velocidad** | Qué tan rápido aparece gradualmente el contenido visible |
| **Peso de soldadura** | JavaScript, CSS, imagen, fuente y tamaño de carga útil de terceros |
| **Misiones largas / LoAF** | JavaScript y fotogramas clave largos que bloquean el hilo principal |
| **Tasa de errores y fallos** | Si fallaron solicitudes, scripts o flujos de trabajo críticos |
| **Transformación, abandono y éxito de la misión** | Si el rendimiento afecta los resultados de los usuarios |

FCP y TTFB son particularmente útiles para diagnosticar LCP: TTFB puede revelar la latencia del servidor, FCP puede revelar bloqueos de procesamiento o problemas de procesamiento prematuro. El TBT es esencialmente un **diagnóstico de laboratorio**; El campo no reemplaza INP. [web](https://web.dev/articles/user-centric-rendimiento-metrics)

Al interpretar informes:1. Comience con datos de campo; Encuentre la página, el dispositivo, la geografía, el navegador y el segmento de usuarios afectados.
2. Mire el percentil 75, no los promedios.
3. Separe “lo que experimentan los usuarios” de “las causas”.
4. Utilice herramientas de laboratorio para reproducir y aislar la causa.
5. No sólo las páginas con la puntuación más baja; Priorice los problemas que afectan los viajes importantes.
6. Plantee hipótesis, realice un cambio específico y vuelva a medir.
7. Verifique que el cambio mejore tanto el rendimiento como el resultado del usuario, como la finalización o la conversión.

No pienses en la puntuación del Lighthouse como el objetivo. El objetivo no es “100”; Son experiencias más rápidas, con mayor capacidad de respuesta y más estables para usuarios reales.

### Arquitecturas de cliente en evolución (breve)

En los SPA, la navegación suave no restablece LCP y CLS puede continuar acumulándose. La **API de navegación suave** experimental detecta la navegación suave bajo la acción del usuario + cambio de URL + condiciones de pintura visibles, lo que abre la puerta a medir LCP intersticial en RUM. La renderización/captación previa con la **API de reglas de especulación** puede acercar el LCP a cero (ejemplo de Ray-Ban en la sección de seguimiento). **sGTM (Administrador de etiquetas del lado del servidor)** reduce el costo del subproceso principal y DNS/TLS para obtener ponderación de etiquetas de terceros desde el navegador, lo que se refleja directamente en INP y LCP.

## Herramientas de laboratorio

### Faro: auditoría de desempeño

Lighthouse ofrece auditorías automatizadas de rendimiento, accesibilidad, SEO, mejores prácticas y funciones de PWA. El informe de desempeño incluye métricas, verificaciones de diagnóstico, oportunidades y enlaces de mejora sugeridos. [desarrollador.chrome](https://developer.chrome.com/docs/devtools/lighthouse)

Utilice el faro para:

- Controles de solicitud de extracción o construcción.
- Comparaciones de referencia reproducibles.
- Detección de fuentes de bloqueo de renderizado.- Encontrar imágenes demasiado grandes y JavaScript no utilizado.
- Investigación de LCP, CLS, FCP, TBT y métricas de laboratorio relacionadas.
- Probar páginas con poco o ningún tráfico en el sitio.

Ejecute con condiciones consistentes: misma URL, emulación de dispositivo, perfil de red, estado de autenticación y repeticiones. Considere tramos individuales ruidosos; Mire las medianas o las tendencias. En Lighthouse CI, `numberOfRuns` (por ejemplo, 3–5) y las aserciones basadas en métricas crean puertas más confiables basadas en el ruido de la puntuación.

### Panel de rendimiento de Chrome DevTools: diagnóstico profundo y asistencia de IA

El panel Rendimiento registra un seguimiento del navegador que incluye actividad de red, trabajo de CPU, ejecución de JavaScript, renderizado, diseño, pintura e interacciones del usuario. Lighthouse es la herramienta que debe utilizar cuando encuentra un síntoma pero necesita encontrar la actividad de bloqueo exacta. [desarrollador.chrome](https://developer.chrome.com/docs/devtools/rendimiento/overview)

Flujo de trabajo práctico:

- Ahorra carga de página o una interacción lenta.
- Busque fases de LCP, solicitudes de bloqueo de renderizado, infractores de cambio de diseño y tareas largas en la vista **Insights**.
- Encuentre el guión, el recálculo de estilo, el diseño o la pintura responsable de la línea de tiempo principal y el gráfico de llamas.
- Asociar la traza con el panel Red y el elemento DOM afectado.
-Volver a guardar después de la corrección.

Chrome DevTools también ofrece asistencia de IA para perfiles de rendimiento guardados. Puede explicar conocimientos seleccionados o realizar un seguimiento de las actividades y sugerir posibles mejoras; Úselo como ayuda para el análisis, verificando cada sugerencia con su seguimiento y código. [developer.chrome](https://developer.chrome.com/docs/devtools/ai-assistance/performance) Los registros LoAF reducen el cuello de botella de INP a la función y la ubicación de los recursos.

### WebPageTest: pruebas realistas y análisis avanzadoWebPageTest es útil para realizar pruebas realistas y avanzadas en ubicaciones, navegadores, dispositivos, perfiles de conexión y ejecuciones repetidas. **Tira de película** lo que ven los usuarios a lo largo del tiempo; **cascada** muestra las dependencias de las solicitudes, la programación, la prioridad y las latencias de los recursos. [rendimiento.shopify](https://rendimiento.shopify.com/blogs/blog/how-to-test-with-webpagetest)

Úselo cuando investigue:

- Rendimiento lento de cierto país o región.
- Dispositivo móvil y comportamiento lento de la red.
- Repetir aparición con la primera aparición.
- CDN, DNS, TLS, servidor y programación de conexiones.
- Descubrimiento visual y priorización de solicitudes.
- Scripts de terceros y cuellos de botella en cascada.
- Progresión visual, no sólo la puntuación final.
- Simulación SPOF de terceros (si la ruta crítica está bloqueada o no cuando el servidor de etiquetas deja de funcionar).

## Herramientas de campo

### Captura de CWV en campo con `web-vitals.js`

La biblioteca `web-vitals` mide Core Web Vitals en el navegador y envía los resultados a su sistema de análisis o de observabilidad. Una aplicación mínima:```html
<script type="module">
  import {onCLS, onINP, onLCP}
    from 'https://unpkg.com/web-vitals@4?module';

  function sendToAnalytics(metric) {
    navigator.sendBeacon('/rum', JSON.stringify({
      name: metric.name,
      value: metric.value,
      id: metric.id,
      path: location.pathname
    }));
  }

  onCLS(sendToAnalytics);
  onINP(sendToAnalytics);
  onLCP(sendToAnalytics);
</script>
```La biblioteca oficial también proporciona una compilación de **atribución**: el elemento o recurso LCP agrega contexto de depuración para INP, como `inputDelay` / `processingDuration` / `presentationDelay`, `interactionTarget` y registros LoAF. Da la coordenada criminal en lugar de la puntuación. [desarrolladores.google](https://developers.google.com/codelabs/chrome-web-vitals-js)

Agregue dimensiones seguras para la privacidad en Producción: plantilla de página y ruta; clase de dispositivo y tipo de conexión; navegador y sistema operativo; país o región; versión; conectado/anónimo; indicador de experimento o característica.

No envíe una URL, ID de usuario, contenido de formulario u otros datos personales a menos que su diseño de privacidad lo permita expresamente.

### CrUX y datos externos

**Informe de experiencia de usuario de Chrome (CrUX)** representa la experiencia de usuarios reales de Chrome elegibles en sitios populares. Proporciona datos de campo para LCP, INP, CLS y otras dimensiones a través de PageSpeed ​​​​Insights, Search Console, CrUX API y BigQuery. [desarrollador.chrome](https://developer.chrome.com/docs/crux)

CrUX es valioso para: realizar evaluaciones comparativas con la web pública; comprobar si los problemas de rendimiento afectan a usuarios reales; verificar si un lanzamiento cambia el desempeño en el campo; comparación entre dispositivos móviles y de escritorio; Tendencias históricas.

CrUX tiene límites de cobertura y disponibilidad; Es posible que no represente a todos los usuarios o a todas las páginas. El promedio móvil de 28 días no muestra el impacto de la distribución de ayer. Úselo con RUM propio para audiencia exacta y dimensiones específicas del producto.

### Más allá de Web Vitals RON

El monitoreo de usuarios reales también debe capturar:

- Cambio de ruta o sincronización de navegación SPA (se puede mejorar con Soft Navigations).
- Latencia de API y solicitudes fallidas.- Errores de JavaScript y rechazo de promesas.
- Misiones largas y fotogramas clave largos (LoAF).
- Retraso de interacción por característica.
- Búsqueda, pago, inicio de sesión o finalización de carga.
- Clic de rabia, reintento y abandono.
- Fallos, estados fuera de línea y cambios de conexión.
- Fallos de accesibilidad cuando sean mensurables.

La pregunta útil no es simplemente “¿Es malo el INP?” no lo es; "¿Qué interacción es lenta, para qué usuarios, en qué versión y esto dificulta la finalización de la tarea?"

Los scripts de marketing/análisis de terceros pueden, paradójicamente, romper el INP/LCP cuando se agregan para su medición. **sGTM** colapsa docenas de scripts en el navegador en una única secuencia propia; Mueve el costo de la ejecución de JS, DNS y SSL a la nube, para que la medición en sí no afecte el rendimiento.

## Presupuestos, alertas y seguimiento continuo

Los presupuestos de desempeño traducen los objetivos de calidad en límites exigibles. Defina presupuestos tanto para métricas de usuario como para motivos:

- LCP: percentil 75 ≤ 2,5 segundos.
- INP: percentil 75 ≤ 200 milisegundos.
- CLS: percentil 75 ≤ 0,1.
- Transferencia de JavaScript: máximo acordado por ruta.
- Peso total de la página: máximo por clase de dispositivo.
- Solicitudes de terceros: lista aprobada y coste máximo.
- Tasa de error: porcentaje máximo aceptable.
- Éxito del flujo de trabajo crítico: tasa mínima de finalización.

Utilice tres niveles de alerta:

- **Advertencia:** acercándose al límite métrico.
- **Regresión:** métrica empeoró al exceder el porcentaje acordado.
- **Crítico:** un Core Web Vital o un flujo de trabajo crítico ha superado el umbral de error.

Ejemplo de afirmaciones de Lighthouse CI: prefiera puertas basadas en métricas a puntuaciones:```json
{
  "ci": {
    "collect": {
      "url": ["http://localhost:3000/", "http://localhost:3000/blog"],
      "numberOfRuns": 3,
      "settings": { "preset": "desktop" }
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.9}],
        "first-contentful-paint": ["warn", {"maxNumericValue": 2000}],
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}]
      }
    }
  }
}
```### Ejemplo de monitoreo continuo

Un sistema práctico podría funcionar así:

1. Lighthouse se ejecuta en un conjunto representativo de páginas en cada versión.
2. WebPageTest se ejecuta todas las noches desde varias ubicaciones y perfiles de conexión.
3. `web-vitals.js` (atribución si es posible) envía LCP, INP y CLS anónimos desde producción.
4. El panel divide los resultados por versión, ruta, dispositivo y geografía.
5. La alerta se dispara cuando el INP móvil empeora un 15% en dos periodos consecutivos.
6. El equipo monitorea la interacción afectada con DevTools + LoAF.
7. Después de acortar una tarea larga de JavaScript, se validan tanto los datos de seguimiento como los de campo.
8. El cambio sólo se mantiene si el desempeño mejora y el logro/conversión de tareas no disminuye.

Esto crea un ciclo de retroalimentación: **Lighthouse detecta, DevTools diagnostica, WebPageTest hace pruebas de estrés, RUM verifica, los presupuestos previenen la regresión**.

### Monitoreo continuo en la práctica (breves notas de casos)

- **Taboola:** TBT/INP alto en los sitios de los editores; Marcado de cuellos de botella con LoAF, reducción de escala de terceros y rediseño del motor de renderizado.
- **Fotocasa:** Verde durante el período FID; "Necesita mejorar/débil" en Search Console después del INP de marzo de 2024. Las ralentizaciones ocultas de los clientes en las interacciones de la galería, el mapa y los filtros se han resuelto con RUM.
- **Ray-Ban:** Prerenderizar páginas de productos con reglas de especulación; LCP ~43 % de caída (sub 1s) y conversión de PDP móvil ~101 % / escritorio ~156 % de aumento reportado.
- **T-Mobile:** Disminución de conversión y aumento de rebote por cada retraso de 100 ms cuando LCP supera los 2 segundos; Convertieron la velocidad en un KPI y aumentaron la conversión de visitas a pedidos en aproximadamente un 60 %.

La medida no es para pintar el tablero de verde; es hacer posible la misión en viajes reales.

## Parejas que se confunden con más frecuencia```text
❌ FID hâlâ güncel bir Core Web Vital’dır
✓ FID Mart 2024’te emekli oldu; odak INP’dedir (ziyaret boyunca yanıt)

❌ Yeşil Lighthouse skoru saha CWV’nin iyi olduğu anlamına gelir
✓ Lab teşhis eder; CrUX/RUM gerçek kullanıcı deneyimini doğrular

❌ Ortalama LCP “yeterince iyi”yi temsil eder
✓ 75. yüzdeliği mobil ve masaüstü ayrı izleyin

❌ TBT, INP’nin yerine geçer
✓ TBT lab teşhisidir; saha yanıtı için INP kullanın

❌ web-vitals skoru tek başına kök nedeni gösterir
✓ Attribution + LoAF etkileşim hedefi ve suçlu betiği gösterir

❌ CrUX dünkü deploy’u yansıtır
✓ CrUX ~28 günlük ortalamadır; anlık regresyon için birinci taraf RUM şarttır

Lista de verificación: medir lo que hay que medir

1. Elija una Estrella del Norte + una métrica de comportamiento, percepción, retención y técnica/confiabilidad.
2. Definir escenarios de laboratorio y dimensiones de campo (dispositivo, red, geografía, ruta) para viajes críticos.
3. Corrija los umbrales “buenos” de p75 para LCP, INP y CLS por separado para dispositivos móviles y de escritorio.
4. Divida el LCP en cuatro retrasos (TTFB, descubrimiento, descarga, renderizado); Divida el INP en tres fases.
5. Ejecute Lighthouse CI + WebPageTest en URL representativas; Leer mediana/tendencia.
6. Instale RUM en producción con web-vitals (se prefiere atribución) + dimensiones seguras para la privacidad.
7. Utilice CrUX para realizar evaluaciones comparativas; Confíe en RUM para la regresión y el diagnóstico de características.
8. Definir presupuesto y tres niveles de alerta (alerta/regresión/crítico); Validar la mejora mediante el éxito o la transformación de la tarea.

Si no puede responder a estos ocho ítems, todavía está “observando el marcador”; Aún no estás realizando mediciones orientadas al usuario.

Puntos clave de este episodio

1. La medición centrada en el usuario combina comportamiento, percepción, retención y desempeño técnico, no solo tráfico o puntuación de laboratorio.
2. Lab explica la capacidad y la razón; el campo valida el desempeño en el mundo real; Los dos son un ciclo.
3. Los Core Web Vitals actuales son LCP, INP y CLS; La FID es histórica. Umbrales en p75: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1.
4. LCP se divide en cuatro retrasos, INP en tres fases; LoAF y la atribución atribuyen la causa raíz a la coordenada en lugar de a la puntuación.
5. Las herramientas arquitectónicas como Soft Navigations, Speculation Rules y sGTM ayudan a cerrar los puntos ciegos de medición y la ponderación de terceros.
6. Los presupuestos, las alertas y el seguimiento continuo hacen que la mejora sea permanente; Taboola, Fotocasa, Ray-Ban y T-Mobile demuestran que la medición está ligada al resultado empresarial.

El objetivo no es poner el tablero en verde. El objetivo es saber (y diseñar conscientemente) si los usuarios pueden completar tareas importantes de manera rápida, confiable y satisfactoria.

Próximo: Transformaremos Core Web Vitals de “buenas métricas” a requisitos de productos, presupuestos y puertas de lanzamiento.