Mi sitio tiene diez años en línea y el 15 de octubre de 2026 sacó 34 en PageSpeed móvil. La página principal tardaba 38 segundos en pintar su elemento más grande y pesaba entre 6,5 y 7,9 MB. Hoy esa misma página saca 97 en PageSpeed Insights y pinta en 1,8 segundos. No lo logré con un plugin de caché ni optimizando el tema que tenía: cambié de tema, quité casi todos los plugins y puse la caché en Cloudflare. Aquí cuento qué hice, qué me salió mal y qué no he medido.
El punto de partida
| Antes (15-oct-2026) | Después (24 a 26-oct-2026) | |
|---|---|---|
| PageSpeed móvil, página principal | 34 | 97 |
| Una nota cualquiera | 30 | 98 a 99 |
| LCP en móvil | 38,0 s | 1,8 s (notas: 2,0 a 2,2 s) |
| Tiempo de bloqueo (TBT) | 1,8 a 2,4 s | 0 ms |
| Peso de la página | 6,5 a 7,9 MB | 138 a 555 KB |
| Plugins activos | 31 (13 sin actualizar) | 2 |
Las cifras «después» son de PageSpeed Insights sobre el sitio en producción, en móvil, medidas el 26 de octubre de 2026. Son pruebas de laboratorio, no datos de usuarios reales; las condiciones y límites van al final.
Qué lo hacía tan lento
El elemento más grande de la página, la miniatura principal, no estaba en el HTML: el tema la pintaba con JavaScript como background-image. El navegador tenía que descargar el tema, ejecutar los scripts y solo entonces sabía qué imagen mostrar. Con un teléfono y una red lenta, eso son 38 segundos. A eso se sumaban banners y widgets de terceros, treinta y un plugins y páginas de varios megas.
Qué cambié, por orden de impacto
1. Un tema propio y mínimo. Cambié el tema multipropósito por uno hecho a mano con plantillas PHP simples, sin constructor visual y sin jQuery. Su JavaScript propio son cuatro archivos de unos 10 KB en total, todos con defer.
2. La imagen principal, en el HTML. La imagen destacada va como una etiqueta <img> normal con fetchpriority="high". El navegador la descubre desde el primer byte y la pide de inmediato. Solo con esto el LCP deja de depender del JavaScript. Si solo vas a cambiar una cosa en tu sitio, que sea esta.
3. De 31 plugins a 2. Dejé únicamente uno de SEO y uno de correo. El resto o lo reemplacé con unas pocas líneas en el tema, o lo retiré. Menos plugins es menos código en cada visita y menos cosas por actualizar. Antes tenía 13 pendientes de actualización y las actualizaciones automáticas apagadas.
4. Imágenes en WebP y con carga diferida. WordPress puede generar las miniaturas en WebP con un filtro (image_editor_output_format). Capturas PNG que pesaban 700 KB bajaron a unos 60 KB. Las imágenes que no se ven al abrir la página cargan cuando haces scroll.
5. Fuentes en mi propio servidor. Las dos tipografías (Inter y JetBrains Mono) están en wp-content/themes/ en formato woff2, la principal con preload y font-display: swap. Sin pedir nada a Google Fonts.
6. Caché de página en Cloudflare, no en un plugin. El tema envía una cabecera Cache-Control para el HTML de visitantes anónimos, y una regla de caché de Cloudflare lo guarda. La regla excluye a quien tenga sesión o haya comentado, y rutas como /wp-admin/, /wp-login.php y /wp-json/. El tiempo hasta el primer byte bajó de unos 650 ms a unos 50 ms en las visitas que dan HIT. Si quieres montarlo, tengo una guía para configurar Cloudflare paso a paso.
7. Rocket Loader apagado. Es la función de Cloudflare que reescribe los scripts para retrasarlos. En mi caso empeoraba las cosas, como cuento abajo.
Lo que me salió mal
Con Rocket Loader encendido, el LCP de las notas tenía unos 2,1 s de retraso solo en pintar y el TBT subía a 50 o 100 ms. Lo apagué con una Configuration Rule de Cloudflare solo para mi dominio. Y ahí apareció un segundo problema: en las notas con imágenes grandes el TBT saltó a 200 y hasta 450 ms y el rendimiento bajó a 79.
La causa estaba en mi propio código. El script que abre las imágenes en grande (un lightbox) medía el ancho de cada imagen al cargar la página, y eso obliga al navegador a recalcular el diseño de toda la página. Rocket Loader lo había estado retrasando sin que yo lo supiera. La corrección fue marcar una imagen como ampliable cuando pasas el puntero por encima, no al cargar. Con eso el TBT volvió a 0.
La lección: una optimización externa puede tapar un problema tuyo. Cuando apagas algo y todo se rompe, el error probablemente estaba antes.
Resultado final
Primero, las mediciones de PageSpeed Insights (desde los servidores de Google, móvil, 26-oct-2026). En las tres, accesibilidad, prácticas recomendadas y SEO dieron 100:
| Página | Rendimiento | LCP | TBT | CLS | Speed Index |
|---|---|---|---|---|---|
| Principal | 97 | 1,8 s | 0 ms | 0 | 3,9 s |
| Nota de correos en local | 99 | 1,8 s | 0 ms | 0 | 1,7 s |
| Nota de optimizar la base de datos | 98 | 2,2 s | 0 ms | 0 | 2,6 s |
El único indicador en naranja fue el Speed Index de la principal (3,9 s). Y mis mediciones anteriores con Lighthouse en mi ordenador, el 24 de octubre, con la caché activa:
| Página | Rendimiento | Accesibilidad | LCP | TBT | CLS | Peso |
|---|---|---|---|---|---|---|
| Principal | 98 | 100 | 1,8 s | 0 ms | 0 | 477 KB |
| Nota nueva | 96 | 100 | 2,0 s | 0 ms | 0 | 138 KB |
| Nota vieja | 98 | 100 | 2,2 s | 0 ms | 0 | 248 KB |
| Categoría | 99 | 100 | 1,9 s | 0 ms | 0 | 277 KB |
| Portafolio | 99 | 100 | 1,7 s | 0 ms | 0 | 555 KB |
Lo que no he medido
- Son datos de laboratorio. PageSpeed Insights y Lighthouse simulan un móvil con red lenta. Los datos de usuarios reales llegan a Search Console con semanas de retraso, y no puedo prometer que coincidan.
- Los anuncios no están en estas cifras. Los míos se cargan diferidos, a los 5 segundos o con la primera interacción, y una prueba automática termina antes. Eso es una decisión de diseño: que el anuncio no retrase lo primero que ve la persona. El efecto real de los anuncios solo se verá en datos de usuarios reales, y todavía no los tengo.
- Mi caso no es el tuyo. Reconstruí el tema entero; no es un truco de diez minutos. Lo que sí se traslada a cualquier sitio es la lista de arriba: imagen principal en el HTML, menos plugins, WebP, fuentes propias y caché de página.
¿Tu WordPress también va lento?
Si tu sitio da más de 3 segundos en el móvil, casi siempre hay una causa concreta, y se puede encontrar con una auditoría. Si quieres que le eche un vistazo al tuyo, escríbeme desde aquí.
Referencias
- Lighthouse (documentación de Chrome para desarrolladores).
- Optimizar el LCP y Optimizar el TBT en web.dev.
- Cloudflare: reglas de caché.
