¿WordPress lento? 100/100 en Lighthouse y 3/3 en navegación agéntica
Nuestra antigua web usaba WordPress y Elementor. Al construir la nueva nos propusimos reducir peso y peticiones sin renunciar a diseño ni contenido. Hoy: 7 peticiones, unos 68 KB, 100 en las cuatro auditorías de Lighthouse y 3/3 en navegación agéntica. Y lo que no podemos medir, lo decimos.
Durante bastante tiempo nuestra web estuvo construida con WordPress y Elementor.
No hay nada especialmente raro en eso. Millones de páginas funcionan así y WordPress puede sostener proyectos excelentes. El problema aparece cuando, con los años, una web empieza a acumular capas: el constructor visual, plugins, estilos, scripts, funcionalidades que llegaron para resolver una necesidad concreta y recursos que continúan cargándose mucho después de que alguien haya olvidado por qué estaban allí.
Llega un momento en que abrir una página se parece un poco a preparar una maleta después de diez años sin vaciarla.
Todo parece necesario hasta que toca levantarla.
Cuando desarrollamos la nueva web de Sakudarte decidimos abordar el problema desde otro lugar. No queríamos terminar el diseño y preguntarnos después cómo hacerlo más rápido. Queríamos que el rendimiento formara parte de las decisiones de desarrollo desde el principio.
El resultado que medimos hoy en la portada es bastante concreto: 7 peticiones y unos 68 KB transferidos en una primera visita.
A eso se suman 100 puntos en las cuatro categorías de Lighthouse/PageSpeed —Rendimiento, Accesibilidad, Prácticas recomendadas y SEO— tanto en móvil como en ordenador, y un 3/3 en su nueva auditoría de navegación agéntica.
Pero antes de celebrar demasiado los números, hay una cosa que conviene decir.
No tenemos una medición equivalente de la antigua web realizada bajo las mismas condiciones.
Así que este no es un artículo de «antes pesábamos X y ahora pesamos Y».
No vamos a inventarnos el antes para hacer más espectacular el después.
Lo interesante es otra cosa: qué ocurre cuando dejas de intentar optimizar una web construida por acumulación y empiezas a desarrollar pensando desde el principio en cuánto necesita realmente cargar una página para hacer su trabajo.
¿Era WordPress el problema?
Sería tentador responder que sí, pero no sería del todo cierto.
WordPress no tiene por qué ser lento. Lo que ocurre es que su flexibilidad hace muy sencillo añadir capas a un proyecto.
Un constructor visual incorpora sus propios recursos. Un plugin añade otros. Una funcionalidad necesita una librería. El siguiente plugin carga algo más. Una plantilla incluye componentes que quizá utilizamos en una página de veinte, pero cuyos estilos o scripts terminan viajando mucho más de lo necesario.
Nada de eso suele ser desastroso por separado.
El problema es la suma.
En nuestro caso, la web anterior utilizaba WordPress y Elementor. No conservamos una medición rigurosa de peso, número de peticiones o LCP que permita afirmar que el cambio ha supuesto una mejora de un porcentaje determinado, y preferimos decirlo así.
Lo que sí sabemos es cómo está construida y cuánto necesita hoy la nueva.
Y siete peticiones dejan poco espacio para esconder recursos innecesarios.
El objetivo no era conseguir un 100, sino necesitar menos cosas
Cuando hablamos de optimización web es fácil convertir PageSpeed en una especie de videojuego: 97, 98, 99, volvemos a tocar algo, 100, y durante unos segundos sentimos que hemos completado Internet.
Nosotros también nos propusimos alcanzar ese 100, pero el ejercicio resultó útil sobre todo porque nos obligaba a justificar técnicamente cada decisión.
¿Necesitamos cargar este recurso? ¿Tiene sentido esta dependencia? ¿Esta funcionalidad aporta suficiente valor como para pagar su coste? ¿Podemos conseguir el mismo resultado con una solución más sencilla?
La diferencia es importante.
Una página rápida no aparece necesariamente porque al final de un proyecto alguien instale un plugin de caché, active cuatro casillas y comprima las imágenes.
El rendimiento se decide mucho antes.
Se decide en arquitectura, en el número de dependencias que aceptamos, en cómo construimos los componentes y en cuánto código obligamos al navegador a recibir, interpretar y ejecutar para mostrar algo que quizá era bastante sencillo.
Por eso el dato de las siete peticiones nos interesa casi tanto como la puntuación.
Hay muy pocas conversaciones ocurriendo antes de que la página pueda hacer su trabajo.
Lo que podemos demostrar hoy: 68 KB, 7 peticiones y 100 en Lighthouse
Conviene ser preciso con la cifra, porque es fácil dar una que no cuadre cuando alguien la comprueba.
En la medición que utilizamos para este artículo, la portada necesita siete peticiones: el propio documento HTML más seis subrecursos —la hoja de estilos, la tipografía, el script del layout, el logotipo, un icono y una flecha—.
El reparto es este:
- Documento HTML: 16,1 KB comprimidos. Sin comprimir son 68,5 KB, así que gzip se lleva por delante el 76 % del peso.
- Tipografía (WOFF2): 30,4 KB. Es el recurso más pesado de la página, y es una fuente variable con todo su rango de grosores.
- Hoja de estilos: 9,5 KB comprimidos, para todo el sitio.
- JavaScript: 5,2 KB.
- Imágenes: 6,5 KB entre logotipo, icono y flecha, todas vectoriales salvo el favicon.
Total: unos 68 KB en la primera visita.
Y hay un segundo dato que nos gusta más todavía. Los recursos estáticos se sirven con una caché de un año marcada como inmutable, así que en una visita posterior el navegador prácticamente solo necesita el HTML: unos 16 KB. La tipografía, que es lo más caro de la página, se paga una vez.
Además, la portada alcanza 100 puntos en Rendimiento, Accesibilidad, Prácticas recomendadas y SEO en las auditorías de Lighthouse/PageSpeed, en móvil y en ordenador.
Aquí la expresión importante es «de laboratorio».
PageSpeed Insights combina dos tipos de información que no conviene mezclar. Por una parte están las pruebas sintéticas de Lighthouse, realizadas bajo condiciones controladas: muy útiles para detectar problemas técnicos, comparar cambios y comprender cómo se comporta una página en un escenario determinado. Por otra están los datos de campo de Chrome UX Report, CrUX, que proceden de experiencias reales de usuarios de Chrome durante un periodo de tiempo.
Nuestra web todavía no dispone de suficiente volumen de datos reales para que CrUX muestre métricas de campo.
Si alguien abre hoy PageSpeed Insights y encuentra el mensaje «No hay datos», esa es la razón.
No significa que la web no pueda medirse ni que el 100 desaparezca misteriosamente. Significa que todavía no existen suficientes muestras reales, anónimas y representativas para que Google publique datos de campo de esa URL u origen.
Nos parecía importante explicarlo precisamente porque estamos hablando de medición.
No tendría mucho sentido pedir rigor con los datos y esconder el dato que todavía no tenemos.
Un 100 de laboratorio no significa que todos los usuarios obtengan un 100
Este matiz también merece quedarse.
Las pruebas de laboratorio son repetibles y comparables, pero una persona real puede visitar una página desde un teléfono distinto, con una conexión peor, mientras el dispositivo está ocupado con otros procesos o desde unas condiciones que una prueba sintética no reproduce exactamente.
Por eso, cuando nuestra web acumule suficiente tráfico para disponer de datos CrUX representativos, habrá una segunda capa de información mucho más interesante: podremos comparar aquello que diseñamos y medimos en laboratorio con aquello que viven realmente los usuarios.
Hasta entonces, nuestra afirmación es más modesta y también más precisa: hemos construido una web que obtiene resultados máximos en las auditorías de laboratorio que utilizamos y que mueve una cantidad muy pequeña de información para presentar la página analizada.
Eso sí podemos medirlo hoy.
¿Por qué importa tanto reducir peso y peticiones?
Porque cada recurso tiene un coste.
El navegador tiene que solicitarlo, recibirlo y, dependiendo del tipo de archivo, procesarlo o ejecutarlo.
Una web muy pesada puede funcionar estupendamente en determinadas circunstancias, pero a medida que añadimos dependencias aumentan también las posibilidades de introducir esperas, bloqueos, errores o comportamientos difíciles de controlar.
Esto no significa que el objetivo de cualquier proyecto deba ser alcanzar nuestros 68 KB.
Una web ecommerce, una aplicación, un configurador industrial o una plataforma con visualización 3D tienen necesidades muy diferentes.
La cuestión no es fijar una cifra universal.
La pregunta es si el peso y la complejidad que estamos añadiendo están justificados por aquello que aportan al usuario.
En nuestra nueva web queríamos diseño, fotografía, contenidos y una experiencia visual reconocible. No queríamos conseguir velocidad convirtiéndola en una página prácticamente vacía.
El reto era precisamente demostrar que rendimiento y diseño no tienen por qué sentarse en extremos opuestos de la mesa. Es la misma idea que aplicamos en los proyectos de diseño web B2B: la arquitectura, los contenidos y el rendimiento se deciden juntos, no en fases separadas.
Navegación agéntica: qué comprueba y por qué la pasamos
Aquí aparece una novedad que no existía cuando publicamos el artículo original en 2019.
Lighthouse añadió en su versión 13.3 una categoría nueva llamada Agentic Browsing, navegación agéntica, y la habilitó a través de la API de PageSpeed en la 13.4. A diferencia de las puntuaciones clásicas de 0 a 100, PageSpeed la muestra como una relación de comprobaciones superadas.
En nuestra web el resultado actual es 3/3. Y lo interesante no es el número, sino qué comprueba cada una, porque las tres son consecuencia de decisiones concretas:
- El árbol de accesibilidad tiene un formato correcto. Un árbol bien formado ayuda a los agentes a desplazarse por la página e interactuar con ella. En nuestro caso viene de trabajar la semántica del HTML: un solo h1 por página, jerarquía de encabezados sin saltos y texto alternativo en todas las imágenes. Lo hicimos por accesibilidad, no por los agentes.
- Cambios de diseño acumulados: 0. El CLS mide el movimiento de los elementos visibles mientras la página carga. Un cero exacto significa que nada salta de sitio, y eso importa igual a una persona que va a pulsar un botón y a un agente que necesita localizar un elemento.
- El llms.txt sigue las recomendaciones. Debe ser un fichero Markdown con al menos un encabezado H1, para que un modelo de lenguaje pueda interpretar cómo quieres que se rastree y se use tu sitio.
De las tres, la del llms.txt es la que más nos hizo pensar.
Publicamos ese fichero el 3 de julio de 2026, cuando montamos el schema y la estructura de URLs de la web nueva. No existía ninguna auditoría que lo comprobara: lo pusimos porque nos parecía lo razonable si queríamos que las herramientas de IA entendieran quiénes somos y qué hacemos.
La auditoría llegó después.
Y esa es exactamente la tesis de este artículo, extendida a lo agéntico: una web no se prepara para los agentes el día que aparece la herramienta que los mide. Se prepara antes, tomando decisiones defendibles, y luego la herramienta te encuentra listo.
Dicho lo cual, no queremos convertir el 3/3 en otro número mágico.
No significa que ChatGPT vaya a citarnos más, que Gemini vaya a colocarnos delante de un competidor o que una página pase a posicionarse mejor en Google. Significa que ya existe una auditoría técnica específica para comprobar determinados aspectos de la navegación de agentes, y que nuestra web supera hoy las tres comprobaciones que PageSpeed presenta en esa categoría.
Eso es medible. Y cualquiera puede volver a ejecutar la prueba.
Del SEO a una web que también tendrán que entender las máquinas
Esta sección era mucho más larga en la primera versión del artículo y hemos decidido recortarla por una razón sencilla: ya tratamos con bastante más profundidad cómo están cambiando SEO, inteligencia artificial y descubrimiento de proveedores en nuestro artículo sobre cómo debe funcionar una web industrial.
Aquí nos interesa únicamente la consecuencia técnica.
Durante años desarrollamos pensando fundamentalmente en dos interlocutores: las personas y los motores de búsqueda.
Ahora hay un tercero entrando en la ecuación.
Sistemas y agentes de IA también necesitan acceder a contenido, interpretar estructuras y entender qué pueden hacer dentro de una página.
Eso no convierte en obsoletas las buenas prácticas anteriores. Más bien hace todavía más valiosas algunas de ellas: HTML comprensible, semántica, accesibilidad, estabilidad visual, contenido disponible y una arquitectura que no dependa de una montaña de ejecución innecesaria para entender lo que hay delante.
El 3/3 de navegación agéntica no demuestra que hayamos «ganado la IA». Demuestra algo mucho más concreto y, por tanto, bastante más útil.
Todo esto es la parte técnica, la que se hace una vez y aguanta. El trabajo continuado de posicionamiento para empresas que venden a empresas lo tratamos en SEO B2B e industrial.
Entonces, ¿hay que abandonar WordPress para tener una web rápida?
No.
Sería una conclusión bastante pobre.
Hay webs extraordinariamente rápidas construidas sobre WordPress y webs desesperadamente lentas desarrolladas con tecnologías mucho más modernas.
La herramienta importa, pero las decisiones importan más.
Hay proyectos para los que WordPress sigue siendo una magnífica opción. También existen casos en los que un constructor visual aporta una autonomía de edición que compensa sobradamente parte de su coste técnico.
La cuestión aparece cuando esa arquitectura deja de responder a las prioridades del proyecto.
En nuestro caso decidimos cambiarla. No porque quisiéramos demostrar que Elementor era el villano de la película, sino porque la nueva web nos permitía replantear desde cero qué necesitábamos cargar y qué podíamos dejar fuera.
Por eso tampoco plantearíamos la solución a un WordPress lento como una receta universal.
A veces el problema está en imágenes enormes. Otras, en el hosting. Puede estar en una plantilla, plugins, JavaScript de terceros, fuentes, widgets, etiquetas publicitarias o una combinación de veinte decisiones aparentemente pequeñas.
Hay webs que necesitan optimización.
Y hay otras en las que llega un momento en que resulta más sensato revisar la arquitectura.
La diferencia solo aparece después de medir.
Lo que no queremos volver a hacer
Quizá esta sea la principal conclusión que nos deja el proyecto.
No queremos volver a tratar el rendimiento como la fase que llega después de terminar una web.
Primero diseñamos. Después desarrollamos. Y al final optimizamos.
Esa secuencia invita a considerar la velocidad como una corrección técnica, cuando muchas veces el peso de una página es la consecuencia acumulada de todas las decisiones anteriores.
En la nueva web hemos intentado invertir esa lógica.
Cada vez que añadimos algo, también preguntamos cuánto cuesta. No solo en diseño o en horas de desarrollo: cuánto cuesta al navegador, cuánto añade a la petición, qué dependencia introduce y si realmente merece estar ahí.
El resultado visible son 68 KB en siete peticiones, puntuaciones de 100 en las auditorías de laboratorio que utilizamos y 3/3 en navegación agéntica.
Más adelante tendremos datos reales de CrUX y podremos añadir otra perspectiva. Hoy todavía no los tenemos, y decirlo forma parte del caso.
Tampoco sabemos con precisión cuánto pesaba aquella antigua web de WordPress y Elementor bajo exactamente las mismas condiciones. También forma parte del caso.
Porque quizá la lección más interesante no sea cuánto hemos mejorado respecto a una cifra antigua que no guardamos.
Es saber que ahora podemos explicar con bastante precisión qué está cargando nuestra web y por qué.
El 100 queda estupendo en PageSpeed.
Los 68 KB nos cuentan una historia bastante más interesante.
Fuentes
- PageSpeed Insights, la herramienta con la que cualquiera puede repetir estas mediciones
- Notas de publicación de Lighthouse: la 13.3 añade la categoría de navegación agéntica y la 13.4 la habilita en la API de PageSpeed
- Chrome UX Report (CrUX): de dónde salen los datos de campo, y por qué una URL sin suficientes muestras no los tiene
- Core Web Vitals: qué miden LCP, INP y CLS, y sus umbrales
- Especificación de llms.txt
Este artículo forma parte de nuestro servicio de diseño web B2B.