Lo que vi en Google I/O 2026: Chrome y la plataforma web

Lo que vi en Google I/O 2026: Chrome y la plataforma web
15 min read

Este año pude ir nuevamente a Google I/O 2026, y si bien los keynotes se llevan los títulos principales (Gemini 3.5 y Omni, novedades de antigravity y AI Studio, los cambios de google search y mucho más), lo que siempre me gusta destacar son las que que surgen en la carpa de Chrome, donde se están las novedades de la plataforma web. Así que este post no es un análisis exhaustivo de cada API: es más bien un resumen de lo que vi en vivo, enfocado en lo que nos toca como developers web, con algunas de las fotos que saqué de las slides.

Lo que sigue sale principalmente de dos charlas que vi en vivo: What's new in Chrome de Paul Kinlan y What's new in Web UI de Una Kravets y Bramus Van Damme. Sumo también la sesión virtual de HTML-in-Canvas de Thomas Nattestad, que vi después online porque me parece super interesante el tema.

El hilo conductor: la agentic web

Si tuviera que resumir el tono del evento en una frase, sería esa: la web dejando de ser un medio donde el usuario navega y hace, para sumar agentes a los que delegamos tareas. Kinlan lo planteó como un cambio comparable al salto a mobile, pero mucho más rápido. Y lo interesante es que, abajo de ese relato, lo que se pide es algo bastante viejo: volver a comprometerse con HTML semántico y accesibilidad, porque es lo que permite que un agente (y cualquier herramienta) entienda qué hace tu sitio.

De ahí salen las dos piezas que más me interesaron de la primera charla: WebMCP, para que los sitios participen de ese ecosistema, y un par de herramientas para que nuestros coding agents construyan mejor.

WebMCP: tu sitio como un set de tools

La idea es que un sitio exponga tools estructuradas —funciones JavaScript o formularios HTML— para que un agente que corre en el browser las invoque, en vez de tener que leer screenshots y simular clicks. La gran diferencia con un MCP server tradicional es que acá no levantás nada aparte: la pestaña abierta del usuario es el server, y reutiliza la sesión, las cookies y el DOM que ya existen.

Slide de la charla mostrando un diagrama de WebMCP: un sitio expone tools find(item), add(item) y buy(item), y un agente las invoca a partir del pedido del usuario "Find me size 10 shoes and add them to my cart"

En el ejemplo que mostraron, un e-commerce expone tools como find, add y buy, y el agente las encadena para cumplir un pedido en lenguaje natural ("buscame zapatillas talle 10 y agregalas al carrito"), con un humano en el loop para confirmar las acciones sensibles. Lo que me gustó es que no inventa una capa nueva: para la versión declarativa, le agregás atributos a un <form> que ya tenés.

Slide con código de WebMCP declarativo: un form con atributos toolname, tooldescription y toolparamdescription sobre los inputs

Ese tooldescription en el form, y los toolparamdescription en cada campo, son toda la API que necesitás para la vía declarativa. Si preferís código, está la imperativa con navigator.modelContext.registerTool({ name, description, inputSchema }). Le dediqué un post entero a WebMCP, así que no me extiendo, pero la parte que no podés saltearte es el modelo de permisos: tratá cada tool como una API pública y validá los parámetros del lado del sitio, porque el input lo manda un agente que puede estar comprometido (hola, prompt injection).

Estado: origin trial. Kinlan dijo que aterriza en Chrome 149 (~2 de junio de 2026), y mostraron testing con Expedia, Booking.com, Shopify, Etsy, Instacart y varios más. Todavía es experimental, el objetivo del origin trial siempre es juntar feedback.

Herramientas para construir mejor (con agentes)

El otro frente de la charla fue cómo construimos. Una problematica habitual es el avance continuo de la web comparado a los modelos: Chrome se actualiza cada cuatro semanas, pero los modelos están entrenados con una foto de la web de hace un año, así que generan HTML y CSS con patrones relativamente viejos. Dos respuestas a eso:

Modern Web Guidance es un skills pack evergreen, mantenido por el equipo de Chrome, que le inyecta a tu herramienta el conocimiento de la plataforma moderna: skills de performance, identidad y seguridad, más de 100 casos de uso comunes, y todo baseline-aware (cuando una feature no es baseline, te da el fallback en vez de usarla a ciegas). Se instala con un comando universal que anda en cualquier IDE o CLI que soporte skills:

npx modern-web-guidance install

Chrome DevTools for Agents es lo que les faltaba a los coding tools: visibilidad real de qué pasa dentro del browser. Es un MCP server, así que lo instalás como cualquier otro y le pedís cosas tipo "corré un análisis de performance completo de developer.chrome.com". Con eso el agente accede a console logs, tráfico de red, memory traces y el árbol de accesibilidad, y puede hacer profiles, heap snapshots y auditorías de Lighthouse.

