¿WordPress lento? La guía 2026 para alcanzar el 100 % en Google PageSpeed

Si su puntuación de Google PageSpeed está en rojo, suele ser señal de un servidor sobrecargado, una base de datos fragmentada o recursos JavaScript mal optimizados que frenan su crecimiento. Esta lentitud no es una fatalidad: un sitio WordPress se vuelve lento a fuerza de manipulaciones técnicas, de acumular plugins que consumen muchos recursos o de un alojamiento que ya no sigue el ritmo de su tráfico.

En esta guía completa le explicaré con precisión por qué su sitio va lento y le daré las claves técnicas para corregir cada alerta de Google y aspirar a la puntuación perfecta de 100/100.

🚀 ¿No tiene tiempo para trastear? Yo me ocupo de todo.

Analizo las ralentizaciones y aplico las optimizaciones previstas en el presupuesto. El rendimiento se supervisa de forma adaptada a su sitio; no se garantiza ninguna puntuación de PageSpeed ni posicionamiento SEO.

• ✅ Optimización completa (Caché, imágenes, código)

• ✅ Supervisión mensual del rendimiento

• ✅ Intervenciones según el presupuesto, dentro del volumen mensual acordado

No es solo por diversión. Desde las Core Web Vitals, Google utiliza la velocidad como factor de clasificación. La ecuación es sencilla:

• Sitio lento = SEO deficiente + Tasa de rebote alta + Clientes frustrados
• 
  Sitio rápido = Mejor posicionamiento + Más conversiones + Visitantes satisfechos

Este cliente pasó de 6842/100 a 100/100 en 3 semanas.

Resultado: +35 % de tráfico orgánico y un tiempo de carga dividido por 3.

Antes de lanzarse sobre las alertas técnicas de PageSpeed, hay que entender las causas de fondo. Un sitio WordPress rara vez se ralentiza por un único problema. Suele ser una acumulación.

La razón principal de un sitio lento suele ser un plan de alojamiento que ya no se ajusta a sus necesidades. Al principio todo va bien. Pero en cuanto instala plugins, sube imágenes o aumenta el tráfico, el servidor se satura.

Las señales de alerta:

• Tiempo de respuesta del servidor (TTFB) superior a 600 ms
• Errores 500 o 503 durante los picos de visitas
• Escritorio de WordPress que va lento incluso para usted

La solución: Pida a su proveedor de alojamiento sus estadísticas de consumo de CPU/RAM. Desconfíe de las recomendaciones automáticas de ampliación: a menudo basta con optimizar el sitio. Si realmente tiene que cambiar, recomiendo o2switch a mis clientes franceses. Sus servidores están dimensionados para soportar los picos y su soporte técnico responde en 10 minutos, no en 48 h.

Si ve aparecer con regularidad este código concreto, le invito a leer mi guía para comprender y corregir el error 503. Es la señal típica de que su servidor o2switch (u otro) está al límite de su capacidad.

Otros problemas habituales del servidor:

• Sin CDN (Content Delivery Network) activado
• Servidor geográficamente demasiado lejos de sus visitantes
• Versión de PHP obsoleta (7.4 o inferior)
• Protocolo HTTP/1.1 en lugar de HTTP/2 o HTTP/3

Si su sitio se ha ralentizado bruscamente de un día para otro, suele ser sospechoso. No busque más, probablemente le han atacado.

Los ataques más habituales:

Ataque DDoS: Miles de visitas falsas saturan su servidor. El objetivo es dejar su sitio inaccesible. En general, se calma al cabo de unas horas si los atacantes desisten.

Malware o script malicioso: Un archivo infectado se ejecuta en segundo plano para minar criptomonedas, enviar spam o redirigir a sus visitantes a sitios fraudulentos. Es más insidioso porque puede durar semanas sin que usted se dé cuenta.

La acción inmediata: Analice su sitio con Wordfence (plugin gratuito) o Sucuri (interfaz en línea gratuita para un análisis rápido). Si se detecta una infección, no intente limpiarla usted solo: un archivo olvidado y el ataque vuelve a empezar. En mis planes de seguridad, limpio manualmente los archivos infectados y blindo el sitio para evitar reincidencias.

Incluso antes de buscar el origen del problema, recuerde lanzar una auditoría de seguridad de su sitio WordPress : un escáner de diagnóstico completo le revela en unos minutos los fallos, los archivos sospechosos y las infecciones activas.

Los temas por defecto de WordPress (Twenty Twenty-Four, etc.) son ligeros pero limitados en funcionalidades. Por eso se recurre a los temas premium.

