Lista para comprobar el rendimiento móvil de una web de eventos
Una web rápida en el ordenador de la oficina puede ser lenta en el teléfono del asistente. La lista de BrowserStack propone objetivos, escenarios realistas, entorno, resultados y repetición. Esta versión se centra en el recorrido móvil de una persona; una prueba de carga de muchos usuarios es otra tarea.
Equipo editorial de Boletolibre
Publicado
1. Define tareas y resultado
Elige URL y pasos: leer fecha y lugar, abrir inscripción, llegar a entradas y entender confirmación. Una portada rápida no compensa una compra lenta o rota.
| Paso | Resultado esperado |
|---|---|
| Página | Fecha, lugar y precio legibles |
| Inscripción | Formulario de prueba usable |
| Entradas | Destino correcto y transición clara |
| Confirmación | Estado entendido por el usuario |
BrowserStack recomienda escenarios realistas, objetivos medibles y repetir después de corregir.[1]
2. Anota condiciones repetibles
- Registra fecha, versión, URL, teléfono o tamaño emulado, navegador y sistema.
- Prueba primera visita sin caché y, aparte, visita repetida si importa.
- Usa una red más lenta representativa y el mismo perfil para comparar; comprueba un teléfono real cuando puedas.
- Usa cuentas sintéticas y una ruta segura sin cobrar ni contactar a asistentes.
La simulación de CPU de DevTools depende del ordenador; es aproximación, no sustituto exacto del móvil real.[3]
| Ficha | Valor |
|---|---|
| URL y versión | ________ |
| Dispositivo, navegador y red | ________ |
| Caché y cuenta de prueba | ________ |
| Meta del recorrido | ________ |
3. Recorre la página con un teléfono
- Abre la página y observa cuándo se ven título e imagen principal y si se mueve el botón de compra.
- Encuentra fecha, precio y accesibilidad sin ampliar el cartel.
- Usa el formulario con datos ficticios y observa retrasos o envíos duplicados.
- Sigue el enlace externo; distingue retrasos de la web y del proveedor.
- Tras corregir, repite con las mismas condiciones.
Apunta el efecto en cada paso. Una mejora de puntuación no basta si el botón sigue oculto o responde tarde.
4. Distingue laboratorio de usuarios reales
PageSpeed Insights muestra una simulación de Lighthouse y, si hay suficientes visitas, datos reales de CrUX de los últimos 28 días. Una página nueva puede carecer de datos propios o mostrar solo el origen. No compares una medición de laboratorio de hoy con datos de campo anteriores como si fueran iguales.[2]
| Métrica | Qué observar |
|---|---|
| LCP | Aparición del contenido principal |
| INP | Respuesta a interacción real |
| CLS | Saltos del diseño |
| Laboratorio | Recursos que retrasan la ejecución |
Guarda fecha e indica si cada dato viene de laboratorio, página u origen.[2]
5. Asigna y repite
| Registro | Valor |
|---|---|
| Paso e incidencia | ________ |
| Dispositivo, red y evidencia | ________ |
| Impacto en asistentes | ________ |
| Responsable y cambio | ________ |
| Nueva prueba comparable | ________ |
Da prioridad a bloqueos del recorrido. Si el problema es de compra externa, asigna al proveedor. Pruebas con tráfico simultáneo requieren otro ejercicio autorizado.
Fuentes y lecturas
- Performance Testing ChecklistBrowserStack · Consultado
- About PageSpeed InsightsGoogle for Developers · Consultado
- Simulate mobile devices with Device ModeChrome for Developers · Consultado