Actualización de los Core Web Vitals abril 2026: por qué las pymes deben actuar ya en el frontend
7 Min. de lectura
Actualizado: 22.04.2026
Google ha completado la actualización principal de marzo de 2026 el 8 de abril y ha reducido el umbral de INP de 200 a 150 milisegundos. Para las webs de pymes, esto significa que quienes no optimicen su rendimiento frontend antes del verano perderán posiciones en el ranking frente a competidores que hayan cuidado sus Core Web Vitals. La buena noticia: la brecha suele ser menor de lo esperado si se actúa sobre los tres factores clave.
Lo esencial en resumen
- Umbral de INP reducido: El valor límite para una «buena» Interaction to Siguiente Paint pasa a ser de 150 milisegundos a partir de abril de 2026, antes eran 200 (Google Buscar Central).
- El 43 % de los sitios suspenden INP: INP es así el Core Web Vital más incumplido en 2026 y la corrección más compleja.
- Nueva métrica Smooth Visual Transitions: La actualización penaliza los cambios de página «janky», es decir, la navegación con saltos, frecuente en plantillas antiguas para pymes.
- Evaluación a nivel de sitio: Páginas de aterrizaje lentas arrastran hacia abajo el ranking de toda la web; Google ahora evalúa de forma agregada.
- Tres palancas suelen ser suficientes: Reducción del hilo principal, disciplina con los scripts de terceros y ciclo de vida de las imágenes, en este orden.
RelacionadoCustomer Data Platform en pymes / Gobernanza Low-Code en pymes
Lo que realmente cambió el 8 de abril
¿Qué son los Core Web Vitals? Los Core Web Vitals son tres métricas medibles que Google utiliza para evaluar la experiencia de usuario en una página web: LCP (Largest Contentful Paint, tiempo de carga del contenido principal), INP (Interaction to Siguiente Paint, rapidez de respuesta tras un clic o toque) y CLS (Cumulative Layout Shift, estabilidad visual). Cada valor tiene umbrales para «bueno», «necesita mejora» y «malo», medidos según el percentil 75 de usuarios reales.
La actualización principal de marzo, cuyo despliegue Google confirmó definitivamente el 8 de abril de 2026, introduce tres endurecimientos. Primero: el umbral del INP sube de 200 a 150 milisegundos. Puede parecer poco, pero en la práctica supone un régimen algorítmico completamente distinto, ya que muchas más páginas no cumplirán los requisitos. Segundo: una nueva métrica llamada Smooth Visual Transitions (SVT) mide qué tan fluidos son los cambios entre páginas y las animaciones dentro de la página. Si al hacer scroll o desplegar un menú hay tirones, la página lo pagará. Tercero: Google ahora agrega las señales de rendimiento a nivel de dominio, no por URL. Una sola página de categoría de producto obsoleta puede arrastrar la calificación de toda la tienda.
Para las páginas de pymes, esto es prácticamente una llamada de atención. Muchas instalaciones corporativas de WordPress, tiendas en Shopware o blogs empresariales funcionan con plantillas adquiridas hace tres o cinco años. Estas apenas cumplían los antiguos umbrales. Con un INP de 150, rápidamente entran en zona roja.
Fuente: Análisis del informe CrUX Q1 2026, entre otros web.dev y Fireup
Los tres pilares para equipos de pymes
La mayoría de las mejoras de rendimiento en las pymes no provienen de un nuevo framework, sino de tres intervenciones disciplinadas en el stack existente. Lo veo en cada migración de sitio: en algún lugar hay un pesado bundle de JavaScript que bloquea el Main Thread en el primer clic. En otro, se cargan ocho píxeles de seguimiento de forma asíncrona, pero cada uno registra un listener. Y en algún sitio hay una imagen hero que llega como JPEG de 4 megabytes directamente desde la carpeta de subidas de WordPress.
El primer pilar es la reducción del Main Thread. INP mide cuánto tarda la interacción más larga en provocar una respuesta visual en la página. El mayor enemigo son las tareas largas de JavaScript, típicamente procedentes de plugins, themes o frameworks que fuerzan el renderizado síncrono. Quienes usan React o Vue dividen las tareas largas con scheduler.yield() o con isInputPending. Quienes trabajan con jQuery clásico revisan qué listeners están en document.ready o click y si realmente se necesitan todos. Suena a trabajo minucioso —y lo es—, pero el impacto en el INP suele ser dramático.
El segundo pilar es la disciplina con los scripts de terceros. Google Analytics, un gestor de consentimientos, una herramienta de heatmap, quizá una etiqueta de LinkedIn Insight y tres píxeles de marketing. Cada uno pesa entre 30 y 150 kilobytes, y todos registran listeners de eventos en scroll o click. La suma se nota. La pregunta honesta es: ¿qué scripts necesita realmente el departamento de marketing, y cuáles llevan tres años ahí porque nadie sabe quién los añadió? Una auditoría con las DevTools del navegador y Lighthouse lo saca a la luz en dos horas. El trabajo real es político: quien desactiva un píxel, discute con marketing. Técnicamente, es trivial.
El tercer pilar es el ciclo de vida de las imágenes. Es la victoria más sencilla y la más infravalorada. Las imágenes modernas deberían ser AVIF o WebP, no JPEG. Deberían incluir loading=»lazy» si están bajo el fold. Deberían tener atributos width y height para evitar que el CLS sufra por el reflujo de imágenes. Y deberían servirse a través de un CDN con cambio automático de formato, algo que hoy es un simple interruptor en Cloudflare Images, Imgix o en la mayoría de los hosting gestionados. El efecto combinado en el LCP suele ser del 30 al 50 por ciento.
Comparativa de umbrales antiguos y nuevos
| Métrica | «Bueno» antiguo | «Bueno» 2026 | Fallo típico de pymes |
|---|---|---|---|
| LCP | ≤ 2.500 ms | ≤ 2.200 ms | Imagen hero sin optimizar, hosting lento |
| INP | ≤ 200 ms | ≤ 150 ms | JS de plugins, banners de consentimiento pesados |
| CLS | ≤ 0,1 | ≤ 0,1 | Falta de width/height, espacios para anuncios |
| SVT (nuevo) | no existía | fluido ≥ 85 % | Saltos al hacer scroll, plugins de sliders antiguos |
Fuente: Google Buscar Central, web.dev CrUX-Thresholds, estado abril 2026. SVT se observará inicialmente como «experimental», pero se incluirá en la puntuación del dominio.
Calendario hasta el verano
Un plan realista para pymes distribuye el trabajo en tres meses. El orden es clave, ya que cada paso proporciona la base de datos para el siguiente.
Quien empiece en mayo tendrá cifras sólidas en julio. Quien comience en junio se encontrará en agosto en plena fase de corrección. Y quien aún crea que los Core Web Vitals son solo un «nice-to-have», se preguntará en el tercer trimestre por qué su competidor directo le ha adelantado en tráfico orgánico.
Conclusión
La actualización Core de marzo de 2026 no es un terremoto, pero sí un caso serio. La mayoría de sitios de pymes están a un puñado de ajustes específicos de recuperar el terreno perdido. Main-Thread, Third-Party, Images. En este orden, no todo a la vez. Quien se tome el tiempo hasta julio y integre la higiene de rendimiento en el flujo de trabajo estándar de desarrollo, afrontará la próxima actualización Core sin sudar. Y llegará, porque Google ahora lo hace cada seis meses.
Preguntas frecuentes
¿Es INP ahora el Core Web Vital más importante?
En la práctica, sí, porque la mayoría de sitios incumplen INP en primer lugar. LCP y CLS suelen ponerse en verde con unos parches estándar. INP requiere intervenciones en el stack de JavaScript, y ese es el trabajo que los equipos suelen posponer.
¿Cómo se miden de forma fiable los nuevos umbrales?
Dos fuentes en paralelo: el Chrome User Experience Report ofrece datos de campo del percentil 75 de usuarios reales. Lighthouse en las Chrome DevTools proporciona datos de laboratorio con pistas de diagnóstico. Los datos de campo cuentan para Google, los de laboratorio ayudan a depurar.
¿Vale la pena una reconstrucción completa del template?
Solo si el template existente no tiene salvación estructural. Una reconstrucción cuesta el triple que un proyecto de optimización. Quien logre un «bueno» con los tres ajustes clave, no tiene presión inmediata. En temas de WordPress muy antiguos con Page-Builder integrado, el cambio a un Block-Theme moderno puede compensar.
¿Qué significa Smooth Visual Transitions en concreto?
SVT mide qué porcentaje de frames se renderizan sin tirones durante un cambio de página o una animación. Antiguos sliders en jQuery, transiciones CSS no aceleradas por hardware y efectos de scroll mal implementados arruinan la métrica. La solución suele ser migrar a CSS View-Transitions modernas o desactivar elementos que generen parpadeos.
¿Necesitan los sitios B2B optimización móvil?
Sí, aunque la compra se cierre en desktop. Desde 2023, Google indexa solo en móvil, y los rankings se evalúan según la versión móvil. Una página corporativa que no cargue en 2,5 segundos en un iPhone no obtendrá posición en las SERP, ni siquiera para búsquedas desde desktop.
Lecturas recomendadas
Fuente de la imagen de portada: Pexels / Jakub Zerdzicki (px:36497969)