Una de las conversaciones que más se repiten entre equipos de contenido y de desarrollo es alguna versión de "el sitio está lento" seguida de "pero el contenido está bien, ¿por qué no posiciona?". Es una conversación frustrante para ambos lados porque, sin un vocabulario común, cada equipo asume que el problema es responsabilidad exclusiva del otro. La respuesta casi siempre está en Core Web Vitals: un conjunto de métricas que Google usa para medir la experiencia real de carga de una página, y que forman parte directa de los factores de posicionamiento.
No hace falta ser desarrolladora para entender Core Web Vitals ni para detectar cuándo están afectando tu contenido. Lo que sí hace falta es dejar de tratarlo como "un tema de sistemas" que no te compete — porque, como equipo editorial, muchas de las decisiones que tomas todos los días (qué imágenes subes, cuántos scripts de terceros se agregan a una plantilla, cómo se estructura una página) afectan directamente estas métricas.
Este artículo traduce las tres métricas de Core Web Vitals a un lenguaje que no requiere formación técnica previa, con el objetivo puntual de que cualquier persona en un equipo editorial pueda leer un reporte de rendimiento, entender qué significa, y saber qué preguntar antes de pedir ayuda a desarrollo.
Por qué esto le importa a un equipo editorial, no solo a desarrollo
En el caso del blog inmobiliario que llevé en Lamudi, el contenido editorial era sólido —12 artículos mensuales, bien investigados— pero la posición promedio del sitio se mantenía estancada en el puesto 18. Al auditar el sitio, los errores críticos de Core Web Vitals eran una de las tres causas principales, junto con problemas de crawlability y ausencia de schema markup. Ningún artículo nuevo, por bueno que fuera, iba a superar esa barrera técnica por sí solo.
Esa experiencia es la razón por la que insisto tanto en que los equipos de contenido entiendan al menos lo básico de estas métricas: no para arreglarlas ellos mismos, sino para saber cuándo señalar el problema correcto al equipo correcto, y para evitar introducir nuevos problemas sin darse cuenta.
Hay además una razón menos evidente pero igual de importante: la mayoría de las decisiones que degradan Core Web Vitals no las toma el equipo de desarrollo, las toma el equipo de contenido o marketing, sin saber que tienen ese efecto. Subir una imagen de 4 MB sin comprimir, insertar un video autoplay en el encabezado de un artículo, o pedir "un script más" para medir una campaña son decisiones editoriales y de marketing con consecuencias técnicas directas. Entender esto no es opcional si quieres que tu contenido compita en igualdad de condiciones.
LCP: qué tan rápido aparece lo importante
Largest Contentful Paint mide cuánto tiempo tarda en renderizarse el elemento más grande visible en la pantalla al cargar una página — normalmente una imagen destacada, un video, o un bloque de texto principal. Google considera bueno un LCP menor a 2.5 segundos.
Para un equipo de contenido, el LCP suele estar directamente relacionado con la imagen destacada de un artículo o producto. Una imagen sin comprimir, subida directamente desde una cámara profesional sin optimización, puede por sí sola arruinar el LCP de una página entera, sin importar qué tan optimizado esté el resto del código.
Un hábito simple que resuelve la mayoría de estos casos: comprimir toda imagen a formato WebP antes de subirla, y nunca superar los 200-300 KB para una imagen destacada, sin importar la resolución original con la que se tomó la foto. Herramientas gratuitas como Squoosh o TinyPNG hacen esta conversión en segundos, sin necesidad de software especializado ni conocimientos técnicos.
INP: qué tan rápido responde la página
Interaction to Next Paint reemplazó a First Input Delay como métrica oficial en 2024, y mide cuánto tarda la página en responder visualmente después de que alguien hace clic, toca o escribe algo. Google considera bueno un INP menor a 200 milisegundos.
Esta métrica suele degradarse por exceso de JavaScript ejecutándose en la página: chats en vivo, píxeles de seguimiento de múltiples plataformas publicitarias, widgets de redes sociales incrustados. Cada script adicional que un equipo de marketing pide agregar "solo para medir esto" tiene un costo real en esta métrica, que rara vez se discute antes de instalarlo.
Un ejercicio que recomiendo repetir cada trimestre: hacer un inventario de todos los scripts de terceros activos en el sitio y preguntar, por cada uno, si todavía se está usando. Es sorprendentemente común encontrar píxeles de campañas que terminaron hace meses, o widgets de pruebas que nunca se retiraron, consumiendo recursos de carga sin ningún beneficio actual a cambio.
CLS: cuánto se mueve el contenido mientras carga
Cumulative Layout Shift mide cuánto se desplaza visualmente el contenido de una página mientras esta termina de cargar — ese momento incómodo en el que intentas hacer clic en un botón y, porque un banner de anuncios terminó de cargar arriba, terminas haciendo clic en otra cosa. Google considera bueno un CLS menor a 0.1.
Las causas más comunes de un CLS alto, desde la perspectiva de contenido: imágenes insertadas sin especificar su ancho y alto en el código (lo que hace que el navegador no reserve el espacio correcto de antemano), fuentes web que cambian el tamaño del texto al cargar, y anuncios o banners insertados dinámicamente sin un contenedor de tamaño fijo.
Este es, en mi experiencia, el más frustrante de los tres para un equipo de contenido, porque el problema casi nunca es visible al revisar la página ya cargada — solo se nota en el instante exacto en que carga, que es precisamente cuando la mayoría de los usuarios reales interactúan con ella por primera vez. Revisar el sitio ya cargado en tu propia computadora, con buena conexión, prácticamente nunca revela un problema de CLS que sí está afectando a usuarios reales con conexiones más lentas.
Los culpables más comunes (y quién los suele causar)
- Imágenes sin optimizar — normalmente introducidas por el equipo de contenido al subir material sin comprimir ni redimensionar antes de publicar.
- Scripts de terceros acumulados — normalmente introducidos por marketing, ventas o análisis, cada uno pidiendo "un pixel más" sin coordinación entre equipos.
- Fuentes web pesadas o mal cargadas — normalmente una decisión de diseño que no consideró el impacto en velocidad de carga.
- Plantillas con demasiados elementos por página — normalmente una decisión de UX que prioriza mostrar mucho contenido sin considerar el costo de renderizado.
- Videos incrustados en autoplay — normalmente pedidos por marketing para aumentar tiempo en página, sin medir el costo de carga que representan, especialmente en conexiones móviles.
Vale la pena subrayar que ninguno de estos equipos actúa de mala fe: cada decisión, vista de forma aislada, tiene una justificación razonable (mejor calidad de imagen, mejor medición, más contenido visible, más engagement). El problema aparece cuando nadie mide el efecto acumulado de todas esas decisiones razonables juntas sobre el rendimiento real del sitio.
El patrón que se repite en casi todos los casos: Core Web Vitals rara vez se degrada por un solo error grande. Se degrada por la acumulación de pequeñas decisiones tomadas por distintos equipos, ninguno de los cuales tenía visibilidad completa del impacto combinado.
Cómo priorizar cuando no puedes arreglarlo todo a la vez
En sitios con historial largo y equipos distintos tomando decisiones durante años, es común encontrar decenas de causas acumuladas de un mal desempeño en Core Web Vitals. Intentar arreglarlo todo al mismo tiempo suele paralizar el proyecto. En su lugar, prioriza así:
- Primero, la plantilla con más tráfico. Corregir el LCP de la página de inicio o de la plantilla de artículo principal impacta a miles de páginas de una sola vez, a diferencia de corregir una página individual.
- Segundo, lo que es responsabilidad editorial directa. Comprimir imágenes y auditar scripts de terceros no requiere un sprint de desarrollo — puede resolverse de inmediato desde el equipo de contenido.
- Tercero, lo que requiere desarrollo. Cambios de código, de servidor o de arquitectura se agendan como proyecto técnico, con tiempo y presupuesto reales asignados, no como una tarea "rápida" de último momento.
Cómo medir sin ser desarrolladora
- Google Search Console → Experiencia → Core Web Vitals: muestra el estado de LCP, INP y CLS agrupado por tipo de página, con datos reales de usuarios (no simulados).
- PageSpeed Insights: analiza una URL específica y da un diagnóstico detallado con recomendaciones concretas de qué está afectando cada métrica.
- Chrome DevTools (pestaña Lighthouse): para un análisis más profundo de una página en particular, sin salir del navegador.
Una rutina simple que recomiendo instalar en cualquier equipo editorial: al final de cada mes, exportar el reporte de Core Web Vitals de Search Console y comparar contra el mes anterior. No hace falta un análisis exhaustivo cada vez — basta con confirmar que ninguna plantilla importante empeoró, y si alguna lo hizo, investigar qué cambió en ese periodo antes de que el problema se acumule con el siguiente lanzamiento.
No necesitas entender el código detrás de cada recomendación técnica que estas herramientas generan. Lo que sí necesitas es poder leer el diagnóstico, identificar si el problema viene de una decisión editorial (una imagen, un video insertado) o de una decisión de desarrollo (código, scripts, plantilla), y comunicarlo al equipo correspondiente con el dato específico en mano.
Un detalle que suele confundir a quien empieza a revisar estos reportes: Search Console reporta datos de campo (usuarios reales, con sus conexiones y dispositivos reales), mientras que PageSpeed Insights y Lighthouse pueden mostrar también datos de laboratorio (una simulación en condiciones controladas). Los dos son útiles, pero responden preguntas distintas: el dato de campo te dice qué están experimentando tus usuarios reales hoy; el dato de laboratorio te sirve para probar si un cambio específico mejora o empeora la métrica antes de publicarlo.
Caso real: de la posición 18 a la posición 7
Corregir Core Web Vitals fue una de las tres correcciones técnicas centrales —junto con crawlability y schema markup— que llevaron la posición promedio de un blog inmobiliario de 18 a 7 en Google Search Console en un trimestre. El contenido editorial no cambió en ese periodo; lo que cambió fue que Google finalmente pudo evaluarlo en igualdad de condiciones frente a la competencia.
Checklist para equipos de contenido
Convierte esto en una revisión mensual de 10 minutos, no en un ejercicio anual que se olvida entre auditorías.
- ☐ ¿Comprimes y redimensionas las imágenes antes de subirlas, o las subes directo desde la fuente original?
- ☐ ¿Sabes cuántos scripts de terceros están instalados actualmente en las plantillas principales del sitio?
- ☐ ¿Revisaste el reporte de Core Web Vitals en Search Console en el último mes?
- ☐ ¿Existe un canal claro para reportar al equipo de desarrollo cuando el diagnóstico señala un problema técnico?
- ☐ ¿Se evalúa el impacto en rendimiento antes de aprobar un nuevo widget, pixel o script de terceros?
Preguntas frecuentes
Sí, forma parte de la señal de "experiencia de página" de Google, aunque con menos peso que la relevancia del contenido. Aun así, en mercados competitivos, puede ser el factor que decide entre dos páginas con contenido de calidad similar.
Para diagnosticar, no. Para implementar la corrección técnica final, normalmente sí se necesita a alguien de desarrollo — tu rol como equipo de contenido es identificar el problema y priorizarlo correctamente, no necesariamente resolverlo con código.
Mensualmente como mínimo, y siempre después de cualquier cambio de plantilla, rediseño o instalación de un nuevo script de terceros — son los momentos donde más frecuentemente se introducen regresiones.
No por sí solo. Core Web Vitals es un factor entre muchos — la relevancia y calidad del contenido siguen pesando más. Pero un sitio lento puede anular ventajas de contenido que de otro modo serían suficientes para posicionar mejor que la competencia.
