¿Tu web es rápida en el móvil de quien la usa?

Abre una página de producto en el móvil, elige una opción e intenta continuar. Si el botón tarda en reaccionar, la imagen desplaza el precio o la pantalla se congela mientras carga un script, encontraste un problema. La nota del último informe no cambia esa experiencia.

Una prueba en el portátil del equipo ayuda a investigar. Decidir qué mejorar exige considerar quién usa la web, con qué dispositivo y en qué páginas. Un proceso de compra con pocas visitas puede merecer más atención que la portada.

Usa el laboratorio para investigar y las visitas para priorizar

Lighthouse ejecuta una prueba bajo condiciones controladas. Los datos de campo vienen de visitas reales, con diferencias de dispositivo, red y comportamiento. La guía de web.dev sobre laboratorio y campo explica por qué pueden discrepar.

Sugerimos empezar por una pregunta sobre el uso. ¿En qué etapa alguien espera o repite una acción? Después busca la medida que ayude a investigar esa espera.

Separa móvil y escritorio. Separa también páginas con funciones distintas. Un promedio del dominio puede esconder una inscripción lenta entre cientos de páginas de contenido sencillo.

Si la muestra sigue siendo insuficiente, registra esa limitación. La ausencia de datos no significa que la página apruebe. Usa pruebas controladas para localizar problemas mientras reúnes observaciones de las visitas.

Entiende qué responde cada medida

Los límites de buena experiencia de Core Web Vitals son LCP de hasta 2,5 segundos, INP de hasta 200 milisegundos y CLS de hasta 0,1, evaluados en el percentil 75. En cada métrica, al menos el 75% de las visitas medidas debe cumplir el límite.

LCP observa cuándo aparece el mayor bloque visible de texto o imagen. INP mide la respuesta visual a las interacciones. CLS cuantifica desplazamientos inesperados del contenido. Responden preguntas distintas. Una página puede aparecer pronto y seguir siendo difícil de usar.

Relaciona el reporte con una investigación:

Reporte	Primer punto a investigar
"La foto principal tarda"	Qué elemento determina el LCP y cuándo empieza a cargar
"Toqué y no pasó nada"	El trabajo ejecutado durante la interacción
"El botón se movió"	Qué contenido entró sin espacio reservado

La tabla orienta la búsqueda. No demuestra la causa.

Corrige la demora que encontraste

Si la imagen principal determina el LCP, comprueba que aparece en el HTML inicial y evita loading="lazy" en ella. Entrega un archivo adecuado al tamaño mostrado. Son recomendaciones de la guía de optimización de LCP.

Antes de convertir todos los formatos de imagen, mira la secuencia de carga. Una imagen pequeña descubierta tarde también llega tarde. Registra cuándo la solicita el navegador para saber si el cambio resolvió la espera observada.

Para una interacción lenta, identifica qué mantiene ocupado el hilo principal. La guía de optimización de INP incluye reducir y dividir tareas largas. La respuesta visual al toque importa, pero no elimina el tiempo necesario para terminar una consulta.

En un filtro de productos, mide por separado la reacción del botón y la llegada de resultados. Mejorar la primera no demuestra que la segunda mejoró. Los registros deben distinguirlas.

Define el presupuesto según la página

Un catálogo y un editor de imágenes necesitan cantidades distintas de código. Usa un presupuesto ligado a la página que estás modificando. Registra los bytes transferidos y la duración de las interacciones importantes antes de cambiar la implementación.

Después de corregir, repite el mismo escenario en condiciones comparables. Anota el cambio y observa nuevas visitas. Si el tráfico cambió junto con el despliegue, no atribuyas toda variación al código.

Incluye la tarea completa en los criterios de aceptación. La persona debe poder abrir el producto, elegir una opción y enviar el formulario sin perder lo que escribió. Un informe ayuda a localizar la demora. Terminar esa tarea da sentido a la mejora.