Sitios web rapidos que posicionan en Google: Core Web Vitals 2026

Lo hago con regularidad: por la noche en el sofa, telefono en mano, busco empresas locales de la region del Eifel en Google. No porque necesite algo. Sino porque quiero ver como rinden sus sitios web.

La semana pasada revise diez empresas artesanales del distrito de Euskirchen. El resultado fue desalentador. Siete paginas tardaron mas de cuatro segundos en cargar. Tres tenian cambios de diseno que hacian que el contenido saltara al desplazarse. Y en cinco sitios, paso mas de un segundo hasta que un toque en el boton "Contacto" mostrara alguna reaccion.

Esto no son detalles menores. Son asesinos de ranking.

Que cambio en 2024: INP en lugar de FID

En marzo de 2024, Google realizo un cambio en los Core Web Vitals que paso desapercibido para muchos. FID (First Input Delay) fue reemplazado por INP (Interaction to Next Paint). Suena tecnico. Lo es. Pero el impacto es grande.

FID solo media el retraso de la primera interaccion. Una vez. Despues, la metrica terminaba. INP es mucho mas estricto: mide el tiempo de respuesta durante toda la visita y toma el peor valor (con suavizado estadistico). Si su pagina reacciona rapido al primer clic pero se traba en el tercero o cuarto, eso ahora se nota.

Por que esto es relevante para usted: muchos sitios web que tenian valores verdes con FID estan fallando con INP. Sobre todo paginas con formularios complejos, elementos de slider o frameworks JavaScript pesados. La luz roja en Google Search Console a menudo llega como una sorpresa.

Los tres Core Web Vitals en 2026

Google evalua su sitio web con tres metricas. Cada una mide un aspecto diferente de la experiencia del usuario.

LCP: Largest Contentful Paint

Objetivo: menos de 2,5 segundos

LCP mide cuanto tarda en cargarse el elemento de contenido visible mas grande en el viewport. Suele ser una imagen, un titulo o una miniatura de video. El usuario ve una pagina vacia o a medio terminar durante este tiempo. Cuanto mas tarda, mas probable es que el visitante se vaya.

Que hace subir el LCP:

• Imagenes sin comprimir (la razon mas comun)
• Tiempos de respuesta del servidor lentos
• CSS o JavaScript que bloquean el renderizado
• Falta de priorizacion del contenido principal

INP: Interaction to Next Paint

Objetivo: menos de 200 milisegundos

INP mide el tiempo de respuesta de su pagina a las interacciones del usuario. Cada clic, cada toque, cada entrada de teclado. La metrica captura toda la cadena: desde el evento de entrada, pasando por el procesamiento JavaScript, hasta la siguiente actualizacion visual en el navegador.

200 milisegundos es el limite. Suena como mucho, pero no lo es. Si un clic en "Anadir al carrito" primero ejecuta un script de analytics, luego una verificacion de cookies, luego la animacion, ya ha superado ese limite.

CLS: Cumulative Layout Shift

Objetivo: menos de 0,1

CLS mide cuanto se desplaza el diseno durante la carga. Conoce la sensacion: quiere tocar un boton y en el ultimo momento todo salta hacia abajo porque se carga un banner publicitario o una imagen. Eso es un layout shift.

Las causas mas comunes:

• Imagenes sin ancho y alto definidos
• Banners publicitarios que se cargan despues
• Fuentes web que reformatean el texto durante la carga
• Contenido insertado dinamicamente por encima del viewport actual

El pipeline de renderizado: de la solicitud a la experiencia

Para entender donde se pierde rendimiento, ayuda observar el camino que toma cada carga de pagina. Cada paso de esta cadena puede convertirse en un cuello de botella.

Consulta DNS, handshake TLS, respuesta del servidor: estos son los pasos de red antes de que el navegador siquiera empiece a trabajar. Luego viene el parseo del HTML, la carga de CSS y JavaScript, la construccion del layout y finalmente la interactividad. Cada uno de estos pasos ofrece palancas de optimizacion.

De mi epoca en New Relic lo se bien: la mayoria de los problemas de rendimiento no estan donde uno los espera. Construimos herramientas de observabilidad que hacian visible exactamente este pipeline. Lo que me sorprendia una y otra vez: los desarrolladores pasaban horas optimizando en el lugar equivocado porque no median. Eso aplica tanto a empresas Fortune 500 como al sitio web de la panaderia de un pueblo.

Por que esto importa especialmente para empresas regionales

Cuando alguien busca en Google "fontanero cerca de mi" o "peluqueria en mi ciudad", no esta compitiendo con Amazon. Compite con cinco a quince proveedores locales. Y con ese punado de resultados, los Core Web Vitals pueden marcar la diferencia.

