La velocidad de carga que mataba conversiones · Serpion 009

El concesionario llevaba tres años online. Catálogo multimarca con unas ciento cuarenta fichas de vehículo, formularios de contacto en cada una y un flujo de tráfico orgánico que, hasta hacía poco, generaba entre quince y veinte solicitudes de prueba de conducción al mes. Nada espectacular, pero era un canal que funcionaba solo. Hasta que dejó de funcionar. En cinco semanas, las solicitudes desde móvil cayeron a menos de la mitad. Nadie había tocado nada. Ni el catálogo, ni los textos, ni la estructura. Algo se estaba desviando antes de tiempo.

Lo primero que miré fue el tráfico general. Las impresiones orgánicas seguían más o menos estables, con una caída leve del ocho por ciento en las últimas cuatro semanas. Pero los clics desde móvil habían bajado un treinta y cuatro por ciento. Era un desfase demasiado grande para venir del mismo sitio. Si las impresiones aguantaban, la gente seguía viendo los resultados. Pero no entraba. O entraba y se iba antes de hacer nada. La velocidad de carga era una sospecha obvia, sí, pero no quería cerrar ahí sin mirar qué más podía estar pasando.

La señal clara era esa: el sitio seguía apareciendo, pero algo rompía el camino entre la SERP y la conversión. Y lo rompía sobre todo en móvil. Eso descartaba muchas cosas, pero abría otras que no se ven a simple vista.

Números que bajan y velocidad de carga bajo sospecha

Arranqué con Google Search Console. Filtré por dispositivo y comparé las últimas cuatro semanas con el periodo anterior. Las cifras contaban una historia con dos versiones.

En escritorio, una caída moderada que no seguía el mismo patrón que en móvil. En móvil, un desplome que no tenía una explicación obvia en los datos de posiciones. Las posiciones medias habían empeorado algo, pero no lo bastante como para explicar esa diferencia de clics. El CTR móvil había caído un tercio. La gente veía el resultado, pero algo la frenaba antes de llegar al contenido o justo al aterrizar.

Mi primera hipótesis fue que alguna actualización del sistema había roto el renderizado en móvil. Había visto casos donde un cambio menor en la plantilla generaba un layout shift que destrozaba la experiencia sin que nadie lo notara desde escritorio. Revisé el HTML renderizado en varias fichas de vehículo usando navegación en modo incógnito desde un dispositivo real. El diseño cargaba correctamente. Los elementos interactivos respondían. El formulario de contacto estaba visible y funcional. No había errores de consola relevantes ni capas que bloquearan la interacción.

Descarté esa pista. Si el problema fuera de renderizado o de layout, habría señales visibles: elementos desplazados, botones inaccesibles, contenido que no se mostraba. Aquí no pasaba nada de eso. El sitio se veía bien. Pero tardaba en verse.

Lo que la velocidad de carga revelaba entre línea y línea

Lancé un análisis con PageSpeed Insights sobre tres fichas de vehículo representativas y la página principal del catálogo. Los resultados en modo móvil eran consistentes: puntuación de rendimiento entre 31 y 39 sobre 100. En escritorio, entre 58 y 64. No era un fallo puntual. Era un patrón estable.

Lo que más llamaba la atención no era el score general, sino una métrica concreta. El Time to First Byte, el tiempo que tardaba el servidor en empezar a responder, se movía entre 2,4 y 3,1 segundos en las pruebas móviles. Eso, antes de que el navegador empezara a pintar nada. Antes de que una sola imagen se descargara.

URL: /coches/ford-focus-2022-gasolina
  Dispositivo: móvil (emulado)
  TTFB: 2.814 ms
  LCP: 7.320 ms
  CLS: 0.04
  TBT: 1.890 ms

Un LCP por encima de siete segundos es una sentencia en móvil. Google usa esas métricas como señal de experiencia de página, y un usuario medio no espera más de tres segundos antes de volver a la SERP. Cada segundo extra de carga reduce la probabilidad de conversión de forma desproporcionada. No es lineal. Es una caída que se acelera.

