Probar en gama baja de verdad
Cómo elegir el dispositivo de referencia a partir de tus propios datos, el protocolo de medición que da resultados repetibles en un teléfono real, la depuración remota, y qué hacer cuando no hay dispositivo.
Todo lo anterior de este nivel converge en una recomendación muy poco sofisticada: compra un teléfono barato y úsalo. Cuesta menos que una licencia mensual de casi cualquier herramienta, encuentra clases de problema que ninguna simulación produce, y cambia la conversación de un equipo de una forma que ningún panel consigue. Lo que sí requiere método es medir con él de forma que los números signifiquen algo, porque un teléfono real es un instrumento ruidoso.
- Elegir el dispositivo de referencia a partir de la distribución real de tu tráfico.
- Aplicar el protocolo de medición que hace repetibles las medidas en un dispositivo real.
- Conectar la depuración remota para perfilar el dispositivo desde el escritorio.
- Sustituir el dispositivo real por la mejor alternativa cuando no hay ninguno.
Elegir el dispositivo
El error habitual es comprar el teléfono más barato que haya, bajo la teoría de que si funciona ahí funciona en todas partes. Produce una prueba que nadie usa, porque el resultado es tan malo que resulta imposible distinguir una regresión del ruido de fondo, y el equipo acaba desestimándolo como un caso extremo.
El criterio correcto es empírico: el dispositivo que representa el percentil 75 de tu tráfico, según la clasificación por índice de capacidad de la primera lección del nivel. Con ese histograma delante, la elección es un dato y no una opinión, y además es defendible cuando alguien pregunte por qué se prueba en ese aparato.
Tres reglas más para la compra:
Compra Android en el extremo bajo y iPhone en el medio. La cola lenta del parque es casi toda Android, y el motor de renderizado de iOS es distinto del de Android, así que hacen falta los dos. Un iPhone de hace cuatro o cinco generaciones sigue siendo bastante rápido, así que su función no es representar la lentitud sino el otro motor.
Compra usado y de hace tres o cuatro años. Es lo que tienen tus usuarios y cuesta una fracción.
Ten dos, no uno. Uno se queda como referencia estable y no se actualiza nunca, para poder comparar medidas a lo largo de los meses; el otro se mantiene al día. Sin un aparato congelado, cualquier comparación con una medida de hace seis meses está contaminada por las actualizaciones del sistema.
El protocolo de medición
Un teléfono es un instrumento con mucho ruido. Sin protocolo, dos medidas del mismo commit difieren un treinta por ciento y no hay forma de sacar conclusiones. El procedimiento que las estabiliza:
Antes de empezar. Aparato con la batería por encima del cincuenta por ciento y sin cargador, porque cargar calienta. Modo avión activado y wifi conectado, para que no lleguen notificaciones ni sincronizaciones. Brillo fijo y bajo, no automático. Sin funda. Cierra el resto de aplicaciones. Y dale al aparato cinco minutos de reposo si venías de usarlo.
Perfil del navegador. Ventana nueva sin nada más abierto. Decide explícitamente si mides con caché fría o caliente y anótalo: son dos escenarios distintos y los dos importan, pero mezclarlos arruina la serie.
La ejecución. Cinco pasadas mínimo. Descarta la primera siempre. Toma la mediana de las restantes, no la media, porque una sola pasada mala la desplaza entera. Y deja un minuto entre pasadas para que el aparato disipe calor; sin esa pausa estás midiendo la curva térmica de la lección anterior y no tu página.
El registro. Anota, junto a cada número, el modelo, la versión del sistema, la versión del navegador, si la caché estaba fría, el número de pasadas y la temperatura ambiente aproximada. Sin esos metadatos, la medida no se puede comparar con la del mes que viene, y una medida que no se puede comparar tiene la mitad del valor.
Fecha 2026-08-06
Dispositivo telefono de referencia A, sistema 14
Navegador version 139
Escenario portada, cache fria, wifi
Pasadas 5, descartada la primera
LCP mediana 4.180 ms (rango 3.910 - 4.640)
INP mediana 290 ms (rango 250 - 380)
Notas sin cargador, bateria 71 %, ambiente ~24 CEse formato tan aburrido es lo que convierte medidas sueltas en una serie temporal utilizable. La disciplina de anotar el rango además de la mediana es la que evita el error clásico de celebrar una mejora del cinco por ciento cuando el rango de variación es del veinte.
Depuración remota
Un teléfono no sirve solo para ver: sirve para perfilar, con las mismas herramientas del escritorio. La conexión funciona en los dos ecosistemas principales.
Para Android con un navegador basado en Chromium: activa las opciones de desarrollador y la depuración por USB en el teléfono, conéctalo, abre la página de inspección de dispositivos en el navegador del escritorio y autoriza el equipo. A partir de ahí tienes el panel completo —red, rendimiento, memoria— operando sobre lo que ocurre en el teléfono. Es la configuración más valiosa de este nivel, porque un perfil de rendimiento grabado en el dispositivo real enseña cosas que ningún multiplicador reproduce: los tiempos reales de descodificación de imagen, el coste real de la composición, el comportamiento real del recolector de basura con memoria escasa.
Para iOS: activa el menú de desarrollo en el navegador del escritorio en macOS y la inspección web en los ajustes del teléfono, conéctalo por cable y aparecerá en el menú de desarrollo. El inspector remoto ofrece el panel de línea temporal y el de red sobre el dispositivo real.
Dos avisos. El primero: la depuración remota añade sobrecarga, sobre todo al grabar perfiles. Los tiempos absolutos con el inspector conectado son peores que sin él, así que las cifras oficiales se toman sin depurador y el depurador se usa para entender la forma del problema, no para medir. El segundo: la conexión por cable puede cargar el aparato, con lo que vuelve el efecto térmico. Algunos sistemas permiten limitar la carga; si no, ten en cuenta que una sesión larga de depuración calienta.
Y una herramienta que no requiere ningún cable y que conviene tener: los servicios de prueba que ejecutan tu página en dispositivos físicos en localizaciones reales, con vídeo de la carga y trazas completas. Es lo que va en la ejecución nocturna del nivel siguiente, y su ventaja sobre cualquier simulación es que la red y el aparato son de verdad.
Cuando no hay dispositivo
Situaciones reales: un equipo distribuido, un aparato que no cubre el mercado que te interesa, o una organización donde comprar hardware lleva seis semanas. La escalera de sustitutos, del mejor al peor:
Un servicio con dispositivos físicos remotos. Lo más cercano a tener el aparato. La pega es que suelen estar en centros de datos con conexiones excelentes, así que reproducen bien la CPU y mal la red.
Un emulador de Android con la CPU limitada. Mejor que nada para comprobar comportamiento, y poco fiable para tiempos: un emulador ejecuta sobre tu procesador con una capa de traducción cuyo coste no se parece al de ningún teléfono.
Tu portátil con el multiplicador calibrado. Lo que da la lección de limitación de este nivel. Es la opción práctica para el trabajo diario, con la condición de haber calibrado contra un aparato real al menos una vez. Un multiplicador calibrado hace seis meses contra un teléfono conocido vale mucho más que un multiplicador por defecto.
El campo como sustituto del laboratorio. Si no puedes reproducir, mide. Segmentar tus datos reales por clase de dispositivo te da la verdad sobre el resultado, aunque no te ayude a iterar rápido. Es lento pero no miente, y en ausencia de hardware es lo más honesto.
Lo que no vale como sustituto: probar en el teléfono de gama alta del desarrollador y llamarlo “probar en móvil”. Confirma que todo está bien y no detecta nada, que es la peor propiedad posible en una prueba.
Merece la pena entender por qué esta recomendación tan poco tecnológica tiene un efecto desproporcionado, porque la razón no es la que parece. Un teléfono de gama baja no mide mejor que tu instrumentación: mide peor, con más ruido, más lento y con menos precisión. Su valor no está en el eje de la medida sino en el de la convicción, y ese eje es el que suele estar bloqueado. Piensa en cómo se toman de verdad las decisiones que empeoran el rendimiento. Nadie decide nunca “vamos a hacer la aplicación más lenta”. Se decide añadir una biblioteca que resuelve un problema real, incluir una funcionalidad que alguien ha pedido, meter una etiqueta que el equipo de marketing necesita. Cada una de esas decisiones se toma comparando un beneficio concreto, vívido y atribuible a una persona con nombre, contra un coste abstracto, difuso, expresado en unidades que nadie de la sala experimenta jamás. En esa comparación el coste pierde siempre, y pierde con independencia de lo buena que sea tu instrumentación, porque el problema no es que el número sea desconocido: es que el número no significa nada emocionalmente para quien decide. Un teléfono en la mesa arregla exactamente eso y nada más. Cuando la persona que pide la funcionalidad la ve tardar once segundos en el aparato que tiene su propia madre, la comparación deja de ser entre algo concreto y algo abstracto y pasa a ser entre dos experiencias. He visto revertir en una tarde decisiones que llevaban meses defendiéndose con argumentos, sin que nadie enseñara un solo gráfico, simplemente porque alguien pasó el teléfono al otro lado de la mesa. De ahí salen tres prácticas que valen más que su coste ridículo. Una: que el aparato esté físicamente visible, no en un cajón. Un teléfono en un cajón se usa una vez. Dos: que la revisión de cualquier funcionalidad nueva incluya verla en él antes de darla por terminada, como parte del ritual, no como una tarea aparte que se salta cuando hay prisa. Y tres: que en las demostraciones a dirección se enseñe ahí y no en el portátil. Esa última es la que más incomoda y la que más resultados da, porque alinea de golpe los incentivos de todo el mundo: cuando la demostración trimestral se hace en el aparato del percentil 75, el rendimiento deja de ser un tema de ingeniería y pasa a ser una condición de que la demostración salga bien, que es una categoría de prioridad completamente distinta.
- Saca de tus datos de campo el índice de capacidad del percentil 75 y elige el modelo que corresponde. Cómpralo usado.
- Escribe el protocolo de medición en una página y ejecútalo entero sobre tu portada. Anota mediana y rango.
- Configura la depuración remota y graba un perfil de rendimiento de tu ruta más pesada directamente en el dispositivo.
- Compara ese perfil con el que obtienes en tu portátil con el multiplicador calibrado. Anota las tres diferencias más grandes.
- Deja el teléfono a la vista y haz la próxima demostración en él.