Compatibilidad con plugins de caché

Un optimizador de JavaScript que retrasa, combina o reescribe en async el script de tracking de Beaconry hará que tu pageview deje de dispararse en silencio. Beaconry se autoexcluye de los cuatro optimizadores que exponen un opt-out documentado (WP Rocket, LiteSpeed, SG Optimizer, Cloudflare Rocket Loader), así que en la mayoría de los stacks no hay nada que configurar. Dos funciones de optimización no tienen marcador a nivel de código y necesitan una casilla cada una. El page caching simple siempre es seguro.

Tiempo de lectura: ~6 minÚltima actualización: 2026-06-08

Por qué la optimización de JS rompe el tracking

Beaconry carga dos piezas en el front-end: el archivo nl-data.js con defer (más el script del banner de consentimiento) y un pequeño bloque inline que llama a NLData.init(). Ese bloque inline es lo que realmente dispara el pageview, y lleva el nonce de seguridad por petición que el endpoint REST comprueba. Tres clases de optimización de "velocidad" interfieren con eso:

Delay JavaScript Execution (WP Rocket Delay-JS, LiteSpeed Delay, el defer de SG Optimizer). Estas retienen todo el JavaScript hasta la primera interacción del usuario (scroll, tap, movimiento del ratón). Un visitante que lee una página y se va sin interactuar nunca ejecuta NLData.init(), así que el pageview, y cada evento que depende de él, nunca se dispara. Esta es de lejos la más dañina, porque parece que Beaconry pierde tráfico "al azar".
Combine JavaScript. Fusionar la init inline en un gran bundle puede reordenarla respecto al archivo con defer del que depende, de modo que NLData se llama antes de que exista.
Reescritura en async / Rocket Loader. Cloudflare Rocket Loader reescribe las etiquetas de script para que se carguen de forma asíncrona a través de su propio loader, lo que de nuevo rompe el orden de carga entre el archivo y la init inline.

La minificación simple (eliminación de espacios en blanco) no rompe el orden de ejecución y es segura. El problema siempre es defer/delay, combine o reescritura en async, no minify.

Las dos superficies, y por qué necesitan arreglos distintos

Este es el detalle que hace tropezar a las listas de exclusión hechas a mano. WordPress emite Beaconry como dos etiquetas separadas: la externa <script src="...nl-data.js"> y un <script> inline aparte (el bloque NLData.init()). El filtro estándar de WordPress para etiquetar un script, script_loader_tag, solo reescribe siempre la etiqueta del archivo externo. No puede tocar el bloque inline. Así que proteger solo el archivo no basta, la init inline también tiene que excluirse por contenido, mediante un mecanismo distinto. Beaconry cubre ambas. Una exclusión manual que solo liste la URL del archivo seguiría perdiendo el pageview.

Qué autoexcluye Beaconry (sin configuración)

En cada carga del front-end, Beaconry registra filtros de exclusión y atributos de etiqueta para los optimizadores que publican un opt-out documentado a nivel de código. Cada marcador de abajo fue verificado palabra por palabra contra la propia documentación de ese proveedor, no contra un blog o un hilo de foro. Si usas uno de estos plugins, no tienes que configurar nada.

Optimizador	Función cubierta	Cómo se excluye Beaconry	Superficie
Cloudflare	Rocket Loader	`data-cfasync="false"` en la etiqueta	Archivo externo
WP Rocket	Delay JavaScript Execution	atributo `nowprocket` en la etiqueta	Archivo externo
WP Rocket	Defer / Delay (inline)	filtro `rocket_defer_inline_exclusions`	Init inline
LiteSpeed Cache	Combine + Minify	filtro `litespeed_optimize_js_excludes`	Handle de script
LiteSpeed Cache	Defer + Delay	filtro `litespeed_optm_js_defer_exc`	Handle de script
LiteSpeed Cache	Guest Mode JS	filtro `litespeed_optm_gm_js_exc`	Handle de script
SG Optimizer	Async / Defer	filtro `sgo_js_async_exclude`	Handle de script
SG Optimizer	Minify	filtro `sgo_js_minify_exclude`	Handle de script
SG Optimizer	Combine (archivo)	filtro `sgo_javascript_combine_exclude`	Handle de script
SG Optimizer	Combine (inline)	filtro `sgo_javascript_combine_excluded_inline_content`	Init inline

Algunas notas de implementación que vale la pena conocer:

Cloudflare requiere que data-cfasync="false" aparezca antes del atributo src, así que Beaconry lo inyecta al inicio de la etiqueta. El atributo se añade de forma idempotente, si otro plugin ya marcó la etiqueta, Beaconry la deja en paz.
LiteSpeed y SG Optimizer funcionan a partir de los handles de script de WordPress, así que Beaconry añade sus dos handles (bcnr-nl-data y bcnr-nl-data-gate) a cada lista. Esa única lista de handles cubre combine, minify, defer, delay y (en LiteSpeed) Guest Mode de una sola vez.
La init inline se excluye mediante una subcadena de contenido estable (NLData.init) en los dos optimizadores que exponen un filtro de exclusión inline (WP Rocket y SG Optimizer), que es lo que mantiene el bloque que dispara el pageview fuera de defer y combine.

Dos casos manuales (una casilla cada uno)

Dos funciones de optimización realmente no tienen un opt-out documentado a nivel de código, así que Beaconry no puede aplicarlas automáticamente. Si activas cualquiera de las dos, añade la exclusión a mano en la interfaz de administración del plugin. Ambas son rápidas.