Crucé estos datos con WebPageTest para ver la cascada de carga completa. Ahí empezó a tomar forma algo que desde PageSpeed Insights solo era una sospecha. El diagrama de cascada mostraba un cuello de botella claro al inicio de cada petición: la respuesta del servidor se retrasaba de forma constante antes de entregar el primer byte. Después venían imágenes que pesaban entre ochocientos kilobytes y dos megabytes cada una. Sin compresión. Sin formato moderno. Todo en JPEG a resolución completa.

Waterfall resumen (ficha /coches/ford-focus-2022-gasolina):
  1. Documento HTML .......... espera 2.814 ms
  2. CSS principal ........... 420 ms
  3. JS bundle ............... 680 ms (sin minificar, 1.1 MB)
  4. hero-image.jpg .......... 1.8 MB, carga completa 3.200 ms
  5. gallery-01.jpg .......... 1.2 MB
  6. gallery-02.jpg .......... 940 KB
  Peso total de página: 9.4 MB

Nueve megabytes y medio para una ficha de producto. Solo en la carga inicial. Eso no venía de un problema de código o de un fallo en la plantilla. Venía de más atrás. Pero aún no quería cerrar el diagnóstico sin comprobar una cosa más.

Miré las cabeceras HTTP de respuesta del servidor. Ni cache-control, ni expires, ni compresión gzip activada. El navegador tenía que volver a solicitar todos los recursos en cada visita, sin poder reutilizar nada de accesos anteriores.

Un sitio puede tener contenido excelente y posiciones razonables, pero si la experiencia de carga penaliza al usuario antes de que vea nada, la señal se rompe entre la SERP y la página. Google puede detectar múltiples señales relacionadas con la experiencia de búsqueda y, si el rendimiento afecta de forma sostenida a los usuarios, terminar reflejándose en el rendimiento orgánico.

El punto donde las señales dejaron de ser ruido

La causa estaba repartida entre dos capas que se alimentaban mutuamente. Por un lado, el alojamiento compartido donde corría el sitio llevaba meses saturado. Era un plan básico que en su momento bastaba para el volumen de tráfico que recibía el concesionario, pero que con el crecimiento del catálogo y el aumento gradual de visitas se había quedado sin margen. El servidor respondía tarde porque no tenía recursos suficientes para procesar las peticiones a tiempo. Eso explicaba el TTFB tan alto: no era un problema de red ni de distancia geográfica. Era un servidor que tardaba en arrancar cada respuesta porque estaba repartiendo su capacidad entre decenas de sitios.

Por otro lado, los recursos del propio sitio nunca se habían optimizado. Las fotografías de los vehículos se subían directamente desde la cámara del concesionario, sin redimensionar ni comprimir. El CSS y el JavaScript se servían tal cual los generaba el sistema, sin minificar ni agrupar. No había ninguna red de distribución de contenido que acercara los archivos al usuario. Y las cabeceras de caché no existían, así que el navegador tenía que volver a descargar todos los recursos desde cero en cada visita.

La combinación de ambas cosas creaba un efecto multiplicador. Un servidor lento entregando recursos pesados sin ninguna capa intermedia que aliviara la carga. En escritorio, con conexiones rápidas y procesadores potentes, el impacto era tolerable. En móvil, con conexiones 4G variables y hardware más limitado, la experiencia se convertía en una espera que muy pocos usuarios completaban. Todo apuntaba a que el rendimiento era uno de los factores principales detrás de la caída.

Un rendimiento lento no siempre grita. A veces solo frena lo justo para que el usuario se canse antes de actuar.

Y eso era exactamente lo que estaba pasando: el sitio funcionaba, se veía bien, tenía contenido actualizado y posiciones aceptables. Pero la velocidad de carga había cruzado un umbral donde cada visita móvil se convertía en una oportunidad perdida. Google seguía mostrando los resultados, pero el usuario no llegaba a ver la página completa. O llegaba y se iba antes de que el formulario estuviera operativo.

