Velocidad web: cuándo mueve dinero de verdad y cómo comprobarlo con Semalt

Pocas conversaciones de marketing digital se han vuelto tan supersticiosas como la de la velocidad. Hay empresas que llevan meses persiguiendo una cifra verde en una herramienta de laboratorio mientras su ficha de producto tarda seis segundos en mostrar el precio a un usuario real con red móvil en el metro.

Este artículo intenta poner orden: qué mide cada cosa, cuándo la velocidad afecta al negocio de verdad, y qué intervenciones tienen retorno frente a las que solo mueven la puntuación.

Laboratorio y campo: dos cosas que se confunden a diario

Una herramienta de laboratorio carga tu página en condiciones controladas y devuelve una puntuación. Es útil para diagnosticar, porque señala qué recursos pesan y qué bloquea el renderizado. Pero no describe la experiencia de nadie en concreto.

El dato de campo procede de usuarios reales, con sus dispositivos, sus redes y sus ubicaciones. Es el que se correlaciona con el comportamiento: abandono, páginas por sesión, conversión. Cuando ambos no coinciden, gana el de campo, siempre.

Primero el mapa, después el motor

Antes de tocar una línea de código conviene saber qué páginas importan. Con los datos de búsqueda se obtiene en media hora: qué URLs reciben impresiones y clics, cuáles concentran las consultas comerciales y cuáles se llevan la mayor parte del tráfico móvil.

Las intervenciones que sí devuelven dinero

Ordenadas por relación entre esfuerzo y resultado, según lo que vemos en proyectos reales de comercio y servicios.

Imágenes. Sigue siendo el primer problema en la mayoría de sitios: fotos de producto de varios megas servidas a un móvil. Formato moderno, dimensiones declaradas y carga diferida de lo que está fuera de pantalla resuelven una parte enorme del problema sin tocar la arquitectura.

Scripts de terceros. Chats, mapas, píxeles de publicidad, pruebas A/B, banners de consentimiento. En auditorías es habitual encontrar entre ocho y quince scripts, la mitad heredados de campañas terminadas hace años. Retirar los que ya no se usan es gratis y suele ser la mejora más grande.

Estabilidad visual. Los saltos de contenido mientras carga la página no solo molestan: provocan clics erróneos y abandono. Reservar espacio para imágenes, anuncios y avisos evita la mayoría.

Tiempo de respuesta del servidor. Si el servidor tarda en entregar el HTML, ninguna optimización posterior compensa. Suele ser cuestión de caché mal configurada más que de potencia contratada.

Móvil real frente a móvil simulado

Hay una diferencia enorme entre abrir el sitio en el móvil conectado a la wifi de la oficina y abrirlo como lo abre un cliente: con datos, con la batería en ahorro de energía, en movimiento y con quince pestañas abiertas. Casi todos los problemas graves de experiencia que hemos encontrado aparecen en el segundo escenario y son invisibles en el primero.

La prueba que recomendamos es tan simple como incómoda: salir del edificio, caminar dos manzanas y completar en el móvil la acción que genera ingresos. Comprar, pedir presupuesto, reservar. Lo que falle ahí es la lista de prioridades del trimestre, por delante de cualquier informe automático.

Cuándo la velocidad no es el problema

Hay situaciones en las que invertir en velocidad no cambia nada, y conviene reconocerlas antes de gastar.

Si la página ya carga por debajo de dos segundos y medio en campo, la mejora adicional tiene un efecto marginal: el cuello de botella está en el contenido, en el precio o en la propuesta. Si la página no recibe visitas porque no está posicionada ni indexada, la velocidad es irrelevante hasta que exista tráfico. Y si el formulario pide catorce campos, ningún milisegundo va a arreglar la conversión.

El coste oculto de las herramientas de terceros

Merece un apartado propio porque es, con diferencia, el problema más extendido y el más fácil de resolver. En las auditorías de rendimiento que hacemos en comercios y webs de servicios, el patrón se repite: entre ocho y quince scripts externos cargando en cada página, sin que nadie recuerde para qué está la mitad.

