Una página de listado de WordPress puede sacar un 0,09 en Lighthouse sin tener un solo widget caro. Me pasó en la web nueva de Libelium, dentro del caso completo, y me tocó aprender dónde mirar. Empecé por la home, que es donde se mira siempre. El mayor problema estaba en otra parte.
El índice que imprimía los libros enteros
Pide el índice de una biblioteca y que te entreguen cada libro completo, diez a la vez. Eso hacía el listado. Debía devolver una ficha por entrada y devolvía diez landings enteras.
La home confirma lo esperable
Lighthouse en local me dio una línea base de la home antes de tocar nada. Rendimiento 30, accesibilidad 79, buenas prácticas 52, SEO 61 y un LCPGlosarioLCP (Largest Contentful Paint)Largest Contentful Paint (LCP) es una métrica clave de Core Web Vitals que mide el tiempo necesario para renderizar y pintar el elemento visual o bloque de texto más grande en la pantalla (usualmente la imagen Hero o banner principal).Ver término completo → de 9,7 segundos. El elemento LCP resultó ser el párrafo del hero, bloqueado por una fuente tardía. Una imagen no intervenía.
Los arreglos fueron los de manual. El sitio no enviaba cabeceras de caché y las tres fuentes propias cargaban con font-display: auto. Añadí caché de un año para imágenes y fuentes, 30 días para CSS y JS, cambié a swap y precargué las fuentes del hero.
Eso corrige síntomas de una página. Un rastreo completo con unlighthouse-ci sobre 146 rutas dijo otra cosa.
Cinco listados cerca del cero
Cinco rutas de verticales puntuaban entre 0,09 y 0,33 de rendimiento. /vertical/smart-cities/ marcaba 0,09, envair360 y environment 0,10, crowd-monitoring 0,28 e industrial 0,33. Eran listados de una taxonomía, sin ningún widget especialmente caro.
Cuando varias rutas distintas fallan igual, el fallo vive en lo que comparten. Aquí compartían plantilla.
La plantilla que no existía
El tema no tenía archive.php ni taxonomy.php. WordPress cayó a index.php, que recorre los resultados con the_content(). Elementor engancha ese filtro y devuelve la página completa que construyó para cada entrada.
El listado renderizaba diez landings apiladas bajo una URL. 528 KB de HTML, imágenes a resolución completa multiplicadas por diez y el CSS y el JS de cada landing cargados diez veces.
Escribí un archive.php con tarjetas resumen, miniatura, título y extracto truncado, más paginación. Antes de tocar nada comprobé con WP_Query que /libeliumworld/ no sufría el problema, porque es una página real diseñada en Elementor y no un archivo. La misma plantilla cubre los listados de categorías de casos de éxito.
Qué cambió
Medí una sola ruta, /vertical/smart-cities/, en local con Docker y sobre la web nueva en desarrollo. No es el sitio antiguo ni producción.
| Métrica | Antes | Después |
|---|---|---|
| Rendimiento | 0,09 | 0,31 |
| Accesibilidad | 0,83 | 0,98 |
| CLSGlosarioCLS (Cumulative Layout Shift)Cumulative Layout Shift (CLS) es una métrica de Core Web Vitals que mide la frecuencia y la magnitud con la que los elementos visibles en la pantalla cambian de posición de forma inesperada durante la carga de la página.Ver término completo → | 0,801 | 0 |
| TBTGlosarioTBT (Total Blocking Time)Total Blocking Time (TBT) mide el tiempo total en el que el hilo principal del navegador está bloqueado por tareas de JavaScript de larga duración (más de 50ms), impidiendo que la interfaz de usuario responda rápidamente a clics o inputs.Ver término completo → | 1.400 ms | 660 ms |
| LCP | 13,0 s | 7,9 s |
| HTML | 528 KB | 121 KB |
Un 0,31 sigue siendo un suspenso y un LCP de 7,9 segundos no es para presumir. La tabla enseña el orden de magnitud que movió una plantilla sola. Las otras cuatro rutas no las volví a medir, aunque la auditoría anota el mismo patrón.
Ajustes menores de los días siguientes
Quité un bucle que encolaba los 39 módulos CSS de los widgets en todas las páginas, porque cada widget ya declaraba sus dependencias. En la home, las peticiones de CSS bajaron de 53 a 33. Minifiqué además los 29 ficheros JS propios, que pasaron de 342 KB a 155 KB. Faltó comprobar en el navegador que se servían los .min.js y no tengo registro de esa comprobación.
El mismo rastreo listó 28 enlaces internos que devolvían 404. Quedaron pendientes de decidir entre un 301 y quitar el enlace, y una de esas rutas recibió después su redirección en el motor que describo en migrar 746 rutas.
Lo que me llevo
No tengo medición de producción posterior al corte. La home no se volvió a auditar, así que desconozco el efecto acumulado de caché, fuentes y precarga, y su TBT seguía en 640 ms con jQuery bloqueante.
Lo transferible es el orden de trabajo. Optimizar la home es instintivo y rinde poco cuando el crawl completo señala un grupo de rutas con la misma nota baja. Busca primero la plantilla que comparten. Si WordPress cae a index.php con un constructor visual encima, cada listado paga el precio de cada página completa. El principio general está en la lección Rendimiento de plantillas de archivo con constructores visuales.