Los siete mitos que hay que desmontar
Las creencias falsas más extendidas sobre rendimiento web, por qué son intuitivas, y qué dicen realmente los datos.
El rendimiento web está lleno de intuiciones que fueron ciertas hace quince años, o que nunca lo fueron pero suenan razonables. Cada una de ellas ha costado meses de trabajo mal dirigido en algún equipo. Las repaso aquí, al final del nivel de ontología, porque desmontarlas es requisito para que el mapa de causas y remedios se aplique bien.
- Refutar con datos las siete creencias falsas más costosas sobre rendimiento web.
- Explicar por qué el ancho de banda deja de importar por encima de cierto umbral.
- Distinguir entre una optimización prematura y una decisión de arquitectura reversible.
- Argumentar el caso del rendimiento sin recurrir a cifras de estudios ajenos.
Mitos sobre la red
Mito 1: con más ancho de banda todo va más rápido. Es la creencia más extendida y la más falsa. Las mediciones que sustentan esta afirmación llevan más de una década publicadas: por encima de unos 5 Mbps, aumentar el ancho de banda apenas mejora el tiempo de carga de una página, mientras que reducir la latencia lo mejora de forma casi lineal. El motivo es estructural: la carga de una página es una secuencia de esperas, no una transferencia continua. Si tu página necesita quince viajes de ida y vuelta secuenciales, con 100 ms de RTT vas a pagar un segundo y medio solo en esperar, y ese segundo y medio es idéntico con 10 Mbps que con 1 Gbps. El nivel 5 desarrolla la aritmética completa.
Mito 2: hay que reducir el número de peticiones. Fue un mandamiento correcto con HTTP/1.1, donde cada petición necesitaba su propia conexión y el navegador limitaba a unas seis conexiones simultáneas por origen. Con multiplexación en HTTP/2 y HTTP/3, muchas peticiones pequeñas sobre una conexión abierta cuestan poco. Lo que sigue costando caro es abrir conexiones a orígenes nuevos, porque eso reintroduce DNS, TCP y TLS. La regla moderna no es “menos peticiones” sino “menos orígenes y mejor prioridad”.
Mito 3: una CDN arregla el rendimiento. Una CDN reduce la distancia física y por tanto el RTT, lo cual ataca la causa 1. No toca el bloqueo del renderizado, ni el hilo principal, ni la estabilidad del layout. Un sitio con 2 MB de JavaScript servido desde el borde sigue siendo un sitio con 2 MB de JavaScript. La CDN es necesaria y no es suficiente.
Mitos sobre el código
Mito 4: un kilobyte es un kilobyte. Falso por un factor grande. Un kilobyte de imagen se descarga y se decodifica; un kilobyte de JavaScript se descarga, se parsea, se compila y se ejecuta, y las tres últimas fases ocurren en el hilo principal. En un dispositivo de gama media, el coste de procesar JavaScript puede ser varias veces el de descargarlo. Por eso las mismas cifras de peso total pueden corresponder a experiencias radicalmente distintas según la mezcla de tipos de recurso.
Mito 5: la optimización prematura es la raíz de todo mal. La cita de Knuth se usa habitualmente fuera de contexto para justificar no pensar en rendimiento hasta el final. El propio Knuth añadía inmediatamente que no hay que dejar pasar las oportunidades del 3% crítico. En rendimiento web la distinción útil es otra: hay decisiones reversibles y decisiones estructurales. Ajustar la calidad de una imagen es reversible en cinco minutos. Elegir una estrategia de renderizado que exige hidratar toda la página en el cliente no es reversible: condiciona el INP de por vida y cambiarlo significa reescribir. Aplazar lo reversible es sensato. Aplazar lo estructural es contraer una deuda que se paga con intereses.
Mito 6: si va bien en mi máquina, va bien. Es el sesgo del desarrollador en estado puro, y lo cuantifica la propia configuración de las herramientas: Lighthouse aplica por defecto un multiplicador de CPU de 4x para aproximar un móvil de gama media desde un escritorio potente, y limita la red a 150 ms de latencia con 1,6 Mbps de bajada, un perfil que representa aproximadamente el percentil 85 de las conexiones móviles. Si tu entorno de desarrollo no aplica nada de eso, estás midiendo un escenario que casi ningún usuario vive.
El propio proyecto Lighthouse documenta que 4x mueve un escritorio de gama alta al rango de móvil de gama media, pero que la relación depende del hardware anfitrión, y publica un índice de referencia por cada informe para que puedas calibrarlo. Si tu equipo de desarrollo trabaja con máquinas muy distintas entre sí, los números de laboratorio no son comparables entre personas sin calibrar antes ese multiplicador.
Mitos sobre la medición
Mito 7: si las tres Core Web Vitals están en verde, el sitio va bien. Las tres métricas cubren una fase cada una y dejan territorio sin medir. No hay ninguna Core Web Vital que mida la fluidez del scroll, la transición entre vistas de una aplicación de una sola página, el consumo de memoria, ni el tiempo hasta que un formulario complejo es realmente operativo. Además, el INP solo observa clic, toque y pulsación de tecla; una página con un scroll a tirones y un zoom que se atasca puede tener un INP impecable. Verde significa “no tienes los tres problemas más comunes”, no “no tienes problemas”.
Hay un corolario incómodo de este mito. Como las tres métricas alimentan una señal de posicionamiento en buscadores, es fácil que la organización las convierta en el objetivo. En cuanto una métrica se vuelve objetivo, deja de ser buena métrica: aparecen los atajos que mueven el número sin mover la experiencia. Retrasar la aparición del contenido para que el elemento LCP sea uno más pequeño es el ejemplo canónico, y funciona: baja el LCP y empeora la experiencia.
Todos los mitos anteriores son técnicos y se refutan con datos. El octavo es organizativo y no se refuta con datos, sino con estructura. Un equipo hace un sprint de rendimiento, baja el LCP de 4,2 a 2,1 segundos, celebra, y en cinco meses está otra vez en 3,8 sin que nadie haya hecho nada obviamente malo: se ha añadido una fuente, un script de marketing, un carrusel, un banner de consentimiento. El rendimiento se degrada por acumulación de decisiones individualmente razonables, exactamente igual que la deuda técnica. La única defensa que he visto funcionar es hacer que la degradación sea visible en el momento en que ocurre y no cinco meses después: un presupuesto que rompe la integración continua cuando el bundle crece por encima del umbral, un panel con el percentil 75 de campo que alguien mira cada semana, y la regla de que quien añade un script de terceros presenta su coste medido. Sin esos tres mecanismos, cualquier trabajo de rendimiento tiene fecha de caducidad y la fecha es corta.
Cómo argumentar el caso sin citar estudios ajenos
Se citan mucho estudios de grandes empresas que correlacionan milisegundos con conversión. Son útiles para abrir una conversación y peligrosos para cerrarla, porque tu sitio no es el suyo: distinta audiencia, distinto dispositivo, distinto margen. Alguien lo señalará y tendrá razón.
El argumento sólido se construye con tus propios datos y no necesita más que la instrumentación que montamos en el nivel 4:
- Segmenta tus sesiones por métrica. Agrupa las visitas por su LCP en tres cubos, por ejemplo por debajo de 2,5 s, entre 2,5 y 4, y por encima de 4. Calcula la tasa de conversión de cada cubo con tus datos.
- Enseña la forma de la curva, no un solo número. Casi siempre aparece una relación monótona, y verla dibujada con datos propios convence más que cualquier cifra externa.
- Advierte tú mismo del sesgo antes de que lo haga otro. Parte de la correlación es inversa: los usuarios con intención de compra recargan más y tienen la caché caliente. Decirlo tú da credibilidad al resto del argumento.
- Propón un experimento acotado. Una página, una optimización, medición antes y después con la población controlada. Un resultado propio, aunque sea pequeño, vale más que diez estudios ajenos.
Con esto cierra el nivel de ontología. Ya tienes el vocabulario, el mapa de fases, la cadena de causas, el catálogo de remedios y las trampas. El nivel siguiente baja al terreno de lo que el usuario percibe realmente, que es donde estaban los umbrales que justifican todos los números del resto del track.