El inventario se hace en una tarde. Se listan todos los scripts que carga la página principal y una ficha de producto, y para cada uno se responde a tres preguntas: qué hace, quién lo usa dentro de la empresa y qué pasaría si se retira. La tercera es la clave, porque obliga a encontrar a alguien que defienda cada herramienta. Las que nadie defiende se retiran.

Lo que suele aparecer: píxeles de campañas terminadas hace años, dos sistemas de analítica midiendo lo mismo, un chat que nadie atiende desde hace meses, herramientas de pruebas A/B sin pruebas activas y widgets de reseñas que cargan iframes pesados. Retirar lo que sobra no cuesta dinero, no requiere rediseño y suele mejorar la experiencia real más que cualquier optimización de código.

Comercio electrónico: dónde duele de verdad

En una tienda, el impacto de la velocidad no se reparte por igual entre las páginas. Se concentra en tres momentos, y son los que hay que medir por separado.

El primero es la ficha de producto en móvil, porque es donde el usuario decide. Si el precio, la disponibilidad y el botón de compra no aparecen en el primer pantallazo y en menos de tres segundos, la mejora en cualquier otra parte del sitio es secundaria.

El segundo es la navegación por filtros en categorías grandes. Cada aplicación de filtro que tarda varios segundos multiplica el abandono, y además suele ser el punto donde se generan direcciones que no deberían indexarse.

El tercero es el proceso de compra. Aquí el problema rara vez es técnico: son campos innecesarios, validaciones que borran datos y pasos que piden crear cuenta antes de saber el coste de envío. Ninguna optimización de milisegundos compensa un formulario mal diseñado, y conviene decirlo cuando la conversación se centra solo en la puntuación.

Cómo lo miden realmente los buscadores

La experiencia de página es una señal entre muchas, y no la más determinante. Entre dos páginas con contenido equivalente, la más rápida tiene ventaja; entre una página lenta con la respuesta exacta y una rápida sin ella, gana la primera casi siempre.

Donde la velocidad tiene un efecto indirecto claro es en el rastreo: un servidor lento reduce la cantidad de páginas que se revisan en cada visita, lo que en catálogos grandes retrasa el descubrimiento de contenido nuevo. Eso se comprueba en el módulo de indexación, enviando URLs recién publicadas y observando cuánto tardan en recibir visitas verificadas de rastreadores.

Qué medir cuando el sitio ya es rápido

Si el dato de campo confirma que las páginas importantes cargan bien, seguir invirtiendo en milisegundos tiene retorno decreciente. En ese punto la atención debe moverse a lo que sí sigue bloqueando la conversión: claridad del precio, condiciones de envío visibles, número de pasos hasta completar la acción y calidad de la información en la propia página.

Un plan de trabajo de seis semanas

Semana uno: mapa de páginas que importan y medición de campo solo en esas. Semanas dos y tres: imágenes y scripts de terceros, que suelen concentrar el ochenta por ciento de la mejora posible. Semana cuatro: estabilidad visual y tiempos de servidor. Semanas cinco y seis: medición de nuevo, comparando con los valores iniciales, y decisión sobre si merece la pena continuar.

Ese último paso es el que casi nadie da y el que evita meses de trabajo estéril: si tras las intervenciones evidentes la mejora en conversión es nula, el problema estaba en otra parte y hay que dejar de optimizar.

Cómo justificar la inversión en velocidad

La conversación con dirección suele encallar porque se presenta una puntuación en lugar de un efecto. Lo que funciona es traducir el problema a las páginas que generan ingresos: cuántas visitas reciben al mes, qué porcentaje llega desde móvil y cuánto tarda hoy en aparecer el elemento que decide la compra.

Con esas tres cifras, la propuesta deja de ser técnica. No se pide presupuesto para “mejorar el rendimiento”, sino para que la ficha que recibe treinta mil visitas al mes muestre el precio en menos de dos segundos en lugar de en cinco. La primera formulación compite con cualquier otra petición del equipo técnico; la segunda se aprueba.

Y conviene acordar de antemano cómo se comprobará el efecto: la comparación de comportamiento en esas páginas concretas, cuatro semanas antes y cuatro semanas después, sin otros cambios simultáneos. Es la única forma de que la siguiente petición de presupuesto tenga precedente.

Preguntas frecuentes