Slide "We keep evolving" de Chrome DevTools for Agents con seis features: soporte de Skills/CLI/TypeScript API, conectarse a una instancia de Chrome corriendo, workflows multi-agente, auditorías de Lighthouse, slim mode y detección de elementos y requests

Lo fueron ampliando bastante: Skills propias, una CLI y una API de TypeScript para meterlo en CI, conexión a una instancia de Chrome ya abierta (así el agente sigue desde donde estabas) e incluso a varias a la vez para flujos multi-agente. Para resumir la idea: Modern Web Guidance te ayuda a escribir bien, y DevTools for Agents le da al agente con qué verificar lo que escribió.

IA on-device: la Prompt API ya disponible

La novedad más concreta para quienes venimos jugando con IA en el browser: la Prompt API (built-in AI con Gemini Nano) quedó estable en Chrome 148. Dejó de estar detrás de un flag y ahora ya esta disponible, con tres cosas que valen: es multimodal (le pasás imágenes), soporta salida JSON estructurada (le pedís un esquema y respeta la forma) y sumó idiomas, pasando de solo inglés a francés, alemán, japonés y español.

Ya hay partners que la llevaron a producción como progressive enhancement —Trip.com, Drupal, Temu—, siempre con el patrón de "si la API está, aparece la feature; si no, no pasa nada".

Slide "Prompt API Roadmap": alinearse a la familia de modelos Gemma e introducir function calling

Y lo que viene me parece lo más interesante: alinear la API a la familia de modelos Gemma e introducir function calling nativo, que es lo que habilita agentes client-side autónomos corriendo dentro del browser. La lógica de fondo sigue siendo la de las Task APIs: para tareas acotadas, un modelo chico y afinado antes que prender el general completo.

What's new in Web UI: CSS que se come al JavaScript

Las charlas de Web UI siempre me gustan mucho. Una y Bramus la ordenaron alrededor de cinco principios de UX —respetar las preferencias del usuario, interacciones naturales, navegación guiada, maximizar contenido y reducir ruido, y adaptarse al form factor— y la usaron para mostrar un montón de CSS nuevo. Aqui solo dejo un resumen, recomiendo mucho ver el video de la charla para ver mas novedades.

Una Kravets y Bramus Van Damme en el escenario de Chrome, con una slide que dice "meta name=text-scale"

Respetar preferencias. Tres que hacen mucho más fácil adaptarse a lo que el usuario ya configuró:

  • contrast-color(): le pasás un color de fondo y te devuelve blanco o negro según cuál contraste mejor (algoritmo de WCAG 2). Adiós a hardcodear el color de texto sobre un fondo dinámico. Shippeó vía Interop 2026, así que es baseline newly available.
  • light-dark(): dos valores de color en una sola declaración (uno para claro, otro para oscuro). Un cambio reciente la extiende para aceptar imágenes, y eso llega en Chrome 150.
  • El meta text-scale (Chrome 146): más del 30% de los usuarios en Android e iOS cambió el tamaño de fuente del sistema. Con este meta le decís al browser que tu sitio banca esos tamaños, y el font-size base sale del sistema.
.badge {
  background: var(--brand);
  /* el navegador elige blanco o negro según el contraste */
  color: contrast-color(var(--brand));
}

Navegación guiada. las element-scoped view transitions, estables en Chrome 147 después de cuatro años de cocción. Antes startViewTransition() se llamaba sobre document y congelaba toda la página; ahora la llamás sobre un elemento y la transición corre solo en ese subárbol, dejando el resto interactivo. Eso habilita transiciones en paralelo y anidadas.

// La transición corre solo en este subárbol; el resto de la página sigue vivo.
listA.startViewTransition(() => reorderItems(listA));
listB.startViewTransition(() => reorderItems(listB)); // en paralelo, sin bloquear

Como siempre, es progressive enhancement: chequeás if ('startViewTransition' in element) y, si no está, mutás el DOM directo. Google Search ya las usa así, incluso atadas a gestos. En la misma línea vi las scroll-triggered animations (Chrome 145), que disparan una animación basada en tiempo al entrar o salir de un rango de scroll y reemplazan al clásico IntersectionObserver para scrollytelling, y el Scroll Spy en CSS (Chrome 140): marcar el link activo según la sección visible, que siempre resolvimos con JS, ahora son dos líneas (scroll-target-group: auto + el pseudo :target-current).

Reducir ruido y algunas features destacadas. Hubo un lightning round con varias que vale tener en el radar: las scroll-state queries para el patrón "hidey bar" (la barra que se esconde al bajar) sin JS; shape/border-shape para flechas de tooltips y formas no rectangulares sin perder sombras (y, desde Chrome 149, shape como valor de shape-outside); position: sticky que por fin trackea dos ejes a la vez (header fijo arriba y columna fija a la izquierda, en testing en Chrome 148); y moveBefore() (Chrome 133), que mueve un elemento en el DOM sin destruir su estado —un video no se recorta, un iframe no se recarga, un input no pierde el foco—.

