Mi web sacaba un 92 en PageSpeed. La he auditado en público

Vendo optimización WordPress. Así que lo mínimo es aplicarme el cuento: he pasado mi propia web por PageSpeed Insights, he apuntado todo lo que salía mal y lo he arreglado. Aquí van los números de antes, lo que cambié, lo que decidí no tocar y los números de después. Sin maquillaje.

El punto de partida

Informe del 30 de septiembre de 2026 sobre la home de udista.com, con Lighthouse 13.5:

Un 92 en móvil no está mal. La mayoría de webs WordPress que audito están por debajo de 60. Pero 2,7 segundos hasta ver el primer texto en un móvil con 4G lento es mucho para una home que es, básicamente, texto. Y había cosas más interesantes que la nota.

Lo que encontré

1. Un CSS de 110 KB bloqueando el primer pintado

PageSpeed estimaba 1,5 segundos de ahorro en móvil solo en «solicitudes que bloquean el renderizado». El navegador no pinta nada hasta descargar y procesar la hoja de estilos, y la mía pesaba 110 KB. Dos hojas combinadas: la original del tema y una capa editorial que añadí después, con reglas que se pisan entre sí. El elemento más grande de la pantalla (el LCP) es el titular, un texto. Si el CSS tarda, el titular tarda.

2. 93 KB de Google Analytics que no se usan

Todo el «JavaScript sin usar» que marcaba PageSpeed era un único archivo: la librería de Google Analytics. El navegador la descarga al entrar, aunque no mide nada ni pone cookies hasta que el visitante las acepta (de eso se encarga el plugin de cookies). Así que no hay problema legal, pero son 93 KB que se descargan para nada si luego rechaza las cookies.

3. Un párrafo gris sobre fondo gris

El texto de introducción de la sección de productos tenía un contraste de 4,29:1. WCAG 2.1 AA pide 4,5:1 para texto normal. Casi, pero no. Y justo yo, que vendo auditorías de accesibilidad.

4. Tres enlaces que dicen lo mismo y van a sitios distintos

Las tarjetas de servicios terminaban en «Ver detalle →». Tres veces, tres destinos. Visualmente se entiende porque cada enlace está debajo de su título. Pero quien usa un lector de pantalla y salta de enlace en enlace oye «Ver detalle, Ver detalle, Ver detalle» y no sabe cuál es cuál.

5. Mi llms.txt no respondía a tiempo

Esto es lo nuevo. Lighthouse ha añadido una categoría llamada Navegación agéntica: comprueba si los agentes de IA (los asistentes que navegan y hacen cosas por el usuario) pueden entender y usar tu web. Una de las pruebas es el archivo llms.txt, un resumen en texto plano de quién eres, qué ofreces y dónde está cada cosa, pensado para que lo lean los modelos de lenguaje.

Yo ya tenía llms.txt. El problema era cómo se servía: lo generaba WordPress en cada petición, arrancando PHP, la base de datos y todos los plugins para devolver 2 KB de texto que no cambian nunca. En móvil pasó la prueba. En escritorio, Lighthouse se cansó de esperar: «Timed out fetching resource». Resultado: 2/3.

Lo que hice

1. CSS crítico en línea y el resto en diferido. Los estilos necesarios para pintar la primera pantalla van dentro del HTML y el resto se carga sin bloquear. LiteSpeed puede hacer esto con su servicio QUIC.cloud, pero no quería depender de un servicio externo para algo que se puede generar una vez y dejar en el tema. Lo generé yo con penthouse, recorriendo las plantillas principales en móvil y escritorio. Si algún día da problemas, basta con borrar un archivo y la web vuelve a cargar el CSS como antes.
2. Contraste corregido. El gris del párrafo pasa de #64748b a #475569: de 4,29:1 a 6,9:1. El diseño apenas cambia a simple vista.
3. Enlaces con nombre propio. Cada «Ver detalle» lleva ahora un texto oculto solo para lectores de pantalla: «Ver detalle: Optimización y rescate». Visualmente todo sigue igual.
4. llms.txt como archivo estático. Ahora es un archivo de verdad en la raíz del servidor, que Apache entrega sin despertar a WordPress, con caché de 24 horas. De paso añadí el servicio de desarrollo con IA, que faltaba en la lista.

Lo que no toqué (y por qué)

• «Mejorar la entrega de imágenes: 4 KiB». Cuatro kilobytes. Arreglarlo cuesta más de lo que aporta.
• «Optimizar tamaño del DOM». La home es larga porque tiene mucho que contar. Recortar secciones para ganar un punto sería optimizar para la herramienta y no para quien lee.
• Los 92 KiB de Google Analytics. Ya no bloquean la carga (más abajo cuento por qué lo hacían) y no miden nada sin consentimiento. Retrasar también la descarga ahorraría unos KB, pero no cambia la nota. No compensa.
• Las cabeceras de seguridad (CSP, HSTS, COOP…). Salen como avisos informativos y no restan puntos. Son un proyecto aparte, con su propio post.

Esa es la parte que no te cuenta ninguna herramienta: saber qué avisos importan y cuáles son ruido. Una herramienta te da una lista. El criterio es decidir qué hacer con ella.

El resultado

100 en las cuatro categorías, en móvil y en ordenador. En móvil, el titular aparece en 1,2 segundos en vez de 2,7: menos de la mitad.

Y no fue a la primera. Tras los primeros cambios el móvil solo subió de 92 a 94, y en ordenador el Speed Index empeoró. Pasé la misma versión de Lighthouse que usa PageSpeed y salió el culpable: el plugin de caché le quitaba el async a la etiqueta de Google Analytics, así que el navegador esperaba a descargar 160 KB de JavaScript antes de pintar nada. Con una línea en el tema que marca ese script para que la caché no lo toque, la nota pasó a 100.

Lo que sí ha cambiado de verdad es lo que no sale en la nota: el CSS que bloqueaba la carga ha pasado de 110 KB a cero, un usuario con lector de pantalla ya sabe adónde lleva cada enlace, y los agentes de IA encuentran mi llms.txt a la primera.

¿Y tu web?

Si mi web, que está hecha a medida y sin constructor visual, tenía cinco cosas que arreglar, la tuya probablemente tenga más. Te hago un diagnóstico de rendimiento y te digo qué merece la pena tocar y qué es ruido. Y si ya sabes que tu web va lenta, echa un vistazo a optimización y rescate.