Qué significa rápido
Por qué 'rápido' no es una propiedad del sitio sino de una experiencia concreta, y cómo convertir esa ambigüedad en cantidades medibles.
La frase “el sitio va rápido” no significa nada hasta que dices rápido para quién, haciendo qué, y medido cómo. El mismo despliegue puede ser instantáneo para ti en Madrid con fibra y un portátil de tres mil euros, y una tortura para un usuario en un Android de gama media con 4G saturada. Todo el track de rendimiento se apoya en esta distinción, así que conviene fijarla con precisión antes de tocar una sola línea de código.
- Distinguir el tiempo del servidor, el tiempo del navegador y el tiempo del usuario.
- Formular cualquier afirmación de rendimiento como una cantidad con unidad, condición y percentil.
- Identificar las tres variables que dominan la experiencia real: red, CPU del dispositivo y estado de la caché.
- Reconocer las cuatro formas más comunes de mentir con datos de rendimiento sin querer.
El sitio no tiene una velocidad
Un sitio web no posee un número de velocidad como un coche posee una potencia. Lo que existe son visitas concretas, cada una con su combinación de dispositivo, red, geografía, caché caliente o fría, y momento del día. La velocidad es una distribución, no un escalar.
Esto no es un tecnicismo académico. La distribución de tiempos de carga en la web real tiene una cola derecha larguísima: la mediana y el percentil 95 de un mismo sitio pueden diferir en un factor de cinco o diez. Si informas de la media, la cola te la tapa. Si informas de la mediana, ignoras a la mitad peor de tus usuarios, que es precisamente la que abandona. Por eso el estándar de la industria es el percentil 75, y por eso todas las métricas de este track llevan un percentil pegado.
Hay tres relojes distintos midiendo la misma carga, y confundirlos es el error de bulto más frecuente:
- El reloj del servidor. Cuánto tarda tu backend en generar la respuesta. Lo ves en los logs de tu aplicación. Es el único de los tres que controlas por completo, y también el que menos suele importar: en la mayoría de sitios es una fracción pequeña del total.
- El reloj del navegador. Desde que el usuario inicia la navegación hasta que la página está lista. Incluye DNS, conexión, TLS, transferencia, parseo, ejecución de scripts, layout y pintado. Aquí vive la mayor parte del tiempo.
- El reloj del usuario. Desde que decide ir a tu sitio hasta que percibe que puede empezar a hacer lo que venía a hacer. Es el único que produce dinero o lo destruye, y no coincide con ninguno de los dos anteriores.
Un caso concreto: un endpoint que responde en 40 ms según tus logs puede tener un TTFB de 900 ms para un usuario real. Los 860 ms que faltan son resolución de DNS, apertura de conexión TCP, negociación TLS, y el viaje físico de los paquetes. Nada de eso aparece en el log de tu aplicación, y todo eso lo sufre el usuario.
Cómo se formula una afirmación de rendimiento
Una afirmación de rendimiento que sirva para algo tiene cuatro componentes obligatorios. Faltando cualquiera, la frase es humo.
| Componente | Ejemplo malo | Ejemplo utilizable |
|---|---|---|
| Métrica | “carga rápido” | LCP |
| Cantidad y unidad | “mucho mejor” | 2,1 s |
| Población y percentil | “para los usuarios” | percentil 75 de sesiones móviles |
| Condición de medida | (ausente) | datos de campo, últimos 28 días, España |
Con eso, “el sitio va rápido” se convierte en “el LCP del percentil 75 en móvil en España fue de 2,1 s durante los últimos 28 días”. Esa frase se puede verificar, se puede comparar con la de la semana pasada, y se puede convertir en un objetivo.
El coste de no hacerlo es real. Sin percentil, cualquiera puede elegir el estadístico que le favorece. Sin condición de medida, comparas manzanas con naranjas: una medición en tu portátil con la caché caliente frente a la de un usuario en primera visita. Sin unidad explícita, un “35” puede ser una puntuación de Lighthouse, un número de peticiones o milisegundos.
El número grande de colorines de Lighthouse es una media ponderada de varias métricas de laboratorio, redondeada y comprimida por una curva log-normal. Sirve como resumen orientativo, no como objetivo. Optimizar la puntuación en vez de las métricas subyacentes lleva a decisiones absurdas: la diferencia entre 89 y 92 puede ser ruido de una sola ejecución, mientras que una mejora real de 400 ms en el LCP puede mover la puntuación apenas tres puntos.
Las tres variables que lo dominan todo
Cuando desglosas por qué dos usuarios del mismo sitio viven experiencias tan distintas, casi todo se explica con tres variables.
La red. No el ancho de banda, que es lo que todo el mundo cree, sino la latencia: el tiempo que tarda un paquete en ir y volver. Una carga de página típica necesita del orden de diez a veinte viajes de ida y vuelta secuenciales antes de mostrar contenido útil. Con un RTT de 20 ms eso son 200-400 ms; con un RTT de 200 ms, propio de una red móvil congestionada, son dos a cuatro segundos. Y esos segundos no los arregla contratar más megas. Este es el mito más caro del rendimiento web y lo desmontamos con números en el nivel 5.
La CPU del dispositivo. El coste de ejecutar JavaScript escala con la potencia del procesador, y el abanico de dispositivos reales es brutal. El mismo bundle que tarda 400 ms en parsearse y ejecutarse en un portátil de gama alta puede tardar cuatro segundos en un Android de gama media de hace tres años. Lighthouse aplica por defecto un multiplicador de CPU de 4x precisamente para aproximar ese salto desde el hardware del desarrollador.
El estado de la caché. Una primera visita descarga todo. Una segunda visita con una política de caché bien montada puede no tocar la red para nada más que el documento HTML. La diferencia entre ambas es de un orden de magnitud, y medir siempre con la caché caliente, que es lo que pasa cuando recargas tu propio sitio veinte veces seguidas, produce un optimismo delirante.
Cualquier medición que no fije estas tres variables no es reproducible. Cuando midas en laboratorio, fíjalas explícitamente. Cuando midas en campo, segméntalas para poder leer los datos.
Trabajas en local o contra un entorno de preproducción con red rápida, sin la capa de terceros que marketing inyecta en producción, con la caché caliente de haber recargado cien veces, en un ordenador que está en el percentil 99 de potencia, y conoces la interfaz de memoria, así que ni siquiera esperas a que aparezca el contenido para saber dónde está el botón. Esos cinco sesgos apilados no se suman, se multiplican. He visto equipos convencidos de que su portada cargaba en un segundo mientras el percentil 75 de campo estaba en seis. La única cura es no fiarse nunca del propio dedo: el juicio se emite sobre datos de campo, siempre, y el laboratorio se usa solo para averiguar la causa de lo que el campo ya ha señalado.
Cuatro formas de mentir sin querer
Las cuatro trampas siguientes aparecen en casi todos los informes de rendimiento que verás. Ninguna requiere mala fe.
Medir la media. La media de una distribución de cola larga la arrastran los valores extremos, pero de forma poco intuitiva: una media de 2,4 s puede corresponder a una mediana de 1,2 s con un 10% de usuarios en 15 s. Ni describe al usuario típico ni al usuario que sufre. Usa percentiles.
Medir solo la portada. La portada suele visitarla gente nueva, con la caché fría, y suele ser la página más optimizada porque es la que todo el mundo mira. Las páginas de detalle de producto, el buscador interno y el carrito son donde ocurre el negocio y donde nadie mira nunca.
Comparar antes y después sin controlar la población. Si despliegas una optimización el mismo día que arranca una campaña que trae tráfico de otro país o de otro tipo de dispositivo, la mezcla de usuarios cambia y el número se mueve por razones que no tienen nada que ver con tu cambio. Segmenta y compara segmento a segmento.
Confundir correlación con causa en el negocio. “Las sesiones rápidas convierten más” es cierto en casi todos los datos, pero parte del efecto es inverso: los usuarios con intención de compra recargan, navegan más y tienen la caché caliente, así que sus sesiones son rápidas porque están comprando. Aislar el efecto real exige un experimento, no una correlación.
Estas cuatro trampas no son un apéndice moral: son la razón por la que muchos proyectos de rendimiento se declaran victoriosos sin haber mejorado nada. El resto de este nivel construye el mapa conceptual que evita caer en ellas.