Cómo probar su web en móviles
Pruebe páginas representativas y el recorrido real de contacto, reserva o compra. Use PageSpeed y Lighthouse para rendimiento, emulación para diseño y un teléfono para interacción. Distinga puntuaciones de laboratorio, datos reales y tareas completadas. Registre URL, estado, dispositivo y ajustes, y repita las mismas pruebas tras corregir
Para comprobar si su web funciona en móviles, combine un informe de rendimiento con una prueba práctica de la tarea del visitante. Una página rápida puede tener un botón de envío inaccesible. Un diseño adaptable puede perder los datos de
Google retiró su Mobile-Friendly Test y su API en diciembre de 2023. PageSpeed Insights, Lighthouse, la emulación del navegador y un teléfono real cubren aspectos diferentes. Ninguno certifica por sí solo que una web sea usable, accesible o vaya a
Elija las páginas y acciones importantes
Seleccione la página de inicio, una página principal de producto o servicio y un artículo. Incluya el recorrido real de contacto, reserva o compra, aunque pase por otro dominio. Pruebe los idiomas pertinentes y distintos estados: primera visita con aviso de consentimiento, visita posterior, menú abierto y formulario
Nuestro comprobador móvil gratuito sirve como revisión inicial opcional. Examina el HTML obtenido y la información de respuesta para detectar indicios como la ausencia de una etiqueta viewport, anchos fijos definidos en línea o texto muy pequeño con estilos en línea. No renderiza la página ni ejecuta su JavaScript ni calcula el diseño a partir de hojas de estilo externas. El tamaño del HTML no es el total descargado, y el tiempo de obtención no es el tiempo de carga en un teléfono. Confirme las alertas en
| Comprobación | Para qué sirve | Qué no demuestra |
|---|---|---|
| PageSpeed Insights | Rendimiento de usuarios reales cuando hay datos, más una prueba Lighthouse | Que todos los menús, formularios y pagos funcionen |
| Lighthouse en Chrome | Diagnóstico reproducible, incluso de páginas accesibles localmente | Rendimiento de toda la población de visitantes |
| Modo dispositivo de DevTools | Diseño, ajuste de texto y elementos superpuestos | Comportamiento exacto de un teléfono físico |
| Search Console | Problemas de Core Web Vitals en grupos de URL | Un inventario completo de errores de uso o accesibilidad |
| Teléfono real | Interacción táctil, teclado, navegador y realización de una tarea | Cobertura de todos los dispositivos y visitantes |
Distinga los dos resultados de PageSpeed
Abra PageSpeed Insights, introduzca la URL pública y
Los datos de campo proceden del Chrome UX Report y abarcan los 28 días anteriores. Compruebe si el encabezado indica «Esta URL» u «Origen». Si faltan datos suficientes de la URL, PageSpeed puede mostrar los del origen, que reúne páginas con el mismo protocolo, nombre de host y puerto. Que el origen apruebe no demuestra que esa página concreta lo haga. Si faltan datos en ambos niveles, la ausencia de evaluación no equivale a
La sección de laboratorio es una nueva prueba Lighthouse en condiciones simuladas. Sirve para investigar un recurso lento o un script que bloquea trabajo. Su puntuación de rendimiento es independiente de la evaluación de campo. Una sola prueba de navegación no mide el INP de sus visitantes. Google explica estas diferencias.
Este ejemplo guardado muestra datos de campo del origen: LCP de 2,4 segundos, INP de 112 milisegundos y CLS de 0. No contiene una puntuación de rendimiento Lighthouse. Ilustra cómo leer el alcance del informe; no es una medición actual de nuestra página
Qué significan los umbrales de Core Web Vitals
Estas categorías utilizan el percentil 75 de las mediciones de campo correspondientes, no
| Métrica | Bueno | Necesita mejorar | Deficiente |
|---|---|---|---|
| LCP: aparece el contenido principal | ≤ 2,5 s | > 2,5 a 4 s | > 4 s |
| INP: respuesta a una interacción | ≤ 200 ms | > 200 a 500 ms | > 500 ms |
| CLS: cambios inesperados de posición | ≤ 0,1 | > 0,1 a 0,25 | > 0,25 |
Para aprobar la evaluación completa, las tres métricas deben ser buenas. PageSpeed también puede aprobar cuando faltan datos de INP si LCP y CLS son buenos. La falta de datos suficientes de LCP o CLS impide la evaluación. Esta es la regla documentada de PageSpeed; no sustituye las pruebas
Compare Search Console con el mismo alcance
En Search Console, abra Core Web Vitals y el informe móvil. Revise el grupo afectado, su peor métrica y las URL de ejemplo. Google agrupa páginas con experiencias similares; esos grupos no tienen por qué coincidir con sus plantillas. Reproduzca el problema antes de atribuirlo a un
PageSpeed y Search Console pueden discrepar incluso al comparar solo datos de campo. Compruebe URL, origen o grupo, dispositivo, periodo y tratamiento de las URL. Search Console distingue los parámetros de URL, mientras que los datos de campo de PageSpeed se agregan sin ellos. No explique todas las diferencias como «laboratorio frente a usuarios reales». La documentación del informe describe
Tras publicar una corrección, repita de inmediato los mismos pasos y ajustes de laboratorio. Los resultados de campo cambian al incorporarse visitas nuevas al periodo de 28 días, que se renueva diariamente. «Iniciar seguimiento» abre una validación de 28 días; no fuerza el rastreo ni la reindexación. Los datos mostrados pueden cambiar antes de esos 28 días, aunque la validación sigue necesitando su periodo de seguimiento y
Registre los ajustes de Lighthouse
Abra la página en Chrome, abra DevTools, elija Lighthouse y seleccione Móvil antes de ejecutar la auditoría. Lighthouse local puede probar páginas con sesión iniciada a las que una petición pública de PageSpeed no accede. La documentación de Lighthouse explica
Guarde el informe, fecha, URL, versión de Lighthouse, perfil de dispositivo, limitación de velocidad y versión de la página. Mantenga constantes esas condiciones para comparar un cambio y repita los resultados sorprendentes. La máquina, el navegador, el consentimiento y la configuración pueden alterar las mediciones. Ralentizar manualmente el procesador en DevTools no garantiza reproducir la simulación
Automatice una prueba con la API PageSpeed
Este comando Bash solicita diagnósticos móviles de rendimiento, accesibilidad y SEO. Sustituya la URL por una
curl --get \
'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
--data-urlencode 'url=https://example.com/' \
--data-urlencode 'strategy=mobile' \
--data-urlencode 'category=performance' \
--data-urlencode 'category=accessibility' \
--data-urlencode 'category=seo'En Windows, utilice una terminal Bash para esta sintaxis multilínea. La guía de inicio documenta el acceso y recomienda una clave para consultas automatizadas frecuentes. Revise la cuota del proyecto antes de programar lotes. Un error HTTP, incluida una respuesta de cuota, no es una auditoría fallida de
Dentro de lighthouseResult, lea categories y audits; una puntuación de categoría de 0.92 equivale a 92 sobre 100. Guarde fetchTime, lighthouseVersion, requestedUrl, finalUrl y configSettings, y gestione runtimeError antes de aceptar el resultado. Consulte la referencia de respuestas. Para monitorizar datos de campo, Google recomienda CrUX API o CrUX History API porque prevé retirar los datos CrUX de la
Pruebe la tarea en navegador y teléfono
Active la barra de dispositivos de DevTools y empiece con 360 × 800 y 390 × 844 píxeles CSS. Cambie gradualmente el ancho y pruebe la orientación horizontal. El modo dispositivo es una aproximación; termine en dispositivos físicos y navegadores relevantes para sus visitantes, incluido Safari en iPhone
- Abra y cierre navegación, controles de consentimiento y cuadros de diálogo. Compruebe que cabeceras fijas y avisos no tapen contenido ni botones.
- Lea títulos largos, tablas y traducciones. Pruebe el zoom y un diseño estrecho. El criterio de redistribución de las pautas de accesibilidad web (WCAG) utiliza 320 píxeles CSS para contenido con desplazamiento vertical, equivalentes a una ventana de 1280 píxeles con zoom al 400 %. Las tablas realmente bidimensionales tienen una excepción: conserve la lectura y el desplazamiento utilizable, en lugar de ocultar lo que sobresale.
- Toque controles próximos y utilice el teclado cuando sea compatible. El criterio de tamaño de objetivo WCAG 2.2 AA usa 24 × 24 píxeles CSS, con excepciones por separación y otros motivos. Controles mayores, como 48 × 48, pueden resultar cómodos. Ninguna cifra demuestra por sí sola conformidad de accesibilidad.
- Rellene el formulario con el teclado virtual abierto. Compruebe etiquetas, foco, errores, conservación de datos, envío y confirmación. Para compras o reservas, use un entorno de pruebas autorizado y verifique el recibo o registro correspondiente.
- Repita en una conexión móvil representativa. Un retraso de carga o una petición fallida debe permitir recuperarse de forma clara.
Un informe de error útil es específico. Ejemplo hipotético: «En la reserva a 390 × 844, el teclado y el aviso de consentimiento tapan Enviar. La página se desplaza, pero el botón sigue inaccesible». Adjunte URL, navegador, dispositivo, estado, pasos, captura, resultado esperado y responsable. Una reserva bloqueada merece atención aunque el rendimiento aparezca
Corrija la causa medida
Si el LCP es lento, identifique el elemento principal real y el motivo de su retraso. Si es una imagen, facilite su detección temprana y evite cargarla de forma diferida. Precargue solo los recursos que necesiten descubrirse antes, no todas las imágenes y fuentes. La guía de LCP explica
Para interacciones lentas, registre la acción e investigue el trabajo bloqueante. Reduzca scripts innecesarios o divida tareas largas, conservando las funciones necesarias y el consentimiento. Para cambios de posición, reserve espacio para imágenes, elementos incrustados y contenido añadido. Las guías de INP y CLS diagnostican estos
En WordPress o Shopify, pruebe cada cambio de tema o aplicación en un entorno de pruebas con el mismo contenido y recorrido. Mida su efecto antes de culpar a todos los complementos o proponer una reconstrucción. Algunas correcciones son ajustes; otras requieren modificar componentes. Nuestro servicio de optimización web puede ayudar a identificar y realizar ese trabajo, con desarrollo web cuando haga falta
Separe indexación y usabilidad
Google recomienda el diseño adaptable para la indexación móvil, pero admite otras configuraciones. Asegure que Googlebot acceda al contenido, las imágenes y los metadatos móviles. Una página usable puede tener un problema de indexación que requiera una investigación SEO aparte.
Las métricas Core Web Vitals intervienen en los sistemas de posicionamiento, pero buenos resultados no garantizan posiciones altas, y una mala puntuación no demuestra una penalización. La guía de experiencia de página de Google las sitúa dentro de la utilidad general de
Conserve un registro práctico: problema encontrado, cambio publicado, tarea repetida con éxito y validación de campo pendiente. Revise los recorridos afectados tras cambios de tema, aplicación, formulario o etiquetas. Obtener una evaluación positiva y permitir que el visitante complete su tarea son