El problema: Algunos temas son auténticas fábricas de gas. Cargan decenas de archivos CSS y JavaScript en todas las páginas, aunque solo utilice el 10 % de sus funcionalidades.

Los peores culpables:

• Temas multiuso con más de 50 demos prediseñadas (Flatsome, BeTheme…)
• Temas acoplados a constructores de páginas pesados (Divi, Elementor en su versión gratuita)
• Temas pirateados descargados de sitios dudosos (a menudo infectados de regalo)

Los temas que recomiendo:

• Astra : Ultraligero (menos de 50 KB), compatible con todos los constructores de páginas
• GeneratePress : El preferido de los desarrolladores por su código limpio
• Kadence : Equilibrio perfecto entre ligereza y funcionalidades

Cada plugin añade código que cargar. Incluso desactivado, un plugin puede dejar a veces rastros en la base de datos.

La regla de oro: Elimine (no desactive, elimine) todo lo que no sirva. Si no ha usado un plugin en 3 meses, fuera con él.

Los plugins que suelen lastrar el rendimiento:

• Sliders animados (Revolution Slider, etc.): prefiera una simple imagen de cabecera
• Plugins para compartir en redes sociales con contadores: hacen solicitudes externas en cada carga
• Constructores de formularios pesados: Gravity Forms carga 300 KB de JS incluso en las páginas sin formulario
• Plugins de estadísticas del lado del servidor: Google Analytics basta de sobra

Mis plugins imprescindibles (y optimizados):

• WP Rocket : Caché, minificación y lazy loading todo en uno
• Imagify : Compresión automática de imágenes a WebP
• Wordfence : Seguridad y firewall sin ralentizar el sitio

Su base de datos almacena todo: artículos, ajustes, comentarios, pero también miles de residuos invisibles.

Lo que se acumula:

• Revisiones de artículos : WordPress guarda cada modificación. Un artículo de 2 años puede tener 150 revisiones almacenadas
• Comentarios spam : Incluso eliminados, permanecen en la papelera
• Transients caducados : Datos temporales de plugins que nunca se limpian
• Opciones autocargadas : Ajustes de plugins desinstalados que se cargan en cada página
• Tablas huérfanas : Plugins eliminados que dejan sus tablas MySQL atrás

El resultado: Una base de datos de 500 MB a menudo puede reducirse a 50 MB tras una buena limpieza.

La solución básica: Puede utilizar WP-Optimize para una limpieza automática (revisiones, spam, transients).

⚠️ Atención: Haga siempre una copia de seguridad antes.

La limpieza experta: Para una limpieza a fondo (tablas huérfanas, opciones autocargadas inútiles), es una operación delicada. La hago manualmente en SQL durante los mantenimientos mensuales, apuntando con precisión a los datos parásitos sin riesgo de romper el sitio.

Antes de corregir las alertas técnicas de Google, hay que sentar unas bases sólidas. Sin ellas, se pasará el tiempo tapando fugas.

Ya hablamos de ello más arriba, pero aquí está el método completo:

Paso 1: Limitar las revisiones futuras

Añada esta línea a su archivo wp-config.php:

define('WP_POST_REVISIONS', 3); Esto limita las revisiones a 3 por artículo en lugar de ilimitadas.

Paso 2: Limpiar lo existente

Con WP-Optimize (gratuito):

1. Vaya a Plugins → WP-Optimize
2. Marque: Revisiones, Borradores, Spam, Transients
3. Lance la optimización

Paso 3: Programar una limpieza automática

WP-Optimize permite programar una limpieza semanal. Actívela para olvidarse del asunto.

La trampa que hay que evitar: NUNCA toque manualmente las tablas wp_options o wp_postmeta si no sabe lo que hace. Una línea borrada por error y su sitio deja de arrancar.

Si todavía está en PHP 7.4, está perdiendo entre un 30 y un 40 % de rendimiento. PHP 8.2 (u 8.3) es hasta 2 veces más rápido gracias a optimizaciones profundas del motor.

Cómo comprobar su versión:

1. Vaya a Herramientas → Salud del sitio
2. Pestaña «Información» → Busque «Versión de PHP»

Cómo cambiarla:

1. Inicie sesión en su cPanel (o Plesk)
2. Busque «Seleccionar versión de PHP» o «MultiPHP Manager»
3. Elija PHP 8.2 (o la versión más reciente recomendada por su proveedor de alojamiento)
4. ⚠️ Pruebe su sitio después: algunos plugins antiguos no son compatibles

