Core Web Vitals y Velocidad Web para Empresas LatAm 2026
Un sitio que tarda más de tres segundos en cargar pierde a buena parte de quienes intentan abrirlo, y la mayoría de esas personas en Latinoamérica entran desde un celular con conexión móvil, no desde una oficina con fibra. Los Core Web Vitals son las tres métricas con las que Google mide esa experiencia real (qué tan rápido aparece el contenido, qué tan rápido responde la página y qué tanto se mueve mientras carga) y funcionan a la vez como señal de posicionamiento y como termómetro de cuánta gente abandona antes de convertir. Esta guía explica qué son LCP, INP y CLS, cómo medirlos con herramientas gratuitas, por qué la lentitud te cuesta clientes y posiciones, cuáles son las causas típicas en sitios de empresas LatAm y cómo arreglarlas, paso a paso, con tablas y un checklist accionable.
No es un artículo para programadores. Es un manual para que el dueño o responsable de marketing de una empresa entienda qué está roto, qué pedir a su agencia o desarrollador, y cómo verificar que el trabajo se hizo bien. Los precios son orientativos y en USD porque varían por país; donde haga falta un dato oficial variable, se indica que se consulte la fuente correspondiente.
Resumen ejecutivo
- Los Core Web Vitals son tres métricas: LCP (carga), INP (interactividad) y CLS (estabilidad visual). Verde = LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, medido en el percentil 75 de visitas reales.
- Afectan al SEO como desempate y, sobre todo, a la conversión: un sitio lento pierde visitantes antes de que compren.
- Se miden gratis con PageSpeed Insights, el informe Core Web Vitals de Search Console y la extensión Web Vitals de Chrome.
- Las tres causas más comunes de lentitud en LatAm: imágenes sin optimizar, hosting lejano o saturado y exceso de JavaScript y plugins.
- WordPress puede aprobar bien optimizado; Next.js parte con ventaja estructural. La decisión depende del proyecto.
¿Qué son los Core Web Vitals y por qué importan para una empresa?
Los Core Web Vitals son un conjunto de tres métricas que Google definió para medir, con datos reales de visitantes, qué tan buena es la experiencia de uso de una página: la velocidad de carga del contenido principal, la rapidez de respuesta a las interacciones y la estabilidad visual mientras la página se arma. Importan porque condensan en tres números algo que antes era difuso —"el sitio va lento"— y porque Google los usa como parte de su evaluación de experiencia de página, que es señal de ranking.
La palabra clave es experiencia real. Antes, la velocidad web se medía con pruebas de laboratorio que simulaban una carga ideal. Los Core Web Vitals añaden los datos de campo: cómo cargó tu sitio para personas de carne y hueso, en sus dispositivos, con sus conexiones, durante los últimos 28 días. Para una empresa de LatAm esto es decisivo, porque el visitante promedio no usa una MacBook con fibra: usa un celular de gama media con una conexión móvil que se cae al entrar a un sótano o al cruzar una zona sin cobertura. Si tu sitio solo es rápido en condiciones ideales, los Core Web Vitals lo delatan.
Las tres métricas miden tres momentos distintos de la experiencia, y cada una responde a una pregunta concreta del visitante:
| Métrica | Pregunta del visitante | Qué mide | Umbral "bueno" |
|---|---|---|---|
| LCP (Largest Contentful Paint) | "¿Ya cargó?" | Tiempo hasta que aparece el elemento principal visible (foto de portada, titular grande) | ≤ 2,5 segundos |
| INP (Interaction to Next Paint) | "¿Responde cuando toco?" | Tiempo entre que el usuario interactúa (clic, toque, tecla) y la página reacciona | ≤ 200 milisegundos |
| CLS (Cumulative Layout Shift) | "¿Por qué se movió y toqué otra cosa?" | Cuánto se desplaza el contenido de forma inesperada mientras carga | ≤ 0,1 (sin unidad) |
Importa entender que estos umbrales no se evalúan sobre el promedio, sino sobre el percentil 75 de las visitas. Es decir, para aprobar, el 75% de tus visitantes debe experimentar valores dentro de "bueno". Google lo hace así a propósito: el promedio puede ocultar a una cuarta parte de usuarios con una experiencia pésima, y el percentil 75 obliga a que la mayoría amplia, no la media tramposa, tenga un sitio rápido.
La diferencia entre dato de laboratorio y dato de campo
Hay dos formas de medir que se confunden todo el tiempo, y esa confusión genera discusiones inútiles entre empresa y desarrollador. El dato de laboratorio es una simulación: una herramienta carga tu página una vez, en un entorno controlado, y te da un número al instante. Sirve para diagnosticar y para probar cambios rápido. El dato de campo es la realidad agregada: los valores que registraron los navegadores Chrome de tus visitantes reales durante 28 días. Es el que Google usa para la señal de ranking.
La consecuencia práctica: puedes mejorar el dato de laboratorio en una tarde y verlo verde de inmediato, pero el dato de campo, que es el que cuenta para Google y para Search Console, tardará tres o cuatro semanas en reflejar la mejora, porque necesita acumular suficientes visitas nuevas con los valores buenos. Quien promete "Core Web Vitals en verde mañana" en Search Console no entiende cómo funciona o está vendiendo humo.
Si todavía estás eligiendo con quién construir o rehacer tu sitio, conviene incorporar el rendimiento como criterio de selección desde el principio, no como un parche posterior; la guía de diseño web para empresas en Latinoamérica detalla qué exigir a un proveedor para que la velocidad venga resuelta de fábrica y no como un extra que se cobra aparte.
¿Qué es el LCP y cómo se mejora la velocidad de carga?
El LCP (Largest Contentful Paint, o "pintado del contenido más grande") mide cuánto tarda en aparecer el elemento visible más grande de la pantalla inicial, que casi siempre es la foto de portada, un titular grande o un bloque de imagen-texto del hero. Un LCP bueno es de 2,5 segundos o menos; por encima de 4 segundos se considera deficiente. Es la métrica que mejor responde a la sensación de "¿esto ya cargó o sigo esperando?".
El LCP es, con diferencia, el Core Web Vital que más se incumple en sitios de empresas LatAm, y casi siempre por la misma razón: imágenes pesadas servidas desde un hosting lento o lejano. La buena noticia es que también es el más fácil de arreglar con mejoras concretas, sin reconstruir nada.
Causas típicas de un LCP malo
Las causas se acumulan; rara vez es una sola. En orden de frecuencia en sitios reales de la región:
- Imágenes sin optimizar. Una foto de portada subida directo desde el celular pesa varios megabytes cuando debería pesar cientos de kilobytes. El navegador no puede pintar el hero hasta descargarla entera.
- Hosting lento o lejano. Si el servidor tarda en responder (TTFB alto) o está en otro continente, toda la carga arranca tarde. Un visitante en Lima esperando un servidor en Europa paga el viaje de ida y vuelta en cada recurso.
- Demasiados recursos bloqueantes. Hojas de estilo y scripts que el navegador debe procesar antes de pintar nada retrasan el momento en que aparece el contenido.
- Fuentes web mal cargadas. Si el texto grande del hero usa una fuente personalizada que tarda en descargarse, el LCP se retrasa o el texto parpadea.
- Falta de caché. Sin caché de página, cada visita obliga al servidor a generar el HTML desde cero, especialmente costoso en WordPress.
Cómo mejorar el LCP, en orden de impacto
| Acción | Esfuerzo | Impacto en LCP | A quién pedírsela |
|---|---|---|---|
| Comprimir imágenes y pasarlas a WebP/AVIF | Bajo | Muy alto | Plugin, agencia o desarrollador |
| Redimensionar imágenes al tamaño real mostrado | Bajo | Alto | Diseñador o desarrollador |
| Activar caché de página | Bajo | Alto | Hosting, plugin o desarrollador |
| Precargar la imagen del hero (preload) | Medio | Alto | Desarrollador |
| Migrar a hosting más rápido o cercano | Medio | Alto | Agencia o proveedor de hosting |
| Añadir un CDN | Medio | Medio-alto | Agencia o servicio CDN |
| Diferir CSS/JS no críticos | Medio | Medio | Desarrollador |
| Optimizar carga de fuentes (font-display, preload) | Bajo | Medio | Desarrollador |
La regla práctica para el dueño de empresa: si tu LCP está mal, empieza por las imágenes. En la mayoría de los casos, comprimir y convertir a WebP las fotos de portada, redimensionarlas y activar caché baja el LCP a la mitad sin tocar el diseño ni el hosting. Solo si tras eso sigue alto conviene mirar el servidor y el CDN.
¿Qué es el INP y cómo se mejora la respuesta de la página?
El INP (Interaction to Next Paint, o "interacción hasta el siguiente pintado") mide cuánto tarda la página en reaccionar visualmente cuando el usuario hace algo: tocar un botón, abrir un menú, escribir en un formulario. Un INP bueno es de 200 milisegundos o menos; por encima de 500 ms se considera deficiente. Responde a la sensación de "toqué y no pasa nada, ¿se trabó?".
El INP reemplazó en 2024 a la antigua métrica FID, que solo medía la primera interacción. El INP es más exigente porque evalúa todas las interacciones de la visita y se queda con la peor (o casi la peor), que es justo la que recuerda el usuario frustrado. Para empresas con formularios, filtros, carritos o configuradores, el INP es crítico: un sitio que se siente "pegajoso" al interactuar pierde ventas aunque cargue rápido al inicio.
Por qué un sitio carga rápido pero responde lento
La causa casi universal del mal INP es el JavaScript en exceso. Cuando el usuario toca algo, el navegador necesita un instante de "hilo principal" libre para procesar la respuesta. Si ese hilo está ocupado ejecutando scripts pesados (un constructor visual recargado, varios rastreadores de analítica, chats de terceros, widgets sociales), la interacción se queda en cola y el usuario percibe lentitud aunque el contenido ya esté visible.
Las fuentes de mal INP más comunes en sitios de empresa:
- Constructores visuales pesados que cargan toneladas de JavaScript para renderizar la página.
- Scripts de terceros acumulados: píxel de publicidad, mapas de calor, varios chats, botones sociales, todos compitiendo por el hilo principal.
- Plugins mal hechos que ejecutan código en cada interacción.
- Tablas, filtros o buscadores internos sin optimizar que procesan demasiado en el navegador.
Cómo mejorar el INP
| Acción | Esfuerzo | Impacto en INP |
|---|---|---|
| Auditar y eliminar scripts de terceros que no aportan | Bajo | Alto |
| Cargar scripts no esenciales de forma diferida (defer/async) | Medio | Alto |
| Reducir o dividir el JavaScript que se ejecuta al cargar | Alto | Alto |
| Sustituir constructor visual pesado por una solución más liviana | Alto | Alto |
| Usar un solo chat/widget en vez de varios | Bajo | Medio |
| Migrar a una arquitectura que envíe menos JS al navegador | Alto | Muy alto |
La pregunta honesta que debe hacerse una empresa: ¿de verdad necesito los seis widgets que tengo instalados? Cada chat, cada botón de "compartir", cada rastreador suma peso al hilo principal. La mejora de INP más rentable suele ser quitar lo que no aporta antes de optimizar lo que se queda.
¿Qué es el CLS y cómo se evita que la página "salte"?
El CLS (Cumulative Layout Shift, o "desplazamiento acumulado del diseño") mide cuánto se mueve el contenido de forma inesperada mientras la página carga. Un CLS bueno es de 0,1 o menos; por encima de 0,25 se considera deficiente. Es la métrica detrás de esa experiencia irritante en la que vas a tocar un enlace, carga un banner arriba, todo se empuja hacia abajo y terminas tocando otra cosa.
El CLS no es una cuestión de velocidad sino de estabilidad visual, y por eso muchos desarrolladores lo descuidan. Pero su impacto en la confianza del usuario es enorme: un sitio que salta se percibe como amateur y descuidado, justo lo contrario de lo que una empresa quiere transmitir. Además, los saltos provocan toques accidentales que dan al usuario la sensación de que no controla la página.
Causas típicas de un CLS malo
- Imágenes sin dimensiones declaradas. Si el navegador no sabe cuánto medirá una imagen antes de descargarla, reserva cero espacio y empuja todo cuando llega.
- Anuncios y banners insertados después. El espacio publicitario que aparece tras la carga desplaza el contenido que el usuario ya estaba leyendo.
- Fuentes que cambian de tamaño al cargar. El texto se pinta primero con una fuente del sistema y luego cambia a la fuente personalizada, alterando el alto de los bloques.
- Contenido inyectado por scripts. Avisos de cookies, barras de promoción o widgets que se insertan arriba después de que la página ya se veía.
Cómo evitar el CLS
| Acción | Esfuerzo | Efecto |
|---|---|---|
| Declarar ancho y alto en todas las imágenes y vídeos | Bajo | Elimina la causa nº 1 |
| Reservar espacio fijo para banners y anuncios | Bajo | Evita el empuje al insertarlos |
| Cargar el aviso de cookies sin desplazar contenido (overlay) | Bajo | Frecuente y fácil |
| Precargar la fuente y usar font-display adecuado | Medio | Reduce el salto de texto |
| No insertar contenido encima de lo ya visible | Medio | Disciplina de maquetación |
El CLS es, de los tres Core Web Vitals, el más barato de arreglar y el que más rápido se nota a ojo. Declarar dimensiones de imágenes y reservar espacio para los elementos que cargan tarde resuelve la mayoría de los casos en horas, no en días.
¿Por qué la velocidad web afecta al SEO y a la conversión?
La velocidad web afecta a tu negocio por dos vías que conviene separar: una indirecta, el SEO, y otra directa y más fuerte, la conversión. Google usa la experiencia de página como señal de posicionamiento, pero el golpe mayor lo da la pérdida de visitantes que abandonan un sitio lento antes de llegar a comprar o contactar. Confundir ambas vías lleva a obsesionarse con el puntaje y olvidar lo que de verdad mueve el dinero.
El efecto en SEO: un desempate, no la palanca principal
Google ha confirmado que la experiencia de página, donde viven los Core Web Vitals, es una de las señales que considera para rankear. Pero no es la más fuerte: la relevancia del contenido y la autoridad del sitio pesan más. En la práctica, los Core Web Vitals funcionan como desempate: entre dos páginas con contenido equivalente, la más rápida y estable tiende a quedar por encima. No esperes subir veinte posiciones solo por optimizar la velocidad si tu contenido es flojo; sí espera que, con buen contenido, la velocidad te ayude a consolidar y mejorar posiciones.
Hay un matiz que sí es contundente: una página lenta dificulta que Google la rastree e indexe con eficiencia, y una mala experiencia de página puede frenar el crecimiento de un sitio que por contenido merecería más. Para profundizar en cómo encaja esto en una estrategia completa, conviene revisar los fundamentos en la guía de SEO para pymes en LatAm.
El efecto en conversión: aquí está el dinero
Este es el motivo real para optimizar. El comportamiento del visitante ante la lentitud es consistente y bien documentado por la industria: cada segundo de retraso en la carga aumenta la probabilidad de abandono, y el efecto se agrava en móvil. Quien abandona antes de cargar nunca ve tu oferta, nunca llena el formulario, nunca compra. La velocidad no es un capricho técnico: es la diferencia entre que tu inversión en publicidad y SEO termine en una conversión o en un rebote.
Para una empresa de LatAm el cálculo es directo. Si pagas anuncios para traer tráfico y tu sitio tarda cuatro segundos en cargar en móvil, estás quemando parte de ese presupuesto en visitantes que se van antes de ver nada. Optimizar la velocidad multiplica el rendimiento de todo lo demás: del SEO, de la publicidad pagada y del trabajo de contenido.
| Vía de impacto | Fuerza del efecto | Cuándo se nota |
|---|---|---|
| SEO (señal de ranking) | Moderada, tipo desempate | Semanas a meses, tras el dato de campo |
| Rastreo e indexación | Moderada | Variable |
| Conversión y abandono | Fuerte y directa | Inmediato, desde el primer visitante |
| Coste por adquisición en publicidad | Fuerte | Inmediato, mejora el retorno del gasto |
| Percepción de marca y confianza | Cualitativa pero real | Inmediato |
¿Cómo medir los Core Web Vitals paso a paso?
Para medir los Core Web Vitals no necesitas pagar nada ni saber programar: con tres herramientas gratuitas de Google obtienes el diagnóstico completo del sitio y de cada página. El orden correcto es: Search Console para ver el estado de todo el sitio, PageSpeed Insights para diagnosticar una URL concreta y la extensión Web Vitals para verificar en vivo mientras navegas. Saltarse el orden lleva a optimizar páginas sueltas sin entender el problema general.
Paso 1: Google Search Console — la vista de todo el sitio
Search Console tiene un informe llamado "Core Web Vitals" (o "Métricas web esenciales") que agrupa todas las URLs de tu sitio según su estado de campo: "Buena", "Necesita mejorar" o "Deficiente", separado por móvil y escritorio. Es tu punto de partida porque te dice cuántas páginas tienen problema y de qué tipo, agrupándolas por la causa común (por ejemplo, "LCP mayor a 2,5 s en 40 URLs"). Si todavía no tienes Search Console conectado, es lo primero que debes configurar; es gratis y la base de cualquier trabajo de SEO técnico.
Paso 2: PageSpeed Insights — diagnóstico de una URL
PageSpeed Insights (pegas una URL y te da el análisis) combina las dos vistas en una sola pantalla:
- Datos de campo (arriba): la experiencia real de tus visitantes en los últimos 28 días, con LCP, INP y CLS y la marca de "Aprobada" o no. Es lo que cuenta para Google.
- Datos de laboratorio (abajo): una simulación instantánea en móvil de gama media, con el puntaje de 0 a 100 y, más abajo, las oportunidades y diagnósticos: la lista concreta de qué arreglar, ordenada por cuántos milisegundos te ahorraría cada cosa.
Mide siempre la versión móvil primero. La mayoría del tráfico de LatAm es móvil y los umbrales se incumplen mucho más fácil en celular que en computadora.
Paso 3: extensión Web Vitals de Chrome — verificación en vivo
La extensión Web Vitals para Chrome muestra LCP, INP y CLS en tiempo real mientras navegas por tu propio sitio. Es la forma más rápida de confirmar que un cambio funcionó (mides, aplicas el cambio, recargas y compruebas) y de cazar problemas de INP y CLS que solo aparecen al interactuar: abrir un menú, enviar un formulario, hacer scroll.
Cómo leer el resultado sin confundirse
| Si ves... | Significa... | Qué hacer |
|---|---|---|
| Campo aprobado, laboratorio bajo | Tus usuarios reales lo viven bien | No te obsesiones con el número de laboratorio |
| Campo no aprobado, laboratorio alto | Algo en la realidad (red, dispositivos) es peor que la simulación | Revisa hosting, CDN y peso real en móvil |
| Sin datos de campo | El sitio tiene poco tráfico para muestra | Guíate por laboratorio y la extensión en vivo |
| Search Console "Deficiente" en grupo de URLs | Problema sistémico (plantilla, tipo de página) | Arregla la plantilla, no URL por URL |
La trampa más común es perseguir el puntaje de laboratorio de PageSpeed mientras se ignora el dato de campo. El número de laboratorio es una guía de diagnóstico; el dato de campo es el veredicto. Optimiza para el campo.
¿Cuáles son las causas típicas de lentitud en sitios de empresas LatAm?
Las causas de lentitud se repiten de un sitio a otro, y en LatAm hay tres que dominan: imágenes sin optimizar, hosting lejano o saturado y exceso de JavaScript y plugins. Identificar cuál de las tres pesa más en tu caso evita gastar en la solución equivocada (por ejemplo, cambiar de hosting cuando el problema eran las fotos). Esta sección las ordena por frecuencia real y por costo de arreglarlas.
1. Imágenes pesadas (la causa nº 1)
La gran mayoría de los sitios de empresa que fallan el LCP fallan por las imágenes. Fotos subidas a tamaño completo desde el celular, banners de varios megabytes, galerías sin compresión. El navegador no puede mostrar la portada hasta descargar la imagen grande, y en una conexión móvil eso son segundos perdidos. Es, a la vez, la causa más común y la más barata de resolver.
2. Hosting económico, saturado o lejano
Mucho hosting barato de la región mete cientos de sitios en un mismo servidor compartido; cuando uno tiene un pico, todos se ralentizan. A eso se suma la distancia: si tu hosting está físicamente en otro continente, cada recurso viaja ida y vuelta a través del océano. El síntoma es un TTFB alto (el servidor tarda en empezar a responder), que arrastra a toda la carga. Un CDN mitiga la distancia; un mejor plan de hosting resuelve la saturación.
3. Exceso de JavaScript y plugins acumulados
El sitio empezó limpio y, con los años, acumuló plugins de SEO, de seguridad, de formularios, de chat, de redes, de analítica, de pop-ups. Cada uno suma código que el navegador debe descargar y ejecutar. Es la causa nº 1 del mal INP y un agravante del LCP. La auditoría de "qué plugins de verdad necesito" suele liberar peso considerable sin coste.
4. Falta de caché
Sin caché, cada visita obliga al servidor a construir el HTML desde cero. En WordPress esto es especialmente caro porque cada página se arma consultando la base de datos. Activar caché de página es de las mejoras de mayor impacto y menor esfuerzo que existen.
5. Fuentes y scripts de terceros mal cargados
Fuentes personalizadas que bloquean el pintado, chats que cargan toda su librería al inicio, mapas embebidos que arrastran megabytes. Cargar estos elementos de forma diferida y solo cuando se necesitan resuelve buena parte del problema.
| Causa | Frecuencia en LatAm | Métrica afectada | Costo de arreglar |
|---|---|---|---|
| Imágenes sin optimizar | Muy alta | LCP, CLS | Bajo |
| Hosting lejano o saturado | Alta | LCP (TTFB) | Medio |
| Exceso de JS y plugins | Alta | INP, LCP | Bajo a medio |
| Falta de caché | Alta | LCP (TTFB) | Bajo |
| Fuentes y terceros mal cargados | Media | LCP, INP, CLS | Bajo a medio |
¿Cómo elegir hosting y CDN para que el sitio vaya rápido?
El hosting determina cuánto tarda el servidor en empezar a responder, y un CDN reduce la distancia entre ese servidor y cada visitante; juntos resuelven la mitad del problema de velocidad que no depende de tu código. La regla para empresas de LatAm: elige un hosting con buen TTFB, idealmente con servidores cercanos a tu mercado, y añade un CDN, que suele ser la mejora de mayor impacto por menos dinero. Un sitio impecable montado sobre un servidor lento seguirá siendo lento.
Qué mirar en un hosting
No te dejes llevar por el precio del primer mes ni por los gigabytes prometidos. Lo que importa para la velocidad:
- TTFB bajo (tiempo hasta el primer byte). Es la métrica que delata un servidor lento. Pídela o mídela con PageSpeed.
- Ubicación de los servidores. Cuanto más cerca de tu mercado principal, mejor. Para LatAm, servidores en la región o en Estados Unidos suelen rendir mejor que en Europa o Asia.
- Tipo de alojamiento. El compartido barato satura; un plan con recursos garantizados, un VPS o un alojamiento gestionado rinde de forma más estable.
- Soporte real. Cuando algo se rompe, importa que respondan rápido y en tu idioma.
Qué hace (y qué no hace) un CDN
Un CDN (red de distribución de contenido) guarda copias de tu sitio en servidores repartidos por el mundo y sirve a cada visitante desde el más cercano. Sus beneficios:
- Reduce el TTFB sirviendo desde un nodo cercano, incluso si tu hosting está lejos.
- Absorbe picos de tráfico sin que el servidor de origen colapse.
- Aporta capa de seguridad ante ataques y abusos.
- Sirve imágenes y archivos estáticos muy rápido y, en muchos casos, ya optimizados.
Lo que un CDN no hace: arreglar imágenes pesadas mal subidas, eliminar JavaScript de más o corregir un CLS por imágenes sin dimensiones. El CDN acelera la entrega; no arregla un sitio mal construido. Es complemento, no sustituto de la optimización de la página.
| Escenario de la empresa | Recomendación práctica |
|---|---|
| Sitio en hosting compartido barato y lento | Subir de plan o cambiar de proveedor antes que nada |
| Hosting decente pero servidores lejos del mercado | Añadir CDN: máximo impacto por poco dinero |
| Tráfico con picos (campañas, lanzamientos) | CDN obligatorio para no caer en el pico |
| Proyecto nuevo desde cero | Elegir hosting con buen TTFB y CDN desde el día 1 |
Existen CDN con plan gratuito suficiente para muchas pymes; el costo de uno de pago es orientativo y arranca bajo. Por la relación impacto-precio, para un sitio de LatAm con hosting lejano, el CDN es casi siempre la primera inversión que conviene hacer.
¿Cómo optimizar las imágenes para Core Web Vitals?
Optimizar imágenes es la acción de mayor retorno para la velocidad web porque ataca a la vez el LCP (la métrica más incumplida) y el CLS, y casi siempre es de bajo esfuerzo. El método tiene cuatro pasos: convertir a formatos modernos (WebP o AVIF), redimensionar al tamaño real en que se muestran, comprimir y aplicar carga diferida a lo que no se ve al abrir la página. Hacer solo esto suele recortar el LCP a la mitad sin tocar nada más.
Los cuatro pasos, en orden
- Convierte a WebP o AVIF. Estos formatos modernos pesan mucho menos que JPG o PNG con calidad equivalente. La conversión es automática con plugins o con herramientas de la agencia, y los navegadores actuales los soportan sin problema.
- Redimensiona al tamaño real. Una imagen que se muestra a 800 píxeles de ancho no necesita medir 4.000. Servir la imagen al tamaño en que realmente se ve evita descargar datos que el navegador desecha.
- Comprime. Una compresión inteligente reduce el peso sin que el ojo note la diferencia. El objetivo orientativo: que las fotos de contenido bajen a cientos de kilobytes, no megabytes.
- Aplica carga diferida (lazy loading). Todo lo que está debajo del primer pantallazo se carga solo cuando el usuario hace scroll hacia ello, liberando el arranque. Importante: la imagen del hero (la del LCP) no debe llevar lazy loading; al contrario, conviene priorizarla.
Detalles que evitan el CLS
Optimizar el peso no basta: para que las imágenes no provoquen saltos hay que declarar siempre el ancho y el alto (o la proporción) de cada imagen. Así el navegador reserva el espacio exacto antes de descargarla y nada se mueve cuando llega. Es la corrección de CLS más frecuente y una de las más olvidadas.
| Problema de imagen | Síntoma | Solución |
|---|---|---|
| Foto de portada de varios MB | LCP alto | WebP + redimensionar + comprimir |
| Imágenes sin ancho/alto declarado | CLS alto, página que salta | Declarar dimensiones o aspect-ratio |
| Galería completa cargando al inicio | Carga inicial pesada | Lazy loading en todo menos el hero |
| Imagen del hero con lazy loading | LCP innecesariamente alto | Quitar lazy y precargar (preload) el hero |
Para una pyme con WordPress, un buen plugin de optimización de imágenes hace los pasos 1 a 4 en automático sobre toda la biblioteca. Para un proyecto en Next.js, la optimización de imágenes viene de fábrica con el componente de imagen del propio framework.
¿WordPress o Next.js para rendimiento? Comparativa honesta
Para rendimiento puro, Next.js parte con ventaja estructural sobre WordPress, pero un WordPress bien optimizado puede aprobar los Core Web Vitals sin problema; la decisión correcta depende del proyecto, no de una regla absoluta. WordPress gana en facilidad de gestión y ecosistema; Next.js gana en velocidad de fábrica porque envía menos JavaScript y entrega páginas estáticas o renderizadas en el servidor. Lo importante es no elegir por moda, sino por lo que el negocio necesita.
Por qué WordPress tiende a ser más lento
WordPress no es lento por naturaleza; se vuelve lento por acumulación. Cada página se genera al vuelo consultando la base de datos, los temas comerciales cargan funciones que no usas, y con los años se apilan plugins que suman peso. Un WordPress descuidado falla los tres Core Web Vitals. Un WordPress cuidado (buen hosting, caché de página, imágenes en WebP, pocos plugins, un tema liviano, un CDN) los aprueba. La clave es la disciplina de mantenimiento, que muchas empresas no tienen.
Por qué Next.js parte con ventaja
Next.js genera las páginas como HTML estático o renderizado en el servidor y envía al navegador solo el JavaScript imprescindible. Eso significa, por defecto, mejor LCP (la página llega casi lista), mejor INP (menos JavaScript que bloquee el hilo) y optimización de imágenes incorporada. No hay base de datos consultándose en cada visita ni plugins compitiendo por recursos. Es la arquitectura que más fácil pone tener LCP, INP y CLS en verde, pero requiere desarrollo (no se administra con clics como WordPress) y un perfil técnico para mantenerlo.
Comparativa para decidir
| Criterio | WordPress | Next.js |
|---|---|---|
| Velocidad de fábrica | Media (depende de optimización) | Alta |
| LCP / INP típicos | Aprobables con trabajo | Verdes con menos esfuerzo |
| Facilidad para editar contenido | Muy alta (sin técnico) | Media (suele requerir apoyo) |
| Costo de mantenimiento | Bajo a medio | Medio |
| Ecosistema de plugins | Enorme | Menor, más a medida |
| Ideal para | Blog, sitio corporativo, tienda estándar | Sitio rápido, web app, proyecto con escala |
| Riesgo de degradarse con el tiempo | Alto si no hay disciplina | Bajo |
La recomendación práctica: si ya tienes WordPress y funciona, no migres solo por velocidad; primero optimízalo, que suele bastar. Plantéate Next.js cuando empiezas de cero, cuando el rendimiento es crítico para el negocio o cuando WordPress se volvió inmanejable por acumulación. La migración es una inversión seria, no un cambio cosmético; conviene evaluarla con criterio dentro de una estrategia de diseño completa, como se detalla en la guía de diseño web para empresas en Latinoamérica.
¿Cuánto cuesta optimizar la velocidad de un sitio en LatAm?
El costo de optimizar la velocidad es orientativo y varía por país y por el estado del sitio, pero se puede ordenar en tres niveles según la profundidad del trabajo. Una optimización básica sobre un sitio existente suele ir de 150 a 600 USD; una intermedia con hosting o CDN de 600 a 2.000 USD; una reconstrucción estructural parte de varios miles de USD. El retorno no se mide en puntos de PageSpeed sino en más conversión y mejor posicionamiento.
| Nivel | Qué incluye | Rango orientativo (USD) | Cuándo conviene |
|---|---|---|---|
| Básico | Caché, compresión de imágenes, limpieza de plugins, ajuste de fuentes | 150 – 600 | Sitio que solo necesita afinarse |
| Intermedio | Lo anterior + migración a mejor hosting o CDN + revisión de scripts de terceros | 600 – 2.000 | Hosting lento o lejano, sitio cargado |
| Estructural | Reconstrucción en arquitectura moderna (p. ej. Next.js) para resolver de raíz | Desde varios miles | Sitio inmanejable o rendimiento crítico |
Estos rangos varían entre México, Colombia, Argentina, Chile y Perú según el costo local del trabajo técnico y según cobres en moneda local o en USD. Trátalos como referencia para conversar con un proveedor, no como tarifa fija; pide siempre desglose de qué incluye y cómo se medirá el resultado (antes y después en PageSpeed y Search Console). Para entender qué mueve el precio de un proyecto web completo y cómo pedir presupuesto sin pagar dos veces, ayuda contrastar con la guía de diseño web para empresas LatAm.
Una advertencia útil: desconfía de quien cobra mucho por "subir el puntaje a 100" sin hablar de los datos de campo ni de conversión. El número de PageSpeed es un medio; el objetivo del negocio es que el sitio sea rápido para tus visitantes reales y que esos visitantes conviertan.
Checklist de optimización de velocidad web
Este checklist es el orden de trabajo recomendado, de mayor impacto y menor esfuerzo hacia arriba. Sirve tanto para auditar tu sitio actual como para verificar el trabajo de una agencia: cada punto se comprueba con PageSpeed, Search Console o la extensión Web Vitals. Hazlo en este orden y mide después de cada bloque.
Bloque 1 — Imágenes (mayor impacto, menor esfuerzo)
- Todas las imágenes en WebP o AVIF, no JPG/PNG pesados
- Imágenes redimensionadas al tamaño real en que se muestran
- Compresión aplicada (fotos de contenido en cientos de KB, no en MB)
- Lazy loading en todo lo que está bajo el primer pantallazo
- Imagen del hero (LCP) sin lazy loading y, si es posible, precargada
- Ancho y alto (o proporción) declarados en cada imagen
Bloque 2 — Servidor y entrega
- TTFB medido y razonable (servidor responde rápido)
- Caché de página activada
- Compresión del servidor activa (gzip/brotli)
- CDN configurado, sobre todo si el hosting está lejos del mercado
- Hosting con recursos suficientes (no compartido saturado)
Bloque 3 — JavaScript y terceros
- Inventario de scripts de terceros: eliminar lo que no aporta
- Scripts no esenciales con carga diferida (defer/async)
- Un solo chat/widget en vez de varios
- Plugins auditados: desinstalar los que no se usan
- Constructor visual revisado por su peso de JavaScript
Bloque 4 — Estabilidad visual (CLS)
- Espacio reservado para banners y anuncios
- Aviso de cookies que no desplaza el contenido (overlay)
- Fuentes precargadas y con font-display adecuado
- Sin contenido inyectado encima de lo ya visible
Bloque 5 — Medición y seguimiento
- Search Console conectado y revisado el informe Core Web Vitals
- PageSpeed medido en móvil primero, luego escritorio
- Extensión Web Vitals usada para verificar en vivo tras los cambios
- Re-medición de campo programada a 4 semanas (no esperar resultado inmediato)
- Objetivo claro: los tres Vitals en verde para usuarios reales, no 100 puntos
¿Cómo dar el primer paso para acelerar tu sitio?
El primer paso no es contratar una reconstrucción, sino medir con honestidad y atacar la causa de mayor impacto, que en la mayoría de sitios de LatAm son las imágenes. La secuencia sensata es: medir el estado real, identificar cuál de las tres causas comunes pesa más, arreglar primero lo barato y de alto impacto, volver a medir y solo entonces decidir si hace falta hosting, CDN o una reconstrucción. Hacerlo en este orden evita gastar de más en la solución equivocada.
- Mide el estado real. Pasa tu URL principal por PageSpeed en móvil y revisa el informe Core Web Vitals de Search Console. Anota LCP, INP y CLS de campo.
- Identifica la causa dominante. ¿LCP alto por imágenes? ¿INP alto por scripts? ¿CLS por imágenes sin dimensiones? El diagnóstico dirige la inversión.
- Ataca primero lo barato y de alto impacto. Imágenes, caché y limpieza de plugins. Suele bastar para mover las métricas de forma notable.
- Vuelve a medir. Confirma la mejora con la extensión en vivo y, para campo, espera la ventana de 28 días.
- Decide el siguiente nivel solo si hace falta. Si tras lo barato el TTFB sigue alto, mira hosting y CDN. Si el problema es estructural, evalúa una reconstrucción.
Para una empresa de Latinoamérica, la velocidad web es de las inversiones con mejor retorno que existen porque multiplica el rendimiento de todo lo demás: el SEO trabaja mejor, la publicidad pagada convierte más y la marca transmite seriedad. No hace falta empezar por lo grande ni perseguir el puntaje perfecto. Hace falta medir bien, arreglar lo que de verdad pesa y comprobar que tus visitantes reales, los del celular y la conexión móvil, viven un sitio rápido y estable. Ese es el objetivo, y casi siempre está a unos pocos arreglos de distancia.
¿Cómo afectan los Core Web Vitals al e-commerce y a las páginas de conversión?
En una tienda online o en una landing de captación, la velocidad no es un asunto técnico: es facturación. Cada décima de segundo de retraso en una página de producto o en un formulario reduce la tasa de conversión, y el efecto se multiplica en móvil, que es donde compra y consulta la mayoría del tráfico en LatAm. Las páginas que mueven dinero —ficha de producto, carrito, checkout, landing de campaña— son las que más rinden al optimizar y las primeras que conviene atacar.
La lógica es de embudo. Cada paso entre que el visitante llega y que paga o contacta es una oportunidad de abandono, y la lentitud agranda esa fuga en cada paso. Un checkout que se siente "pegajoso" (mal INP) hace que el comprador dude en el peor momento; una ficha de producto cuyo precio o botón de compra salta al cargar (mal CLS) destruye la confianza justo cuando el cliente iba a decidir; una landing de campaña que tarda en pintar (mal LCP) quema el presupuesto publicitario que pagaste para traer ese clic.
Dónde duele más cada métrica en una tienda
| Página | Métrica crítica | Por qué |
|---|---|---|
| Inicio / categoría | LCP | Primera impresión; si tarda, el visitante no explora |
| Ficha de producto | LCP y CLS | La foto pesa; el precio y el botón no deben saltar |
| Buscador y filtros | INP | Cada filtro es una interacción; si se traba, frustra |
| Carrito | INP y CLS | Cambiar cantidades debe responder al instante y sin saltos |
| Checkout | INP | Es el paso del dinero; cualquier lentitud genera dudas |
| Landing de campaña | LCP | Pagaste por el clic; tiene que cargar ya |
Prioriza las páginas que mueven dinero
El error frecuente es repartir el esfuerzo de optimización por igual entre todas las páginas. El acierto es ordenar por impacto en negocio: primero las páginas que reciben tráfico pagado o que están en el camino directo a la compra, después el resto. Una tienda con cientos de fichas no necesita que las cientos estén perfectas el primer día; necesita que la plantilla de ficha de producto y el checkout estén impecables, porque eso optimiza todas las fichas de golpe y protege el paso donde se decide la venta. Si tu negocio ya combina la tienda con flujos de atención automatizada, conviene que esa capa también sea rápida; la guía de inteligencia artificial para empresas en Latinoamérica explica cómo encajan chatbots y automatización sin penalizar el rendimiento del sitio.
La medición aquí debe ir más allá del puntaje: cruza los Core Web Vitals de campo con la tasa de conversión por página de tu analítica. Cuando veas que una página con mal LCP también tiene una tasa de conversión baja respecto a sus pares, tienes la prueba económica que justifica la inversión y el orden de prioridades.
Errores comunes al optimizar la velocidad (y cómo evitarlos)
La mayoría de los proyectos de optimización fallan por criterio, no por falta de herramientas. El error más caro es perseguir el puntaje de laboratorio en vez de la experiencia real de campo; el más común es optimizar todo a la vez sin medir entre cambios. Conocerlos de antemano ahorra tiempo, dinero y discusiones con el proveedor.
Error 1: obsesionarse con llegar a 100 en PageSpeed
El número de PageSpeed es una guía de diagnóstico, no la meta. Pasados los umbrales "buenos" de campo, cada punto extra cuesta cada vez más esfuerzo y rinde cada vez menos al negocio. Un sitio con 85 puntos y los tres Vitals en verde para usuarios reales vale más que uno con 99 al que nadie le compra. La meta es campo en verde y conversión, no un número redondo.
Error 2: confundir dato de laboratorio con dato de campo
Es la fuente número uno de malentendidos entre empresa y desarrollador. El laboratorio mejora al instante; el campo tarda semanas porque se basa en 28 días de visitas reales. Quien promete Search Console en verde "mañana" no entiende la diferencia. Mide ambos, pero toma las decisiones de negocio mirando el campo.
Error 3: cambiar muchas cosas a la vez sin medir entre medias
Si aplicas diez cambios juntos y el sitio mejora, no sabes cuál funcionó ni cuál pudo empeorar otra cosa. Trabaja por bloques (imágenes, luego servidor, luego scripts), mide después de cada uno y guarda el "antes". Así aíslas lo que de verdad mueve la aguja y puedes deshacer lo que rompa algo.
Error 4: ignorar el móvil y medir solo en escritorio
El tráfico de LatAm es mayoritariamente móvil y los umbrales se incumplen mucho más en celular. Optimizar mirando solo la versión de escritorio deja sin resolver justo donde están tus visitantes y tus ventas. Mide móvil primero, siempre.
Error 5: instalar plugins de velocidad sin entender qué hacen
Apilar varios plugins de "optimización" puede empeorar el sitio: chocan entre sí, duplican funciones y a veces rompen la maquetación. Un plugin de caché bien configurado vale más que cinco mal puestos. Menos es más, también aquí.
Error 6: optimizar la portada y olvidar las páginas que convierten
La portada suele recibir el cuidado, pero las que mueven dinero son las fichas de producto, las landings y el checkout. Asegúrate de que las plantillas de esas páginas estén optimizadas; es ahí donde la velocidad se traduce en facturación.
Error 7: no volver a medir pasadas las semanas
La optimización no termina al aplicar los cambios. El veredicto real llega cuando el dato de campo se actualiza, tres o cuatro semanas después. Programa una re-medición y confirma que las URLs pasaron a "buena" en Search Console; sin ese cierre, no sabes si el trabajo funcionó de verdad.
Cómo leer un informe de PageSpeed sin perderse en los tecnicismos
Un informe de PageSpeed Insights abruma a quien no es técnico porque mezcla en una pantalla datos de campo, datos de laboratorio, un puntaje grande, oportunidades, diagnósticos y una auditoría con decenas de líneas. La regla para leerlo bien: mira primero los tres números de campo (LCP, INP, CLS) y la marca de "Aprobada"; el resto es diagnóstico para decidir qué arreglar, no la nota final. Saber qué ignorar es tan importante como saber qué mirar.
El orden de lectura correcto, de arriba abajo
- ¿Hay datos de campo? Si aparece el bloque "Descubre lo que experimentan tus usuarios reales", esos son los números que cuentan. Si no aparece, tu sitio tiene poco tráfico para muestra y debes guiarte por el laboratorio y la extensión en vivo.
- ¿Está "Aprobada" la evaluación de campo? Es un sí o un no global de los tres Vitals en el percentil 75. Ese es el veredicto de Google sobre la experiencia de página.
- ¿Cuál de los tres está en rojo o ámbar? El que falle te dice por dónde empezar: rojo en LCP manda a imágenes y servidor, rojo en INP manda a JavaScript y terceros, rojo en CLS manda a dimensiones e inserciones tardías.
- El puntaje grande de laboratorio (0-100): úsalo como termómetro de diagnóstico, no como meta. Es útil para comparar antes y después de un cambio el mismo día, no para presumir.
- "Oportunidades" y "Diagnósticos": aquí está la lista de tareas concretas, cada una con el ahorro estimado en tiempo. Es tu lista de trabajo priorizada.
Qué significan las oportunidades más frecuentes en lenguaje claro
| Mensaje técnico de PageSpeed | Qué quiere decir | Acción del negocio |
|---|---|---|
| "Mejora la entrega de imágenes" | Las imágenes pesan de más o no están en formato moderno | Comprimir y pasar a WebP/AVIF |
| "Difiere los recursos que bloquean el renderizado" | CSS/JS frenan el primer pintado | Pedir al desarrollador que difiera lo no crítico |
| "Reduce el tiempo de respuesta del servidor (TTFB)" | El hosting tarda en empezar a responder | Mejorar hosting o añadir CDN |
| "Minimiza el trabajo del hilo principal" | Demasiado JavaScript ejecutándose | Auditar plugins y scripts de terceros |
| "Las imágenes no tienen dimensiones explícitas" | Causa de saltos (CLS) | Declarar ancho y alto en cada imagen |
| "Precarga la imagen LCP" | La portada llega tarde | Priorizar la imagen del hero (preload) |
Con esta traducción, el dueño de empresa puede leer el informe, identificar las dos o tres tareas de mayor ahorro y pedírselas a su proveedor con nombre y apellido, en lugar de delegar a ciegas o pagar por "optimización" sin saber qué se hizo.
Cómo documentar el antes y el después para no pagar por humo
La forma de protegerse de un proveedor que cobra sin entregar es exigir evidencia medible. Antes de cualquier trabajo, captura el estado: una imagen del informe de campo de PageSpeed en móvil de tu URL principal y de tus dos páginas que más convierten, más el estado del informe Core Web Vitals de Search Console. Guarda fecha. Tras el trabajo, repite la captura del laboratorio de inmediato (debe mejorar ya) y agenda la del campo a las cuatro semanas (es la que vale). Si el laboratorio no mejoró el mismo día, el trabajo no se hizo bien; si el campo no mejora a las cuatro semanas, hay que revisar. Esta disciplina de evidencia convierte una promesa difusa en un resultado verificable.
Velocidad web y visibilidad en buscadores de IA (GEO)
La velocidad web también influye en que tu sitio sea elegido como fuente por los buscadores y asistentes de IA, aunque por una vía distinta a la del SEO clásico. Los rastreadores que alimentan a los motores de respuesta con IA tienen presupuestos de rastreo y tiempos de espera: un sitio lento se rastrea peor, se indexa con menos frecuencia y queda en desventaja frente a fuentes equivalentes más rápidas a la hora de ser citado. En un escenario donde cada vez más tráfico llega vía respuestas generadas por IA, la velocidad deja de ser solo experiencia de usuario y pasa a condicionar la "rastreabilidad" de tu contenido.
Por qué un sitio lento se cita menos en respuestas de IA
Los sistemas que generan respuestas con IA (resúmenes en el buscador, asistentes conversacionales) construyen sus respuestas a partir de páginas que sus rastreadores lograron leer y entender con eficiencia. Una página que tarda mucho en responder o que requiere ejecutar mucho JavaScript para mostrar su contenido le pone trabas al rastreador: o lo abandona antes de leerlo entero, o lo visita con menos frecuencia, o capta una versión incompleta. El contenido puede ser excelente, pero si el rastreador no lo procesa bien, no entra en la "biblioteca" desde la que el modelo construye su respuesta.
Esto conecta con dos buenas prácticas que se refuerzan entre sí: tener contenido que responda directo a la pregunta (formato answer-first) y servirlo rápido y sin depender de JavaScript para que aparezca. Un sitio rápido con HTML legible de inmediato es, a la vez, mejor para los Core Web Vitals y más fácil de citar para un motor de IA.
La ventaja estructural del renderizado en servidor
Aquí reaparece la diferencia entre arquitecturas. Una página que entrega su contenido ya armado desde el servidor (como hace Next.js por defecto, o un WordPress con buena caché) es legible para cualquier rastreador en la primera lectura. Una página que solo muestra su contenido después de ejecutar JavaScript en el navegador obliga al rastreador a un trabajo extra que no siempre completa. Para una empresa que quiere aparecer en respuestas de IA, servir el contenido renderizado y rápido no es un lujo técnico: es la condición para entrar en el juego.
| Factor de velocidad | Efecto en SEO clásico | Efecto en visibilidad de IA (GEO) |
|---|---|---|
| TTFB bajo | Mejor rastreo e indexación | Rastreador lee más páginas por visita |
| Contenido sin depender de JS | Indexación fiable | El motor de IA capta el contenido completo |
| LCP bueno | Señal de experiencia de página | Menos abandono del rastreador |
| HTML limpio y answer-first | Mejores fragmentos en resultados | Más probabilidad de ser citado en la respuesta |
La conclusión práctica para 2026: optimizar la velocidad ya no rinde solo en posiciones y conversión, sino también en aparecer cuando alguien pregunta a una IA por lo que tu empresa ofrece. Es la misma inversión sirviendo a tres frentes a la vez.
Mantener la velocidad en el tiempo: la optimización no es un evento
El mayor error después de optimizar es creer que el trabajo terminó; la velocidad se degrada sola con el uso normal del sitio. Un sitio que aprobó los Core Web Vitals vuelve a fallarlos en meses si nadie vigila lo que se añade: cada imagen pesada subida sin comprimir, cada plugin nuevo, cada script de marketing pegado en el encabezado erosiona lo ganado. Mantener la velocidad es un hábito, no un proyecto con fecha de cierre.
De dónde viene la degradación
La velocidad se pierde por las mismas vías por las que se ganó, en sentido contrario. El equipo de marketing pega el código de un nuevo píxel de seguimiento. Alguien sube al blog una foto de cuatro megabytes directa del celular. Se instala un plugin para un formulario que carga su propia librería en todas las páginas. Se añade un banner promocional que se inserta tarde y empuja el contenido. Ninguno de estos actos es grave por sí solo; sumados a lo largo de un año, devuelven el sitio al punto de partida.
Rutina mínima de mantenimiento
Una empresa no necesita un equipo dedicado para mantener la velocidad; necesita una rutina ligera y constante:
- Regla de imágenes en la publicación. Quien sube contenido aplica siempre compresión y formato moderno antes de publicar. Si es WordPress, un plugin que lo haga automático evita depender de la disciplina humana.
- Revisión trimestral de PageSpeed. Cada tres meses, una pasada por las páginas que más convierten en móvil. Diez minutos que cazan la degradación antes de que pese.
- Política de scripts nuevos. Ningún código de terceros se añade sin preguntar qué aporta y qué pesa. Cada script tiene que justificar su sitio.
- Auditoría anual de plugins. Una vez al año, desinstalar lo que no se usa. La acumulación silenciosa es la causa número uno de la degradación a largo plazo.
Quién es responsable de la velocidad
El punto que más se descuida es la responsabilidad. Si la velocidad no es tarea de nadie, se degrada sin que nadie lo note hasta que las ventas bajan. Asignar la vigilancia a una persona —interna o en la agencia— con una revisión periódica en el calendario convierte el mantenimiento en un proceso, no en una reacción tardía. Para muchas pymes, lo más rentable es incluir esta vigilancia en un contrato de mantenimiento con quien construyó el sitio: sale más barato prevenir la degradación que volver a optimizar desde cero cada dos años.
| Frecuencia | Tarea de mantenimiento | Tiempo aproximado |
|---|---|---|
| En cada publicación | Comprimir y convertir imágenes nuevas | Automático con plugin |
| Trimestral | PageSpeed en móvil de páginas clave | 10-15 minutos |
| Ante cada cambio | Evaluar peso de scripts nuevos | Minutos por decisión |
| Anual | Auditoría y limpieza de plugins | 1-2 horas |
Conclusión operativa
Los Core Web Vitals condensan en tres números —LCP de carga, INP de respuesta y CLS de estabilidad— la experiencia real que vive quien entra a tu sitio, casi siempre desde un celular con conexión móvil. Verde significa LCP ≤ 2,5 s, INP ≤ 200 ms y CLS ≤ 0,1 medido en el percentil 75 de visitas reales, y se evalúa con datos de campo que tardan semanas en moverse, no con el puntaje instantáneo de laboratorio. Importan al SEO como desempate y, sobre todo, a la conversión, donde el efecto es inmediato y fuerte: un sitio lento pierde clientes antes de que vean tu oferta. Las causas se repiten —imágenes sin optimizar, hosting lejano y exceso de JavaScript— y el orden de arreglo correcto va de lo barato y de alto impacto (imágenes, caché) a lo estructural (hosting, CDN, reconstrucción). WordPress aprueba con disciplina; Next.js parte con ventaja. El costo es orientativo y variable por país, pero el retorno es claro porque la velocidad multiplica el rendimiento de toda tu inversión digital. Mide, arregla lo que pesa y comprueba contra tus usuarios reales: ahí está el negocio.