Velocidad del sitio en 2026: Core Web Vitals, umbrales oficiales y nuestro caso con el blog en móvil
El servidor respondía en 0,23 segundos, pero en el móvil los artículos no aparecían en absoluto. Los umbrales oficiales de Core Web Vitals, qué dice Google sobre su efecto en la búsqueda y nuestro caso: portadas de ~2 MB a 213 KB y qué revisar.
¿Qué métricas de velocidad considera clave Google?
Las Core Web Vitals son tres métricas. LCP (carga): el elemento más grande debe aparecer en 2,5 segundos o menos. INP (respuesta): la página debe reaccionar a las acciones en 200 milisegundos o menos. CLS (estabilidad visual): un desplazamiento del diseño de 0,1 o menos. Se miden en el percentil 75 de las cargas, por separado en móvil y ordenador, y la página aprueba solo si las tres son buenas. INP sustituyó a FID en 2024. Web.dev indica que las métricas estables no cambian más de una vez al año, así que los «nuevos umbrales 2026» que citan algunos blogs no los confirma Google.
¿Influye la velocidad en el posicionamiento?
Google afirma que las Core Web Vitals, junto con otros aspectos de la experiencia en la página, se alinean con lo que sus sistemas de clasificación buscan recompensar, y recomienda encarecidamente buenas puntuaciones. Google no da un peso aparte a la velocidad, así que no es un botón mágico sino una condición más. Los datos reales de usuarios están en el informe Core Web Vitals de Search Console.
¿Qué encontramos en nuestro propio sitio?
El 11 de noviembre de 2026 abrimos el blog de Metriverra en un móvil y los artículos tardaban «muchísimo» en cargar. Las mediciones mostraron que el servidor respondía en 0,23 segundos: no era el problema. La lista de 19 artículos era un único bloque con una animación de aparición que se activaba al verse el 12 % del bloque. En el móvil el bloque medía 8.509 píxeles de alto y la pantalla 844, solo el 9,9 %: el umbral nunca se alcanzaba y los artículos seguían invisibles. Además, las portadas se servían a tamaño completo, unos 2 MB por lista. Quitamos la animación de la lista, paginamos en páginas de 10 y 9 artículos y servimos portadas reducidas: 12 portadas pesaban 213 KB en lugar de unos 2 MB.
¿Qué revisar en su sitio?
Abra el informe Core Web Vitals de Search Console y empiece por las páginas móviles. Revise las páginas en una ventana móvil real, no solo el tiempo de respuesta del servidor: el contenido oculto hasta que se ejecuta un script simplemente no se ve. Sirva imágenes del tamaño de la pantalla (srcset) y cargue en diferido las que están bajo la primera pantalla, pero no la imagen principal. Reserve espacio para las imágenes para que el diseño no salte. Y recuerde que los scripts y etiquetas pesados empeoran la respuesta, es decir, el INP.
Qué hacer ahora
- Abra el informe Core Web Vitals de Search Console y empiece por las URL móviles.
- Revise las páginas clave en una ventana móvil: ¿se ve el contenido sin esperar animaciones ni scripts?
- Sirva imágenes del tamaño de la pantalla y copias reducidas para listados y tarjetas.
- No difiera la carga de la imagen principal de la primera pantalla, solo las de abajo.
- Revise las métricas tras cada cambio importante del sitio, no una vez al año.
Metriverra muestra a diario el comportamiento de los visitantes y las conversiones, así que tras un cambio de velocidad puede comparar rebotes y ventas antes y después.
En resumen
- Umbrales de Google: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 en el percentil 75.
- Las métricas estables cambian como mucho una vez al año; los «nuevos umbrales 2026» no los confirma Google.
- Google: las Core Web Vitals se alinean con lo que los sistemas de clasificación recompensan.
- Nuestro caso: servidor a 0,23 s, pero artículos invisibles en el móvil por una animación.
- Portadas del listado: ~2 MB → 213 KB.
Fuentes: web.dev — Web Vitals · Google Search Central — Understanding Core Web Vitals and Google search results
