Una web lenta: qué medir y qué corregir antes de rediseñarla
Una puntuación alta no demuestra que tus clientes puedan consultar y contactar con rapidez. Revisa página, dispositivo y alcance del dato.
Hoja de prueba: Web lenta: prioridades de Core Web Vitals
Una puntuación alta no demuestra que tus clientes puedan consultar y contactar con rapidez. Revisa página, dispositivo y alcance del dato. Registra datos, resultado esperado, evidencia, responsable y resultado observado.
Empieza por la página que usa tu comprador
Una distribuidora puede perder consultas si el catálogo tarda en mostrar productos; una empresa de servicios depende de que se lea su alcance y se encuentre cómo contactar. Escoge una ruta y una tarea, con dispositivo y conexión de prueba. La página principal puede funcionar bien mientras la ficha que comparte ventas carga una imagen enorme o un formulario que bloquea la interacción.
PageSpeed Insights distingue datos de laboratorio y datos reales de CrUX, con una ventana de 28 días. Cuando falta muestra de una página, puede mostrar datos del origen o no tener datos reales. Conserva ese alcance: una prueba simulada y un agregado de todo el sitio no son mediciones equivalentes de la página que quieres corregir.
Relaciona cada métrica con una molestia concreta
web.dev describe LCP para carga, INP para respuesta a interacciones y CLS para estabilidad visual. Sus umbrales de buena experiencia son LCP de hasta 2.5 segundos, INP de hasta 200 milisegundos y CLS de hasta 0.1, evaluados al percentil 75 y separados por móvil y escritorio. Úsalos como referencia técnica, no como una promesa de posicionamiento o ventas.
| Métrica | Qué puede observar el cliente | Qué revisar antes de cambiar |
|---|---|---|
| LCP | Contenido principal aparece tarde | Imagen principal, respuesta inicial y recursos críticos |
| INP | Toca un control y la página tarda en responder | Trabajo de la interacción y tareas de JavaScript |
| CLS | Botón o contenido se mueve mientras lo usa | Espacio reservado para imágenes, anuncios y fuentes |
| Resultado del formulario | No sabe si su consulta llegó | Recepción y confirmación, además de rapidez |
Ejemplo ficticio: 93 de laboratorio y móvil pendiente
Una página de catálogo tiene, en el ejemplo, puntuación de laboratorio 93. Su muestra móvil real muestra percentil 75 de LCP 3.4 segundos, INP 250 milisegundos y CLS 0.04. LCP e INP no cumplen los umbrales citados aunque el resultado de laboratorio sea favorable. Estos datos son sintéticos, no una medición del sitio de Nightly ni una previsión de conversión.
La revisión encuentra una imagen principal sobredimensionada y una interacción de filtros que ejecuta trabajo innecesario. Se propone corregir una causa por vez y repetir el mismo recorrido. La prueba inmediata puede mostrar una mejora del laboratorio; la ventana real no cambia por completo en ese momento. Registra ambas observaciones sin presentar una como la otra.
| Caso | Resultado esperado | Evidencia |
|---|---|---|
| Medir ficha crítica en móvil | Ruta, dispositivo, conexión y alcance identificados | Reporte y fecha |
| Datos reales disponibles solo por origen | Limitación visible, sin afirmar dato de la ficha | Alcance del reporte |
| Optimizar imagen principal | Contenido legible y recursos adecuados, sin pérdida visual relevante | Antes/después en mismo recorrido |
| Reducir trabajo del filtro | Resultado correcto y respuesta comprobada | Interacción y prueba comparable |
| Reservar espacio de imágenes | Contenido no desplaza el botón al cargar | Recorrido visual |
| Enviar consulta tras la optimización | Recepción y confirmación siguen funcionando | Referencia de consulta de ensayo |
Corrige lo que explica el problema observado
No elimines un recurso solo porque aparece en una lista. Revisa su función: una imagen puede mostrar un acabado que el comprador necesita; una integración puede gestionar citas. Define el cambio, el resultado esperado y una forma de volver a la versión anterior si rompe la tarea. Cambiar todo a la vez dificulta saber qué ayudó.
Repite pruebas comparables y conserva variación, especialmente si una medición aislada cambia mucho. El resultado depende de caché, dispositivo, conexión y carga del servicio. Si no hay datos reales suficientes, declara esa limitación y usa pruebas controladas para diagnóstico. No inventes percentiles del negocio a partir de una sola ejecución.
Comprueba la experiencia y el resultado por separado
Una página puede mejorar sus métricas y seguir explicando mal el producto. Relaciona el rendimiento con facilitar la compra, medir consultas útiles y formularios que conservan contactos. Para interfaces de operación consulta diseño de software empresarial.
La hoja descargable incluye diez pruebas, sin datos medidos. Trae la página crítica, el recorrido del comprador y reportes con fecha a una consulta gratuita de páginas web. Podemos revisar la prioridad de una corrección o si hace falta cambiar una parte de la experiencia antes de plantear un rediseño completo.
Preguntas frecuentes
No para todos los usuarios ni tareas. La puntuación depende de una prueba concreta. Revisa datos reales cuando existan, dispositivo, página y recorrido. También comprueba interacción y recepción de consultas: pueden fallar aunque una auditoría de carga sea favorable.
La vista de CrUX usada por PageSpeed Insights agrupa una ventana de 28 días. Una corrección no sustituye de inmediato toda esa muestra. Conserva fecha de cambio y alcance, y distingue pruebas inmediatas del seguimiento posterior.
No por esa sola razón. Puede faltar muestra suficiente. Ejecuta un diagnóstico controlado de las tareas críticas y declara el límite. Un rediseño necesita explicar qué problema resuelve mejor que una corrección de recursos o interacción.
La mejora técnica no demuestra por sí sola causalidad comercial. Mide consultas útiles y ventas con definiciones y periodos adecuados. Contenido, oferta, seguimiento y otros cambios también influyen; evita atribuirles a las métricas un resultado que no verificaste.
Fuentes
- Web Vitalsweb.dev / Google
- About PageSpeed InsightsGoogle
Última actualización: