Introduccion
Google publicó dos cambios consecutivos en Google Publisher Tag que merecen una revisión conjunta. Durante la semana del 31 de agosto, GPT comenzó a solicitar pubads_impl.js con prioridad alta. Además, desde el 8 de septiembre de 2026 actualizará automáticamente los slots que estaban activamente visibles cuando una persona vuelva a la página mediante la caché de navegación atrás/adelante del navegador.
Ninguno de los dos cambios exige una migración general. Sí cambian supuestos habituales sobre el orden de carga y sobre cuándo puede producirse una nueva impresión, por lo que conviene verificar la implementación real antes de interpretar una variación de latencia, requests o revenue.
En síntesis
- GPT ahora asigna prioridad alta a la descarga dinámica de pubads_impl.js, salvo que el publisher indique otra prioridad en el loader de gpt.js.
- A partir del 8 de septiembre, volver a una página mediante bfcache puede refrescar automáticamente slots que estaban activamente visibles.
- El control AutoRefreshConfig permite desactivar ese comportamiento cuando la política de refresh o la lógica de targeting del sitio requieren manejo propio.
- La validación debería mirar requests duplicados, targeting vigente, viewability, latencia y consistencia de medición; no solo el total de impresiones.
Qué cambió en la prioridad de carga
GPT ahora agrega fetchpriority="high" al solicitar dinámicamente pubads_impl.js. Esa señal le pide al navegador que priorice la biblioteca central dentro de su planificación de red y busca reducir la latencia publicitaria en la ruta crítica.
El comportamiento sigue siendo configurable. Si el loader de gpt.js declara fetchpriority="low" o fetchpriority="auto", el script interno hereda ese valor. Esto permite conservar una decisión de performance explícita en sitios donde el contenido editorial debe competir menos con la carga publicitaria.
Qué cambia cuando una página vuelve desde bfcache
La bfcache puede restaurar una página completa al navegar hacia atrás o hacia adelante, sin reconstruirla como una carga tradicional. Desde el 8 de septiembre, GPT refrescará automáticamente los slots que estaban activamente visibles antes de esa restauración.
Para un publisher, esto puede recuperar oportunidades de impresión que antes quedaban congeladas al volver a la página. También incorpora una nueva ruta de refresh que debe convivir con cualquier lógica propia basada en tiempo, visibilidad, navegación interna o eventos de la aplicación.
Qué revisar antes de dejar el comportamiento por defecto
El punto principal no es decidir si el cambio es bueno o malo en abstracto, sino comprobar que no duplica una automatización existente y que conserva el estado correcto de cada slot.
- Reproducir navegación hacia otra página y regreso con los controles atrás y adelante del navegador.
- Confirmar que cada slot visible genera como máximo el refresh esperado.
- Verificar si las key-values deben recalcularse antes de una nueva solicitud.
- Separar en la medición los retornos por bfcache de una carga de página convencional.
- Comparar latencia publicitaria, viewability, Core Web Vitals e impresiones antes y después del cambio.
Cuándo considerar un opt-out
Desactivar el refresh de bfcache puede tener sentido cuando el sitio ya administra esa transición, cuando una regla comercial limita la frecuencia o cuando el targeting debe actualizarse de forma obligatoria antes de cada request. GPT expone esa decisión mediante AutoRefreshConfig.backForwardCache.
Un opt-out no debería ser automático: primero conviene observar el comportamiento en un entorno controlado y documentar la razón. La configuración más simple es la que evita requests inesperados sin renunciar a una oportunidad válida de monetización.
Lectura de Pi
Estos cambios muestran por qué una integración de GPT no termina al insertar el loader. El navegador, la navegación y la política de refresh forman parte del sistema publicitario. Cuando cambia uno de esos componentes, el trabajo útil es traducir la nota de versión en una prueba pequeña, observable y repetible.
La recomendación operativa es registrar un baseline, probar el regreso por bfcache y revisar la secuencia de requests antes de modificar la configuración. Una mejora declarada por la plataforma no reemplaza la evidencia de la implementación propia.
Fuentes
La información factual de esta nota se verificó en las siguientes fuentes primarias.
- Google Publisher Tag release notes Google for Developers · 2026-08-31
Guias tecnicas relacionadas
Lecturas relacionadas
Preguntas frecuentes
GPT va a refrescar todos los slots al volver con el botón Atrás?
La nota de Google especifica los slots que estaban activamente visibles al restaurarse la página desde bfcache. La implementación debe probarse en el sitio real porque el resultado depende de la navegación, la elegibilidad para bfcache y el estado de los slots.
Se puede desactivar el refresh automático por bfcache?
Sí. Google documenta la propiedad AutoRefreshConfig.backForwardCache para controlar ese comportamiento. Conviene desactivarlo solo cuando exista una política propia o un conflicto comprobado.
fetchpriority=high garantiza más revenue?
No. Es una señal de prioridad de red que puede reducir latencia de carga publicitaria, pero el impacto final depende del sitio, la competencia por recursos, la demanda y la medición. Debe validarse con datos propios.