Scripts de terceros en WordPress: auditoría de rendimiento

Una web puede estar bien configurada en el servidor, usar caché y tener las imágenes optimizadas y, aun así, responder con lentitud. El problema puede encontrarse fuera de WordPress: analítica, publicidad, mapas, vídeos, chats, gestores de etiquetas, píxeles, tipografías, sistemas de consentimiento o widgets que cargan código desde otros dominios.

Estos recursos suelen incorporarse porque aportan una función concreta. El conflicto aparece cuando nadie mantiene un inventario, varios servicios hacen lo mismo o un script se ejecuta en todas las páginas aunque solo sea necesario en una. También puede ocurrir que una etiqueta siga enviando peticiones después de haber dejado de utilizar la herramienta que la creó.

Una auditoría útil no empieza eliminando scripts al azar. Empieza identificando qué se carga, quién lo necesita, cuánto cuesta y bajo qué condiciones debe ejecutarse. El objetivo es decidir con evidencias qué conservar, qué limitar, qué retrasar y qué retirar.

Índice

Qué es realmente un recurso de terceros.
Por qué puede perjudicar al rendimiento.
Crea un inventario antes de optimizar.
Mide el coste en red y en el navegador.
Bloquea peticiones de forma temporal para aislar su impacto.
Comprueba qué ocurre antes y después del consentimiento.
Decide entre eliminar, limitar, retrasar o sustituir.
Cómo aplicar los cambios en WordPress.
Valida que la optimización no rompe funciones críticas.
Convierte la auditoría en una revisión periódica.

Qué es realmente un recurso de terceros

Un recurso de terceros es cualquier archivo, marco o petición que la página obtiene desde una infraestructura ajena al dominio principal. Puede ser visible, como un vídeo incrustado o un mapa, o actuar en segundo plano, como un píxel publicitario.

En una instalación WordPress es habitual encontrar:

Herramientas de analítica y publicidad. Etiquetas de medición, conversiones, campañas y remarketing.
Gestores de etiquetas. Contenedores que pueden cargar otras etiquetas sin modificar directamente WordPress.
Vídeos, mapas y publicaciones incrustadas. Elementos que suelen utilizar iframe y descargan sus propios scripts, estilos, fuentes e imágenes.
Chats y herramientas comerciales. Widgets de soporte, reservas, captación de contactos o recomendación de productos.
Tipografías, iconos y bibliotecas. Archivos servidos desde CDN o dominios del proveedor.
Sistemas de consentimiento. Plataformas que muestran el aviso, conservan preferencias y activan o bloquean otros servicios.
Pruebas A/B y personalización. Código que decide qué variante mostrar y puede modificar el contenido después de la carga inicial.

No toda petición externa es innecesaria ni todo script de terceros es lento. El problema técnico es la pérdida de control: su código, su disponibilidad, su caché y sus cambios dependen en parte del proveedor. Además, una sola integración puede abrir conexiones adicionales hacia varios dominios que no aparecen en la configuración visible del plugin.

Por qué puede perjudicar al rendimiento

Un script no cuesta únicamente los kilobytes que muestra la columna de tamaño. El navegador tiene que resolver el dominio, negociar la conexión, descargar el archivo, analizarlo, compilarlo y ejecutarlo. Durante parte de ese trabajo puede competir con la renderización de la página o con una interacción del usuario.

El impacto puede aparecer de varias formas:

Retraso del contenido principal. Un recurso síncrono o una cadena de dependencias puede competir con la imagen, el texto o la fuente que determinan el LCP.
Bloqueo del hilo principal. El JavaScript pesado puede retrasar clics, menús, filtros o formularios y empeorar el INP.
Saltos visuales. Un banner, un anuncio o un widget insertado tarde puede desplazar contenido y afectar al CLS.
Más conexiones y peticiones. Cada origen nuevo añade trabajo de DNS, conexión y TLS antes de descargar recursos.
Comportamiento variable. Una etiqueta puede activarse solo después de aceptar cookies, en determinadas páginas o ante campañas concretas.
Dependencia externa. Un proveedor lento o inaccesible puede dejar peticiones pendientes y afectar a una función importante.

Google documenta que los scripts síncronos pueden retrasar la construcción del DOM y la renderización. También recomienda identificar el coste de terceros con Lighthouse y Chrome DevTools antes de decidir cómo cargarlos.[1][2]

Si el problema apareció después de añadir una extensión, conviene separar primero el trabajo de PHP y base de datos del que realiza el navegador. La guía sobre WordPress lento tras instalar un plugin explica cómo localizar ese límite antes de atribuir toda la lentitud a una única causa.

