Una web que parece rápida en el portátil de la oficina puede hacer esperar a quien la abre desde el móvil. Empieza por la página y la tarea concretas que van lentas; después, utiliza un informe de rendimiento móvil para acotar la causa. Comprar otro alojamiento o añadir un complemento de velocidad sin localizar la demora es una forma cara de adivinar.
Esta guía está dirigida a responsables de empresas que van a encargar una mejora de su web actual. El procedimiento es una recomendación práctica, no un diagnóstico de tu sitio ni una promesa de más consultas.
1. Describe la espera antes de pedir una solución
Abre en un móvil una página publicada de un servicio o producto. Recorre el camino de un cliente: leer la oferta, abrir el menú, consultar un producto y llegar al contacto. Anota la URL, el dispositivo, el navegador, la conexión y si era una primera visita o una visita repetida.
Describe lo que ocurre. ¿La pantalla queda en blanco? ¿La imagen principal aparece tarde? ¿Puedes leer, pero el menú no se abre? ¿Un botón se mueve justo cuando vas a tocarlo? Son problemas distintos. Una captura de una puntuación baja no explica qué tarea del cliente está fallando.
Compara otra página representativa en las mismas condiciones. Si todas van lentas, conviene investigar algún recurso compartido; si solo ocurre en una ficha, revisa sus imágenes, elementos externos o plantilla. Es una pista que investigar, no una causa demostrada.
Para una revisión más amplia, utiliza la lista de revisión de una web de empresa. Aquí buscamos convertir un problema de rendimiento en una reparación con alcance definido.
2. Distingue la prueba móvil de los datos de visitas reales
Introduce la URL exacta en PageSpeed Insights y selecciona Móvil. Guarda el enlace del informe y la fecha. Revisa Ordenador por separado: un buen resultado allí no resuelve la pregunta sobre el móvil.
La documentación de PageSpeed distingue las pruebas controladas de Lighthouse de los datos históricos de visitas reales de Chrome User Experience Report. La prueba controlada ayuda a investigar la página ahora; los datos de visitantes describen experiencias en distintas condiciones reales. Si difieren, revisa las condiciones antes de concluir que una medición está equivocada.
Comprueba el alcance del apartado de usuarios reales. La guía de CrUX explica que puede mostrar la URL analizada o el origen, es decir, la dirección general del sitio. Un resultado del conjunto del sitio no mide exclusivamente tu ficha de producto. Si faltan datos suficientes, deja constancia: la ausencia de informe no demuestra un buen rendimiento.
3. Entiende el síntoma que representa cada cifra
La guía de Web Vitals distingue carga, respuesta a las interacciones y 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 en el percentil 75 de las visitas y por separado para móvil y ordenador. Son criterios de medición, no una garantía para cada visitante.
| Indicador | Qué describe | Qué preguntar al responsable de mantenimiento |
|---|---|---|
| LCP: Largest Contentful Paint | Cuándo se muestra la imagen o el bloque de texto visible más grande | ¿Qué elemento se mide y en qué fase se retrasa? |
| INP: Interaction to Next Paint | La rapidez de la respuesta visual a las interacciones | ¿Qué menú, filtro u otra interacción resulta lenta en los datos de visitantes? |
| CLS: Cumulative Layout Shift | Los movimientos inesperados del contenido visible | ¿Qué se mueve y se puede reservar su espacio antes de que cargue? |
La puntuación global de rendimiento de Lighthouse es otro resumen. No representa el porcentaje de visitantes satisfechos. Tampoco una prueba de carga demuestra que todos los menús o formularios respondan bien: recorre esas tareas.
4. Pide localizar el problema y proponer una mejora concreta
Pide que se identifiquen la página afectada, el elemento o interacción que se retrasa, las pruebas y el cambio propuesto. «Instalar optimización» no define un alcance útil por sí solo.
Si la imagen principal tarda, pide comprobar cuándo se descubre, descarga y muestra. La guía oficial de optimización de LCP explica que la demora puede estar en la respuesta del servidor, la carga de recursos o la presentación en pantalla. Reducir el archivo de imagen puede dejar intacta otra demora.
Si un menú o filtro responde tarde, pide reproducir esa interacción. Si los botones se desplazan, pregunta qué contenido cambia la distribución. Cambiar de alojamiento debería apoyarse en pruebas de que la respuesta del servidor contribuye al problema; la puntuación por sí sola no lo demuestra.
Revisa el chat, los vídeos incrustados y otras funciones opcionales con quien toma las decisiones del negocio. Quitar una vía de contacto puede mejorar una prueba y reducir la utilidad de la web. Acuerda qué función puede cambiar y comprueba que sigue cumpliendo su propósito.
5. Compara la reparación en condiciones equivalentes
Acuerda las páginas y las tareas antes de comenzar. Conserva una copia recuperable del sitio actual y prueba los cambios fuera de la web pública cuando sea posible. La lista de copias de seguridad y restauración explica qué comprobar antes de confiar en esa copia.
Repite el mismo informe móvil y las mismas tareas después de la reparación. Mantén comparables las URL, el modo de dispositivo y las condiciones; si los resultados varían, revisa más de una ejecución. Compara el indicador afectado y el comportamiento visible, sin escoger únicamente la mejor puntuación global.
Comprueba el menú, la información de productos, las imágenes, el cambio de idioma y el contacto. Si hay un formulario, utiliza la guía de diagnóstico de formularios para distinguir una interfaz que funciona de una consulta recibida. Envía pruebas solo en formularios propios o para los que tengas permiso.
Los datos históricos de visitantes no pasan a medir exclusivamente la nueva versión nada más publicarla. Identifica las pruebas inmediatas como pruebas actuales y vuelve a consultar los datos reales cuando incluyan de forma significativa la reparación.
6. Guarda una breve acta de aceptación
Una entrega útil incluye el síntoma original, las URL afectadas, los informes anteriores y posteriores, los cambios, las tareas comprobadas y las limitaciones pendientes. Asigna quién volverá a revisar tras añadir un vídeo pesado, modificar una plantilla o instalar un elemento externo.
Acepta la reparación cuando el problema acordado mejore con pruebas y las tareas del cliente sigan funcionando. Si solo mejora la puntuación, pregunta qué ha cambiado para quien usa la página. Si el problema visible persiste, mantenlo pendiente aunque el informe sea mejor.
La guía de experiencia de página de Google indica que unos buenos resultados en los informes no garantizan los primeros puestos en las búsquedas. Registra una mejora de rendimiento como tal. La visibilidad y las consultas necesitan pruebas propias.