Reconstruir el camino entre el clic y la conversión

La solución no era un parche único. Había que actuar en las dos capas que habían generado el problema: la infraestructura del servidor y el peso de los recursos que servía.

Lo primero fue abordar las imágenes. Todas las fotografías del catálogo se recomprimieron y se convirtieron a formato WebP con una calidad del ochenta y dos por ciento, suficiente para mantener la presentación visual de los vehículos sin que el peso se disparara. Las imágenes principales de cada ficha pasaron de pesar entre uno y dos megabytes a moverse entre noventa y ciento sesenta kilobytes. Se implementó carga diferida real para las imágenes de galería que quedaban fuera del viewport inicial, de modo que solo se descargaban cuando el usuario hacía scroll.

El CSS y el JavaScript se minificaron y se agruparon en menos archivos. El bundle principal de JavaScript bajó de 1,1 megabytes a 310 kilobytes. Se añadieron cabeceras de caché con tiempos de expiración razonables para recursos estáticos, de forma que las visitas recurrentes no tuvieran que volver a descargar todo desde cero.

Mover los cimientos o apuntalar lo que había

Aquí estaba la decisión que marcaba la diferencia entre una mejora temporal y una corrección de verdad. La optimización de recursos iba a reducir el peso de página de forma importante, sí, pero si el servidor seguía respondiendo con un TTFB de casi tres segundos, el cuello de botella inicial no desaparecía. Era como quitar peso de un coche que tiene el motor gripado: va algo mejor, pero sigue sin tirar.

Una opción era subir de plan dentro del mismo proveedor. Era lo más rápido y lo menos invasivo. Pero al revisar las condiciones, el siguiente nivel de ese alojamiento compartido solo garantizaba más almacenamiento, no más capacidad de procesamiento. No resolvía el problema real. Y si el tráfico seguía creciendo, volveríamos al mismo punto en unos meses.

La otra opción era migrar a un servidor virtual privado con recursos dedicados y configurar una CDN para los estáticos. Era más complejo, requería migración completa del sitio y reconfiguración de DNS, con el riesgo de que cualquier fallo en el proceso dejara el sitio caído justo en un periodo donde el concesionario estaba lanzando campaña de vehículos de ocasión. Si la migración salía mal y el sitio pasaba dos o tres días inaccesible, las posiciones orgánicas podían resentirse justo cuando más tráfico necesitaban.

Decidí preparar la migración en paralelo. Montar el entorno nuevo, replicar el sitio completo, verificar que todo funcionaba en un dominio temporal y hacer el cambio de DNS en una ventana de tráfico bajo: un domingo por la noche. El tiempo de propagación fue de unas seis horas, pero el servidor antiguo seguía respondiendo como fallback durante ese periodo. No hubo caída.

Con el servidor nuevo y la CDN activa, el TTFB bajó a 380 milisegundos de media. El LCP en móvil se situó en 2,1 segundos. El peso total de una ficha de vehículo cayó de 9,4 megabytes a 1,3. La auditoría devolvía ahora una puntuación de rendimiento entre 82 y 88 en móvil.

La velocidad de carga dejó de ser un obstáculo. En las tres semanas siguientes, el CTR móvil recuperó su nivel anterior y las solicitudes de prueba de conducción volvieron al rango de catorce a dieciocho mensuales. No fue una explosión de tráfico. Fue una recuperación limpia de lo que ya estaba funcionando antes de que el rendimiento lo frenara.

Una corrección bien ejecutada no siempre se nota por lo que mejora. A veces se nota porque deja de estorbar.

Validé los cambios durante las dos semanas posteriores con monitorización de velocidad de carga en las fichas más visitadas, seguimiento de TTFB desde tres ubicaciones distintas y revisión del comportamiento del tráfico móvil en Search Console. Las métricas se estabilizaron sin oscilaciones extrañas. El servidor nuevo aguantaba picos sin degradar tiempos de respuesta.