Protocolo HTTP/3: el turbo invisible

HTTP/3 permite cargar varios archivos en paralelo sin bloqueos. Es especialmente eficaz en móvil con una conexión inestable.

Cómo activarlo: Póngase en contacto con su proveedor de alojamiento para comprobar si HTTP/3 está disponible. En o2switch, Cloudways o Kinsta, suele estar activado por defecto. Si no, pida su activación.

El problema del sitio «dinámico»

Por defecto, WordPress reconstruye cada página en cada visita. Si tiene 100 visitantes simultáneos, el servidor tiene que generar la misma página 100 veces. Es puro desperdicio.

La solución: la caché

La caché guarda una versión «congelada» de su página (en HTML puro) y la sirve a los siguientes visitantes. Resultado: el servidor trabaja una sola vez en lugar de 100.

WP Rocket se encarga de esto a la perfección:

• Caché de páginas : Activada por defecto
• Caché del navegador : Los archivos CSS/JS se almacenan en el navegador del visitante (no los vuelve a descargar en cada página)
• Precarga de la caché : WP Rocket «visita» todas sus páginas en segundo plano para generar la caché antes de que llegue un visitante

El CDN: descargar su servidor

Un CDN (Content Delivery Network) almacena sus imágenes, CSS y JS en servidores de todo el mundo. Resultado: un visitante de Tokio carga sus imágenes desde un servidor japonés, no desde su servidor en Francia.

La solución gratuita: Cloudflare (CDN + protección DDoS incluida). Se configura en 10 minutos.

Gestionar un pico de carga (promoción, publicación viral)

¿Recibe 1300 visitantes de golpe por un anuncio en Facebook? Si no está preparado, el error 500 está asegurado.

Mi lista de comprobación anticaídas:

1. Caché activada : WP Rocket debe servir páginas HTML estáticas
2. CDN activado : Sus imágenes no deben solicitar su servidor
3. Desactive temporalmente : Los plugins de estadísticas pesados, los chats en directo, los formularios complejos (conserve solo lo esencial)
4. Avise a su proveedor de alojamiento : Si son buenos, pueden asignar temporalmente más recursos

La supervisión técnica puede señalar una indisponibilidad. Las solicitudes se atienden de lunes a viernes de 9 h a 18 h, hora de París, excepto festivos en Francia, con un objetivo indicativo de primera respuesta en 24 horas laborables. No se garantiza ninguna guardia ni la ausencia de pérdida de ventas.

¿Ha lanzado un análisis y Google le muestra una lista roja de errores técnicos? Estos términos pueden parecer bárbaros, pero corresponden a problemas concretos. Este es el análisis detallado de las alertas más frecuentes y cómo resolverlas.

¿Cuál es el problema?

Por defecto, WordPress utiliza JPEG o PNG. Estos formatos datan de los años 90 y son pesados. Una imagen JPEG de 200 KB podría pesar 60 KB en WebP con la misma calidad visual.

¿Por qué insiste Google en esto?

Porque las imágenes representan entre el 50 y el 70 % del peso total de una página web. Es la palanca con más impacto.

La solución:

No intente convertir sus imágenes manualmente antes de subirlas. Utilice Imagify o ShortPixel. Estos plugins analizan su biblioteca de medios y crean automáticamente una versión WebP de cada imagen. Sus imágenes antiguas permanecen intactas, pero el navegador carga la versión WebP si la admite.

Configuración de Imagify:

1. Instale el plugin
2. Elija el nivel «Agresivo» (la pérdida de calidad es imperceptible)
3. Active «Crear imágenes WebP»
4. Lance la optimización masiva

En 10 minutos, todas sus imágenes están convertidas. En un sitio de 500 imágenes, puede ganar entre 5 y 10 segundos de tiempo de carga.

¿Cuál es el problema?

Cuando el navegador carga su página, no sabe cuánto espacio reservar para las imágenes. Resultado: el texto baja bruscamente cuando aparece la imagen. Es lo que se llama un mal CLS (Cumulative Layout Shift).

Ejemplo concreto:

Está en el móvil, empieza a leer un artículo y de repente ¡PAM!, el texto baja 300 píxeles porque acaba de cargarse una imagen encima. Molesto, ¿verdad? A Google también le molesta.

La solución:

WP Rocket añade automáticamente los atributos width y height que faltan en su código HTML. Active la opción en «Medios» → «Añadir los atributos width y height que faltan».

Si no utiliza WP Rocket, asegúrese de que su tema declara correctamente estas dimensiones. Si no, cambie de tema (en serio).

