Abres la web de tu negocio en el móvil, con datos del celular y no con el wifi de la oficina, y pasa lo que ya te comentaron tres clientes: la pantalla queda en blanco, aparece una imagen a medias y recién ahí entra el contenido. Cuando se lo planteas a quien te hizo el sitio, la respuesta es que la velocidad no influye y que lo que importa es el diseño. Te quedas con la duda y con una sensación incómoda: sabes que algo se pierde, pero nadie te dice cuánto.
Este artículo responde eso con lo que sí está documentado. Primero, qué mide la industria cuando habla de velocidad y cuáles son los umbrales oficiales. Segundo, qué se ha medido sobre la relación entre velocidad y conversión, con sus cifras y sus límites, y de quién es la responsabilidad cuando el sitio pesa. Tercero, cómo comprobarlo tú mismo con herramientas gratuitas y qué tácticas se venden en Chile sin sustento. Nadie puede prometerte un porcentaje de conversión por acelerar tu web; lo que sí se puede es medir antes y después con el mismo método.
Tu sitio puede verse impecable en el computador de la oficina y ser lento donde está la gente. La documentación de Google sobre indexación mobile-first establece que el rastreador de smartphones es el agente principal con el que Google rastrea e indexa los sitios (Search Central). La versión que el cliente abre en la calle no es la secundaria: es la principal. Tu sitio puede verse impecable en el computador de la oficina y ser lento justo donde está la gente.
Ahí aparecen dos variables que no se ven en una maqueta. La red: la conexión desde la calle no es la misma línea fija donde se aprobó el diseño, y cambia según la cobertura y la carga de la red en ese momento. Y el dispositivo: un teléfono de gama media tiene menos memoria y menos CPU que un notebook, así que el mismo código pesa distinto en cada uno.
Después está la distancia entre lo que se ve y lo que se mide. Una portada puede mostrar el logo y el menú en menos de un segundo y estar técnicamente reprobada, porque la métrica que importa no es cuándo aparece algo, sino cuándo aparece lo principal.
Google define un conjunto de métricas de campo llamadas Core Web Vitals, y son tres: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS) (web.dev). Cada una mide algo distinto y las tres tienen umbral publicado.
| Métrica | Qué mide | Bien | Necesita mejorar | Mal |
|---|---|---|---|---|
| LCP | Cuándo se pinta el contenido principal de la página | ≤ 2,5 s | 2,5 – 4 s | > 4 s |
| INP | Cuánto tarda en responder cuando el usuario toca, escribe o hace clic | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS | Cuánto salta el contenido de lugar mientras carga | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Los umbrales se evalúan en el percentil 75 y son los mismos para móvil y para escritorio, aunque la evaluación se informa por separado (web.dev). No se juzga el peor caso ni el promedio, sino lo que viven tres de cada cuatro visitas. El móvil no tiene un estándar más blando: el mismo 2,5 segundos aplica a un teléfono con mala conexión.
LCP tampoco mide solo la descarga de la imagen grande. Incluye el tiempo hasta el primer byte, las redirecciones y el tiempo de conexión (web.dev). Por eso un hosting lento arruina una página liviana, y una imagen de 3 MB arruina un hosting rápido.
INP reemplazó a First Input Delay, y su nota oficial es incómoda para quien solo mira el peso de la página: 90% del tiempo que un usuario pasa en una página ocurre después de que cargó (web.dev). Por eso un sitio que carga en dos segundos y se congela al tocar «Ver precios» sigue siendo lento para ese cliente. En la lista de mejoras documentadas de Google, esa capacidad de respuesta es una de las que más sitios reprueba (web.dev).
Aquí conviene ser preciso, porque es la parte donde más se exagera. Existen casos de éxito publicados por Google que relacionan métricas de velocidad con resultados de negocio, y todas sus cifras vienen de la propia empresa, sobre su propio tráfico. No son una tasa universal que puedas multiplicar por tus visitas.
Renault analizó más de 10 millones de visitas en 33 países durante cuatro meses. Reportó que una mejora de 1 segundo en LCP se asocia a −14% de rebote y +13% de conversión en formularios de contacto, y una mejora agregada de 22% en la proporción de visitantes con LCP rápido (web.dev). Son regresiones sobre su propio tráfico y sus propios formularios.
redBus es más cercano al problema del que habla este artículo. Tenía interacciones lentas y el diagnóstico no estaba en el diseño: manejadores de scroll sin control, un componente que volvía a renderizar la interfaz entera en cada pulsación de tecla y lotes de resultados demasiado grandes por petición. Con esos arreglos el INP mejoró 72% y reportaron un aumento de 7% en ventas (web.dev).
El tercer dato lo cita la guía de rendimiento de Google: la BBC detectó que perdía 10% de usuarios por cada segundo adicional de carga (web.dev). Es el más fácil de entender y el más fácil de mal usar, porque perder usuarios no equivale a perder pesos.
Los límites hay que decirlos: las cifras de Renault son correlacionales, de una empresa, en su mercado. En Chile no existe un estudio público con metodología declarada sobre velocidad y conversión, así que cualquier cifra chilena que te muestren sin método ni muestra no la puedes verificar.
Cuando un sitio tarda, casi siempre es una combinación de estos cinco. Ninguno exige un rediseño, y todos se pueden medir antes de tocar nada.
Fotos exportadas a 4000 píxeles de ancho, servidas al mismo tamaño a un teléfono que muestra 400, en formato pesado. La documentación de LCP recomienda servir el tamaño correcto con atributos de imagen responsiva y precargar la imagen principal, que suele ser el elemento LCP (web.dev).
Chat de atención, mapa embebido, píxeles de publicidad, reproductor de video, encuesta, aviso de cookies. Cada uno se sumó en un momento distinto y ninguno se revisó después. Google mantiene una guía de buenas prácticas para incorporaciones de terceros porque suelen quedar fuera del control de quien administra el sitio (web.dev).
Un tema comprado por pocos dólares que carga hojas de estilo, tipografías y librerías completas para funciones que no usas, más quince plugins que cada uno suma su JavaScript. El sitio que nadie construyó así creció por acumulación. Conviene revisar el diseño y desarrollo web antes de culpar al hosting.
El tiempo hasta el primer byte es el primer tramo del LCP y depende del servidor. Un plan compartido barato, sin caché de página y sin CDN, entrega cada visita desde un servidor lejano. Esto es parte de un trabajo de posicionamiento web profesional, porque la velocidad del servidor también afecta el rastreo.
Cuatro tipografías web con todos sus pesos, cargadas antes del contenido, más archivos JavaScript en el encabezado que deben descargarse y ejecutarse antes de mostrar nada. web.dev recomienda usar menos tipografías, en formatos comprimidos, y mostrar el texto con una fuente de reemplazo mientras la definitiva llega (web.dev).
Ninguna de estas cosas es un delito por sí sola. El problema es lo que se promete con ellas.
Ese puntaje es una medición de laboratorio: Lighthouse carga tu página con un dispositivo y una red simulados y calcula un número. Su documentación reconoce que fluctúa por causas ajenas al sitio, como publicidad, enrutamiento del tráfico, extensiones del navegador o antivirus (Chrome for Developers). Si tienes datos de laboratorio y de campo, el de campo es el que debes usar para priorizar (web.dev).
La caché ayuda y suele ser la intervención con mejor relación entre costo y efecto, pero ataca un solo tramo. No reduce el peso de una imagen de 4 MB, no elimina un scroll que congela el teléfono y no arregla un servidor lento. Instalarla y no volver a medir es cambiar un síntoma por la sensación de haber resuelto el problema.
Es la frase que abre este artículo. No se sostiene como afirmación general: Google define métricas con umbrales publicados para evaluar la experiencia de página, y la evaluación se hace por separado en móvil y en escritorio (Search Central). Que la velocidad no sea lo único que importa es cierto. Que no importe, no.
Migrar sin diagnóstico es pagar más por el mismo resultado. Si el problema está en las imágenes y en el código de terceros, un servidor más potente entrega rápido una página igual de pesada. Mide primero y mueve el servidor solo si el cuello de botella está ahí.
Una plantilla nueva puede mejorar el punto de partida y también empeorarlo, porque trae sus propias librerías y fuentes, y arrastra los plugins existentes. Sin una línea base medida antes, no vas a poder saber si mejoró o si solo cambió.
Las herramientas oficiales son gratuitas y no dependen de quien te hizo el sitio.
| Herramienta | Qué te dice | Qué no te dice |
|---|---|---|
| Informe de Core Web Vitals en Search Console | Agrupa las URLs de tu sitio en correctas, necesitan mejora o incorrectas, y separa móvil de escritorio | No explica la causa del problema ni cómo arreglarlo |
| PageSpeed Insights | Dos bloques: lo que experimentan usuarios reales y el diagnóstico de laboratorio | Su puntaje es de laboratorio y fluctúa; no es la experiencia de tus clientes |
| Chrome UX Report (CrUX) | Distribución de la experiencia real de usuarios de Chrome en los últimos 28 días | No incluye Chrome en iOS, ni WebView de Android, ni otros navegadores Chromium, y omite sitios con poco tráfico |
La limitación de CrUX importa: su metodología exige que la página o el origen sea «suficientemente popular» según un umbral que no se divulga, y excluye Chrome en iOS, las apps de Android que usan WebView y otros navegadores basados en Chromium (Chrome for Developers). Si tu negocio es pequeño, PageSpeed Insights puede decirte que no hay datos suficientes. Eso no significa que tu web vaya bien: significa que no hay muestra pública.
La única medición de primera parte es Search Console, porque son tus URLs y tus datos. Y si tu web no aparece en Google, hay causas técnicas que conviene resolver antes de hablar de velocidad: revisa por qué tu web no aparece en Google aunque esté publicada. Un sitio que no está indexado no tiene un problema de velocidad; tiene uno anterior.
Se puede mejorar mucho en la mayoría de los casos, y se puede medir. Lo que no se puede es poner una fecha ni una cifra de ventas en un contrato.
Los factores que limitan el resultado son concretos. El punto de partida: un sitio que hoy tarda 8 segundos tiene más margen que uno que tarda 3. La plantilla y los plugins: un WordPress con veinte plugins tiene un techo que no se rompe sin tocar la arquitectura. Y quién controla el servidor y el código de terceros, que muchas veces no es quien administra el contenido.
Lo que una agencia honesta puede comprometer es el trabajo, el método de medición y una línea base tomada antes de intervenir. Nunca un porcentaje de conversión ni una posición en Google.
Hay un orden que evita gastar dos veces: se mide y se guarda la línea base, se atacan los tres o cuatro problemas de mayor impacto y no los veinte, se vuelve a medir con el mismo método y recién entonces se decide si vale la pena seguir.
La atención de nuestra agencia es remota, así que este trabajo se hace con acceso a tu sitio y reuniones en línea, sin visitas presenciales.
El estándar publicado es LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos, evaluados en el percentil 75 de las visitas reales. No es un objetivo comercial, es el umbral con el que la industria define una buena experiencia de carga. Si tu sitio está muy por encima de esos valores en móvil, ahí está el problema. Si está dentro, la lentitud que percibes probablemente sea intermitente.
Google evalúa la experiencia de página con estas métricas y lo documenta como su conjunto de señales para medir la experiencia de carga e interacción. Lo que no publica es cuánto pesan frente al contenido y al resto de factores. Quien te diga que subirás tres posiciones por optimizar velocidad está inventando un dato que Google no entrega. La velocidad es una condición que conviene tener en orden, no una palanca con resultado garantizado.
Tiene razón en una parte: el diseño y el contenido influyen en si el visitante confía y contacta. Está equivocado en la conclusión, porque un diseño que no alcanza a verse no vende nada. Google define umbrales numéricos de velocidad y los aplica igual en móvil y en escritorio. Lo razonable no es elegir entre diseño y velocidad, sino exigir que el diseño se vea dentro del tiempo que el cliente está dispuesto a esperar.
Tu computador suele estar en fibra o wifi, con un procesador potente y el sitio ya en caché porque lo visitas todos los días: son condiciones distintas. Tu cliente llega por primera vez, desde datos móviles, con un teléfono de gama media y sin nada cacheado. La documentación de Google lista la caché, el tipo de red y la capacidad del dispositivo entre las causas de esa diferencia. La prueba válida la haces en un teléfono con datos móviles, no en tu escritorio.
Rara vez justifica el esfuerzo. Ese puntaje es una auditoría de laboratorio con red y dispositivo simulados, y su documentación reconoce que fluctúa por factores externos al sitio, como publicidad, enrutamiento del tráfico o extensiones del navegador. Pasar de 90 a 100 suele ser trabajar en los últimos milisegundos del diagnóstico, mientras el dato que importa es el de usuarios reales. Si tienes ambos, la recomendación oficial es priorizar el dato de campo.
No basta, aunque ayuda y suele ser lo primero que conviene hacer. La caché reduce el tiempo de respuesta del servidor, que es un tramo del LCP, pero no reduce el peso de una imagen mal exportada, no elimina el JavaScript que congela el teléfono del cliente y no arregla un servidor lento. Si después de activarla no vuelves a medir, quedas con la sensación de haber resuelto el problema sin evidencia.
El cambio técnico se aplica de inmediato y se puede verificar el mismo día con una prueba de laboratorio. El dato de campo se mueve lento: el Chrome UX Report entrega distribuciones calculadas sobre una ventana de 28 días, así que la mejora se va mezclando con las visitas anteriores. Conviene esperar unas semanas antes de comparar y no sacar conclusiones con dos días de datos.
Depende de qué hagas con esas visitas. Si son cien visitas y cada una vale una cotización, medio segundo de mejora se paga solo con retener una. Si el sitio tiene pocas visitas porque no aparece en Google, el orden correcto es otro: primero resolver la indexación y la visibilidad, porque acelerar una página que nadie visita no cambia nada. La velocidad se optimiza cuando ya hay tráfico que proteger.
Si llegaste hasta aquí, ya tienes algo que la mayoría de las conversaciones con proveedores no te da: un criterio. Sabes que existe un estándar publicado, que se mide en usuarios reales y no en una captura de pantalla, y que el puntaje de laboratorio no es la experiencia de tus clientes.
El trabajo que sí se puede comprometer es concreto: tomar una línea base de tu sitio en móvil y escritorio, identificar los tres o cuatro problemas con mayor impacto, corregirlos y volver a medir con el mismo método para mostrarte la comparación. Sin promesas de conversión y sin fechas inventadas.
Si quieres partir por el diagnóstico técnico antes de decidir cualquier otra cosa, cuéntanos el caso de tu web y te decimos con franqueza qué se puede medir en tu sitio y qué no.
Cuéntanos tu caso concreto y te decimos si tiene arreglo, qué implicaría y cuánto costaría. Sin compromiso y sin tecnicismos: si no podemos ayudarte, te lo decimos.
Escríbenos por WhatsApp o déjanos tus datos y te contactamos.
La atención es remota: no hace falta que vengas a ninguna oficina.
Luis Altair es ingeniero electrónico y especialista en posicionamiento web con más de 10 años de experiencia en SEO, SEO local, remoción de contenido negativo y visibilidad ante motores de inteligencia artificial. Es autor de libros de SEO publicados en Amazon.
Escribe sobre cómo los negocios chilenos pueden ser encontrados —en Google, en el mapa y en los asistentes de inteligencia artificial— sin recurrir a tácticas que no se sostienen. La atención de la agencia es remota y no implica oficinas fuera de Santiago.
Un sitio lento no se nota en la oficina: se nota en el celular del cliente que iba a pedirte una cotización y se fue. Cómo medirlo, qué lo causa en WordPress y en qué orden se arregla.
Pagas publicidad todos los meses. Llegan consultas: por WhatsApp, por el formulario, por teléfono. El problema aparece el día que abres la planilla y no
Si tu negocio tiene Perfil de Empresa verificado, sitio publicado y clientes que lo recomiendan, y aun así no apareces cuando alguien busca tu servicio