Crea un inventario antes de optimizar

La primera entrega de una auditoría no debería ser una lista de plugins para borrar, sino un inventario de servicios externos. Para cada dominio o herramienta conviene registrar:

Proveedor y finalidad. Qué servicio es y qué función aporta.
Responsable interno. Quién necesita esa integración y puede confirmar si sigue siendo necesaria.
Origen técnico. Qué plugin, tema, fragmento, contenedor o bloque la carga.
Páginas afectadas. Si aparece en todo el sitio o únicamente en plantillas concretas.
Condición de activación. Si carga al abrir la página, al desplazarse, al interactuar o después del consentimiento.
Dependencias. Qué funcionalidad puede dejar de funcionar si se bloquea.
Datos y almacenamiento. Si utiliza cookies, almacenamiento local, identificadores o envía datos a otro dominio.
Fecha de revisión. Cuándo se confirmó por última vez que seguía siendo necesaria.

Abre Chrome DevTools, entra en Network, desactiva temporalmente la caché durante la medición y recarga la página. El panel permite filtrar las peticiones de terceros, revisar el dominio, el iniciador, el tipo de recurso, el tamaño transferido y el tiempo empleado.[3]

Haz la prueba en varias situaciones:

Con una visita nueva y sin sesión iniciada.
Después de rechazar las finalidades no necesarias.
Después de aceptar las categorías disponibles.
En una página de contenido, una landing y un proceso crítico.
En móvil o con limitación de red y CPU.
Con el registro de red conservado durante redirecciones o navegación entre páginas.

Una única captura de la portada no representa necesariamente todo el sitio. WooCommerce, formularios, reproductores o herramientas de reserva pueden cargar recursos solo en las páginas donde se utilizan.

También hay que revisar el gestor de etiquetas. El HTML puede mostrar únicamente el contenedor principal, mientras que la interfaz del gestor revela etiquetas, activadores y variables que no se ven en WordPress. Inventariar solo plugins dejaría fuera esa capa.

Mide el coste en red y en el navegador

La medición debe separar transferencia y ejecución. Un archivo pequeño puede consumir mucho tiempo de CPU, mientras que un recurso grande descargado después de una interacción puede no afectar a la carga inicial.

Utiliza Lighthouse como punto de partida

Lighthouse puede señalar proveedores en apartados relacionados con uso de terceros, tiempo de ejecución de JavaScript y carga total de red. Sirve para localizar candidatos, pero no para dictar automáticamente qué debe eliminarse.

Realiza varias mediciones en condiciones equivalentes y compara valores centrales, no el resultado más favorable. Los servicios externos pueden responder de forma distinta entre cargas y algunos cambian los recursos que sirven.

Revisa Performance y las tareas largas

El panel Performance permite comprobar cuándo se ejecuta JavaScript y si mantiene ocupado el hilo principal. Relaciona cada tarea con el momento en que aparece el contenido o se procesa una interacción.

Las comprobaciones útiles son:

Contenido principal. Comprueba si el script se ejecuta antes de que aparezca.
Consentimiento. Revisa si se concentra mucho trabajo justo después de aceptar cookies.
Carga anticipada. Confirma si el chat o el mapa se inicializan aunque el usuario nunca llegue a verlos.
Interacciones. Observa si una acción sencilla desencadena varias etiquetas y peticiones.
Alcance. Comprueba si el recurso se repite en páginas donde no aporta ninguna función.

Comprueba el código que realmente se utiliza

El panel Coverage muestra bytes utilizados y no utilizados de JavaScript y CSS durante la sesión registrada.[4] No significa que todo lo marcado como no utilizado pueda borrarse: una función puede activarse al abrir un menú, enviar un formulario o completar una compra. Hay que recorrer las interacciones importantes antes de interpretar el informe.

Relaciona el hallazgo con métricas reales

LCP, INP y CLS ayudan a describir la experiencia, pero no sustituyen al diagnóstico. Una guía general sobre Core Web Vitals en WordPress permite entender qué mide cada indicador. En esta auditoría interesa relacionar una petición concreta con el retraso, el bloqueo o el movimiento que provoca.

Bloquea peticiones de forma temporal para aislar su impacto

Cuando ya existe una lista de candidatos, Chrome DevTools permite bloquear o ralentizar una URL o un dominio mediante Request conditions.[5] Esta prueba no modifica WordPress ni elimina el servicio: solo cambia el comportamiento del navegador mientras DevTools permanece abierto.

El procedimiento puede ser:

Medir la página con el recurso activo.
Bloquear el dominio o patrón sospechoso.
Recargar en las mismas condiciones.
Repetir la medición varias veces.
Comparar red, ejecución y comportamiento visual.
Probar las funciones que dependían del servicio.

Si al bloquear un dominio mejora claramente la respuesta, todavía no se ha demostrado que deba eliminarse. La prueba confirma que tiene un coste; falta decidir si ese coste está justificado y si puede reducirse sin perder la función.

También conviene comprobar el fallo contrario: ralentizar el proveedor en vez de bloquearlo. Una integración puede funcionar bien en una prueba normal y dejar un formulario esperando cuando la API externa tarda varios segundos.

No utilices esta técnica como sustituto de una prueba funcional. Un píxel puede desaparecer sin cambios visibles, pero un sistema antifraude, una pasarela o un componente de consentimiento pueden afectar a procesos críticos.

Comprueba qué ocurre antes y después del consentimiento

Rendimiento y privacidad se cruzan en el momento de activar etiquetas. La revisión técnica debe comprobar qué peticiones aparecen antes de que el visitante elija, cuáles se activan al aceptar y cuáles siguen presentes al rechazar.

La guía de la Agencia Española de Protección de Datos distingue entre cookies propias y de terceros y establece obligaciones de información y consentimiento para las finalidades no exceptuadas.[6] La AEPD también contempla que determinadas herramientas de medición de audiencia podrían quedar exentas bajo condiciones estrictas, entre ellas una finalidad limitada a la medición, datos estadísticos anónimos y ausencia de reutilización o transmisión incompatible.[7]

Esto no significa que cualquier analítica esté exenta ni que una auditoría técnica sustituya al asesoramiento jurídico. Sí permite formular comprobaciones concretas:

Carga previa. Comprueba si se envían peticiones publicitarias antes de aceptar.
Rechazo. Confirma que las categorías no necesarias permanecen bloqueadas.
Cambio de preferencias. Verifica que la nueva selección modifica realmente las peticiones.
Transparencia. Compara el listado del aviso con los proveedores observados.
Gestor de etiquetas. Comprueba que respeta el estado de consentimiento.
Contenido incrustado. Revisa si los iframes o widgets establecen identificadores antes de interactuar.

Un sistema de consentimiento también puede perjudicar al rendimiento. Web.dev documenta que estos avisos pueden afectar a LCP, INP y CLS, especialmente cuando al pulsar Aceptar se inyectan muchos scripts a la vez.[8] Por eso hay que medir tanto la visita inicial como la interacción con el aviso.

Decide entre eliminar, limitar, retrasar o sustituir

Después de medir, cada integración debería terminar en una decisión documentada.

Eliminar

Retira el servicio cuando ya no tenga responsable, duplique otra herramienta, pertenezca a una campaña finalizada o no aporte datos utilizados. El mejor script para el rendimiento y la privacidad es el que no necesita cargarse.

Limitar a las páginas necesarias

Un mapa de contacto no debería aparecer en todas las entradas. Lo mismo ocurre con widgets de reservas, scripts de comparación, pasarelas o recursos de WooCommerce. La carga condicional reduce peticiones sin renunciar a la función.

Retrasar sin romper dependencias

defer permite descargar un script mientras el navegador continúa procesando el HTML y ejecutarlo después de construir el documento. async lo ejecuta cuando termina la descarga y no garantiza el orden respecto a otros scripts. La elección depende de sus dependencias; añadir atributos indiscriminadamente puede romper integraciones.

Cargar bajo interacción

Un vídeo, un mapa o un chat pueden mostrarse inicialmente como una vista previa ligera y cargar el recurso completo cuando el usuario decide abrirlo. Los iframe situados fuera de la zona visible también pueden utilizar carga diferida cuando la funcionalidad lo permite.

Conectar antes solo cuando sea necesario

preconnect puede anticipar DNS, TCP y TLS para un origen externo importante. No debe añadirse a todos los dominios: cada conexión también consume recursos. Úsalo para unos pocos orígenes imprescindibles y medidos.

Sustituir o alojar localmente con criterio

Una alternativa más ligera puede reducir peticiones o ejecución. Alojar localmente un recurso puede mejorar el control de caché, pero también traslada la responsabilidad de actualizaciones, licencias y seguridad. Además, servir el archivo desde el propio dominio no elimina por sí solo sus implicaciones de tratamiento de datos.

Cómo aplicar los cambios en WordPress

La solución depende de dónde se origine el recurso.

Scripts añadidos por el tema o un desarrollo propio