¿Cuál es el problema?

WebP está bien, pero AVIF es todavía mejor. Este formato ultrarreciente (2021) comprime un 30 % más que WebP. El problema: aún no es compatible con todos los navegadores.

La solución:

Por ahora, quédese con WebP. AVIF será estándar de aquí a 2026. Imagify empezará a admitirlo automáticamente cuando sea pertinente.

¿Cuál es el problema?

Por defecto, su navegador carga TODAS las imágenes de la página, incluso las que están abajo y que el visitante quizá nunca verá (el 90 % de la gente no se desplaza hasta el final).

La solución:

El lazy loading carga las imágenes solo cuando el visitante baja por la página. Desde WordPress 5.5, está activado por defecto para las imágenes del contenido. Pero no para las de las barras laterales, los widgets o el pie de página.

Con WP Rocket:

1. Pestaña «Medios»
2. Active «Lazy load» para las imágenes Y los iframes (vídeos de YouTube)
3. Excluya su imagen de cabecera (logotipo, banner) para que se cargue de inmediato

¿Cuál es el problema?

Carga el código de su formulario de contacto en páginas donde no hay formulario. Carga el script de su slider en páginas donde no hay slider. Es puro desperdicio.

Ejemplo concreto:

Contact Form 7 carga 150 KB de JavaScript en TODAS las páginas de su sitio, incluso en las que no tienen formulario. En un sitio de 50 páginas, son 7,5 MB de código cargado inútilmente.

La solución de nivel fácil:

En WP Rocket, active «Cargar JavaScript en diferido» y «Eliminar JavaScript no utilizado». El plugin lo clasifica automáticamente.

La solución de nivel experto (lo que hago en el mantenimiento):

Utilizo Asset CleanUp para desactivar manualmente los scripts plugin por plugin en cada página. Es quirúrgico y sin riesgo de errores.

Ejemplo de regla:

• Contact Form 7: Desactivado en todas partes EXCEPTO en la página Contacto
• WooCommerce: Desactivado en todas partes EXCEPTO en la tienda, el carrito y el proceso de pedido
• Google Maps: Desactivado en todas partes EXCEPTO en la página Contacto

Resultado: Puede ganar entre 500 KB y 1 MB por página. Puede parecer poco, pero en móvil con 4G media, son de 2 a 3 segundos ganados.

¿Cuál es el problema?

Sus archivos JavaScript contienen espacios, comentarios, saltos de línea… todo lo que es legible para una persona pero inútil para un ordenador.

La solución:

WP Rocket → Pestaña «Optimización de archivos» → Marque «Minificar archivos JavaScript». El plugin comprime automáticamente todos sus archivos JS.

Atención: La minificación de JavaScript puede romper a veces alguna funcionalidad (menús desplegables, sliders). Si ocurre:

1. Identifique el archivo problemático en la consola del navegador (F12)
2. Exclúyalo de la minificación en WP Rocket

¿Cuál es el problema?

Un script de JavaScript bloquea todo el navegador mientras se ejecuta. Durante ese tiempo, su visitante no puede hacer clic, ni desplazarse, ni hacer nada. El sitio se queda congelado.

Traducción a lenguaje corriente:

El «hilo principal» es el procesador de su navegador. Si un script monopoliza ese procesador durante más de 50 milisegundos, Google lo considera una «tarea larga».

Los culpables habituales:

• Sliders animados (Revolution Slider, LayerSlider)
• Chats en directo (LiveChat, Tawk.to)
• Animaciones JavaScript complejas
• Google Analytics mal configurado

La solución:

1. Identifique al culpable con Query Monitor (plugin gratuito que lista todos los scripts cargados)
2. Aplace la carga de este script con WP Rocket (opción «Cargar JavaScript en diferido»)
3. Si es un plugin pesado, sustitúyalo por una alternativa más ligera

Ejemplo: Un slider Revolution Slider puede sustituirse por una simple imagen de cabecera. Pierde el efecto «guau» pero gana 800 KB y 2 segundos de carga.

¿Cuál es el problema?

Su navegador debe descargar ciertos archivos CSS y JavaScript ANTES de poder mostrar nada. El visitante se queda, por tanto, ante una página en blanco durante unos segundos preciosos.

La solución: la carga diferida (Defer/Async)

Hay que indicar al navegador que cargue primero lo visual y los scripts en segundo plano.

Dos técnicas:

