¡Muy buenas, amigos del blog! 😁
Ojo cuidao, que hoy no soy Rubén. Hoy Rubén ha dejado las llaves del castillo a otro.
Soy Omar Tissir, el tipo detrás de la «fontanería» en PonteClick, ese ingeniero que suele estar en la sombra mirando pantallas negras con letras verdes mientras otros graban podcasts molones y hablan de lifestyle.
¿Y por qué estoy aquí «asaltando» el blog de mi Posicionamiento Web? Pues porque Rubén y yo compartimos una obsesión casi patológica: la panoja. Pero tenemos un problema, uno gordo.
Tú quieres llenarte los bolsillos con AdSense, con afiliación de Amazon (AAWP a tope), y con scripts de tracking que saben hasta qué marca de cereales desayuna tu visitante.
Y Google… bueno, Google quiere que tu web vuele.
Google quiere que tu web sea un Fórmula 1, pero tú le estás enganchando un remolque lleno de ladrillos publicitarios. 😵
Aquí está la «verdad incómoda» que nadie quiere decirte en esos hilos de Twitter llenos de humo y capturas de pantalla de ingresos retocadas:
La infraestructura es marketing
Si tu web tarda 5 segundos en cargar porque le has metido 40 banners y un script de chat que nadie usa, no tienes un «problemilla técnico»: tienes un problema grave de ventas.
Estás quemando billetes de 50€🔥 antes de que el usuario lea la primera sílaba de tu copy.
Imagina que has montado una fiesta increíble (tu contenido). Has traído al mejor DJ, hay barra libre y la gente está deseando entrar. Pero la puerta de entrada pesa tres toneladas, está oxidada y atascada…
La gente empuja un poco, ve que no abre, se frustra y se va a la fiesta del vecino, que es más fea, pero tiene la puerta abierta de par en par.
Eso es tu web ahora mismo si no cuidas las Core Web Vitals.
Te lo digo con sinceridad: si tu castillo se cae a pedazos, a nadie le importa que el contenido sea el Rey. El Rey vivirá debajo de un puente digital.
Hoy no vamos a hablar de teoría barata. Vamos a bajar al barro. Vamos a hablar de la Ingeniería del Banner.
Vamos a ver cómo meterle toda la «chicha» de monetización posible a tu WordPress sin que Google te pegue un bofetón en los rankings.
¡Vamos al lío! 🚀
- 🔹 La paradoja de la monetización: el Ferrari con ruedas de madera
- 🔹 Ingeniería del banner: cómo sobrevivir a las Core Web Vitals
- 🔹 Caso real: de ladrillo a cohete (con datos)
- 🔹 Herramientas para «no-técnicos» (hazlo tú mismo)
- 🚩 Conclusión: llamada a la panoja
- 🔹 Anexo técnico: profundización para los muy cafeteros
- 🚩 Conclusión técnica final
🔹 La paradoja de la monetización: el Ferrari con ruedas de madera
Vivimos en una contradicción constante en el mundo del SEO y la monetización. Es una guerra civil interna entre tu bolsillo y tu departamento técnico (que, seamos sinceros, sueles ser tú mismo a las 2 de la mañana…).
💶 Por un lado, queremos monetizar, queremos esos ingresos pasivos, esa «guita» que entra mientras dormimos.
Para eso necesitamos herramientas: plugins de afiliación como AAWP o Lasso, scripts de publicidad programática como AdSense, Mediavine o Raptive, píxeles de Facebook para el retargeting, Hotjar para ver mapas de calor…
Cada una de estas herramientas es un «pasajero» extra en tu coche. Y NO son pasajeros ligeros precisamente; algunos son como llevar a un equipo de rugby en el asiento de atrás.
🏎️ Por otro lado, queremos velocidad.
Queremos pasar los Core Web Vitals con buena nota para que Google nos quiera, nos mande tráfico y podamos presumir de puntuaciones verdes en PageSpeed Insights. Queremos que todo cargue en 0,5 segundos. Queremos la experiencia de usuario de Apple con el modelo de negocio de un bazar abarrotado.
¿El resultado?
Te compras un Ferrari (un hosting caro + una web con un diseño premium de 3.000€ lleno de efectos guay y vídeos 4K) y le pones ruedas de madera (docenas de scripts sin optimizar y una base de datos que parece un trastero a oscuras).
Y tú te preguntas por qué no ganas la carrera… 😵
El coste real del retraso
Vamos a hablar el idioma universal: el dinero.
¿Cuánto cuesta realmente que tu web tarde un segundo más?
No es una cuestión de «me gustaría que fuera más rápida». Es una cuestión de supervivencia económica.
Estudio
Hay estudios clásicos que deberíamos tatuarnos en el antebrazo. Amazon, en un estudio fundacional para la web moderna, calculó que 100 milisegundos de retraso costaban un 1% de ingresos. 😮
Piénsalo. Un parpadeo humano dura unos 300-400 milisegundos.
Si tu web parpadea, has perdido un 3% o 4% de tu facturación potencial. Si facturas 1.000€ al mes, 100ms te cuestan 10€.
Parece poco. Pero si tardas 3 segundos más de la cuenta… Echa cuentas. Es un desastre financiero acumulativo.
Estudio
Otro estudio de Akamai mostró que un retraso de 100ms podía reducir las tasas de conversión en un 7%. Y si pasamos de 1 segundo a 3 segundos de carga, la probabilidad de rebote (gente que se va sin hacer nada) aumenta un 32%.
Si llegas a los 5 segundos, la probabilidad de rebote sube al 90%. Básicamente, estás pagando por tráfico (ya sea con tiempo en SEO o dinero en Ads) para tirarlo por el desagüe.
Pero más allá del dato frío, está lo que yo llamo «Fricción Cognitiva», o lo que viene siendo haer las cosas «bonicas» y fáciles.
Imagina que entras a un restaurante de lujo en Santiago de Compostela (uno de esos donde se come marisco del bueno, con su albariño fresquito). Te sientas y pides un vaso de agua.
Algo sencillo, ¿verdad?
Pero resulta que la cocina de este restaurante no está en Santiago. La cocina está en Frankfurt (donde suelen estar los servidores de AWS eu-central-1).
Por muy rápido que sea el avión (la fibra óptica), la física es la física. Ese viaje tiene un coste en tiempo. Tarda, digamos, 2 segundos.
Cada vez que pides «agua», el camarero tiene que salir del restaurante, coger un avión a Alemania, llenar el vaso, volver en avión y servirlo.
Tú, sentado en la mesa, no piensas: «Oh, qué compleja es la logística internacional y qué mérito tiene este camarero».
Tú piensas: «Este servicio es una mierda. Me muero de sed».
Tu cerebro asume inmediatamente que el restaurante (tu web) es incompetente, estúpido o que se ha colgado.
Lo mismo pasa con la publicidad.
Si un banner tarda en cargar y de repente empuja el texto que estás leyendo hacia abajo, no es un «fallo técnico». Es una falta de respeto hacia tu usuario.
Es como si en el restaurante estás leyendo el menú tranquilamente, a punto de pedir, y el camarero te lo arranca de las manos y te pone otro plato delante sin avisar. Eso es el CLS (Cumulative Layout Shift), y es la forma más rápida de cabrear a tu audiencia y hacer que se larguen a la competencia. 🤬
El triángulo imposible: ingresos, UX y Google
El reto de la monetización «a lo bestia» es equilibrar tres fuerzas que, por naturaleza, se odian entre sí.
Es un ménage à trois donde nadie se lleva bien:
- El script de publicidad (AdSense/Mediavine/Amazon): su único objetivo es ejecutarse lo antes posible. Quiere ser el primero en cargar para contar la impresión, lanzar la cookie, rastrear al usuario y asegurar que ganas ese céntimo. Le da igual si el contenido principal no se ha visto. Es egoísta.
- El usuario: quiere leer el contenido YA. No le importan tus ingresos. Quiere la respuesta a su pregunta («mejores hostings 2026») sin que nada se mueva, sin esperar a que cargue un vídeo en el footer y sin que el scroll se quede pegado.
- Google (Core Web Vitals): es el árbitro severo. Va a penalizarte si el Largest Contentful Paint (LCP) tarda más de 2,5 segundos o si el Interaction to Next Paint (INP) pasa de 200ms. Google ha dejado claro que la experiencia de página es un factor de ranking. Si no cumples, te vas al rincón de pensar (la página 2 de los resultados).
La mayoría de los bloggers fallan aquí porque adoptan una mentalidad de «todo o nada». O quitan los anuncios y pierden dinero (y entonces, ¿de qué vives?), o llenan la web de anuncios hasta en la sopa y sin optimizar, destruyen la experiencia de usuario, y a la larga pierden el tráfico que les daba de comer.
Hoy vamos a ver la tercera opción: la ingeniería de la carga diferida y la optimización.
Vamos a enseñar a esos scripts egoístas a esperar su turno, vamos a darle al usuario la velocidad que merece, y vamos a mantener a Google contento para que siga enviando «visitas a cholón». 😉
🔹 Ingeniería del banner: cómo sobrevivir a las Core Web Vitals
Vamos a ponernos la bata de ingeniero (pero sin que te explote la cabeza, lo prometo, va a ser una «explicación humana»).
Para monetizar a lo bestia sin penalizaciones, tienes que entender las tres métricas que vigila el «Ojo de Sauron» (Google) y, lo más importante, cómo tus anuncios y enlaces de afiliados las atacan sistemáticamente.
Entender esto es la diferencia entre ser un amateur que instala plugins a lo loco y un profesional que domina su negocio.
🔸 LCP (Largest Contentful Paint): el camarero lento
Qué esEl tiempo que tarda en aparecer lo más grande e importante de tu pantalla (normalmente el título H1 o la imagen destacada del post). Es la primera impresión.
Entras al restaurante, tienes hambre, te sientas.
El cronómetro empieza a correr. El LCP es el tiempo que tarda el camarero en traerte el primer plato a la mesa.
- Si tarda 0,5 segundos: «¡Wow, qué servicio!» (Usuario feliz, se queda).
- Si tarda 4 segundos: en el mundo real es poco, pero en Internet es una eternidad. Es como si te dejaran 20 minutos mirando un mantel vacío. Te levantas y te vas al bar de enfrente.
Cómo lo matan los anuncios
Si cometes el error capital de poner un banner de AdSense en la cabecera (above the fold) y ese banner tarda en cargar, Google puede considerar que el contenido principal no ha cargado hasta que sale el anuncio.
Peor aún: los scripts de publicidad suelen ser «render-blocking» (bloquean el renderizado). Imagina que hay un guardia de seguridad en la puerta del restaurante (el script de Ads) que no deja pasar al camarero con tu comida (el contenido) hasta que no ha verificado la identidad de TODOS los comensales.
El usuario ve una pantalla blanca mientras el script de publicidad negocia una subasta en tiempo real en un servidor de Nueva York. 🤦♂️
La solución
Nunca, bajo ningún concepto, dejes que un script de publicidad bloquee el «hilo principal» (main thread) del navegador antes de que se pinte el LCP.
- Priorización: tienes que decirle al navegador: «Oye, primero píntame el título y la foto destacada. Eso es lo urgente. Luego, si te sobra tiempo y recursos, preocúpate de buscar el anuncio».
- Técnica: usa
fetchpriority="high"para tu imagen destacada. Esto la pone en la vía rápida VIP. Y usaloading="lazy"para todo lo demás (imágenes secundarias, iframes, anuncios inferiores). - Exclusión: si usas plugins de optimización (como WP Rocket, el preferido de Rubén), excluye la imagen destacada del Lazy Load. Si la haces perezosa, tardará más en aparecer y tu LCP subirá. La imagen destacada debe ser «ansiosa» (eager), no perezosa.
| Acción | Impacto en LCP | Coste de Implementación |
| Optimizar imágenes (WebP/AVIF) | Alto (reduce peso 90%) | Bajo (plugin/Squoosh) |
| CDN (Content Delivery Network) | Medio/Alto (acerca contenido) | Medio (Cloudflare/Bunny) |
| Eliminar Ads del above the fold | Crítico (desbloquea renderizado) | Cero (decisión de diseño) |
| Fetchpriority High en LCP | Alto (prioriza carga) | Bajo (código/plugin) |
🔸 CLS (Cumulative Layout Shift): la broma pesada del menú
Qué esEstabilidad visual.
¿Se mueven las cosas mientras cargan?
Estás en el restaurante, leyendo la carta. Has decidido pedir el «Entrecot a la pimienta».
Levantas el dedo, vas a señalarlo y… ¡zas! Alguien mueve la carta hacia abajo. Tu dedo aterriza en «Ensalada de col». 😫
Rabia pura. Te sientes estúpido y engañado.
Pues eso es el CLS. Pasa cuando estás leyendo un artículo y, de repente, carga un banner publicitario encima del texto, empujando todo el párrafo hacia abajo y haciéndote perder el hilo de la lectura.
Cómo lo matan los anuncios
Este es el clásico de AdSense y de los banners de afiliados mal implementados.
Tienes un hueco en tu post, el texto carga rápido (porque el texto pesa poco), el usuario empieza a leer y un segundo después el script de AdSense termina de ejecutarse inyectando un banner de 300×250 píxeles donde antes no había nada (o había un espacio de 0 píxeles). Así que todo el contenido inferior pega un salto.
Google odia esto, y los usuarios lo odian aún más.
La solución
La Reserva de Espacio (CSS placeholders)
No puedes dejar que AdSense decida el tamaño de tu web en tiempo real. Tienes que reservar el espacio antes de que llegue el anuncio.
Es como poner un cartel de «Reservado» en la mesa del restaurante. Aunque el comensal (el anuncio) llegue tarde, la mesa está ahí, ocupando espacio, y nadie más se sienta en ella.
Si sabes que vas a meter un anuncio cuadrado (MPU) de 300×250 píxeles, mételo en un contenedor (<div>) que tenga ese tamaño fijo o mínimo.
.anuncio-contenedor {
min-height: 250px; /* Altura mínima reservada: CLAVE para evitar saltos */
min-width: 300px; /* Anchura mínima */
background-color: #f4f4f4; /* Opcional: un gris clarito para que no se vea roto */
display: block;
margin: 20px auto;
text-align: center;
}/* Ajuste para móviles para evitar espacios vacíos gigantes */
@media (max-width: 768px) {
.anuncio-contenedor {
min-height: 100px; /* Altura típica de banner móvil */
min-width: 320px;
}
}
Al hacer esto, el navegador «dibuja» una caja gris de 250px de alto instantáneamente al cargar la página.
El texto se coloca debajo de esa caja desde el milisegundo cero.
Así cuando el anuncio llega (tarde, porque lo vamos a retrasar), simplemente rellena la caja reservada.
Cero saltos. Cero penalización CLS. El usuario ni se entera. 😎
Pero AdSense es caprichoso.
A veces te mete un banner de 100px de alto, otras veces uno de 280px, y otras uno de 600px (vertical). Si reservas 250px y llega uno de 600px, tendrás un salto (el contenedor crecerá). Si reservas 600px y llega uno de 100px, tendrás un espacio en blanco enorme.
- Truco Pro: reserva el espacio para el tamaño más probable o el más grande que estés dispuesto a tolerar. Si reservas 280px y el anuncio es de 250px, tendrás 30px de espacio blanco extra. ¿Importa? NO significa un drama. Al usuario le da igual un poco de aire (espacio negativo). Lo que odia es que el texto se mueva mientras lee. Es infinitamente mejor tener un espacio vacío estable que un contenido bailarín.
- Auto Ads: si usas los «Anuncios Automáticos» de Google, estás vendiendo tu alma al diablo del CLS. Google inyectará anuncios donde quiera, empujando tu contenido. Mi consejo de experto: desactiva los Auto Ads, o al menos, usa la herramienta de exclusión de zonas de AdSense para prohibirles tocar la zona above the fold (la parte superior visible sin scroll).
🔸 INP (Interaction to Next Paint): el interruptor roto
Qué esEsta es la métrica nueva, la que ha venido a sustituir al FID (First Input Delay) y que trae de cabeza a todos en 2026. Mide la interactividad.
¿Cuánto tarda la web en reaccionar cuando haces clic, tocas o escribes?
Entras al baño del restaurante, le das al interruptor de la luz y… nada.
Esperas. Un segundo. Dos segundos. De repente, la luz se enciende. Pero en ese intervalo, tú ya le habías dado al interruptor como cinco veces más, pensando que estaba roto…
Esa sensación de «web pastosa», de que el sistema no responde, es un INP alto. Es la muerte de la conversión en ecommerce y formularios.
Cómo lo matan los anuncios
Los scripts de publicidad son, con diferencia, los mayores culpables de un mal INP. Ejecutan código JavaScript complejo y pesado en el «hilo principal» del navegador.
Hacen cosas como:
- Rastrear el movimiento del ratón
- Lanzar subastas de header bidding con 10 proveedores a la vez
- Comprobar cookies y consentimiento
- Renderizar creatividades pesadas (HTML5)
Si el navegador está ocupado al 100% procesando ese script de AdSense, no puede hacer caso cuando el usuario hace clic en el menú de hamburguesa o en un botón de «Comprar en Amazon». El clic se queda en cola, esperando a que el anuncio termine de cargar.
El usuario percibe retraso y frustración.
La solución
Aquí es donde entra la magia del «Delay JavaScript Execution». Esta es la técnica más potente para monetizar a lo bestia sin penalización.
👉 No cargues el script de AdSense (adsbygoogle.js), ni el pixel de Facebook, ni Analytics, hasta que el usuario INTERACTÚE.
¿Qué es interactuar? Pues mover el ratón, tocar la pantalla (en móvil) o pulsar una tecla.
De esta forma, la carga inicial (LCP) es limpia, rápida y ligera. El navegador está libre y feliz. Google ve una web que vuela.
En cuanto el usuario mueve el ratón (señal inequívoca de que es un humano vivo y activo), ¡BAM!, cargamos toda la publicidad en segundo plano.
¿Pero pierdo dinero?
Es normal que pienses: «si retraso el anuncio, ¿no pierdo impresiones?»
Pero la realidad es esta, piénsalo:
- Si un usuario entra a tu web y no mueve el ratón ni hace scroll (es un rebote de 0 segundos, o un bot), ese anuncio no lo iba a ver de todas formas. No iba a clicar. No iba a generar valor.
- Al retrasarlo, mejoras la velocidad drásticamente. Una web rápida rankea mejor. Rankear mejor trae más tráfico. Más tráfico cualificado que interactúa = Más dinero.
- Además, aumentas tu métrica de Viewability (tasa de visibilidad). Como los anuncios solo se cargan cuando hay un humano interactuando, el porcentaje de anuncios que realmente se ven sube. Y los anunciantes pagan CPMs (Coste por Mil) más altos en webs con alto Viewability. Estás vendiendo inventario de mayor calidad. 👌
🔹 Caso real: de ladrillo a cohete (con datos)
Para que veas que esto no es humo ni teoría de salón, vamos a ver un caso real de mi agencia PonteClick. No diré el nombre del cliente (por confidencialidad y porque no me pagan por ello), pero llamémosle «Tienda Gourmet Gallega».
Situación inicial
Este cliente vendía productos gourmet de alta calidad. Habían invertido una barbaridad en una web nueva.
- Diseño: espectacular. Vídeos de fondo en 4K con percebes rompiendo en las rocas, animaciones que entraban por los lados, efectos parallax… Una obra de arte visual
- Imágenes: fotos de productos enormes, subidas directamente desde la cámara del fotógrafo («ladrillos» de 3MB y 4MB cada una)
- Monetización: tenían Ads de programática y muchos widgets de afiliación
- Problema: nadie compraba. El tráfico llegaba (pagaban Ads), pero el carrito se quedaba vacío
Métricas de Terror
- LCP: 6.8 segundos (un desastre absoluto)
- TTFB: 2.1 segundos (el servidor tardaba una vida en responder)
- INP: 450ms (la web se sentía rota al clicar)
El dueño estaba desesperado. Pensaba que sus productos eran caros o que el mercado estaba mal. La realidad era que la puerta de entrada a su tienda pesaba tres toneladas.
Nuestra Solución (El «Asalto» técnico)
Nosotros no tocamos el diseño visual (al cliente le encantaba). Cambiamos el motor.
Hicimos 3 intervenciones:
El cocinero ocupado (TTFB):
Tenían un hosting compartido barato (de esos de 3€ al mes). El servidor estaba saturado.
- Solución: migración a un servidor con discos NVMe (ultrarrápidos) y, lo más importante, activación de Redis (object cache). Redis es como tener los platos ya preparados en el mostrador de la cocina. Cuando el cliente pide, se lo das al instante. Sin Redis, el cocinero tiene que ir al almacén (base de datos), buscar los ingredientes, cocinarlos y servir. Redis evita consultas repetitivas a la base de datos.
- Resultado: El TTFB bajó de 2.1s a 0.1s. La web respondía al instante.
Los ladrillos (Imágenes):
Tenían gigas de imágenes pesadas.
- Solución: No las borramos. Implementamos un sistema de optimización al vuelo. Pasamos todas las imágenes a formato AVIF (que es mejor que WebP) y las redimensionamos. Una foto de 4MB de un queso tetilla pasó a pesar 85KB. Misma calidad visual ante el ojo humano, pero un 98% menos de peso para el navegador.
El guardia de seguridad (render blocking):
Tenían scripts de chat de soporte (Zendesk), AdSense, Analytics y el pixel de Facebook cargando en la cabecera. La web no se pintaba hasta que todo eso se descargaba.
- Solución: Configuramos Delay JavaScript. Hicimos que el chat, los anuncios y los trackers esperaran a la interacción del usuario.
- Resultado: La web carga visualmente en 0.8 segundos. El usuario ve el producto. Mueve el ratón. Y entonces, carga el chat y la publicidad. El usuario no nota la diferencia, ¡pero Google sí que lo nota!
El Resultado (la panoja) 🤑
- Core Web Vitals: Pasaron de «Pobre» (Rojo) a «Bueno» (Verde) en todas las métricas.
- Tráfico Orgánico: Subió un +40% en solo dos meses. Google detectó la mejora de experiencia y subió sus rankings.
- Conversión: Las ventas se recuperaron. La tasa de abandono de carrito cayó en picado porque la gente dejó de frustrarse con una interfaz lenta.
- Coste: Solo horas de consultoría técnica y un plugin de caché bien configurado. El ROI fue, como diría Rubén, «brutal». 😲
🔹 Herramientas para «no-técnicos» (hazlo tú mismo)
Vale Omar, muy bonito todo, pero yo no sé qué es Redis, no sé tocar código y me da alergia la pantalla negra de Matrix. Yo solo quiero escribir en mi blog de recetas o de marketing y ganar dinero. ¿Cómo lo hago?
Tranquilo. Aquí tienes tu kit de supervivencia. Herramientas que hacen la «fontanería» por ti, explicadas para que las configure hasta mi abuela. 🤝
🔸 Para caché y retraso de scripts: WP Rocket o Perfmatters
Estos son los reyes. Olvídate de configurar servidores a mano si no sabes. Estos plugins son magia enlatada.
· Configuración «a lo bestia» de WP Rocket para monetizar con AdSense
- Ve a la pestaña Optimizar Archivos.
- Activa la casilla «Retrasar la ejecución de JavaScript» (delay JavaScript execution).
- Esta es la clave: WP Rocket ya trae una lista de exclusiones automáticas, pero tú quieres asegurarte de que los scripts de publicidad SÍ se retrasen.
- Lista de Exclusión (Lo que NO quieres retrasar): aquí solo pon lo esencial para que la web se vea bien (menús, sliders principales). No pongas nada de Google aquí.
- Verificación: Asegúrate de que adsbygoogle.js y googlesyndication.com NO están en la caja de exclusiones. Si no están, el plugin los retrasará automáticamente hasta que el usuario mueva el ratón.
Truco Ninja para Ad Inserter
Si usas el plugin Ad Inserter para colocar tus anuncios (muy recomendado), tienes que tener cuidado. Ad Inserter a veces usa sus propios scripts para gestionar la rotación de anuncios. Si retrasas AdSense pero no retrasas a Ad Inserter, puedes tener huecos blancos.
- Asegúrate de añadir ai_insert_code a la lista de scripts a retrasar si usas la opción manual de exclusiones.
· Configuración de Perfmatters para AdSense
- Ve a Assets > JavaScript.
- Activa Delay JavaScript.
- Comportamiento: elige «Only delay specified scripts» (Solo retrasar los especificados). Esto es más seguro que «Delay All» y rompe menos cosas.
- En la caja de texto, pega estos «sospechosos habituales» (uno por línea):
-
- adsbygoogle.js (el culpable principal: AdSense)
- gpt.js (Google Ad Manager, si usas programática avanzada)
- fbq (pixel de Facebook)
- gtag/analytics.js (Google Analytics)
- fbevents.js (eventos de Facebook)
El timeout (vital): activa la opción de «timeout» y ponla a 10 o 15 segundos.
- ¿Por qué? Esto es un salvavidas. Si un usuario entra a tu web, deja la pestaña abierta y se va a hacer un café sin mover el ratón, el anuncio no cargaría nunca. Con el timeout, le dices al plugin: «si en 15 segundos el usuario no ha hecho nada, carga los anuncios de todas formas». Así recuperas esas impresiones de usuarios pasivos, pero para entonces, Google ya ha medido tu LCP y te ha dado el visto bueno. 👌
🔸 Para afiliados de Amazon: AAWP
El plugin AAWP es una maravilla para poner cajitas de productos de Amazon que convierten genial. Pero tiene un peligro: hace llamadas a la API de Amazon.
Cada vez que alguien visita tu post de «los mejores portátiles», AAWP pregunta a Amazon: «¿cuánto cuesta esto ahora?».
Si tienes mucho tráfico, tu servidor se pasa el día llamando a Amazon. Es el problema del camarero al que le pedía el vaso de agua y se iba hasta Alemania pero multiplicado por mil. 😩
· Cómo optimizar AAWP
- Caché de producto: asegúrate de que en los ajustes de AAWP la duración de la caché está puesta en al menos 12 o 24 horas. No necesitas saber el precio al segundo. Esto reduce muchísimo las llamadas a la API.
- Imágenes locales (con cuidado): algunos plugins permiten descargar la imagen de Amazon a tu servidor. Esto es genial para la velocidad (puedes optimizarla con WebP), pero ten cuidado con los Términos de Servicio (TOS) de Amazon. Amazon quiere que uses sus imágenes via API.
-
- Solución intermedia: usa un servicio de CDN para servir las imágenes de Amazon más rápido, o asegúrate de que tu plugin de caché soporta el Lazy Load de iframes y de imágenes externas (como WP Rocket).
- Sin ladrillos en el above the fold: si tu post empieza con una caja de producto de Amazon, esa imagen va a ralentizar tu LCP (acuérdate del camarero lento). Intenta poner un párrafo de texto introductorio antes de la primera caja de producto. Deja que el texto cargue primero. Si tienes que poner la caja arriba sí o sí, usa código para añadir
fetchpriority="high"
a esa imagen específica.
🔸 Para imágenes: Squoosh y WebP
Deja de subir fotos tal cual salen del móvil, de Unsplash o de Pexels. Esos son ladrillos de 4MB (o más). Subir eso a tu web es un crimen contra el rendimiento.
El flujo de trabajo del optimizador de imágenes
- Entra en https://squoosh.app (es una herramienta de Google, gratis y funciona en el navegador)
- Arrastra tu foto-ladrillo
- En el menú de la derecha, elige formato WebP o AVIF (AVIF comprime más, pero WebP es más compatible)
- Baja la calidad (quality) hasta que veas que la imagen empieza a verse un poco mal, y luego súbela un pelín. Normalmente, al 75-80% se ve perfecta
- Redimensiona (resize): si la imagen va a ir en un blog, no necesitas que tenga 4000 píxeles de ancho, con 1200px o 800px vas sobrao
- Descarga. Verás que tu foto de 4MB ahora pesa 80KB o parecido. Has reducido el peso un 98%.
- Súbela a WordPress.
Esto es «fontanería básica» que te ahorra gigas de transferencia y segundos de carga. 😉
🔸 El hosting: el motor del coche
Puedes tunear el coche todo lo que quieras, ponerle alerones (caché) y óxido nitroso (CDN), pero si el motor es el de un cortacésped…
- Huye de lo barato (sin calidad): si pagas 2€ al mes en una empresa famosa de hosting, compartes servidor con 5.000 webs más. Si una de ellas tiene un pico de tráfico, tu web se cae. Si quieres vivir de esto, invierte en un hosting decente.
- Discos NVMe: busca siempre esta sigla. Son discos duros mucho más rápidos que los SSD normales.
- Geolocalización: busca servidores que estén cerca de tu audiencia/lectores/usuarios. Si tu público es de España, tu servidor debería estar en España o como mucho países cercanos (Francia). No lo contrates en EEUU porque sea más barato. Recuerda la metáfora del camarero en Frankfurt: la luz no es instantánea, la distancia física importa. Un servidor en España responde en 20ms a un usuario español. Uno en EEUU tarda 150ms. Esa diferencia base es insalvable con plugins.
- Actualiza PHP: esto es gratis y vital. Entra en tu panel de hosting (cPanel) y busca «selector de versión de PHP» o similar. Si estás usando la versión y pásate mínimo a la 8.1, 8.2 o superior. Las nuevas versiones de PHP son mucho más eficientes procesando código. Es como cambiar el motor del coche por uno nuevo totalmente gratis. *Nota: Haz copia de seguridad antes por si algún plugin viejo no es compatible.
🚩 Conclusión: llamada a la panoja
Hemos dado un repaso técnico importante, hemos hablado de camareros alemanes, de puertas atascadas y de ladrillos digitales. Pero quiero acabar con una reflexión casi filosófica (sí, los ingenieros también tenemos corazoncito, aunque esté hecho de silicio). 😁
Optimizar la velocidad de tu web (WPO) no es una tarea para frikis que viven en sótanos. No es algo que haces «para que Google no te penalice».
Es una cuestión de empatía y respeto.
El tiempo es el recurso más valioso, finito e irrecuperable que tiene tu lector. Nadie te debe su atención.Filosofía WPO
Si alguien decide regalarte cinco minutos de su vida para leer tu artículo sobre «Las mejores freidoras de aire» o tu reseña de un hosting, lo mínimo, lo mínimo que puedes hacer es no hacerle esperar.
Una web rápida es un acto de hospitalidad.
Dice: «Valoro tu tiempo, gracias por venir, aquí tienes lo que buscas, rápido y limpio».
Una web lenta, llena de saltos (CLS), que no reacciona cuando clicas (INP) y que tarda siglos en cargar, grita: «Me importo yo, mi publicidad y mi dinero más que tú». Y los usuarios, que no son tontos, lo notan. Y se van.
Así que, haz los deberes. No necesitas ser ingeniero de la NASA.
- Reserva el espacio de tus anuncios (adiós CLS)
- Retrasa la carga de AdSense y analytics (hola LCP y INP verdes)
- Limpia tus imágenes (fuera ladrillos)
- Cachea como si no hubiera un mañana (Redis es tu amigo)
Si haces esto, no solo Google te premiará con mejores posiciones, tus usuarios estarán más felices, navegarán por más páginas, harán más clics en tus enlaces de afiliado y, en definitiva, aumentará la panoja.
Porque al final, una web rápida es una web que factura. 💲
Ah, y a esto súmale que hay que dedicarle tiempo, porque esto va de CURRAR, va de echarle horas; y más al principio que es cuando más cuesta.
¿Y tú? ¿Cuántos ladrillos llevas en tu remolque? Te leo en los comentarios.
Aleee, ciaoo ciao ciao.
🔹 Anexo Técnico: profundización para los muy cafeteros
Para aquellos que no se conforman con el kit de supervivencia y quieren ir un paso más allá, aquí desglosamos la «ciencia» detrás de la magia.
Si quieres sacar matrícula de honor, sigue leyendo. 😉
🔸 La Ciencia del CLS y los placeholders dinámicos
El Cumulative Layout Shift (CLS) es particularmente puñetero en diseños responsivos. Un bloque de anuncio puede colapsar (altura 0) si Google no tiene inventario para mostrar, o expandirse a 600px si entra un anuncio vertical tipo «rascacielos».
La técnica del min-height que mencionamos antes es la defensa de primera línea. Pero, ¿qué pasa en móviles VS escritorio? 🤔
Un cuadrado de 300×250 queda bien en móvil, pero en escritorio igual quieres mostrar un leaderboard de 728×90. Si reservas 300px de alto en escritorio para un banner que solo mide 90px, dejas un hueco enorme.
Estrategia Avanzada de CSS
Usa media queries para reservar espacios diferentes según el dispositivo.
/* Espacio para MPU (Cuadrado) en Escritorio y Tablet */
.ad-slot {
min-height: 250px;
min-width: 300px;
background-color: #f4f4f4;
}
/* Espacio para Banner Móvil (más pequeño) */
@media (max-width: 768px) {
.ad-slot {
min-height: 100px; /* Banner móvil típico 320×100 o 320×50 */
min-width: 320px;
}
}
/* Espacio para Leaderboard (Cabecera) en Escritorio */
.ad-header-slot {
min-height: 90px;
min-width: 728px;
}
Esto asegura que la «broma pesada del menú» no ocurra ni en el iPhone del usuario que va en el metro ni en el monitor 4K del que está en la oficina. Estás protegiendo la experiencia en todos los frentes. 😎
🔸 La verdad sobre el «delay JS» y el impacto en ingresos
He mencionado que retrasar JS mejora el rendimiento, pero profundicemos en el impacto real en métricas.
Retrasar adsbygoogle.js hasta la interacción del usuario transforma la métrica TBT (Total Blocking Time). El TBT es una métrica de laboratorio que correlaciona fuertemente con el INP (métrica de campo). Si tu TBT es alto (el navegador está ocupado procesando scripts), tu INP será malo. Es matemático.
Al mover la ejecución de AdSense post-interacción ocurren 2 cosas:
- El navegador está «idle» (ocioso) al principio: el LCP se pinta rapidísimo porque no hay nadie compitiendo por la CPU.
- Viewability Real: los anunciantes pagan más por impresiones visibles. Si cargas un anuncio en el footer nada más entrar (eager loading) y el usuario no hace scroll y se va, has «gastado» una impresión con 0% de viewability. Eso ensucia tus estadísticas y baja tu eCPM.
Al usar lazy load o delay, el anuncio solo se carga (y se cuenta) cuando el usuario está activo. Esto puede bajar tus impresiones totales (porque eliminas las impresiones basura), pero suele subir tu RPM (Revenue Per Mille) y tu CPM porque tu inventario es de mayor calidad (más visible y con usuarios más activos).
Estudio de Caso de Latencia
Como vimos con la metáfora del «camarero en Frankfurt», la latencia mata la conversión.
- prebid.js y header bidding: si ya juegas en las grandes ligas y usas programática avanzada (header bidding), el timeout de la subasta es crítico. Si das 1000ms a los anunciantes para pujar, estás añadiendo 1 segundo de espera al usuario.
- Recomendación: ajusta los timeouts de tus subastas. A veces, bajar de 1000ms a 500ms reduce ligeramente la competencia de pujas (algunos anunciantes lentos no llegan a tiempo), pero la mejora en UX es tan grande que el tráfico total y las impresiones visibles compensan la pérdida de algún céntimo en el CPM. Es mejor vender barato y rápido que intentar vender caro y que el cliente se vaya antes de ver el producto.
🔸 Optimización de afiliados: el enlace «limpio»
Los enlaces de afiliados (como los de Amazon o Booking) a menudo vienen «sucios» con imágenes de seguimiento de 1×1 píxeles o scripts de redirección que hacen tres saltos antes de llegar al destino.
- Rel=’sponsored’: esto no es velocidad, es seguridad SEO. Google exige que marques estos enlaces con
rel="sponsored"(o nofollow). No hacerlo es jugar a la ruleta rusa con una penalización manual. - Cloaking vs. redirección 301: usar un plugin como PrettyLinks o ThirstyAffiliates para crear enlaces bonitos tipo tudominio.com/ir/producto es bueno para la gestión y para que no te roben comisiones. Pero añade una petición extra al servidor (tu servidor tiene que procesar la redirección).
- Optimización WPO: asegúrate de que tu plugin de redirección usa las cabeceras de caché correctas. Una redirección 301 debe ser cacheada por el navegador para que, si el usuario clica dos veces, la segunda sea instantánea y no toque tu servidor. Configura tu plugin de caché (WP Rocket/LiteSpeed) para cachear estas redirecciones si es posible, o mejor aún, usa reglas a nivel de servidor (.htaccess / Nginx) para que la redirección no cargue todo el core de WordPress (PHP) solo para redirigir un enlace.
🚩 Conclusión Técnica Final
Al final, todo se reduce a dos conceptos: física y economía.
- Física: los datos no se teletransportan. Tienen que viajar. Acércalos (CDN, Edge Computing) y reduce lo que envías (compresión).
- Economía: los recursos (CPU, RAM, Tiempo de usuario) son finitos y caros. No los gastes en scripts que el usuario no ha pedido ver todavía.
Si tratas tu infraestructura con el mismo cariño y estrategia que tratas tu contenido, el Dios Google te sonreirá. Y lo más importante: tu cuenta bancaria también notará la diferencia.
La confianza que generas con un blog cuesta mucho ganarla y poco perderla.Un señor que pasaba por ahí
¿A qué esperas? ¡A darle caña a esa web!
¡A por la panoja!