Google confirmo en 2021 que los Core Web Vitals alimentan la senal de ranking. Cuando dos paginas tienen calidad de contenido equivalente, el algoritmo favorece la mas rapida. En un mercado local donde las diferencias de contenido suelen ser pequenas, el rendimiento se convierte en el factor decisivo.

Ademas esta el comportamiento del usuario. Un estudio de Google de 2023 muestra: cuando una pagina movil tarda mas de tres segundos en cargar, el 53% de los visitantes la abandona. En busquedas locales, la impaciencia es aun mayor. Alguien que busca "pizzeria cerca" mientras camina no va a esperar cinco segundos.

Lo vivi en primera persona con un cliente de la region. Una empresa mediana, buen trabajo, buena reputacion, pero el sitio web tardaba mas de seis segundos en cargar en movil. Despues de mejoras de rendimiento especificas (imagenes comprimidas, JavaScript limpiado, servidor trasladado a Frankfurt), el tiempo de carga bajo a menos de dos segundos. En ocho semanas, la visibilidad en Google Search Console aumento un 40%.

Eso no es magia. Es fisica. Y algoritmo.

Mejoras de rendimiento en la practica

Ahora vamos a lo concreto. Las siguientes tecnicas no son un libro de texto teorico. Son las cosas que implementamos en Plexito en cada proyecto y que son estandar en nuestros servicios.

Imagenes: la palanca mas grande

Las imagenes representan el 50-70% del volumen de datos transferidos en la mayoria de los sitios web. Aqui es donde se encuentra la mayor palanca para tiempos de carga mas rapidos.

• WebP y AVIF en lugar de JPEG y PNG. WebP ahorra en promedio un 25-35% en comparacion con JPEG a la misma calidad. AVIF va aun mas lejos, hasta un 50% mas pequeno. Ambos formatos son compatibles con todos los navegadores modernos
• Imagenes responsivas con srcset. Por que un smartphone deberia cargar una imagen de 2400px de ancho cuando la pantalla solo tiene 390px? Con srcset y sizes, el navegador entrega exactamente el tamano adecuado
• Lazy loading para todo lo que esta debajo del viewport. El atributo loading="lazy" ya es un estandar HTML nativo. Las imagenes que el usuario aun no puede ver solo se cargan cuando se desplaza hacia abajo. La imagen hero en la parte superior recibe loading="eager" e idealmente fetchpriority="high"
• Dimensiones fijas en HTML. Cada etiqueta <img> necesita atributos width y height. De lo contrario, el navegador no sabe cuanto espacio reservar y usted produce layout shifts

Codigo: menos es mas rapido

JavaScript es la razon mas comun de malos valores INP. Cada script que se ejecuta en el hilo principal bloquea la interactividad.

• Code splitting. Cargue solo el codigo que necesita la pagina actual. Con Next.js esto sucede automaticamente por ruta, pero bibliotecas como Chart.js o Moment.js deben cargarse por separado
• Tree shaking. Si solo usa una funcion de una biblioteca, solo esa funcion deberia estar en el bundle. Los bundlers modernos como Turbopack lo hacen automaticamente, pero solo con modulos ES
• defer y async para scripts de terceros. Analytics, widgets de chat, pixeles de seguimiento: nada de eso pertenece al camino critico de renderizado. defer carga el script en paralelo y lo ejecuta solo despues de que el parseo HTML haya terminado

Un punto que conozco de mi trabajo en New Relic: los peores asesinos del rendimiento a menudo no son su propio codigo, sino los scripts de terceros. Un solo widget de chat mal cargado puede duplicar sus valores INP. Mida eso. Siempre.

Servidor y red: la base invisible

Puede optimizar el lado del cliente todo lo que quiera. Si el servidor responde lento, nada de eso ayuda.

• Edge hosting en Frankfurt. Para clientes en la region DACH, un servidor en Frankfurt am Main es la mejor ubicacion. La latencia hacia un usuario en el Eifel es entonces de 5-15ms en lugar de 80-120ms con un servidor en EE.UU. Suena poco, pero con multiples solicitudes se acumula
• CDN para assets estaticos. CSS, JavaScript, imagenes, fuentes: todo esto deberia servirse a traves de un Content Delivery Network como Vercel Edge, Cloudflare o AWS CloudFront. El usuario recibe los datos desde la ubicacion edge mas cercana
• Compresion Brotli. Brotli comprime un 15-20% mejor que Gzip. La mayoria de los servidores y CDN modernos lo soportan. Activelo. Ahora
• Configurar correctamente los headers de cache. Los assets estaticos (CSS, JS, imagenes) reciben Cache-Control: public, max-age=31536000, immutable. Asi el navegador los carga desde el cache local en la segunda visita. Cero solicitudes de red
• HTTP/2 o HTTP/3. El multiplexing permite al navegador cargar muchos archivos simultaneamente sobre una sola conexion. Esto elimina el bloqueo head-of-line de HTTP/1.1