1. CSS crítico: Hay que extraer el CSS necesario solo para la parte superior de la página («above the fold») y cargar el resto más tarde. WP Rocket lo hace automáticamente con la opción «Optimizar la carga del CSS».

2. JS diferido: Los scripts no esenciales (analytics, chat, sliders) deben cargarse con el atributo defer para no bloquear la visualización. WP Rocket lo gestiona con «Cargar JavaScript en diferido».

Atención: La carga diferida puede romper algunos scripts que deben ejecutarse de inmediato (jQuery, algunos plugins). Si se rompe, excluya esos archivos en los ajustes de WP Rocket.

¿Cuál es el problema?

Su tema carga un archivo CSS de 300 KB con 10 000 reglas de estilo. Pero su página solo utiliza 500 de ellas. Las otras 9500 son lastre.

¿Por qué ocurre?

Porque su tema está diseñado para gestionar decenas de tipos de página distintos (blog, tienda, portfolio, etc.). Por eso carga TODO el CSS en TODAS las páginas, aunque solo utilice una parte de las funcionalidades.

La solución:

WP Rocket → Active «Eliminar CSS no utilizado». El plugin analiza cada página y carga solo el CSS realmente necesario. Puede ganar entre 100 y 200 KB por página.

Atención: Esta función puede romper a veces el diseño de algunas páginas (menús desplegables, ventanas emergentes). Si ocurre, excluya esas páginas en los ajustes.

Dos palancas rápidas que probar: pasar sus imágenes al formato WebP y elegir un buen plugin de caché.

Para ir más lejos, puede consultar la herramienta PageSpeed Insights de Google.

¿Cuál es el problema?

Como con JavaScript, sus archivos CSS contienen espacios y comentarios inútiles.

La solución:

WP Rocket → «Minificar archivos CSS». Ganancia típica: entre un 20 y un 30 % de reducción del peso.

¿Cuál es el problema?

Su sitio carga 15 archivos CSS distintos (uno por plugin, uno para el tema, uno para las fuentes, etc.). Cada archivo requiere una solicitud HTTP. 15 solicitudes = 15 viajes de ida y vuelta al servidor.

La solución:

WP Rocket → Active «Combinar archivos CSS». El plugin fusiona todos sus archivos CSS en uno solo. Resultado: 1 solicitud en lugar de 15.

Atención: La combinación puede crear a veces conflictos de estilo (un elemento que se muestra mal). Si ocurre, desactive la opción para ese archivo concreto.

¿Cuál es el problema?

Utiliza una fuente de Google Fonts (Roboto, Open Sans, etc.). Mientras se carga esa fuente, el texto es invisible. El visitante ve una página en blanco aunque el contenido ya está ahí. Es lo que se llama FOIT (Flash Of Invisible Text).

¿Por qué es grave?

En una conexión 3G, una fuente de Google Fonts puede tardar de 2 a 3 segundos en cargarse. Durante ese tiempo, el visitante no ve NADA. El 40 % se irá.

La solución:

Opción 1 (fácil): WP Rocket → Active «Optimizar la visualización de las fuentes de Google Fonts». El plugin utiliza el atributo font-display: swap, que muestra primero una fuente del sistema (Arial) y la sustituye por su fuente personalizada cuando se ha cargado.

Opción 2 (óptima): Aloje sus fuentes localmente mediante su tema o con el plugin OMGF (Optimize My Google Fonts). En lugar de descargar la fuente desde los servidores de Google, se almacena directamente en su servidor. Ganancia típica: de 200 a 500 ms.

¿Cuál es el problema?

Su navegador descubre que utiliza una fuente personalizada solo DESPUÉS de haber descargado y analizado su CSS. Es demasiado tarde, añade un retraso.

La solución:

Diga al navegador que descargue su fuente CON PRIORIDAD mediante un «preload». WP Rocket lo hace automáticamente si activa «Precargar las fuentes».

La compresión GZIP permite que su sitio cargue más rápido al reducir el tamaño de los archivos enviados al navegador.
Puede activarla de tres formas.

Mediante un plugin de caché
Si utiliza WP Rocket, WP Super Cache o W3 Total Cache, la compresión ya se gestiona desde su interfaz. En WP Super Cache, marque la casilla «Comprimir las páginas para que se sirvan más rápido a los visitantes» en los ajustes avanzados. En W3 Total Cache, actívela desde la sección «Caché del navegador».

Mediante el .htaccess
Si es partidario de hacer las cosas a mano y odia sobrecargar su sitio con plugins a porrillo, añada este bloque a su archivo .htaccess en la raíz de su sitio:


AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
AddOutputFilterByType DEFLATE text/javascript application/javascript
AddOutputFilterByType DEFLATE application/json application/xml


Mediante la configuración de su servidor
Si no sabe lo que hace, evite hurgar en su servidor.
Para comprobar que está activo, utilice GiftOfSpeed o Check GZIP Compression. Pegue la URL de su sitio y le confirma si la compresión está activa.

¿Cuál es el problema?

Su página contiene más de 1500 elementos HTML (divs, spans, párrafos, etc.). Google considera que es demasiado. Cuantos más elementos hay, más tarda el navegador en construir la página.

¿Por qué ocurre?

Suele ocurrir con constructores de páginas como Elementor, que generan un código muy pesado. Para hacer un simple bloque de texto con un botón, Elementor puede generar 15 divs anidados cuando bastarían 2.

Ejemplo: Una página media de Elementor: 2500 elementos DOM. La misma página programada a mano: 600 elementos.

La solución:

1. Simplifique su maquetación (menos secciones, menos widgets)
2. Limite el número de widgets de su barra lateral (5 como máximo)
3. Dé preferencia a Gutenberg: Es el editor nativo de WordPress. Genera un código extremadamente limpio y ligero, lo que lo convierte en la opción n.º 1 para el rendimiento puro. Pase a Bricks u Oxygen: Si necesita un constructor visual avanzado, estas herramientas están pensadas para desarrolladores y producen un DOM mucho más reducido que Elementor o Divi.
4. Para páginas muy largas, considere una paginación

¿Cuál es el problema?

El navegador hace demasiados cálculos (análisis de JavaScript, maquetación, renderizado). A partir de 2 segundos de «trabajo» en móvil, Google lo considera excesivo.

Los culpables habituales:

• Animaciones CSS complejas con transiciones en 50 elementos
• Recálculos constantes del diseño (por culpa del CLS)
• JavaScript que manipula el DOM de forma masiva

La solución:

1. Desactive las animaciones CSS pesadas (efectos parallax, particles.js)
2. Utilice un tema ligero (Astra, GeneratePress)
3. Limite el número de elementos DOM (<1500 idealmente)

¿Cuál es el problema?

Google Analytics, Facebook Pixel, chat en directo, publicidad… Todos estos pequeños scripts externos se acumulan y lastran su rendimiento.

¿Por qué es grave?

Para cargar estos scripts, su sitio debe conectarse a servidores externos (los de Google, Facebook, etc.). Si esos servidores son lentos o están sobrecargados, SU sitio se ralentiza.

La solución:

Opción 1: Retrase su carga 5 segundos con Flying Scripts (plugin gratuito). Durante esos 5 segundos, su contenido principal se carga con prioridad.

Opción 2: Utilice Perfmatters (de pago) para diferir manualmente cada script de terceros y elegir con precisión dónde se cargan.

Opción 3 (experto): Centralice todos sus scripts de seguimiento en Google Tag Manager. En lugar de cargar 5 scripts distintos, carga solo uno que gestiona los demás.

¿Cuál es el problema?

Sus archivos CSS, JavaScript e imágenes no se almacenan en la caché del navegador del visitante. Resultado: en cada visita, tiene que volver a descargarlo todo.

La solución:

WP Rocket activa automáticamente la caché del navegador con duraciones óptimas (1 año para las imágenes, 1 mes para CSS/JS).

Más allá de las alertas técnicas, Google observa 3 indicadores clave para evaluar la experiencia de usuario de su sitio. Estas métricas son factores de clasificación oficiales desde 2021.

¿Qué es?

El tiempo que tarda en mostrarse su elemento visible más grande. Suele ser su imagen de cabecera, su banner o su vídeo principal.

Los umbrales de Google:

• 🟢 Bueno : Menos de 2,5 segundos
• 🟡 Mejorable : Entre 2,5 y 4 segundos
• 🔴 Malo : Más de 4 segundos

¿Por qué es importante?

Si su LCP es de 4,2 segundos, significa que el visitante espera más de 4 segundos antes de ver su contenido principal. En móvil, el 40 % de los visitantes se irá antes incluso de haber visto nada.

¿Cómo identificarlo?

Lance un análisis de PageSpeed. Google le dice con precisión qué elemento es su LCP. A menudo es:

• Su imagen de cabecera (hero image)
• Su logotipo si no tiene imagen de cabecera
• Un bloque de texto si su página es muy sobria

¿Cómo corregirlo?

1. Optimice su imagen LCP:

• Conviértala a WebP (Imagify)
• Comprímala al máximo (idealmente menos de 100 KB)
• Utilice las dimensiones adecuadas (no hace falta una imagen de 4000 px de ancho si se muestra a 1200 px)

2. Precargue esta imagen:

WP Rocket → Pestaña «Precarga» → Añada la URL de su imagen LCP. Le dice al navegador que la descargue CON PRIORIDAD antes que todo lo demás.

3. Mejore su TTFB (Time To First Byte):

Es el tiempo que tarda su servidor en empezar a enviar datos. Si su TTFB supera los 600 ms, es su servidor el que es demasiado lento.

• Active la caché (WP Rocket)
• Pase a PHP 8.2
• Cambie de proveedor de alojamiento si es necesario

Ejemplo concreto:

Un cliente tenía un LCP de 5,1 segundos. Su imagen de cabecera pesaba 850 KB en PNG. Tras convertirla a WebP (120 KB) y precargarla, el LCP bajó a 2,1 segundos. Resultado: +28 % de tasa de conversión en móvil.

¿Qué es?

Una medida de los «saltos» visuales durante la carga. Cada vez que un elemento se desplaza por la pantalla, aumenta su puntuación CLS.

Los umbrales de Google:

• 🟢 Bueno : Menos de 0,1
• 🟡 Mejorable : Entre 0,1 y 0,25
• 🔴 Malo : Más de 0,25

¿Por qué es importante?

Está en el móvil, empieza a leer un artículo y de repente ¡PAM!, todo baja 300 píxeles porque se acaba de cargar un anuncio encima. Se ve obligado a volver a desplazarse para encontrar dónde estaba. Es exasperante.

Las causas más frecuentes:

1. Imágenes sin dimensiones:

El navegador no sabe cuánto espacio reservar. Cuando carga la imagen, todo se desplaza.

Solución: WP Rocket añade automáticamente los atributos width y height que faltan.

2. Fuentes web que cargan tarde:

Su texto se muestra primero con Arial y luego «salta» cuando se carga su fuente de Google Fonts.

Solución: Utilice font-display: swap (WP Rocket lo hace automáticamente) o aloje sus fuentes localmente (OMGF).

3. Banners publicitarios:

Tiene anuncios de Google AdSense sin tamaño fijo. Cuando cargan, empujan su contenido hacia abajo.

Solución: Reserve un espacio fijo para sus anuncios con CSS:

.ad-container { min-height: 250px; width: 300px; }

Banners, notificaciones, ventanas emergentes que aparecen DESPUÉS de la carga inicial y empujan el contenido.

Solución: Muestre estos elementos en superposición (por encima del contenido) en lugar de insertarlos en el flujo.

¿Cómo detectar los elementos culpables?

PageSpeed le lista los elementos que causan CLS. También puede usar la pestaña «Rendimiento» de Chrome DevTools para ver en tiempo real qué se mueve.

Ejemplo concreto:

Un sitio de comercio electrónico tenía un CLS de 0,42 por un banner promocional que se insertaba en la parte superior de la página 2 segundos después de la carga. Al mostrar ese banner en posición fija (sticky header) en lugar de insertarlo en el flujo, el CLS bajó a 0,06.

Cambio importante: Google sustituyó el FID (First Input Delay) por el INP en marzo de 2024. Es una métrica más completa que mide la reactividad en TODAS las interacciones, no solo en la primera.

El tiempo entre el momento en que el visitante hace clic en un botón, escribe texto o abre un menú, y el momento en que algo ocurre en pantalla.

Los umbrales de Google:

• 🟢 Bueno : Menos de 200 ms
• 🟡 Mejorable : Entre 200 ms y 500 ms
• 🔴 Malo : Más de 500 ms

¿Por qué es importante?

Si su INP es de 600 ms, significa que hay medio segundo de retraso entre el momento en que el usuario hace clic y el momento en que se abre el menú. En un sitio de comercio electrónico, basta para frustrar al cliente y hacer que se vaya.

1. Demasiado JavaScript:

El navegador está ocupado ejecutando código JavaScript, así que no puede reaccionar de inmediato al clic.

Solución: Reduzca los scripts innecesarios, aplace su carga, utilice la minificación.

2. Tareas largas:

Un script que monopoliza el procesador durante más de 50 ms bloquea todas las interacciones.

Solución: Identifique y aplace los scripts pesados (sliders, animaciones, analytics).

3. Servidor lento:

Si una interacción requiere una llamada al servidor (formulario, filtros, etc.) y su servidor tarda 800 ms en responder, el INP será malo.

