Rescate de Core Web Vitals para sitios WordPress hechos con IA

#Rescate de Core Web Vitals para sitios WordPress hechos con IA: el problema tras el build

Un asistente de IA puede poner un sitio WordPress online en una tarde. No puede avisarte de que el cuarto plugin de “velocidad” que recomendó está peleando con la segunda capa de caché que recomendó dos prompts antes. Los dueños suelen enterarse por una captura de PageSpeed Insights con números en rojo, o porque un stakeholder pregunta por qué un sitio de aspecto rápido carga como en 2015. Este es un rescate pensado exactamente para ese modo de fallo: Core Web Vitals rotos porque el build se montó por prompt, no porque el negocio eligiera a propósito un tema pesado.

Es un servicio más estrecho que la optimización de velocidad general. Una auditoría de rendimiento estándar asume decisiones arquitectónicas deliberadas, aunque imperfectas, tomadas a lo largo del tiempo. Este rescate asume lo contrario: un asistente que respondió a diez peticiones separadas con diez instalaciones de plugins en una sola sesión de build, y un page builder que envía markup, CSS y JavaScript de cada bloque sin importar qué se renderiza above the fold.

#Por qué los builds con IA destrozan los Core Web Vitals

Tres mecanismos aparecen en casi todos los builds asistidos por IA que abrimos, casi siempre juntos.

Exceso de plugins. Los modelos de lenguaje no mantienen un inventario en vivo de lo ya instalado. El prompt uno pide un plugin de formularios. El prompt quince pide un segundo plugin de formularios porque el modelo no recuerda el prompt uno. Cada instalación es defendible por separado; el peso acumulado no. Documentamos las cifras anonimizadas de este patrón en exceso de plugins tras un build con IA: 38 plugins activos es un punto de partida habitual para un build asistido de tres semanas, no un caso extremo.

Optimizadores duplicados. La reacción instintiva a una página lenta es “instala un plugin de caché”. Si el TTFB sigue alto una semana después, el siguiente prompt es “instala un caché más rápido”, a menudo sin desactivar el primero. Encontramos con regularidad dos cachés de página completa, dos minificadores y dos plugins de optimización de imágenes peleándose en el mismo sitio, a veces con JavaScript roto de forma intermitente porque dos minificadores reescriben los mismos assets de forma distinta.

Output de builder que bloquea el render. Los page builders generan markup genérico y reutilizable para que cualquier bloque funcione en cualquier layout. Esa genericidad implica que cada bloque envía su propio CSS y JS, cargado sin mirar la posición en el viewport. Un hero montado con un builder de arrastrar y soltar más un pack de addons suele enviar más CSS que bloquea el render del que necesita toda la página, y eso es exactamente lo que arrastra LCP e INP al rojo en móvil.

En tiendas WooCommerce del mercado español lo vemos con otra capa: el asistente añade Redsys, luego un conector Bizum aparte, luego un sync con Holded “porque hace falta facturación”, y tres plugins de píxeles de remarketing “por si Black Friday”. Ninguno de esos installs es absurdo por sí solo; juntos hinchan el hilo principal del checkout justo cuando el tráfico de campaña llega. El rescate mide primero la plantilla de pago con Redsys/Bizum activos, no solo la home de aspecto limpio.

#Prueba de la práctica: de 38 a 21 plugins, TTFB de 1,47s a 0,68s

La evidencia más clara es el caso anonimizado documentado entero en exceso de plugins tras un build con IA. Un sitio B2B de servicios profesionales, construido en unas tres semanas con herramientas asistidas por IA, llegó con:

Hosting y tema no cambiaron. La mejora vino de quitar plugins duplicados de SEO, caché y analytics, fusionar tres constructores de formularios en uno, y auditar tres mu-plugins personalizados que había generado el asistente, de los cuales dos se borraron tras un pase de seguridad. Esa es la forma de un rescate de Core Web Vitals en un sitio hecho con IA: sobre todo desinstalaciones y fusiones, no infraestructura nueva.

#Tabla de triaje: síntoma, causa, acción

Haz esto antes de comprometerte con un encargo completo. Te dice si basta un pase corto o el build necesita un desmontaje por fases.

Si la mayoría de filas apunta a duplicación aislada de plugins, suele bastar un desmontaje enfocado. Si aparecen juntos código personalizado de IA, exceso de plugins y flujos de usuario rotos, acota el rescate completo en lugar de parchear el rendimiento aislado.

#Orden del desmontaje por fases

