Tu sitio tiene tres segundos para convencer a alguien de quedarse. La mayoría de las empresas B2B chilenas los usa en cargar imágenes sin comprimir, plugins acumulados durante años y un servidor que cobra lo mínimo por razones que se notan. Para cuando el visitante ve el menú, ya tomó una decisión.
Google lo documentó hace años y el número no ha cambiado en lo esencial: cuando el tiempo de carga pasa de uno a tres segundos, la probabilidad de que el visitante abandone el sitio aumenta un 32%. Si llega a cinco segundos, ese número sube al 90%. Estos no son datos de e-commerce masivo — aplican igual para el gerente de compras que busca un proveedor de servicios industriales un martes por la tarde.
El problema real no es que el sitio sea lento. El problema es que la mayoría de las empresas no lo sabe, o lo sabe y asume que “para lo que lo usamos, está bien”. Esa lógica tiene un costo concreto que vale la pena revisar.
Por qué los sitios corporativos acumulan peso sin que nadie lo note
Los sitios web corporativos no nacen lentos. Se vuelven lentos de a poco, por acumulación. Cada vez que alguien sube una foto desde su computador sin redimensionarla, el sitio gana entre 3 y 8 MB de peso innecesario. Cada vez que se instala un plugin para resolver un problema puntual y no se desinstala cuando deja de usarse, queda corriendo en segundo plano. Cada vez que se contrata un hosting “económico” con recursos compartidos, se comparte capacidad de procesamiento con decenas de otros sitios.
El resultado típico en un sitio B2B que tiene tres o cuatro años de existencia sin mantención técnica: imágenes que pesan entre diez y veinte veces más de lo necesario, entre quince y treinta plugins activos de los cuales la mitad no cumple ninguna función visible, un tema o plantilla con código JavaScript que bloquea el renderizado de la página, y un servidor ubicado en Estados Unidos atendiendo solicitudes desde Santiago.
Esto no es negligencia — es la consecuencia natural de construir un sitio sin un criterio técnico de largo plazo. Alguien diseñó el sitio para que se viera bien en pantalla, lo entregó, y desde entonces nadie con criterio técnico lo ha revisado.
El hosting barato tiene un precio que no aparece en la boleta
Un servidor compartido de bajo costo puede funcionar razonablemente bien cuando el sitio recibe pocas visitas simultáneas. El problema aparece en los momentos que importan: cuando una campaña de LinkedIn genera tráfico, cuando un artículo empieza a posicionarse, cuando un prospecto llega al sitio después de una reunión comercial y quiere revisar los servicios con calma.
En esos momentos, el servidor tarda entre 400 y 800 milisegundos solo en responder la primera solicitud — antes de transferir una sola línea de contenido. Ese tiempo se llama Time to First Byte (TTFB) y es uno de los indicadores que Google usa para evaluar la experiencia del usuario. Un TTFB saludable está por debajo de los 200 milisegundos. La diferencia puede parecer técnica y abstracta hasta que se traduce en un prospecto que cierra la pestaña antes de ver la propuesta de valor.
Qué mide Google y por qué le importa a tu posición en buscadores
Desde 2021, Google incorporó los Core Web Vitals como factor de posicionamiento. No es una tendencia ni una novedad — es un estándar establecido que determina, en parte, si tu sitio aparece antes o después que el de un competidor cuando alguien busca lo que tu empresa ofrece.
Los Core Web Vitals para empresas B2B se resumen en tres métricas:
LCP (Largest Contentful Paint): mide cuánto tarda en aparecer el elemento visual más grande de la página — generalmente una imagen principal o un bloque de texto destacado. El umbral aceptable es 2.5 segundos. La mayoría de los sitios corporativos sin optimización está entre 4 y 7 segundos.
FID / INP (Interaction to Next Paint): mide cuánto tarda el sitio en responder cuando el usuario hace clic en algo. Un sitio con JavaScript pesado puede tardar entre 300 y 500 milisegundos en procesar un clic — suficiente para que la interacción se sienta torpe.
CLS (Cumulative Layout Shift): mide si los elementos de la página se mueven mientras carga. Es ese fenómeno donde el usuario va a hacer clic en un botón y el contenido se desplaza un centímetro en el último segundo. Un CLS alto es señal de código front-end mal estructurado.
Un sitio que falla en estas tres métricas no solo frustra a los visitantes. Le indica a Google que la experiencia que ofrece es inferior a la de otros sitios sobre el mismo tema. El algoritmo ajusta las posiciones en consecuencia. El impacto sobre el SEO técnico de un sitio B2B es directo y medible.
Un ejemplo concreto de cómo se conecta la velocidad con la conversión
Imagine una empresa de servicios de ingeniería que recibe 400 visitas mensuales a su sitio, con una tasa de conversión de contacto del 2% — esto es, 8 consultas al mes. Si el tiempo de carga promedio supera los cuatro segundos, una optimización técnica que lo lleve a menos de dos segundos puede recuperar entre un 30% y un 40% del tráfico que abandona antes de interactuar.
En números: si el 35% de los visitantes abandona por velocidad, y se corrige ese problema, el sitio puede pasar de 400 a 540 visitas efectivas sin aumentar un peso en publicidad. Con la misma tasa de conversión, eso se traduce en 3 a 4 consultas adicionales al mes. Para una empresa B2B con ticket promedio de varios millones de pesos, el cálculo se justifica solo.
Cómo evaluar la velocidad de tu sitio hoy, sin contratar a nadie
Antes de tomar cualquier decisión, hay que medir. Estas herramientas son gratuitas y no requieren conocimientos técnicos para obtener un diagnóstico inicial:
-
Google PageSpeed Insights (pagespeed.web.dev): ingresa la URL de tu sitio y entrega una puntuación entre 0 y 100 para móvil y escritorio, junto con los problemas específicos ordenados por impacto. Una puntuación sobre 80 en móvil es el umbral mínimo aceptable para un sitio corporativo activo.
-
GTmetrix (gtmetrix.com): muestra el peso total de la página, el número de solicitudes al servidor y una cascada de carga que permite ver exactamente qué elemento está ralentizando todo. La versión gratuita es suficiente para un diagnóstico inicial.
-
Google Search Console: si el sitio ya está verificado en esta plataforma, la sección “Experiencia de página” muestra directamente cuántas URLs del sitio aprueban o fallan los Core Web Vitals según datos reales de usuarios.
Una vez que tengas los resultados, revisa este checklist básico. Cada punto que puedas confirmar como resuelto indica que el sitio está en mejor posición técnica:
- Las imágenes del sitio están en formato WebP o AVIF (no JPG ni PNG sin comprimir)
- El sitio usa un sistema de caché activo (para WordPress: WP Rocket, W3 Total Cache o similar)
- El hosting está ubicado en Latinoamérica o tiene CDN con nodos regionales
- El sitio no tiene más de diez plugins activos en WordPress (o equivalente en otras plataformas)
- El LCP medido en PageSpeed Insights está bajo 2.5 segundos en móvil
- No hay scripts de terceros cargando de forma síncrona en el encabezado (Google Tag Manager mal configurado es el caso más frecuente)
- El TTFB medido en GTmetrix está bajo 200 milisegundos
Si más de tres de estos puntos están sin resolver, la velocidad del sitio está afectando activamente su rendimiento como activo digital — tanto en posicionamiento como en conversión.
Qué hacer con lo que encuentres
El diagnóstico técnico no requiere reconstruir el sitio desde cero en la mayoría de los casos. Las optimizaciones de mayor impacto — compresión de imágenes, configuración de caché, migración de servidor — suelen resolver entre el 60% y el 80% del problema en un sitio corporativo estándar.
Lo que sí requiere criterio es distinguir cuándo el problema es de mantención técnica acumulada y cuándo es de arquitectura de base. Un sitio construido sobre una plantilla genérica cargada de funciones que no se usan tiene un límite de optimización: llega un punto en que optimizar encima de una base débil es más costoso que partir con una base técnica correcta.
La diferencia entre uno y otro caso no se ve a simple vista — requiere revisar el código, la estructura de archivos, las dependencias activas y el comportamiento real del servidor bajo carga. Ese es exactamente el tipo de análisis que cubre el diagnóstico digital de PTW.
Si las métricas que encontraste al revisar tu sitio están lejos de los umbrales descritos en este artículo, hay un paso lógico antes de cualquier decisión de inversión: entender con precisión qué está fallando y qué impacto tiene sobre el negocio. El diagnóstico de PTW está diseñado para responder esa pregunta con criterio técnico y comercial, no con una lista genérica de recomendaciones.