La conclusión clave: una puntuación baja de PageSpeed Insights en WordPress casi siempre se debe a las mismas causas — imágenes sin optimizar, scripts que bloquean el renderizado y falta de caché. Corrígelas en ese orden, vuelve a probar tras cada cambio, y la mayoría de los sitios pasan de rojo a verde sin necesidad de mejorar el hosting ni reescribir el tema.
Por qué los sitios WordPress obtienen malas puntuaciones en PageSpeed Insights
WordPress facilita añadir plugins, constructores de páginas y scripts de terceros — cada uno aporta su propio CSS, JavaScript y, a veces, solicitudes externas. Una instalación por defecto con un constructor de páginas, unos pocos plugins de marketing y medios sin optimizar puede fácilmente enviar 3-4MB de recursos para una sola página.
PageSpeed Insights ejecuta dos análisis independientes en cada URL que pruebas:
- Datos de laboratorio: una auditoría de Lighthouse simulada, ejecutada al instante en los servidores de Google bajo condiciones fijas de red y dispositivo. Útil para detectar problemas concretos, pero es una instantánea, no comportamiento real de usuarios.
- Datos de campo: mediciones reales de usuarios de Chrome que visitaron tu sitio en los últimos 28 días, extraídas del Chrome User Experience Report (CrUX). Solo aparecen si tu sitio tiene suficiente tráfico de Chrome.
Un sitio puede obtener 95 en el laboratorio y aun así mostrar una calificación "poor" (deficiente) en los datos de campo — normalmente porque los usuarios reales tienen conexiones más lentas o dispositivos más antiguos de lo que asume la simulación de laboratorio. Ambas cifras importan, pero el informe de Core Web Vitals de Search Console usa datos de campo, así que esa es la que está ligada a las señales de ranking de búsqueda.
El orden que realmente cambia la puntuación
Trabaja estos puntos en orden — cada uno suele tener un efecto mayor que el siguiente, así que hacerlos fuera de orden desperdicia tiempo en ganancias menores primero.
1. Corrige primero tus imágenes
En una página WordPress promedio, las imágenes representan el 50-80% del peso total de la página. Esta es casi siempre la corrección de mayor impacto, y suele ser lo que provoca una puntuación roja de Largest Contentful Paint (LCP), ya que el elemento LCP en la mayoría de las páginas es una imagen hero, una imagen destacada o una foto de producto sobre el pliegue.
Tres cosas que revisar en cada imagen sobre el pliegue:
- Formato — ¿sigue siendo JPEG o PNG sin procesar? WebP es aproximadamente un 25-35% más pequeño con calidad equivalente, y AVIF a menudo reduce el tamaño a la mitad comparado con JPEG.
- Dimensiones — ¿se está comprimiendo una foto de 4000px de ancho en un contenedor de 800px? El navegador igual descarga el archivo completo antes de reducirlo.
- Prioridad de carga — ¿la imagen LCP está marcada accidentalmente como
loading="lazy"? Este es uno de los errores más comunes que vemos: un plugin de "velocidad" aplica lazy loading a todas las imágenes de la página, incluida la que el navegador necesita primero.
Lo cubrimos con más detalle en nuestra checklist de imágenes para Core Web Vitals y nuestra guía de conversión a WebP. Erdo Image Optimizer gestiona automáticamente la conversión de formato y la corrección del lazy loading, usando la propia librería GD o Imagick de tu servidor — sin API externa ni cuota mensual.
2. Elimina el CSS y JavaScript que bloquean el renderizado
Cada <script> y <link rel="stylesheet"> en tu <head> sin async, defer o una media query bloquea el renderizado de la página hasta que se descarga y (en el caso de los scripts) se ejecuta. Los constructores de páginas y temas multipropósito son culpables frecuentes aquí, cargando a menudo una librería de iconos completa o un framework de animación incluso en páginas que no los usan.
La solución no siempre es "eliminar el plugin" — a menudo basta con retrasar los scripts no críticos e integrar en línea el poco CSS necesario para la primera pantalla. La mayoría de los plugins de caché y rendimiento tienen una opción para esto; prueba con cuidado después de activarlo, ya que un retraso agresivo puede a veces romper un script que depende del orden de carga.
3. Activa el caché del lado del servidor y del navegador
Una página que tiene que ser reconstruida por PHP y MySQL en cada solicitud añade varios cientos de milisegundos al Time to First Byte (TTFB), lo que retrasa todo lo que viene después, incluido el LCP. El caché de página (servir un archivo HTML estático pregenerado a los visitantes recurrentes) y el caché de objetos (evitar consultas repetidas a la base de datos) valen la pena, y la mayoría de los plugins de caché configuran ambos con valores predeterminados razonables.
Este paso importa, pero rara vez es el mayor factor de la puntuación — una página bien cacheada con una imagen hero sin comprimir de 2MB seguirá fallando en LCP.
4. Audita la cantidad y calidad de los plugins
La cantidad de plugins en sí no es inherentemente un problema de rendimiento — un plugin bien programado que solo carga sus recursos donde se necesitan cuesta muy poco. El problema real son los plugins que cargan CSS/JS en todo el sitio, sin importar si la página actual los usa. Diez plugins ligeros y bien delimitados son menos problemáticos que dos mal programados.
Una auditoría práctica: abre Chrome DevTools → pestaña Network, recarga una página lenta y ordena por tamaño. Cualquier cosa inesperadamente grande merece investigarse — rastréala hasta el plugin o componente de tema que la carga.
Referencia rápida: umbrales de Core Web Vitals
| Métrica | Bueno | Necesita mejora | Deficiente |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Menos de 2,5s | 2,5s – 4s | Más de 4s |
| INP (Interaction to Next Paint) | Menos de 200ms | 200ms – 500ms | Más de 500ms |
| CLS (Cumulative Layout Shift) | Menos de 0,1 | 0,1 – 0,25 | Más de 0,25 |
Estos son los umbrales publicados por Google, medidos en el percentil 75 de visitas reales — lo que significa que tres de cada cuatro visitantes deben estar en el rango "Bueno" para que la métrica apruebe.
Un ejemplo trabajado
En una auditoría reciente de una tienda WooCommerce con una configuración bastante típica (constructor de páginas, 3 plugins de marketing, fotografía de producto sin optimizar), así fue la evolución antes y después de abordar las imágenes y los scripts que bloquean el renderizado:
| Cambio | LCP antes | LCP después |
|---|---|---|
| Convertir imágenes hero y de producto a WebP | 4,8s | 3,6s |
| Corregir dimensiones de imágenes demasiado grandes | 3,6s | 2,9s |
Quitar loading="lazy" de la imagen hero |
2,9s | 2,1s |
Ninguno de estos tres cambios tocó el hosting, la configuración de caché ni el código del tema — llevaron el LCP de "deficiente" a "bueno" únicamente mediante el manejo de imágenes. Esto es coherente con lo que vemos en la mayoría de las auditorías de WordPress: las imágenes son el primer lugar donde mirar, no el último.
El error que conviene evitar
Un instinto común cuando PageSpeed Insights muestra rojo es empezar a desactivar plugins uno por uno, esperando encontrar "al" culpable. Esto es lento y a menudo poco concluyente, porque el verdadero cuello de botella suele ser una sola imagen demasiado grande, no un plugin. Revisa primero la sección "Diagnóstico" del informe de PageSpeed Insights — nombra el elemento LCP real y enumera los recursos concretos que bloquean el renderizado, lo cual es un punto de partida mucho más rápido que desactivar por ensayo y error.
Para terminar
Una puntuación roja de PageSpeed Insights en WordPress da la sensación de necesitar una mejora de hosting o una reconstrucción completa del tema, pero en la práctica, la solución casi siempre es más acotada: llevar las imágenes a un formato moderno con el tamaño correcto, dejar de bloquear el renderizado con scripts innecesarios, cachear lo que se pueda cachear, y podar los plugins que cargan recursos que no necesitan. Trabaja estos cuatro puntos en orden y vuelve a probar después de cada uno — normalmente sabrás en el primer o segundo paso qué corrección está haciendo el verdadero trabajo.
Si las imágenes resultan ser tu mayor problema (suele ser así), Erdo Image Optimizer automatiza la conversión de formato, las alertas de dimensiones y la auditoría de lazy loading descritas arriba, convirtiendo así una revisión manual recurrente en una configuración de una sola vez.