Respuesta corta: la velocidad sí cuenta para el posicionamiento, pero cuenta poco y solo en los extremos. Donde de verdad se juega tu dinero es en la gente que se va antes de leerte. Google lo tiene escrito con esas dos mitades, y casi nadie cita las dos.
Este artículo separa las dos cosas: cuánto pesa la velocidad en Google —con las frases literales de sus páginas— y qué hace la lentitud con una visita real. Al final están las cifras que medimos hoy en nuestra web y en las cuatro de clientes que enseñamos, incluido un fallo nuestro que encontramos escribiéndolo.
Cuánto pesa la velocidad en el posicionamiento
Pesa, es oficial, y es pequeño. Las dos fuentes que lo fijan son de Google y dicen cosas complementarias.
La primera es el anuncio de la llamada «actualización de velocidad», del 17 de enero de 2018, que llevó la velocidad al posicionamiento de las búsquedas en móvil. Ahí acotan el alcance sin ambigüedad: «Este cambio, al que llamamos "actualización de velocidad", solo afectará a las páginas más lentas y a un pequeño porcentaje de las consultas». Y en la frase siguiente ponen el límite que más se olvida: «La intención con la que se hace una consulta de búsqueda seguirá siendo un factor muy importante, así que una página lenta podrá tener una buena posición en los resultados si ofrece contenido relevante y de calidad».
La segunda es la página vigente sobre la experiencia en la página, actualizada el 18 de diciembre de 2025. Confirma que «nuestros sistemas de posicionamiento usan las Core Web Vitals» y, en el mismo bloque, avisa de lo contrario: «obtener buenos resultados en informes como el informe "Core Web Vitals" de Search Console o en herramientas de terceros no garantiza que tus páginas vayan a aparecer al principio de los resultados de la Búsqueda de Google. La experiencia en la página es mucho más compleja que la puntuación de Core Web Vitals en sí». Y remata con una frase que no verás en ningún presupuesto de optimización: «es posible que intentar obtener una puntuación perfecta solo por razones de SEO no sea la mejor forma de invertir tu tiempo».
Interpretación de PotencIA, separada del hecho. De ahí salen dos reglas que usamos para decidir si tocamos la velocidad de una web o no. Si tu web está entre las más lentas —la que tarda cinco o seis segundos en enseñar algo en un móvil con datos—, la velocidad te está costando visitas y probablemente posiciones, y hay trabajo que hacer. Si ya está en un rango normal, subir la puntuación de 82 a 95 se justifica por lo que gana el visitante, no por lo que suba en Google. Vender lo segundo como una subida de posiciones es vender humo con datos oficiales en contra.
Qué pasa de verdad cuando una web va lenta
Se va gente, y se va en tres momentos distintos. Confundirlos es lo que hace que las optimizaciones no se noten.
El servidor pensando. Entre que alguien pulsa tu enlace y llega el primer byte de respuesta no hay nada en pantalla: ni tu logotipo, ni un texto, ni una barra de carga. Es tiempo en blanco. Google recomienda para esa medida —el tiempo hasta el primer byte, TTFB— un objetivo de 0,8 segundos o menos, y considera deficiente por encima de 1,8 segundos. Conviene saber además que el TTFB no es una métrica de Core Web Vitals: no lo miran para posicionar, pero arrastra a todo lo que viene detrás.
La primera pantalla útil. Es el momento en que aparece el elemento grande que hace que la página parezca cargada: la fotografía de cabecera o el titular. Es lo que mide el LCP, y el umbral bueno son 2,5 segundos. Junto a él, los otros dos: 200 milisegundos de INP para que un botón responda al tocarlo y 0,1 de CLS para que el contenido no salte mientras cargan las imágenes. Los tres se miden en el percentil 75 de las visitas, es decir, mirando a la cuarta parte peor y no a la media. El detalle métrica a métrica lo dejamos para su propio artículo; aquí importa el orden: si el primer byte tarda, el LCP no se arregla comprimiendo imágenes.
El momento de tocar algo. Es el más caro y el que ninguna herramienta te grita. El visitante decide escribirte, va a pulsar el botón, y el botón se mueve porque acaba de cargar una imagen encima, o no responde porque el navegador está ocupado ejecutando guiones. Ese contacto no se pierde por lentitud: se pierde por desconfianza. Es el mismo eslabón que analizamos entero en por qué una web bonita puede no conseguir clientes.
La cifra que ves no es la que vive tu cliente
Esta es la parte que casi nunca se explica y que cambia por completo cómo hay que leer un informe de velocidad.
Hay dos tipos de datos. Los de campo vienen de usuarios reales de Chrome que han visitado tu web, se agregan durante los 28 días anteriores y se resumen en el percentil 75. Los de laboratorio son una simulación: Lighthouse carga tu página en condiciones fijas, emulando un móvil de gama media en una red móvil, desde un servidor que puede estar en Norteamérica, Europa o Asia.
Y aquí viene lo importante para una pyme: es muy probable que tu web no tenga datos de campo. La documentación de PageSpeed Insights lo explica sin rodeos: para mostrar la experiencia de usuario de una página tiene que haber datos suficientes en el conjunto de CrUX, y una página puede no tenerlos si se publicó hace poco o si tiene muy pocas muestras de usuarios reales. Cuando eso pasa, la herramienta baja al nivel del dominio entero; y si tampoco hay suficientes, no muestra ningún dato de usuarios reales.
Consecuencia práctica, y va sin rodeos: si tu negocio recibe unos cientos de visitas al mes, el número de colores que te enseña una herramienta de velocidad es casi seguro una simulación en un móvil que no es el de tus clientes, en una red que no es la suya y desde un sitio que no es tu ciudad. Sirve para depurar, que no es poco. No sirve para prometer, ni para firmar un antes y un después.
Lo que medimos hoy en nuestras cinco webs
El método, para que puedas repetirlo: el 16 de septiembre de 2026 descargamos con curl el documento HTML de la portada de nuestra web y de las cuatro webs de cliente publicadas en nuestra página de creación de webs, desde una conexión doméstica en España. Las cinco responden con código 200. Es una medición de servidor sobre el documento, hecha una vez, no una serie ni un dato de campo: no la leas como una nota de rendimiento.
Primera petición, en frío, con resolución de DNS y negociación de TLS incluidas, que es lo que paga quien te visita por primera vez: 0,58 s en potenciasoluciones.com, 0,96 s en aerotermiaproyectoseinstalaciones.es, 0,84 s en thiasa.es, 0,42 s en autenticapizzamesondelboalo.es y 0,55 s en madresprotectorasmadrid.es.
Mediana de tres peticiones seguidas, ya con la conexión abierta: 0,11 s, 0,31 s, 0,24 s, 0,12 s y 0,11 s, en el mismo orden.
Esa diferencia —de hasta seis décimas entre la primera visita y las siguientes— es la lección del día, y explica por qué «a mí me va rápida» no significa nada: tú tienes el DNS resuelto, la conexión caliente y la caché llena. Tu cliente, no. Con datos móviles y en una zona con mala cobertura, esa diferencia se estira.
El documento HTML pesa entre 10 y 38 KB comprimido en las cinco, cuando sin comprimir van de 79 a 244 KB. Las cinco sirven comprimido, que es la comprobación aburrida que todo el mundo da por hecha y conviene mirar igualmente.
En reserva de espacio, el recuento sale limpio: 64 imágenes entre las cinco portadas y ninguna sin su hueco reservado, sea con los atributos de ancho y alto declarados o dentro de un contenedor con las medidas ya fijadas. Es el trabajo invisible que evita que el texto salte bajo el pulgar.
El fallo que encontramos escribiendo esto
Y aquí va la parte incómoda, porque nos toca a nosotros. En el HTML que sirve nuestra propia portada hay 18 elementos con opacidad cero, y uno de ellos es el titular principal: sale del servidor con el estilo «opacity:0» y solo se vuelve visible cuando el navegador ejecuta el JavaScript que dispara la animación de entrada.
Eso tiene dos consecuencias medibles. La primera es que, en la práctica, nuestra primera pantalla no depende del HTML sino de que cargue y se ejecute un paquete de JavaScript. La segunda es más fina: la documentación de Chrome explica que las mediciones de LCP excluyen con heurísticas los elementos «con una opacidad de 0, que son invisibles para el usuario» —traducción nuestra de la versión en inglés—, así que nuestro titular no cuenta como pintado hasta que la animación arranca. Nos hemos puesto una animación delante de nuestra propia métrica.
De las cinco webs, solo dos sirven contenido con opacidad cero: la nuestra, con 18 elementos, y autenticapizzamesondelboalo.es, con 33. Las otras tres, ninguno. Queda apuntado como corrección pendiente en nuestra portada y lo publicamos aquí en lugar de esperar a tenerlo arreglado, que es la única forma honesta de escribir un artículo sobre velocidad.
El orden en que lo arreglamos
No es una lista de mejoras, es una secuencia. Cada paso hace inútil o innecesario parte del siguiente.
- El primer byte. Hosting, caché de servidor y cadenas de redirecciones. Si aquí se pierde un segundo, no hay imagen que optimizar que lo recupere.
- Lo que construye la primera pantalla. La imagen de cabecera se carga con prioridad y nunca en diferido; todo lo que está más abajo, al revés. Confundirlo es el error más repetido que vemos.
- El hueco de todo lo que llega tarde. Imágenes, vídeos incrustados, avisos de cookies y cualquier cosa que aparezca de golpe necesita su espacio reservado antes de existir.
- Lo que sobra en la primera pantalla. Fuentes que no se usan, guiones de terceros que nadie mira nunca y animaciones de entrada. Empezamos por la nuestra.
- Volver a medir en el móvil, con datos y fuera de la oficina. Es la única prueba que se parece a lo que hace tu cliente.
Cuándo la velocidad no es tu problema
Decirlo nos quita trabajo, así que vale la pena decirlo. La velocidad no es tu cuello de botella si no llega nadie a tu web: ahí el problema está antes, en que no apareces para lo que busca tu cliente, y eso se trabaja desde el posicionamiento y desde un diagnóstico técnico. Tampoco lo es si llega gente y no entiende en cinco segundos a qué te dedicas, que es un asunto de la primera pantalla. Ni si te entienden y no hay por dónde escribirte, que suele ser una cuestión de qué páginas y qué vías de contacto tiene la web.
Una web que carga en 1,2 segundos y no explica qué vendes no convierte más que una que carga en 3. Arreglar la velocidad de una web que nadie visita es cambiar el motor de un coche aparcado.
Cómo lo trabajamos en PotencIA
Cuando un negocio nos pregunta por la velocidad, lo primero que hacemos es comprobar si tiene datos de usuarios reales o solo una simulación. Si solo hay simulación, lo decimos y ajustamos la expectativa: vamos a mejorar la experiencia, no a enseñar una gráfica de posiciones. Después vamos por el orden de arriba, y medimos antes y después con el mismo método para que la comparación signifique algo.
Y no prometemos posiciones por velocidad, porque las propias páginas de Google dicen que una puntuación perfecta no las garantiza. Prometemos una web que se ve antes, que no salta y que responde al primer toque. Eso sí se puede comprobar.
Fuentes consultadas
- Google, Centro de la Búsqueda, La velocidad de las páginas en el posicionamiento de las búsquedas móviles, 17 de enero de 2018, con la actualización del 9 de julio de 2018: «solo afectará a las páginas más lentas y a un pequeño porcentaje de las consultas» y «una página lenta podrá tener una buena posición en los resultados si ofrece contenido relevante y de calidad». Consultada el 16 de septiembre de 2026.
- Google, Centro de la Búsqueda, Qué es la experiencia en la página en los resultados de la Búsqueda de Google: «nuestros sistemas de posicionamiento usan las Core Web Vitals», la advertencia sobre las puntuaciones y la frase sobre la puntuación perfecta. Última actualización del 18 de diciembre de 2025, consultada el 16 de septiembre de 2026.
- Google, Centro de la Búsqueda, Conceptos básicos sobre las Métricas web principales y los resultados de búsqueda de Google: umbrales de 2,5 segundos de LCP, 200 milisegundos de INP y 0,1 de CLS. Última actualización del 18 de diciembre de 2025, consultada el 16 de septiembre de 2026.
- Google, Métricas web esenciales: el percentil 75 como umbral de medición. Actualizada el 31 de octubre de 2024, consultada el 16 de septiembre de 2026.
- Google, Time to First Byte (TTFB): objetivo de 0,8 segundos o menos, valores deficientes por encima de 1,8 segundos y advertencia de que el TTFB no es una métrica de Core Web Vitals. Versión en inglés, publicada el 26 de octubre de 2021 y actualizada el 18 de noviembre de 2025; traducción nuestra. Consultada el 16 de septiembre de 2026.
- Google, Largest Contentful Paint (LCP): exclusión heurística de los elementos con opacidad cero invisibles para el usuario. Versión en inglés, actualizada el 4 de septiembre de 2025; traducción nuestra. Consultada el 16 de septiembre de 2026.
- Google, Información sobre PageSpeed Insights: datos de campo de CrUX sobre 28 días, percentil 75, condiciones simuladas de Lighthouse y qué ocurre cuando una página no tiene datos suficientes. Versión en inglés por llevar la española aviso de traducción automática; actualizada el 21 de octubre de 2024, consultada el 16 de septiembre de 2026.
- PotencIA Soluciones, medición propia del 16 de septiembre de 2026 sobre el HTML de las portadas de potenciasoluciones.com, aerotermiaproyectoseinstalaciones.es, thiasa.es, autenticapizzamesondelboalo.es y madresprotectorasmadrid.es. Tiempos hasta el primer byte, tamaño del documento, recuento de imágenes con espacio reservado y recuento de elementos servidos con opacidad cero.