Planteamiento del problema y contexto aplicable
Una página de producto de comercio electrónico tiene datos de campo móviles de 28 días con un p75 de LCP de 4.1 segundos, INP de 320 milisegundos y CLS de 0.06. Desktop aprueba las tres métricas. La ejecución local de Lighthouse de un desarrollador reporta un LCP de 1.8 segundos, TBT de 80 milisegundos y CLS de 0.01. Explica cómo reconciliarías la discrepancia, localizarías las causas raíz de LCP e INP, ordenarías las correcciones y demostrarías que los cambios desplegados mejoraron la experiencia de usuario real.
Utiliza los umbrales actuales de "bueno" para Core Web Vitals: calcula el percentil 75 por separado para móvil y desktop, con LCP igual o inferior a 2.5 segundos, INP igual o inferior a 200 milisegundos y CLS igual o inferior a 0.1. Los números son supuestos de entrevista, no mediciones de ninguna empresa real. El objetivo no es recitar una lista de verificación de optimización, sino conectar las distribuciones de usuarios, los componentes de las métricas, el trabajo del navegador y la validación en una cadena de diagnóstico falsable.
Esta pregunta es adecuada para entrevistas de frontend senior, rendimiento web y full-stack. El candidato debe comprender las cascadas de red, el hilo principal y el diseño (layout), al tiempo que reconoce que una única ejecución de Lighthouse no puede invalidar los datos de usuarios reales y que TBT no es INP.
Qué evalúa el entrevistador
Primero, ¿puede el candidato normalizar la evidencia antes de actuar? Una respuesta sólida establece si los datos de campo representan una URL, un grupo de URLs o el origen completo, y luego segmenta por móvil versus desktop, plantilla de ruta, gama del dispositivo, red, geografía y versión (release). Una respuesta débil declara que el problema no existe porque la puntuación local de Lighthouse está en verde.
Segundo, ¿puede el candidato asignar cada métrica a un cuello de botella distinto? LCP se refiere a cuándo aparece el contenido principal. INP cubre el retraso completo desde una interacción hasta el siguiente cuadro renderizado. CLS cubre el movimiento visual inesperado. Comparten algunos costos de hilo principal y renderizado, pero "reducir el bundle" no puede explicar cada fallo.
Tercero, ¿puede el candidato atribuir la latencia? LCP se puede descomponer en TTFB, retraso de carga del recurso (resource load delay), duración de carga del recurso (resource load duration) y retraso de renderizado del elemento (element render delay). La latencia de una interacción se puede descomponer en retraso de entrada (input delay), duración del procesamiento (processing duration) y retraso de presentación (presentation delay). Una corrección debe dirigirse a un componente anómalo en lugar de a un elemento aleatorio de una lista de verificación de rendimiento.
Cuarto, ¿puede el candidato utilizar correctamente las herramientas de campo y de laboratorio? RUM y CrUX identifican lo que experimentan los usuarios reales. DevTools, Lighthouse y un escenario reproducible en un dispositivo restringido ayudan a explicar el porqué. Sin interacción real del usuario, Lighthouse no puede medir INP; las señales de laboratorio como TBT son ayudas de diagnóstico.
Quinto, ¿puede el candidato demostrar una mejora en lugar de limitarse a mostrar un despliegue? Después del lanzamiento, compara distribuciones de RUM homogéneas (like-for-like) por versión o cohorte de despliegue, verifica las barreras de protección (guardrails) de errores y del negocio, y luego deja que los datos de campo móviles de 28 días confirmen el cambio. Una sola captura, un promedio más bajo o un teléfono más rápido no demuestran que el p75 apruebe.
Preguntas a aclarar antes de responder
- ¿Cuál es el alcance de los datos de campo? Los resultados a nivel de URL, grupo de URLs y origen pueden diferir. Si 4.1 segundos pertenece al origen, aún no se ha demostrado que la página de producto sea la causa. Si pertenece a la plantilla de producto, segmenta aún más el tráfico de esa plantilla.
- ¿Qué dispositivos, redes y regiones aportan las muestras móviles? Un fallo confinado a dispositivos de gama baja o a una región requiere una reproducción y prioridad diferentes. Combinar móvil y desktop oculta el problema.
- ¿Cuándo sufrieron una regresión las métricas? La alineación con un despliegue, un script de terceros, el pipeline de imágenes o un cambio en la mezcla de tráfico reduce las hipótesis. Un valor móvil de 28 días no expone con precisión el efecto inmediato de una versión.
- ¿Cuáles son el elemento LCP real y la interacción lenta de INP? Una imagen hero, el texto de un encabezado y un contenedor renderizado en el cliente requieren correcciones diferentes. Agregar al carrito, la selección de variantes y el campo de búsqueda también recorren distintas rutas del hilo principal.
- ¿Cómo se ejecutó Lighthouse? La limitación (throttling) de dispositivo y red, la caché, la autenticación, los datos de la página y el recorrido probado deben asemejarse a la población lenta. Una carga en frío en una laptop rápida no representa la distribución móvil.
- ¿Qué capas puede modificar el equipo? Un equipo exclusivo de frontend aún debe cuantificar TTFB, pero no puede pretender que puede corregir el origen directamente. Si la CDN, el renderizado en servidor y los servicios de imágenes están dentro del alcance, el plan puede cubrir la ruta crítica completa.
- ¿Qué define un lanzamiento exitoso? En este caso, las tres métricas móviles p75 deben ser buenas mientras que la tasa de errores, la conversión y la accesibilidad se mantienen seguras. Pintar antes una imagen hero incorrecta o bloquear una interacción crítica no es un éxito.
La respuesta de 30 segundos
"Primero verificaría si los 4.1 segundos y 320 milisegundos corresponden a datos de campo móviles a nivel de URL o de origen; luego segmentaría por plantilla de ruta, dispositivo, red y versión. Lighthouse TBT no es INP, por lo que el resultado local no puede descartar un problema de usuarios reales. Usaría RUM para identificar el elemento LCP real y la interacción más lenta, y luego capturaría una traza de red y de Performance en un dispositivo comparable. Descompondría LCP en TTFB, descubrimiento, descarga y renderizado, y desglosaría INP en entrada, procesamiento de eventos y presentación del siguiente cuadro. CLS ya aprueba con 0.06, por lo que se convierte en un guardrail contra regresiones en lugar de la primera inversión. Finalmente, realizaría un despliegue gradual, compararía el p75 de RUM homogéneo y los guardrails, y esperaría a que la ventana de 28 días de CrUX lo confirme".
Análisis detallado paso a paso
Paso 1: Explicar cómo los resultados de campo y de laboratorio pueden ser ambos correctos
Veintiocho días de datos de campo combinan los dispositivos, redes, estados de caché, ciclos de vida de páginas e interacciones de usuarios reales. Un p75 de LCP móvil de 4.1 segundos sitúa aproximadamente a la cuarta parte más lenta de las visitas relevantes en 4.1 segundos o peor. No significa que un "teléfono típico" tarde exactamente 4.1 segundos. Que los datos de desktop aprueben sugiere que el fallo puede concentrarse en CPUs restringidas, redes móviles, una plantilla móvil o un recorrido de usuario móvil.
El Lighthouse local es un experimento controlado. Es repetible y útil para cascadas y detección de regresiones, pero representa una sola configuración de dispositivo y red. Sin la interacción del usuario, Lighthouse no puede generar INP directamente. Un TBT de 80 milisegundos es una señal de laboratorio sobre el bloqueo del hilo principal. Una página puede tener un TBT de inicio bajo pero ejecutar una tarea de 300 milisegundos cuando un usuario abre el selector de variantes. Lo contrario también es posible: un TBT alto en laboratorio puede ocurrir en un momento en que pocos usuarios reales interactúan.
Primero confirma en PageSpeed Insights o en la plataforma de datos si el resultado corresponde a datos de URL, origen o grupo de URLs, e inspecciona móvil y desktop por separado. Luego usa RUM propio (first-party) para segmentar por plantilla de página, gama de dispositivo, tipo de conexión efectiva, geografía, tipo de navegación y versión de la aplicación. Cada dimensión necesita suficientes muestras y un límite de privacidad defendible. El diagnóstico de rendimiento no justifica recolectar query strings completas, texto escrito o la identidad del usuario.
Paso 2: Construir RUM que atribuya problemas en lugar de solo reportar puntuaciones
Una implementación mínima puede reportar las tres métricas a través de web-vitals. El siguiente código es idéntico en las ocho versiones de idioma:
import { onCLS, onINP, onLCP } from 'web-vitals';
function sendToAnalytics(metric) {
const body = JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id,
rating: metric.rating,
route: location.pathname,
});
(navigator.sendBeacon && navigator.sendBeacon('/rum', body)) ||
fetch('/rum', { body, method: 'POST', keepalive: true });
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);El ejemplo utiliza location.pathname por legibilidad. El código de producción debe mapearlo a una plantilla de ruta de baja cardinalidad como /products/:id y adjuntar una versión, gama de dispositivo y los campos de atribución necesarios. No transmitas parámetros de consulta, texto del DOM ni información de identificación del usuario. metric.id ayuda a distinguir los eventos de métricas para una visita a la página, pero el servicio receptor aún necesita reglas explícitas de muestreo y de reportes duplicados.
Almacenar únicamente name y value no es suficiente para corregir una regresión. LCP necesita el elemento y cuatro componentes temporales. INP necesita el objetivo de interacción y tres componentes temporales. CLS necesita los elementos desplazados y la fase del ciclo de vida. Utiliza una compilación con atribución o un producto RUM existente para agregar esos campos. Al momento de la agregación, calcula los percentiles a partir de la métrica final de cada navegación. No calcules el p75 para cada componente de forma independiente para luego sumarlos: esas observaciones de percentiles pueden provenir de visitas diferentes.
Paso 3: Diagnosticar LCP con cuatro componentes de tiempo
Una navegación móvil lenta representativa muestra un TTFB de 0.6 segundos, un retraso de carga del recurso de 1.5 segundos, una duración de carga del recurso de 0.9 segundos y un retraso de renderizado del elemento de 1.3 segundos, para un LCP total de 4.3 segundos. Estos componentes pertenecen a la misma navegación, por lo que se pueden sumar. No son cuatro valores p75 independientes.
Los dos componentes sospechosos más grandes son el retraso de carga y el retraso de renderizado. Verifica si el hero se inserta solo después de que se ejecuta el JavaScript del cliente o si tiene lazy loading incorrecto. Para una imagen, coloca el <img> y su src o srcset en el HTML inicial, proporciona un sizes correcto, no apliques lazy loading a la imagen LCP above-the-fold y usa un fetchpriority más alto únicamente para un recurso genuinamente crítico. Si CSS es la única vía de descubrimiento, evalúa un precargado (preload) preciso. Precargar cada imagen grande hace que los recursos críticos compitan por el ancho de banda.
Pasan otros 1.3 segundos después de que el recurso termina de descargarse, por lo que comprimir más la imagen podría simplemente trasladar el tiempo al retraso de renderizado. Inspecciona el JavaScript síncrono, las condiciones que frenan el renderizado del cliente, los estilos bloqueantes, las fuentes y el estado que oculta el hero. Renderizar en el servidor el contenido visible del hero, reducir el CSS crítico y diferir la hidratación no crítica puede ayudar, pero una nueva traza debe demostrar que el componente objetivo realmente disminuyó. Un TTFB de 0.6 segundos aún merece monitoreo. Tiene menor prioridad que los retrasos medidos de 1.5 y 1.3 segundos en esta muestra; no está exento de optimización de forma permanente.
Paso 4: Diagnosticar INP con tres componentes de tiempo
Una interacción lenta representativa de "seleccionar variante" tarda 350 milisegundos: 140 milisegundos de retraso de entrada, 120 milisegundos de procesamiento de eventos y 90 milisegundos de retraso de presentación. Los tres componentes provienen de una sola interacción, por lo que su suma tiene sentido. El INP p75 de campo de 320 milisegundos es un agregado independiente y no puede ser reemplazado por esta traza.
El retraso de entrada significa que otro trabajo ya ocupaba el hilo principal cuando el usuario actuó. Graba una traza de Performance que comience antes de la interacción y busca evaluación de scripts, etiquetas de terceros, temporizadores o tareas largas de hidratación. Divide el trabajo interrumpible en tareas más pequeñas, difiere el trabajo no crítico y evita concentrarlo durante el inicio. Acortar solo el manejador del clic actual no elimina los 140 milisegundos que se pasaron esperando antes de que ese manejador se ejecutara.
La duración del procesamiento pertenece a las devoluciones de llamada (callbacks) de eventos. Pasa el estado seleccionado o la retroalimentación de carga al siguiente cuadro antes del análisis de inventario, la actualización de recomendaciones o el registro de eventos; elimina cálculos duplicados y acota la actualización del estado. Para el retraso de presentación, inspecciona actualizaciones grandes del DOM, diseños síncronos forzados (forced synchronous layout) y layout thrashing. Agrupa lecturas y escrituras del DOM y reduce la región que debe estructurarse y pintarse para esta interacción. Modifica un cuello de botella medido a la vez y repite el mismo recorrido para comparar los tres componentes.
Paso 5: Convertir el CLS que ya es bueno en un guardrail contra regresiones
Un CLS de 0.06 está por debajo de 0.1, por lo que no debe tener mayor prioridad que LCP e INP que están fallando. Aún necesita protección porque una carga más temprana del hero, un componente de imagen de reemplazo o nueva retroalimentación visual de interacción pueden introducir cambios de diseño. Asigna a imágenes y videos width, height o un aspect-ratio estable; reserva espacio para anuncios, recomendaciones y contenido asíncrono; y controla las diferencias de tamaño entre las fuentes web y las de respaldo (fallbacks).
La brecha entre el CLS de laboratorio de 0.01 y el CLS de campo de 0.06 es evidencia útil. Las ejecuciones predeterminadas de Lighthouse cubren principalmente la carga, mientras que los usuarios reales pueden experimentar cambios posteriores a la carga al hacer scroll, abrir componentes o mantener activa una página extensa. Utiliza la atribución de RUM y la pista de Layout Shifts de DevTools para reproducir esos recorridos. Los cambios de diseño dentro de un iframe de origen cruzado pueden aparecer en CrUX pero no pueden atribuirse por completo a través de las APIs web de la página principal, por lo que debes inspeccionar el contenido incrustado cuando aparezca esa discrepancia.
Paso 6: Ordenar los cambios según la evidencia y desplegar gradualmente
No crees proyectos separados de "imágenes" y "JavaScript" cambiando todo en paralelo. Las trazas actuales sugieren que el descubrimiento retrasado del hero en el lado del cliente y las tareas largas de inicio pueden incrementar tanto los retrasos de carga/renderizado de LCP como el retraso de entrada de INP. Un primer lote puede probar una hipótesis compartida: hacer que el hero sea detectable en el HTML inicial y diferir el JavaScript que no se necesita en la primera pantalla. El cambio se mantiene acotado, la afirmación causal sigue siendo comprobable y ambas métricas deficientes pueden mejorar.
Define una señal esperada para cada cambio. La detectabilidad del hero debería reducir el retraso de carga del recurso. Reducir las tareas largas de inicio debería disminuir el retraso de renderizado de LCP, el retraso de entrada de INP y el TBT de laboratorio. Si el componente correspondiente no varía, no atribuyas a esa corrección un cambio de puntuación casual. La calidad de imagen, la tasa de errores, el tiempo hasta que la página es utilizable, la conversión y la accesibilidad son guardrails para que una métrica de rendimiento no oculte una degradación del producto.
Despliega a una cohorte de tráfico mientras retienes una versión antigua comparable o una línea base concurrente. Compara la misma ruta, población móvil y versión mientras verificas que la mezcla de tráfico no haya cambiado materialmente. Cuando un despliegue coincide con un cambio de tráfico, una línea de tiempo de antes y después muestra correlación, no causalidad automática.
Paso 7: Cerrar el problema con tres capas de evidencia
La primera capa es un guardrail de laboratorio previo a la fusión (pre-merge): fija el perfil móvil restringido, el estado de la caché y las interacciones críticas, luego registra LCP, TBT, CLS, la cascada de red y las trazas de Performance. Esto detecta regresiones obvias pero no reemplaza al INP real.
La segunda capa es el RUM posterior al lanzamiento. Verifica el tamaño de muestra, el muestreo estable y la deduplicación de eventos de métricas; luego compara el p75 de LCP, INP y CLS para la plantilla de producto móvil junto con sus componentes y guardrails de producto. El RUM a corto plazo puede revelar la dirección rápidamente. Si la muestra es insuficiente, reporta confianza insuficiente en lugar de afirmar que todos los usuarios aprueban.
La tercera capa es la confirmación móvil de 28 días en CrUX o Search Console. Las visitas antiguas abandonan la ventana gradualmente, por lo que la métrica no salta a su nuevo estado estable el día del despliegue. Aprobar significa que móvil y desktop cumplen por separado con los tres objetivos p75: LCP ≤ 2.5 segundos, INP ≤ 200 milisegundos y CLS ≤ 0.1. Corregir LCP no debe empujar a CLS de 0.06 más allá de su umbral. Registra criterios de reversión (rollback) y cualquier segmento lento restante para que un aprobado global no oculte un problema en dispositivos de gama baja.
Respuesta de ejemplo de alta calidad
"No usaría un resultado local de Lighthouse en verde para descartar los datos de campo móviles. Primero determinaría si 4.1 segundos pertenece a la URL de detalle del producto, a un grupo de URLs o al origen; luego segmentaría el tráfico móvil por dispositivo, red, región y versión. Un p75 de 28 días es una distribución, no un solo dispositivo, y el TBT de Lighthouse no es INP.
Añadiría atribución de RUM para identificar el elemento LCP real y la interacción más lenta, y luego capturaría trazas en un dispositivo comparable. Supongamos que una navegación lenta tiene componentes de LCP de 0.6, 1.5, 0.9 y 1.3 segundos. Atacaría primero el retraso de descubrimiento de 1.5 segundos y el retraso de renderizado de 1.3 segundos: colocaría la imagen hero en el HTML inicial, eliminaría el lazy loading above-the-fold y reduciría el trabajo del cliente que bloquea su renderizado. Comprimir una imagen que ya se ha descargado no sería mi primer movimiento.
Para INP, dividiría la interacción lenta en retraso de entrada, procesamiento y presentación. Si estos son 140, 120 y 90 milisegundos, primero buscaría el trabajo de inicio que ocupa el hilo principal antes de la interacción, luego acortaría el callback y reduciría el diseño y renderizado para la actualización. CLS ya aprueba con 0.06, por lo que las dimensiones de imagen y los marcadores de posición para contenido asíncrono se mantienen como guardrails contra regresiones.
Desplegaría a una pequeña cohorte, exigiría que cada cambio mueva su componente temporal proyectado y compararía versiones con RUM homogéneo y guardrails del producto. Los presupuestos de rendimiento en laboratorio previenen regresiones previas a la fusión, RUM ofrece una señal rápida de usuarios reales y la ventana de 28 días de CrUX proporciona la confirmación final. Cierro el problema solo cuando el p75 móvil de LCP, INP y CLS alcancen 2.5 segundos, 200 milisegundos y 0.1 sin degradar la tasa de errores, la conversión o la accesibilidad".
Errores comunes
- Descartar datos de campo porque el Lighthouse local aprueba → Los dos conjuntos de datos cubren diferentes usuarios, ventanas de tiempo e interacciones → Normaliza primero el alcance de URL, dispositivo, red, versión y métricas.
- Interpretar un TBT de 80 milisegundos como un INP de 80 milisegundos → Lighthouse no puede medir INP sin interacciones reales → Usa INP de campo para evaluar el impacto y TBT junto con trazas de interacción para el diagnóstico.
- Mirar solo un promedio de todo el sitio → Los promedios ocultan la cola móvil y una plantilla con fallos → Calcula el p75 por separado para móvil y desktop, luego segmenta grupos con muestras suficientes.
- Comprimir la imagen en cuanto LCP es lento → El retraso de descubrimiento o de renderizado puede ser el dominante → Descompón LCP en cuatro componentes y modifica el que sea anómalo.
- Precargar todos los recursos above-the-fold → Los recursos supuestamente críticos compiten entre sí → Aumenta la prioridad solo para el recurso LCP confirmado y vuelve a verificar la cascada.
- Optimizar únicamente el callback de clic → Las tareas largas antes del callback y el layout posterior a él también contribuyen → Inspecciona entrada, procesamiento y presentación por separado.
- Priorizar llevar CLS de 0.06 a 0.02 → El esfuerzo se destina a una métrica que ya aprueba mientras LCP e INP siguen fallando → Mantén un guardrail de CLS y prioriza las métricas por encima del umbral.
- Sumar cuatro valores p75 de los componentes → Cada percentil puede provenir de una visita diferente → Suma componentes solo dentro de una misma navegación; calcula el percentil final de la métrica en el momento de la agregación.
- Declarar victoria cuando RUM baja el día del despliegue → El tamaño de la muestra, la mezcla de tráfico y la ventana de 28 días no son estables → Compara cohortes de despliegue, inspecciona guardrails y espera la confirmación de campo móvil.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué el LCP de campo es deficiente cuando varios teléfonos de prueba no logran reproducirlo?
Verifica si el valor de campo corresponde a la URL o al origen, si la plantilla de la página está agrupada correctamente y qué geografía, red, tipo de navegación o versión contiene las muestras lentas. Si los dispositivos de prueba no capturan la cola real, toma etiquetas de entorno de baja cardinalidad de las navegaciones lentas de RUM y recrea un estado comparable de CPU, red, caché y autenticación. Si aún no se puede reproducir, preserva la evidencia de atribución en línea. Ejecutar repetidamente dispositivos rápidos no hará desaparecer el problema.
Pregunta de seguimiento 2: Solo un segmento de Android de gama baja falla en INP, mientras que el p75 global aprueba. ¿Deberías solucionarlo?
Verifica el tráfico de ese segmento, su importancia para el negocio y la fiabilidad de la muestra. Un umbral global aprobado describe la distribución agregada, no a cada cohorte importante. Si esa gama de dispositivos contiene muchos usuarios de pago o su INP está muy por encima de 500 milisegundos, define un SLO para el segmento y abórdalo. Si la muestra es diminuta, mejora primero la observabilidad. Convertir cada segmento pequeño en una barrera estricta de despliegue permitiría que el ruido del muestreo bloquee los lanzamientos.
Pregunta de seguimiento 3: ¿Cómo cambia el plan si el elemento LCP es texto de encabezado que usa una fuente web?
El descubrimiento del recurso pasa de una imagen a fuentes y estilos bloqueantes. Verifica cuándo se descubre la solicitud de la fuente, si cruza una conexión de origen, el tamaño del archivo, font-display y las dimensiones de la fuente de reserva (fallback), además de si el encabezado espera el renderizado del cliente. No copies el plan de fetchpriority de imágenes. Precarga solo los archivos de fuentes que la primera pantalla realmente use, y verifica que esto no cause descargas duplicadas ni desplace recursos más críticos.
Pregunta de seguimiento 4: La interacción lenta está dentro de un iframe de pago de origen cruzado. ¿Qué puede hacer la página principal?
INP puede reflejar la latencia del usuario a partir de la interacción con un iframe, pero el límite de origen cruzado restringe la atribución en la página principal. Correlaciona RUM con la versión incrustada y la página contenedora, usa evidencia de rendimiento del proveedor o una prueba reproducible y colabora con dicho proveedor. La página principal también puede reducir sus propias tareas largas concurrentes. Sin la pila de llamadas interna, delimita la evidencia: ni culpes al proveedor automáticamente ni afirmes que el código local ha solucionado el iframe.
Pregunta de seguimiento 5: La página tiene muy poco tráfico para obtener datos de CrUX a nivel de URL. ¿Cómo decides si aprueba?
Utiliza RUM propio para recopilar métricas por visita y los campos de entorno necesarios, reportando tanto el tamaño de la muestra como la ventana de tiempo, mientras que las pruebas de laboratorio de recorridos críticos protegen contra regresiones. La agregación a nivel de plantilla puede aumentar el tamaño de la muestra solo cuando la estructura de la página y los recorridos de los usuarios sean comparables. Con datos insuficientes, puedes demostrar que las trazas conocidas mejoraron, pero no puedes afirmar un estado "bueno" en CrUX a nivel de URL.
Pregunta de seguimiento 6: Renderizar el hero antes mejora LCP pero inicia la hidratación antes y empeora INP. ¿Qué hacer ahora?
Ese es un compromiso (trade-off) real entre métricas, así que mantén ambos resultados. Verifica si un renderizado más temprano realmente requiere una hidratación más temprana. A menudo, el contenido estático visible puede llegar primero mientras que el código de interacción se carga bajo demanda. Si la interacción inmediata es un requisito del negocio, establece el presupuesto alrededor de la acción crítica del usuario, divide el trabajo del hilo principal y compara LCP, INP y la conversión durante el despliegue. Una puntuación de rendimiento compuesta no debe ocultar una regresión en INP.
Pregunta de seguimiento 7: La política de privacidad prohíbe almacenar URLs completas y objetivos del DOM. ¿Aún puede RUM diagnosticar el problema?
Utiliza plantillas de ruta predefinidas, enumeraciones de componentes, tipos de interacción, versiones de lanzamiento y gamas de dispositivos generales. No retengas identificadores de productos, parámetros de consulta, texto ni identificadores de usuario. Mapea los campos en el cliente antes de reportar y rechaza valores de alta cardinalidad en el servidor. La atribución se vuelve menos precisa, por lo que la reproducción en laboratorio debe llenar el vacío en torno a los componentes y recorridos enumerados. El diagnóstico de rendimiento no es un permiso para ampliar la recopilación de datos personales.