WordPress permite registrar dependencias y estrategias de carga mediante wp_enqueue_script(). Desde WordPress 6.3, el argumento de configuración admite estrategias como defer y async, y WordPress considera el árbol de dependencias al determinar la estrategia finalmente aplicable.[9]

wp_enqueue_script(
    'mi-integracion',
    get_theme_file_uri( '/assets/js/integracion.js' ),
    array(),
    '1.0.0',
    array(
        'strategy'  => 'defer',
        'in_footer' => true,
    )
);

Este ejemplo no debe copiarse sin revisar la integración. Si otro script necesita que se ejecute antes, cambiar el orden puede provocar errores. Aplica modificaciones en un plugin propio o tema hijo, pruébalas en staging y conserva un mecanismo de reversión.

Recursos cargados por plugins

Primero revisa si el plugin permite desactivar módulos o limitar sus recursos por tipo de contenido. Si no existe esa opción, puede ser necesario retirar selectivamente el handle registrado, pero solo después de identificar sus dependencias y probar las funciones afectadas.

Etiquetas gestionadas fuera de WordPress

Los cambios deben realizarse en el gestor de etiquetas, la plataforma de consentimiento o el panel del proveedor. Desactivar un plugin no elimina una etiqueta que sigue publicada en el contenedor externo.

Vídeos, mapas y widgets

Valora una carga diferida, una vista previa que requiera interacción o una alternativa estática. Reserva las dimensiones del contenedor para evitar movimientos cuando se active el contenido.

Plugins de optimización

Las funciones para retrasar JavaScript pueden ayudar, pero no sustituyen al inventario. Una exclusión mal definida puede romper menús, pagos, analítica o consentimiento. Documenta qué recursos se retrasan y por qué.

Valida que la optimización no rompe funciones críticas

Una mejora de PageSpeed no compensa una compra, reserva o medición rota. Después de cada cambio, repite tanto la medición como las pruebas funcionales.

Comprueba como mínimo:

La Navegación, los menús y los elementos interactivos.
Los Formularios, mensajes de confirmación y correos asociados.
El Carrito, el pago y las pasarelas disponibles.
Los Vídeos, mapas, chats y widgets cargados bajo interacción.
El Aviso de cookies, el rechazo, la aceptación y la modificación posterior.
Las Conversiones y eventos que el negocio utiliza realmente.
La Consola del navegador y las peticiones fallidas.
La Experiencia sin sesión y en un dispositivo móvil.

Mantén las condiciones comparables y realiza varias pasadas. PageSpeed Insights y Lighthouse son útiles, pero una auditoría completa también necesita pruebas reales de navegación y, cuando existe suficiente tráfico, datos de campo.

Si el diagnóstico revela varias capas de trabajo —tema, plugins, etiquetas y servidor—, una auditoría de optimización web y WPO permite priorizar cambios por impacto y riesgo en lugar de activar opciones de optimización sin contexto.

Convierte la auditoría en una revisión periódica

El inventario pierde valor si no se mantiene. Los departamentos de marketing cambian campañas, los proveedores actualizan sus bibliotecas y los plugins incorporan nuevas integraciones. Una web puede acumular terceros sin que exista un cambio visible en WordPress.

Incluye esta revisión después de:

Instalar o sustituir un plugin con funciones externas.
Publicar un nuevo contenedor del gestor de etiquetas.
Cambiar la plataforma de consentimiento.
Incorporar publicidad, vídeo, mapas, chat o personalización.
Detectar un empeoramiento de Core Web Vitals.
Finalizar una campaña o dejar de utilizar una herramienta.
Cambiar de agencia o de responsable de analítica.

Una revisión periódica debería responder cuatro preguntas: qué se carga, por qué se carga, quién lo necesita y qué ocurriría si dejase de estar disponible.

Conclusión

Los scripts de terceros no se corrigen instalando otro plugin de caché ni retrasando todo el JavaScript con una única opción. Primero hay que inventariar, medir y reproducir el impacto. Después se decide si cada integración debe eliminarse, limitarse a determinadas páginas, cargarse más tarde o sustituirse.

El resultado no es solo una web más rápida. También es una arquitectura más comprensible, con menos dependencias desconocidas y una relación más clara entre las herramientas utilizadas, el consentimiento y las funciones que sostienen el negocio.

Optimizar consiste en recuperar control sobre lo que el navegador descarga y ejecuta, no únicamente en mejorar una puntuación.

Auditoría de terceros en WordPress: cómo detectar scripts que perjudican el rendimiento y la privacidad