Solución:

• Pase a PHP 8.2 (mejora del 30-40 %)
• Active la caché de objetos (Redis o Memcached)
• Optimice sus consultas a la base de datos

¿Cómo probar el INP?

El INP es difícil de medir en «laboratorio» (prueba artificial). Hacen falta datos reales de usuarios. Puede ver su INP en:

• Google Search Console → Experiencia → Core Web Vitals (datos reales)
• Chrome DevTools → Lighthouse → Modo «Navegación»

Ejemplo concreto:

Un sitio con un mega-menú complejo tenía un INP de 520 ms. El menú se cargaba en JavaScript y requería 400 ms de cálculo. Al pregenerar el menú en HTML puro (sin JavaScript), el INP bajó a 110 ms.

No intente corregir las 3 métricas al 100 % de inmediato. Este es el orden de importancia:

1. Primero el LCP (el de mayor impacto)

• Optimice su imagen principal
• Active la caché
• Mejore su TTFB

2. Después el CLS (el más fácil de corregir)

• Añada las dimensiones de las imágenes
• Fije el tamaño de los bloques publicitarios
• Optimice la carga de las fuentes

3. El INP en último lugar (el más complejo)

• Reduzca el JavaScript
• Aplace los scripts pesados
• Optimice su servidor

Objetivo realista:

Un sitio con una puntuación de 90-95/100 en móvil y unas Core Web Vitals todas en verde (LCP < 2,5 s, CLS < 0,1, INP < 200 ms) es más que suficiente. Aspirar al 100/100 perfecto puede resultar contraproducente si exige sacrificar funcionalidades.

Alcanzar el 100 % en PageSpeed una vez es factible. Mantenerlo todo el año es un oficio.

Su sitio está vivo. Cada nuevo artículo, cada foto añadida, cada actualización de plugin puede hacer que su puntuación vuelva a caer. Un plugin que añade 200 KB de JavaScript, un tema que activa una nueva funcionalidad, una imagen subida con 4 MB porque tenía prisa… y zas, vuelve a estar en rojo.

Los errores que veo en el 90 % de los sitios:

1. La optimización puntual

Optimiza una vez, está contento con el resultado y luego se olvida. 6 meses después, ha vuelto a 45/100 sin entender por qué.

2. Las actualizaciones que lo rompen todo

Un plugin se actualiza y reactiva JavaScript que usted había desactivado. Su tema añade una nueva Google Font. WooCommerce ahora carga sus scripts en todas partes en lugar de solo en la tienda.

3. La falta de supervisión

No sabe que su sitio ha pasado de 2,1 s a 4,8 s de tiempo de carga porque nadie lo vigila.

Ahí es exactamente donde intervengo yo.

En mis planes de mantenimiento, no me limito a optimizar su sitio una vez. Lo superviso de forma continua e intervengo en cuanto se ralentiza:

• ✅ Supervisión automática de la disponibilidad : funciona de forma continua; el seguimiento del rendimiento depende de las mediciones y del alcance acordados
• ✅ Optimización de las nuevas imágenes : Cada imagen que sube se comprime automáticamente a WebP
• ✅ Limpieza mensual de la base de datos : Elimino las revisiones, los transients, las tablas huérfanas
• ✅ Actualizaciones controladas : copia de seguridad y comprobaciones adaptadas; las condiciones de prueba y el posible entorno de preproducción se definen según el sitio y el presupuesto
• ✅ Configuración del servidor : Me aseguro de que siga en PHP 8.2+, HTTP/3, con las extensiones adecuadas activadas
• ✅ Volumen de intervención definido en el presupuesto : para un plan de 3 horas al mes, este volumen cubre todas las intervenciones previstas, incluidas las restauraciones. Las horas no utilizadas no se acumulan. Cualquier exceso previsible se comunica y queda sujeto a su aprobación

¿El resultado?

El objetivo es limitar las ralentizaciones y tratar los problemas identificados dentro del alcance acordado. Los plazos de resolución dependen del diagnóstico; no se puede prometer un posicionamiento en Google ni una disponibilidad perfecta. Las condiciones generales y su presupuesto precisan los compromisos.

El mantenimiento no es un gasto, es una inversión.

Cada segundo ganado = menos visitantes que se van = más conversiones. En un sitio de comercio electrónico que factura 10 000 €/mes, ganar 2 segundos de tiempo de carga puede generar entre 1500 y 2500 € de ingresos adicionales al mes.

¿Quiere un sitio rápido y la mente tranquila?