Presupuesto de rendimiento: como mantener el control

Una mejora de rendimiento puntual no es suficiente. Sin disciplina, el deterioro se cuela. Un nuevo script de seguimiento aqui, una imagen sin optimizar alla, y despues de tres meses esta de vuelta en la zona roja.

La solucion: un presupuesto de rendimiento.

Un presupuesto de rendimiento define limites que no deben superarse. El equipo acuerda cifras concretas e integra la verificacion en el proceso de desarrollo. En Plexito, asi es como se ve:

| Metrica | Presupuesto | Justificacion | | -------------- | ------------------- | ---------------------------------- | | LCP | < 1,8s | Zona verde de Google con margen | | INP | < 150ms | Muy por debajo del limite de 200ms | | CLS | < 0,05 | Mitad del umbral de Google | | JS Total | < 200 KB (gzip) | Mantiene el hilo principal libre | | Imagenes Total | < 500 KB por pagina | Ahorra datos moviles |

Si una nueva funcionalidad o cambio excede el presupuesto, no se despliega. Punto. Suena estricto, pero funciona. Lo verificamos automaticamente en cada build con Lighthouse CI.

El truco es establecer el presupuesto desde el principio. No retroactivamente. Cuando el sitio ya es lento, es mucho mas dificil hacerlo rapido de nuevo que mantenerlo rapido desde el inicio.

Errores comunes que veo en la region

De trabajar con empresas del Eifel y Renania, conozco los patrones tipicos.

Slider en la pagina principal con cinco imagenes en alta resolucion. Cada imagen de 2 MB, todas cargadas al abrir la pagina aunque el usuario solo ve la primera. Son 10 MB para una sola vista de pagina. En movil con LTE, eso tarda una eternidad.

WordPress con 30 plugins. Cada plugin trae su propio CSS y JavaScript. La mayoria no se necesitan en la pagina actual, pero se cargan de todas formas. He visto paginas que enviaban mas de 3 MB de JavaScript. Para comparar: nuestras paginas en Plexito estan por debajo de 200 KB.

Sin cache, sin CDN. El servidor esta en un proveedor de hosting barato en algun lugar de Europa. Cada vista de pagina se renderiza en el servidor desde cero, incluyendo consultas a la base de datos. Sin cache del navegador, sin CDN. Cada visitante espera el tiempo de carga completo.

Google Fonts cargadas incorrectamente. En lugar de alojar la fuente localmente, se carga desde un servidor externo de Google. Eso cuesta una consulta DNS adicional, un handshake TLS y una solicitud HTTP. Y si el servidor de Google esta lento, bloquea todo el renderizado.

Que puede hacer el lunes

Suficiente teoria. Aqui tiene pasos concretos que puede implementar esta semana:

1. Medir. Abra PageSpeed Insights e ingrese su URL. Mire los tres Core Web Vitals. Verde, amarillo o rojo? Anote los valores. Esa es su linea base

2. Identificar las imagenes mas grandes. En el informe de PageSpeed, busque la seccion "Publicar imagenes en formatos de nueva generacion." Ahi vera que imagenes desperdician mas datos. A menudo basta con comprimir las tres mas grandes para mejorar significativamente el LCP

3. Revisar scripts de terceros. Abra las DevTools de Chrome (F12), vaya a la pestana Network y ordene por tamano. Que scripts externos se estan cargando? Realmente necesita todos?

4. Revisar Google Search Console. En "Core Web Vitals" vera como Google evalua sus paginas. Los datos ahi se basan en datos reales de usuarios (CrUX), no en mediciones de laboratorio. Esa es la verdad

5. Verificar la ubicacion del hosting. Donde esta su servidor? Use una herramienta como DNS Checker o el comando ping en la terminal. Si la latencia supera los 50ms, vale la pena cambiar a un proveedor con ubicacion en Frankfurt

Si despues del analisis descubre que sus valores estan en zona roja: no se asuste. Le pasa a la mayoria. Y tiene solucion.

La diferencia entre medir y adivinar

Una frase que me lleve de mi tiempo en New Relic: "If you can't measure it, you can't improve it." Eso aplica al software empresarial igual que al sitio web de su empresa.

Demasiadas agencias y disenadores web trabajan por intuicion. "La pagina se siente rapida." Eso no alcanza. Google mide en milisegundos. Y Google decide si usted aparece en la pagina uno o no.

La buena noticia: las herramientas son gratuitas. PageSpeed Insights, Lighthouse, Search Console, Chrome DevTools. No necesita software costoso. Necesita a alguien que lea los numeros y saque las conclusiones correctas.

Si quiere llevar sus Core Web Vitals a la zona verde y no sabe por donde empezar: contactenos. Revisaremos su sitio web y le diremos honestamente donde estan las mayores palancas. Sin jerga de marketing, solo numeros y acciones concretas.