Sintaxis en movimiento: varias de estas (scroll-triggered, la Overscroll Gestures API para gestos táctiles, etc.) están recién llegando o en discusión en Open UI. Tratá la sintaxis fina como provisoria y validá contra los artículos de developer.chrome.com antes de meterla en producción.

HTML que se actualiza sin JavaScript

Una de las cosas que más me sorprendió, y que Kinlan planteó como uno de los cambios más grandes en HTML en una década (lo cual comparto), fueron los Declarative Partial Updates. La demo era un reloj que se actualiza cada segundo sin una sola línea de JavaScript.

Slide "Declarative partial updates - Experimental in Chrome 148" con código que muestra un placeholder y templates que parchean el contenido del reloj fuera de orden

La idea es poder renderizar updates al HTML out-of-order, fuera del orden en que llegaron por la red. El caso real: mandás una estructura pesada (un menú gigante) al final del documento para que el contenido crítico pinte primero, y luego se actualiza en su lugar. O un placeholder que se completa al final del mismo request HTTP. En la misma línea va la nueva familia de streaming (streamHTML() / streamHTMLUnsafe()): tomás el body de un fetch y lo streameás directo al DOM, sin el baile de parsear JSON y transformarlo. La frase de Kinlan fue "hacer de HTML el nuevo JSON". Ambas cosas están experimentales en Chrome 148.

Performance y Baseline

Algo que Kinlan repitió toda la charla es Baseline: lo que de verdad podés usar tranquilo porque está en todos los browsers. Desde el I/O pasado, unas 55 features pasaron a baseline widely available (Subgrid, OffscreenCanvas, el elemento <search>, MathML…) y otras tantas a newly available, incluida la Navigation API, que reemplaza a la vieja History API.

Slide "LCP and INP are Baseline Newly available", con LCP (Largest Contentful Paint) y sus umbrales 2.5s / 4.0s, e INP (Interaction to Next Paint) con 200ms / 500ms

Algo para destacar: LCP e INP ahora son baseline newly available cross-browser, así que tenés Core Web Vitals incluso en iOS, midas en el browser que midas. Con los umbrales de siempre a la vista: 2.5s/4.0s para LCP, 200ms/500ms para INP. Y para no perderte nada, mostraron el Baseline Checker (baseline-checker.chrome.dev), que cruza tu Google Analytics y te dice qué porcentaje de tus usuarios soporta una feature, y las Baseline Alerts en webstatus.dev.

HTML-in-Canvas: el plato fuerte

Si tuviera que elegir el "wow" del evento a nivel web, fue este. La HTML-in-Canvas API te deja dibujar elementos DOM reales dentro de un <canvas> (2D, WebGL o WebGPU) manteniéndolos accesibles, seleccionables, buscables y traducibles. Esto hasta se mostró en la keynote. En la demo de apertura, Kinlan mostró un navegador 3D "embebido" en una escena donde igual podías seleccionar texto, traducir a galés y usar el find-in-page.

Slide "HTML-in-Canvas" con código: un canvas con layoutsubtree, un h1 adentro, y en el onpaint un ctx.drawElementImage(content, 0, 0); el badge indica Chrome 148

El uso mínimo es lo que ves arriba: el atributo layoutsubtree en el <canvas>, el HTML real adentro, y en el evento paint un drawElementImage() que dibuja y te devuelve el transform para sincronizar la posición del DOM. Three.js y PlayCanvas ya tienen soporte experimental. Está en Chrome 148 como origin trial, así que ya se puede deployar a producción.

El detalle fino no estuvo en la carpa: lo dieron en una sesión virtual aparte, la de Thomas Nattestad, que vi después. Me pareció lo bastante grande como para dedicarle un post entero, que voy a publicar en estos días; cuando esté, lo vas a encontrar acá.

Lo que me llevo

Como siempre en Google I/O se muestran las cosas ya disponibles, como tambien todo lo que esta experimental. En esta oportunidad, cosas listas para usar ya: la Prompt API estable (148), las element-scoped view transitions (147) y todo el combo de theming (contrast-color, light-dark, scroll-state) que mejora la UX real con poco código y buen fallback. Por otro, un montón de experimentos prometedores y super interesantes —WebMCP, HTML-in-Canvas, Declarative Partial Updates— que ya podés tocar vía origin trial o flag, pero que todavía están definiéndose y a los que conviene darles feedback antes de que se estabilicen.

Si me preguntás dónde poner las manos esta semana, iría por la Prompt API y las view transitions para algo de producción, y dejaría WebMCP y HTML-in-Canvas en una rama de juego. Y si trabajás con coding agents, Modern Web Guidance y el Baseline Checker valen el rato que tardás en instalarlos.

Fuentes

Comments

Share your thoughts and join the discussion

Loading comments…


Related Posts