DevTools sigue los scripts de anuncios y mide navegaciones sin recarga
La entrega de octubre de las novedades de Chrome DevTools, con lo llegado en Chrome 153 y 154, añade a la pestaña Ads una tabla de los scripts publicitarios de la página, lleva el análisis de las navegaciones sin recarga a Insights y suma controles de ejecución y memoria al servidor MCP que usan los agentes de programación. Para una auditoría SEO, sirve para localizar el coste de los anuncios y medir el recorrido por la web, no solo la primera carga.
Chrome DevTools amplía la inspección de scripts publicitarios, incorpora el análisis de navegaciones sin recarga a Insights y añade controles para agentes, según el resumen de novedades de octubre de 2026. Para una auditoría SEO, el interés está en localizar el coste de los anuncios y revisar el rendimiento del recorrido por la web, no solo su primera carga.
El anuncio, firmado por Matthias Rohmer el 22 de septiembre de 2026, reúne mejoras que Chrome sitúa en las versiones estables Chrome 153 y Chrome 154, junto con cambios del servidor MCP, siglas de Model Context Protocol, que conecta DevTools con agentes de programación. Nuestra lectura es que conviene incorporarlas a las comprobaciones de rendimiento y depuración, sin convertir cada nueva medida en una señal de posicionamiento.
Ads permite seguir los scripts publicitarios hasta su código
La pestaña Ads de Application no parte de cero: las notas de Chrome 152 ya describían el resaltado de anuncios y un desglose de métricas por frame. El resumen de octubre destaca una tabla de scripts publicitarios del documento principal y muestra cómo abrir uno de ellos en Sources para inspeccionarlo.
El panel reúne mediciones locales relacionadas con las métricas experimentales de anuncios del Chrome User Experience Report (CrUX), ya tratadas en el SEOmanal. Las definiciones oficiales distinguen entre la presencia de anuncios en pantalla y los recursos que consumen (documentación de las métricas):
- Ad Density: proporción media del área visible, o viewport, ocupada por anuncios durante la visita, según la definición de Chrome.
- Ad Count: número medio de frames publicitarios visibles a la vez mientras el usuario recorre la página; no es un inventario de todos los anuncios cargados.
- Ad Weight: CPU: tiempo de procesador consumido por la actividad publicitaria, expresado en milisegundos en la API (guía de herramientas de CrUX).
- Ad Weight: Network: tráfico de red atribuido a los recursos publicitarios, expresado en kilobytes en la API.
Chrome también documenta el desglose de CPU y red por elementos publicitarios y el control para resaltarlos sobre la página. Como criterio de auditoría, interesa separar las preguntas: cuánto espacio ocupa la publicidad, qué recursos descarga y dónde se concentra el trabajo de ejecución.
La comparación con CrUX exige contexto: DevTools mide una sesión local, mientras que CrUX agrega experiencias reales en ventanas móviles de 28 días, según la documentación publicada el 15 de septiembre de 2026. Esa misma documentación aclara que las métricas de anuncios no forman parte de Core Web Vitals ni tienen sus categorías de evaluación.
Chrome mide los anuncios que identifica, no cualquier publicidad
Chrome identifica recursos publicitarios mediante una lista de filtros y el análisis de los scripts que solicitan recursos o crean frames; un frame marcado como anuncio conserva esa clasificación aunque después navegue a otro destino (documentación de detección). El documento principal no se etiqueta como frame publicitario, pero sus scripts y otros recursos sí pueden clasificarse como relacionados con anuncios.
Por eso, nuestra recomendación es comprobar qué está resaltando el navegador antes de interpretar el total. La guía de Natzir Turrado sobre la detección de anuncios desarrolla las diferencias entre lo que etiqueta Chrome y lo que encuentra una persona al revisar la página.
Para investigar un caso concreto, la documentación permite consultar Ad Status en Application, dentro de Frames > Document, y activar la columna Is ad-related en Network. Proponemos combinar esas vistas con la tabla de scripts cuando haya que entregar a desarrollo una incidencia concreta, en lugar de limitar el informe a «la publicidad pesa demasiado».
Insights analiza las navegaciones sin recarga
La novedad en Performance es que Insights incorpora el análisis de navegaciones suaves (soft navigations): los cambios de página que reescriben la URL «sin una recarga completa de la página», en palabras de Chrome. Live Metrics ya las medía desde Chrome 152, y los marcadores de navegación suave y de LCP en la traza estaban documentados desde Chrome 145.
Chrome define una navegación suave mediante una acción del usuario que produce un cambio visible de URL y un pintado de contenido, sin cargar un documento nuevo (documentación de Soft Navigations). La detección puede tener falsos positivos y falsos negativos: utilizar React, Vue o Angular no garantiza por sí solo que cada cambio de estado se reconozca como una navegación.
La API permite medir por navegación Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS), con matices de atribución que detalla Chrome. El LCP de una transición considera los nuevos pintados vinculados a la interacción que la provoca, por lo que su elemento puede ser distinto del que se obtiene al abrir directamente esa misma URL.
Para una auditoría, proponemos tratar como pruebas distintas la entrada directa a una ficha y la llegada desde un listado. La primera sirve para revisar la carga de acceso; la segunda, para investigar lo que ocurre durante ese recorrido, sin dar por hecho que ambas deben producir el mismo resultado.
El soporte en DevTools no confirma un cambio equivalente en los informes de campo: la documentación de Soft Navigations aún deja pendiente concretar cómo se incorporarán estas navegaciones a CrUX. Conviene mantener separadas ambas mediciones en los informes y no esperar, de momento, que CrUX o Search Console reflejen estas navegaciones.
La calibración de CPU llega al protocolo de DevTools
El anuncio incorpora Emulation.setCPUPerformanceOverride al flujo de pruebas mediante Chrome DevTools Protocol (CDP), para configurar niveles de rendimiento de CPU calibrados y facilitar pruebas reproducibles entre niveles de hardware. Para un equipo que automatiza auditorías, nuestra recomendación es registrar esa configuración junto con la versión de Chrome y las condiciones de red, caché y sesión; la calibración no debe convertirse en una promesa de resultados idénticos.
Performance también amplía la búsqueda con Ctrl+F a las pistas personalizadas creadas mediante la API de extensibilidad, incluidos los textos y propiedades de sus entradas. Puede ser útil para localizar instrumentación propia de un recorrido, como la petición de datos y la actualización de una ficha, si el equipo ya registra esos eventos.
El servidor MCP limita la ejecución del agente, no el JavaScript del sitio
El servidor MCP, cuyo uso ya se explicó en la pieza sobre Chrome DevTools para agentes, añade controles de ejecución e inspección de memoria. Su documentación precisa que --no-javascript-evaluation desactiva herramientas como evaluate_script, impide usar initScript al navegar y restringe determinados esquemas de URL (configuración del servidor).
No es un modo de navegación con todo el JavaScript de la página desactivado: el alcance documentado se refiere a las vías de ejecución que expone el servidor al agente. Para comparar contenido con y sin JavaScript, esta opción por sí sola no acredita que se haya realizado esa prueba.
El anuncio también recoge mapas de fuentes bajo demanda, consultas de instantáneas de memoria por tamaño retenido o propiedad y trazas de pila opcionales al listar mensajes de consola. En la referencia actual del repositorio, la consulta de objetos aparece como query_heapsnapshot_objects y requiere activar --memoryDebugging=true, mientras que el artículo utiliza el nombre query_heapsnapshot (referencia de herramientas, anuncio).
El anuncio menciona también la opción --allow-unrestricted-paths de la línea de comandos. Según la configuración del servidor, viene desactivada: sin ella, y si el cliente no declara directorios raíz, las herramientas que escriben archivos solo pueden hacerlo en la carpeta temporal del sistema. Activarla tiene sentido únicamente con un cliente local de confianza.
Network y Elements afinan la depuración
El resto de cambios útiles para una revisión técnica se concentra en estos paneles. La tabla recoge funciones descritas en el anuncio de Chrome, no resultados de pruebas propias.
| Panel | Cambio |
|---|---|
| Elements | Puede conservar a la vista reglas CSS que antes coincidían con el elemento seleccionado y ya no se aplican, con un indicador de inactividad y ajustes en Settings. |
| Network | Edit and resend as fetch abre Console con la llamada preparada para editarla; los local overrides bloquean rutas con %2E%2E y esquemas ajenos a HTTP y HTTPS, como data: o blob:. |
| Memory | Permite filtrar y ordenar referencias de las instantáneas por tamaño, buscar objetos por propiedades y examinar la memoria retenida por contextos de ejecución de V8. |
| Device Mode | Agrupa los perfiles por formato de dispositivo y renueva el catálogo de móviles, plegables, tabletas, equipos de escritorio y pantallas inteligentes. |
En una incidencia de carga de contenido, nuestra propuesta es usar Network para aislar la petición implicada y Elements para revisar el estado visual que queda después. Antes de reenviar una petición, conviene comprobar que no vaya a repetir una operación con efectos sobre datos reales.
La siguiente auditoría debe incluir el recorrido, no solo la entrada
Para incorporar estas mejoras sin rehacer toda la metodología, proponemos empezar con dos comprobaciones. Ambas deben guardar las condiciones de la sesión y las evidencias necesarias para repetir el diagnóstico.
- En sitios con publicidad: elegir una plantilla representativa, fijar el viewport y el estado del consentimiento, recorrerla y comprobar qué anuncios identifica Chrome; entregar a desarrollo los recursos y scripts implicados, no solo el total de consumo.
- En sitios con navegación sin recarga: grabar un recorrido real desde un listado hasta una ficha, verificar qué transiciones detecta DevTools y comparar el diagnóstico con una entrada directa a esa URL, manteniendo separados los resultados locales y los datos de campo.
