Nota de actualización (23/10/2026): este texto se escribió el 10/07/2026, antes de que la cuenta de AdSense fuera enviada y rechazada (02/10/2026). Hoy ningún anuncio carga; el cargador solo se inyecta si existe PUBLIC_ADSENSE_CLIENT, y ads.ts es un stub que no llama a adsbygoogle.push(). La descripción de la carga “después del LCP” describe la intención del diseño, no el comportamiento actual. El presupuesto de CLS y la altura fija siguen siendo válidos como referencia.

Un sitio estático no es inmune a un anuncio malo. Un <script> de terceros cargado sin cuidado empuja el contenido en la pantalla, ocupa el hilo principal y retrasa el elemento visible más grande de la página, y eso vale tanto para un blog en WordPress como para un sitio 100% prerenderizado como este. La diferencia es que, en un sitio estático, no hay excusa de “servidor lento”: si el Core Web Vitals queda mal, el culpable es una decisión de frontend, y punto.

Antes de encender Google AdSense en este blog, traté el anuncio como un presupuesto, no como un extra. Este post es el registro real de ese presupuesto: tres números, tres decisiones técnicas, y por qué existe cada una.

Los tres números que se vuelven presupuesto

Core Web Vitals tiene tres métricas con un umbral de “bueno” bien definido:

  • LCP (Largest Contentful Paint): tiempo hasta que el elemento visible más grande se renderiza. Bueno es 2,5 segundos o menos (web.dev/articles/lcp).
  • INP (Interaction to Next Paint): latencia entre una interacción del usuario (clic, toque, tecla) y el siguiente fotograma pintado en la pantalla. Bueno es 200 milisegundos o menos (web.dev/articles/inp).
  • CLS (Cumulative Layout Shift): suma de los desplazamientos inesperados de layout durante la vida de la página. Bueno es 0,1 o menos (web.dev/articles/cls).

Un anuncio de terceros amenaza a los tres al mismo tiempo: el script retrasa la red (LCP), ejecuta JavaScript pesado en el hilo principal (INP) y, si su espacio no está reservado antes de cargar, empuja todo lo que está debajo cuando por fin aparece (CLS). Traté cada amenaza como una decisión separada, no como un problema genérico de “rendimiento”.

Altura fija, no mínima, contra el CLS

La primera versión del diseño usaba min-height genérico para reservar espacio de anuncio. Eso es un error sutil: min-height garantiza un piso, pero no impide que el elemento crezca si el creativo cargado es mayor de lo esperado, y además infla el espacio reservado respecto del formato real de la unidad (un leaderboard de 90 a 100 píxeles de altura no necesita 280 píxeles de reserva).

La decisión que quedó fue reservar altura fija por variante real de anuncio: 100 píxeles en el leaderboard de celular (90 en el escritorio), 250 píxeles en el rectángulo dentro del artículo y 250 píxeles en el rectángulo de la barra lateral, usando siempre height, no min-height, en el contenedor. Con eso, el espacio existe exactamente del tamaño del anuncio antes de que cargue, y no cambia después, lleno o vacío. El CLS por anuncio se vuelve, en la práctica, cero.

.ad-slot--leaderboard { height: var(--ad-height-leaderboard); }
.ad-slot--in-article  { height: var(--ad-height-in-article); }
.ad-slot--sidebar     { height: var(--ad-height-sidebar); }

Cargar después del LCP, bajo demanda

El script de AdSense carga de forma asíncrona y solo después del elemento que normalmente es el LCP de la página (el <h1> del post o la imagen de portada, cuando existe): nunca antes de él, para no competir por red y renderizado con lo que realmente decide la métrica.

Para los slots debajo del pliegue, la inicialización solo ocurre cuando el slot está cerca de entrar en el viewport, vía IntersectionObserver con un margen de cerca de 200 píxeles: carga un poco antes de que el usuario llegue ahí, no solo cuando el elemento ya está visible. Eso evita gastar presupuesto de red y de hilo principal en un anuncio que el lector tal vez nunca desplace hasta ver.

Límite de 2 a 3 unidades por página

Cada unidad de anuncio adicional es más JavaScript de terceros compitiendo por el mismo hilo principal que procesa el clic y el toque del lector, es decir, más riesgo para el INP. Por eso el techo de este blog es de 2 a 3 unidades por página, no “cuantas quepan”. En una página de post, eso significa exactamente tres posiciones fijas (arriba, dentro del artículo, barra lateral) y ninguna cuarta posición, incluso en pantallas grandes.

Cómo verifico antes de publicar

Ninguna de esas decisiones vale nada sin una forma objetiva de comprobar si el presupuesto se está respetando. Antes de que exista tráfico real en este blog, uso dato de laboratorio: Lighthouse o PageSpeed Insights ejecutado con un perfil fijo de dispositivo y red, no con la buena conexión de mi propia computadora. El perfil que uso es el estándar móvil de esas herramientas: CPU con throttling de 4 veces y red que simula una “Slow 4G”. Es un escenario deliberadamente peor que lo normal, porque eso es lo que separa “funciona en mi portátil” de “funciona para el lector real”.

Cada slot nuevo de anuncio pasa por esa comprobación antes de volverse el estándar. Si el resultado supera el presupuesto de LCP, INP o CLS, la respuesta no es pasar por alto el número: es quitar el slot o reposicionarlo hasta que el presupuesto cierre de nuevo. Después de que el sitio tenga tráfico de verdad durante algunas semanas, Google Search Console pasa a mostrar el Core Web Vitals con dato de campo real (CrUX), que confirma si lo que el laboratorio predijo coincide con la experiencia real del lector; pero ese dato de campo solo acumula muestra suficiente después de un mes de tráfico, así que sirve para confirmar después, no para decidir antes de lanzar.

Lo que haría distinto

Dos cosas que aprendí armando este presupuesto. La primera es que el “espacio reservado” solo resuelve el CLS si el valor reservado coincide con el tamaño real de la unidad servida; probar con el tamaño real del anuncio, no con un placeholder genérico, es obligatorio antes de considerar el slot listo. La segunda es que los auto ads (el modo de Google que decide solo dónde insertar el anuncio) probablemente rendirían más ingresos en el corto plazo, pero renuncié a esa ganancia a propósito: una posición imprevisible es un peor control del CLS, y prefiero un presupuesto que decido yo a uno que el algoritmo decide por mí. Si los ingresos quedan muy por debajo de lo esperado, esa es la primera decisión que reevaluaría, no la última.

Fuentes