El trabajo de rendimiento sigue un orden fijo para que un arreglo no lo deshaga el siguiente lote, y para que problemas de seguridad en código personalizado no queden expuestos al quitar los plugins que los rodeaban en silencio.

1. Congelar instalaciones nuevas. Ninguna respuesta con un plugin hasta que exista el libro de auditoría.
2. Quitar primero plugins de caché y optimización duplicados. Dos cachés de página completa peleándose es la causa más habitual de resultados de PageSpeed inconsistentes; arréglalo antes de tocar nada más.
3. Auditar el código personalizado generado por IA antes de borrar plugins comerciales a su alrededor. Si un mu-plugin generado depende en silencio de un plugin que estás a punto de quitar, borrarlo primero tumba el sitio.
4. Fusionar herramientas solapadas en lotes de cinco a ocho, probando checkout y formularios tras cada lote, midiendo TTFB y recuento de consultas. En España eso incluye Redsys, Bizum y cualquier sync con Holded o similar que el asistente haya apilado.
5. Corregir la ruta de render en las plantillas que llevan tráfico: aplazar JS no crítico, añadir dimensiones explícitas a imágenes y fuentes, reducir addons del builder en el hero.
6. Volver a medir y fijar un presupuesto de plugins para que el siguiente cambio asistido por IA no reabra los mismos agujeros.

#Lista de medición: LCP, INP, CLS y TTFB

Sigue las cuatro juntas. Una puntuación de PageSpeed sola oculta qué métrica concreta mueve el impacto de negocio.

• LCP (Largest Contentful Paint) - objetivo por debajo de 2,5s. Mide en la plantilla real del hero, no en una página de prueba ligera.
• INP (Interaction to Next Paint) - objetivo por debajo de 200ms. Prueba en una página con formulario o filtro, donde la gente interactúa de verdad.
• CLS (Cumulative Layout Shift) - objetivo por debajo de 0,1. Prueba con banners de cookies e imágenes lazy-load presentes; son fuentes habituales de CLS en sitios hechos con IA.
• TTFB (Time to First Byte) - objetivo por debajo de ~800ms sin caché en una página estándar. Mide con curl o WebPageTest en cinco pasadas y usa la mediana, no una sola muestra.
• Consultas a base de datos por vista - sigue con Query Monitor; marca todo lo que pase de unas 120 en una página de contenido.

Mide en la home, la landing más pesada y el checkout o el contacto. Un sitio rápido en la home y lento en el checkout es un patrón habitual de builds con IA, porque las plantillas densas de builder casi nunca son las últimas que alguien midió. En campañas de Black Friday en España, ese desfase se nota primero en la página de pago con Redsys y Bizum, no en el hero de la campaña.

#Qué no hacer

• No instales otro plugin optimizador para arreglar un sitio lento causado por demasiados plugins. Así es como los sitios llegan a 40 plugins.
• No corras dos cachés de página completa “por si acaso”. Elige una y configúrala bien.
• No borres mu-plugins personalizados generados por IA antes de auditar de qué dependen. Algunos parchean en silencio un hueco que dejó otro plugin.
• No persigas una puntuación sintética 100 en PageSpeed a costa del LCP/INP/CLS real en las plantillas que generan ingresos.
• No dejes de medir checkout y contacto porque “la home está bien”. Las plantillas secundarias densas de builder suelen ser donde viven los peores números.

#Cómo se desarrolla el encargo

Paso 1 - base. Medimos LCP, INP, CLS y TTFB sin caché en plantillas representativas, más un inventario completo de plugins y base de datos.

Paso 2 - auditoría. Cada plugin se mapea a su función real; se marcan duplicados y el output del builder que bloquea el render.

Paso 3 - desmontaje por fases. Lotes de cinco a ocho plugins, desactivados, probados, medidos y luego borrados. Sin borrados masivos en producción.

Paso 4 - correcciones de ruta de render. Aplazar scripts no críticos, corregir carga de imágenes y fuentes, consolidar en una sola capa de caché.

Paso 5 - nueva medición y presupuesto fijado. Mismas plantillas, mismas herramientas, antes/después documentado, más la regla de que ningún plugin nuevo entra sin retirar o fusionar uno existente.

#Servicios relacionados y lecturas profundas

Este rescate va junto al trabajo de remediación más amplio que hacemos en sitios generados:

Lectura profunda del blog: Exceso de plugins: cuando un build con IA te deja a 40 plugins de profundidad - el caso anonimizado completo detrás de las cifras usadas arriba.

El presupuesto es individual y se acota tras la auditoría base. Contacta con nosotros con el sitio y una nota breve sobre cómo se construyó.