WP Rocket: Combine JavaScript

El Combine JavaScript de WP Rocket no tiene filtro ni atributo para excluir un archivo o un snippet inline, solo los campos de la interfaz de administración. En WP Rocket → File Optimization, añade dos entradas:

Excluded JavaScript Files: añade nl-data.js (el fragmento de ruta basta, coincide con el archivo empaquetado de Beaconry).
Excluded Inline JavaScript: añade NLData.init para que el bloque inline que dispara el pageview se mantenga fuera del bundle combinado.

Contexto, para que juzgues si siquiera lo necesitas: Combine JS es legacy y está desactivado por defecto en sitios HTTP/2 (combinar perjudica más de lo que ayuda sobre una conexión multiplexada). La función de WP Rocket que de verdad rompe el tracking en la práctica es Delay JavaScript Execution, y esa ya está autoexcluida para ti mediante el atributo nowprocket. Así que, a menos que hayas activado Combine a propósito, aquí no hay nada que hacer.

Cloudflare: Auto-Minify y combine de APO

El Auto-Minify legacy de Cloudflare y el combine de JS que viene con APO son toggles del panel a nivel de zona (Speed → Optimization) sin marcador de origen por script, así que un atributo del lado del origen como data-cfasync no puede alcanzarlos. La buena noticia: minify por sí solo no rompe el orden de ejecución, solo elimina espacios en blanco, así que es seguro dejarlo activado. El único optimizador de JS de Cloudflare que reordena la ejecución es Rocket Loader, y Rocket Loader sí está autoexcluido mediante data-cfasync="false". En resumen: mantén Rocket Loader desactivado (o confía en la autoexclusión de Beaconry) y puedes dejar Auto-Minify activado sin afectar al tracking. No hace falta ninguna casilla manual para Cloudflare, este caso está aquí para que no salgas a cazar un problema que no existe.

El page caching simple siempre es seguro

El page caching (servir una copia HTML almacenada de la página) es algo distinto de la optimización de JavaScript, y no necesita ninguna exclusión. WP Super Cache, la capa de page-cache de W3 Total Cache o WP Fastest Cache, el cache HTML de borde de Cloudflare, todo esto es seguro con Beaconry de fábrica.

Lo único que podría haberse roto con HTML cacheado es el nonce de seguridad. Cada página incrusta un nonce de WordPress de vida corta en la config inline, el endpoint REST rechaza los eventos cuyo nonce ha caducado. Los nonces de WordPress rotan aproximadamente cada 12 horas y siguen siendo válidos unas 24, así que una página servida desde caché (o una pestaña dejada abierta toda la noche) podría acabar llevando un nonce que el endpoint rechaza, y descartar en silencio cada evento. Beaconry cierra esa brecha en el lado del cliente:

Antes de enviar un evento, nl-data.js comprueba cuánto tiempo lleva viva la página. Si tiene más de 6 horas, obtiene un nonce fresco de una ruta dedicada /wp-json/beaconry/v1/nonce (con las propias cookies del visitante, para que el nuevo nonce coincida con su sesión) y lo usa para el envío.
Esa ruta de nonce está marcada como no cacheable, tanto con una cabecera no-store como con una señal explícita de no-cache de LiteSpeed, de modo que ningún proxy ni plugin de caché pueda congelar un nonce a punto de caducar y devolverlo.
Si el fetch de refresco falla por cualquier motivo, recurre al nonce existente en lugar de bloquear el evento. La propia tolerancia de validez de 12 a 24 horas de WordPress cubre la brecha, que abarca con holgura los TTL de caché típicos.

Como esto es independiente del proveedor y se ejecuta en el navegador, funciona igual sin importar qué plugin de page-cache (si lo hay) esté delante del sitio. Una página abierta mucho tiempo, una página cacheada obsoleta o una sesión de invitado rotada, todas siguen trackeando.

Guía rápida de decisión

Tu stack	Qué hacer
WP Rocket, Delay-JS activado (por defecto)	Nada. Autoexcluido.
WP Rocket, Combine JS activado	Añade `nl-data.js` + `NLData.init` en File Optimization (los dos campos manuales de arriba).
LiteSpeed Cache (cualquier optimización de JS)	Nada. Las exclusiones por handle cubren combine, minify, defer, delay, Guest Mode.
SG Optimizer (cualquier optimización de JS)	Nada. Las exclusiones por handle + inline cubren async, minify, combine.
Cloudflare Rocket Loader	Nada. Autoexcluido mediante `data-cfasync="false"`.
Cloudflare Auto-Minify / minify de APO	Nada. Minify no rompe el orden de ejecución.
Page caching de cualquier tipo	Nada. El refresco de nonce del lado del cliente mantiene las páginas cacheadas trackeando.
Otro optimizador con combine de JS agresivo	Excluye `nl-data.js` y el snippet inline `NLData.init` de su optimización de JS. El modo solo page-cache siempre es seguro.

Cómo confirmar que funciona

La comprobación más rápida es el Beaconry Live Dashboard: carga una página en el front-end (como visitante deslogueado, ya que los administradores logueados están excluidos del tracking por defecto), luego observa el panel Live-Conversions a la espera del pageview. Si llegan eventos, la optimización no interfiere. Si no aparece nada en un sitio con una de las funciones de delay/combine activadas, abre DevTools y confirma que el bloque inline NLData.init realmente se ejecutó, un optimizador de Delay-JS que aún lo retiene es el culpable habitual. La guía de troubleshooting recorre el resto.

← Adblock-immune por construcción Troubleshooting →