DEV Community: João Paulo Ávila

Slow and Fragile: The Hidden Math Killing Browser AI Agents (And Why WebMCP Fixes It) ⚡🤖

João Paulo Ávila — Thu, 12 Nov 2026 20:16:59 +0000

Part 2 of the WebMCP Series. (Read Part 1: The Responsive Design Moment of AI Agents)

If you have watched an autonomous AI browser agent complete a real-world task—such as booking a multi-city flight, filling out an insurance claim, or ordering food—you have probably felt two conflicting emotions.

First: “This is pure magic.”

Second, five seconds later: “Why is this taking so painfully long—and why did it just click the wrong button?”

In Part 1, we explored the macro shift: how WebMCP (Web Model Context Protocol) is becoming the "responsive design" moment for AI agents, allowing websites to expose clean tool contracts rather than forcing models to reverse-engineer interfaces.

Today, let’s peel back the layers and talk about the elephant in the room: the engineering bottleneck of browser automation.

Why are current visual workflows fundamentally slow and fragile—and what is the exact math behind how WebMCP fixes them?

The Anatomy of Failure: "Pixels-as-APIs" 🙈

To understand why AI agents struggle on the modern web, we have to recognize a historical mismatch.

For the past three decades, web development has focused entirely on human perception. We construct visual hierarchies, CSS grids, responsive animations, and multi-step modal dialogues designed for eyes, mice, and fingers.

When we ask an autonomous AI agent to navigate that interface using traditional automation tools (like Playwright, Puppeteer, or visual computer-use agents), it is forced into an iterative “screenshot-analyze-click” loop:

Capture: Take a high-resolution screenshot and dump thousands of lines of raw, messy DOM markup.
Perceive: Stream that massive payload to a vision-language model (VLM).
Infer: The model tries to guess which CSS class or button corresponds to the desired action (e.g., trying to distinguish .btn-primary-2 from an identical decorative banner).
Actuate: The agent simulates a physical mouse click or types characters into the input.
Wait & Repeat: Wait for animations or network requests, take another screenshot, and repeat the cycle.

On a simple task with 5 or 6 steps, this loop easily accumulates 30 to 60 seconds of wall-clock latency.

Worse, this visual guesswork hits a hard reliability ceiling: studies and benchmarks consistently show that visual actuation hovers around a ~70% success rate on complex, multi-step web tasks. An agent might succeed nine times in a row, only to fail on the tenth because an A/B test shifted a button by 12 pixels or an unannounced promotional banner popped up.

The Hidden Math: The Token Burn Formula 📉

Beyond latency and fragility, there is a brutal economic reality that kills browser automation in production: token consumption.

In technical reports analyzing agentic actuation, the cost of the visual loop can be formalized as:

C_{visual} = i = 1 \sum N (T_{DOM, i} + T_{screenshot, i})

Where $N$ represents the number of visual screenshot-and-analyze iterations required to complete a multi-step task, and $T$ represents the thousands of tokens consumed per image and raw DOM tree. A single flight booking can easily incinerate tens of thousands of tokens just trying to figure out which calendar date picker to click.

Now compare that with the WebMCP cost function:

C_{webmcp} = T_{schema} + T_{payload}

Under WebMCP, the entire iterative feedback loop collapses into a single, deterministic function call:

The agent reads the concise JSON Schema exposed by the website ( $T_{schema}$ ).
It executes the tool with structured parameters and receives typed JSON data ( $T_{payload}$ ).

The result?

~89% reduction in token overhead ( $C_{webmcp} ≪ C_{visual}$ ).
Task execution accuracy jumps from ~70% to ~98%.
Latency drops from 45 seconds to sub-second execution.

Why Web Automation (Playwright) Wasn't Built for This 🛠️

A common misconception among developers is: "Why do we need WebMCP when we already have Playwright MCP and headless browsers?"

The answer comes down to intent vs. perception:

Dimension	Browser Automation (Playwright / E2E)	WebMCP (Browser-Native Standard)
Primary Goal	Verify Human UI: Test if a human user can see, click, and interact with visual elements (QA testing).	Execute Agentic Logic: Allow AI agents to invoke business functions directly with 98% determinism.
Mechanism	Actuation (simulating mouse clicks, keystrokes, parsing accessibility trees).	Direct invocation of client-side JavaScript tools registered on the page.
Resilience	Zero: CSS refactoring, class renames, or responsive breakpoints break the automation.	High: The visual layout can be completely redesigned without breaking the agent's underlying contract.
Bot Defenses	Often blocked by Cloudflare, WAFs, or visual CAPTCHAs due to simulated mouse events.	A sanctioned, browser-mediated "front door" operating inside the user's authenticated session.

Playwright is an incredible tool for software quality assurance. But using it as an API layer for AI agents is like using a mechanical robot hand to physically type on a keyboard instead of plugging in a USB cable.

What This Means for Product and Engineering Teams 🚀

If your company operates a SaaS platform, an e-commerce store, a dashboard, or a customer portal, here is what this performance gap means for your roadmap:

Stop Building "Scraping" Copilots: Relying on agents that click around your own UI creates massive maintenance debt. Expose your core client-side functions via declarative HTML or the imperative document.modelContext.registerTool() API.
Contextual Tool Lifecycle: Unlike backend MCP servers that overwhelm models by dumping hundreds of tools into the context window, WebMCP tools are page-bound. On the search page, only search tools exist; on the checkout page, only checkout tools appear. This keeps context windows lean and reasoning sharp.
The Speed Advantage Compounds: In the agentic era, users will not wait 60 seconds watching an AI stumble through a checkout flow on Website A if Website B allows the same agent to complete the order in 2 seconds via WebMCP.

The era of making AI agents "pretend to be human" is ending. The web of tomorrow is deterministic, fast, and structured.

How is your engineering team thinking about agentic performance? Are you still relying on visual actuation, or are you preparing structured tool surfaces? Let's discuss in the comments! 👇

The "Responsive Design Moment" for AI Agents: Why Your Company Can't Ignore WebMCP

João Paulo Ávila — Thu, 12 Nov 2026 18:47:28 +0000

Remember 2012? It was when businesses realized they could no longer ignore smartphones. Instead of rebuilding entire systems from scratch, the web adapted with an elegant solution: Responsive Design. We added breakpoints, structured our HTML, and the same websites suddenly served humans on screens of any size.

In 2026, we are living through that exact same shift. But this time, the adaptation isn't for smaller screens — it is for AI agents.

Introducing WebMCP (Web Model Context Protocol), an open standard currently in incubation by the W3C and co-developed by engineers from Google and Microsoft. It is poised to permanently change how AI assistants interact with the internet.

The Problem: AI Agents are Navigating the Web "Blindfolded"
Until today, when you ask an AI agent to perform a task on a website (like booking a flight or building a shopping cart), it has to mimic human behavior:

It takes screenshots of the page.
It parses messy HTML (the DOM).
It tries to guess which button to click or which field to fill out.

This visual method (known as actuation) is extremely slow, token-heavy, and comically fragile. If a designer changes a button's color or shifts the page layout, the AI gets lost and the automation breaks. The average success rate of this "guesswork" navigation hovers around 70%.

The Solution: WebMCP and the "Tool Contract"

WebMCP flips this workflow. Instead of forcing the AI to guess your website's design, your website clearly tells the AI what it is capable of doing.

Through a native browser API (navigator.modelContext), your site registers a list of structured tools with defined inputs (JSON Schemas) and natural language descriptions.

Without WebMCP: The AI scrapes the DOM, desperately trying to find where to click to add a pizza to the cart.
With WebMCP: A restaurant's website exposes a structured function: add_to_cart({ itemId: string, quantity: number, notes: string }). The AI agent simply invokes this function directly, deterministically, and instantaneously.

The results are game-changing:

98% task execution accuracy (no more hallucinations or wrong clicks!).
89% savings in tokens (less data transferred, near-instantaneous local processing).
Complete design freedom: You can redesign your entire website without worrying about breaking AI integrations, because the "tool contract" remains intact.

The Big Win: Native Session and Cookie Inheritance

Integrating systems with AI agents has historically been an infrastructure and security nightmare, requiring complex API keys, dedicated backend servers, and exhaustive OAuth authentication flows.

Because WebMCP runs entirely client-side in the user's browser, it elegantly solves this: the AI agent automatically inherits the user's active cookies, logins (SSO), and sessions.

If a user is already logged into your platform or e-commerce store, the AI agent instantly inherits that secure identity. It operates within the exact same permissions and boundaries as the user, without you having to write a single line of backend authentication logic.

Human-in-the-Loop: Keeping the User in Control

Sensitive actions—like payments, checkouts, or deleting accounts—cannot be left 100% to autonomous AI agents. WebMCP is designed around the principle of cooperation. Sensitive tools can (and should) require on-screen physical validation, such as displaying a confirmation modal so the user can physically approve the transaction before sending an order to the kitchen or processing a payment.

How to Prepare Today?

WebMCP has just transitioned from an experimental prototype to a public Origin Trial in Chrome (versions 149 to 156). Native support across the Chromium engine (Chrome and Edge) is paving the way for the broader ecosystem.

You don't need to rebuild your site. The implementation is incremental:

Audit your HTML: Ensure semantic and clean HTML (which already helps your traditional SEO).
Adopt Progressive Enhancement: Add declarative markups or register imperative JavaScript tools that gracefully no-op on older browsers without breaking the human experience.
Write clear descriptions: In the age of AI, clean tool and parameter descriptions are the new conversion "meta tags."

The era of the agent-ready web has already begun. Brands that make it easy for AI to complete tasks will win. Those that still require manual clicking will be left behind.

Is your website ready to be "executed" by robots, or are you still forcing them to guess your interface?

Image Optimization and Lazy Loading

João Paulo Ávila — Mon, 17 Jun 2024 13:03:18 +0000

In the era of modern frontends, we often raise the question, "How do I make my application more performant?" In this article, I will discuss image optimization and lazy loading to help improve performance and make our application increasingly faster.

Images are always a problem in the life of frontenders.

Very large and heavy images can hinder our application in various aspects, from super slow loading when you have a not-so-fast internet connection, especially when on 3G or 4G, to the initial bootstrap on a desktop, failing to provide elegant feedback to the user. There are many other issues we encounter along the way as well, hehe.

Here, I present some good practice ideas to assist in application development and perhaps provide some tips for those facing this issue. We will use the NgOptimizedImage directive, which helps improve image loading speed.

We will create the project using the Angular CLI. I will assume you already know what we are talking about and import the NgOptimizedImage directive in the AppModule file. Remember that this directive is available from version 14.2.0 onwards.

import { NgOptimizedImage } from '@angular/common';

@NgModule({
  imports: [
    NgOptimizedImage
  ]
})
export class AppModule { }

// If you are using standalone, it can be done as below.

@Component({
  standalone: true,
  imports: [NgOptimizedImage],
})
class StandaloneComponent {}

Change the src property to ngSrc in your HTML template and it will also be necessary to set a width and height.

<img
  ngSrc="../assets/img/image.jpeg"
  width="4000"
  height="3000"
/>

For responsive images, provide various sizes so the browser can choose the best one to render, thus avoiding performance loss.

<img
  ngSrc="../assets/img/image.jpeg"
  width="4000"
  height="3000"
  ngSrcset="200w, 400w, 600w, 800w, 1000w, 1200w, 1600w, 2000w, 3000w"
/>

The Angular NgOptimizedImage directive already loads images by default with lazy loading, but non-visible images should also be loaded this way.

For example, images in a carousel or those lower down the page do not need to be "loaded" when the page is first called. For this, we use another attribute to assist, which is priority.

<img
  ngSrc="../assets/img/image.jpeg"
  width="4000"
  height="3000"
  ngSrcset="200w, 400w, 600w, 800w, 1000w, 1200w, 1600w, 2000w, 3000w"
  priority
/>

With this, all images shown on the page to the user will be marked with priority and will load first. If you have a CDN, from this version of Angular onwards, you can add the provider provideImageKitLoader, making it easier to import images.

import { NgOptimizedImage, provideImageKitLoader } from '@angular/common';

@NgModule({
  imports: [
    NgOptimizedImage
  ],
  providers: [
    provideImageKitLoader("cdn_url")
  ],
})
export class AppModule { }

By doing this, you only need to use the image name in the src, without always typing the full image path, as it will already be called in the provider.

<img
  ngSrc="image.jpeg"
  width="4000"
  height="3000"
  ngSrcset="200w, 400w, 600w, 800w, 1000w, 1200w, 1600w, 2000w, 3000w"
  priority
/>

Below are some data showing the differences between using lazy loading and not.

Without Lazy Loading

With Lazy Loading

These were some tips on how we can use image lazy loading to our advantage, bringing faster loading speeds to our pages and providing good usability for the user.

twitter @joaopaulo_avila

Otimização de imagem e lazy loading

João Paulo Ávila — Fri, 24 Feb 2023 22:30:00 +0000

Nos tempos de frontends modernos, sempre levantamos a questão de… "Como faço para tornar minha aplicação mais performática?” Neste artigo irei falar sobre otimização de imagem e lazy loading para auxiliar nesse processo de performance e ter nossa aplicação cada vez mais rápida.

As imagens sempre são um problema na vida dos frontenders.

Imagem muito grande e pesada pode atrapalhar em vários aspectos nossa aplicação, desde a um carregamento super lento quando se tem uma internet não tão rápida, principalmente quando se está em um 3g ou 4g, como também em um desktop para primeiro bootstrap da aplicação, não dando um feedback para o usuário de forma elegante. Além de vários outros problemas também que as vezes encontramos por esse caminho hehe.

Trago aqui alguma ideia de boa prática e poder auxiliar no desenvolvimento das aplicações e quem sabe dar alguma dica para as pessoas que estão passando por esse problema. Vamos utilizar a diretiva NgOptimizedImage que ajuda a melhorar a velocidade de carregamento de imagens.

Vamos criar o projeto usando a CLI do angular. Vou considerar que você já sabe do que estamos falando e importe a diretiva NgOptimizedImage no arquivo do AppModule. Lembrando que essa diretiva está disponível a partir da versão 14.2.0.

import { NgOptimizedImage } from '@angular/common';

@NgModule({
  imports: [
    NgOptimizedImage
  ]
})
export class AppModule { }

// Caso voce esteja usando standalone pode ser feito da forma a baixo.

@Component({
  standalone: true
  imports: [NgOptimizedImage],
})
class StandaloneComponent {}

Troque a propriedade src para ngSrc no seu template html e também será necessário colocar um width e um height.

<img
  ngSrc="../assets/img/image.jpeg"
  width="4000"
  height="3000"
/>

Para imagens responsivas passe diversos tamanhos, assim o browser escolherá a melhor para renderizar e assim você não irá perder performance.

<img
  ngSrc="../assets/img/image.jpeg"
  width="4000"
  height="3000"
  ngSrcset="200w, 400w, 600w, 800w, 1000w, 1200w, 1600w, 2000w, 3000w"
/>

A diretiva NgOptimizedImage do angular, já carrega as imagens por default em lazy loading, porém as imagens não visíveis também devem ser carregadas dessa forma.

Por exemplo, imagens de um carrosel ou que esteja mais a baixo da página, não precisa ser "carregada” quando a página é chamada, com isso, usamos um outro atributo para nos auxiliar, que é o priority.

<img
  ngSrc="../assets/img/image.jpeg"
  width="4000"
  height="3000"
  ngSrcset="200w, 400w, 600w, 800w, 1000w, 1200w, 1600w, 2000w, 3000w"
  priority
/>

Com ele, todas as imagens que são mostradas na página para o usuário serão marcadas com prioridade e irão ser carregadas primeiro. Caso voce tenha algum CDN, a partir dessa versão do angular, é possível adicionar o provider provideImageKitLoader, assim facilita a importação das imagens.

import { NgOptimizedImage, provideImageKitLoader } from '@angular/common';

@NgModule({
  imports: [
    NgOptimizedImage
  ],
  providers: [
    provideImageKitLoader("url_cdn")
  ],
})
export class AppModule { }

Fazendo isso basta usar só o nome da imagem no src assim, não precisa ficar digitando sempre o caminho da imagem, pois já estará sendo chamado no provider.

<img
  ngSrc="image.jpeg"
  width="4000"
  height="3000"
  ngSrcset="200w, 400w, 600w, 800w, 1000w, 1200w, 1600w, 2000w, 3000w"
  priority
/>

Alguns dados a baixo com as diferenças de usar com e sem lazy loading.

Sem Lazy Loading

Com lazy Loading

Estas foram algumas dicas de como podemos utilizar o lazy loading de imagem ao nosso favor, trazendo mais velocidade de carregamento em nossas páginas e dando uma boa usabilidade para o usuário.

twitter @joaopaulo_avila

Criando eventBinding com exportAs

João Paulo Ávila — Thu, 20 Jan 2022 22:37:48 +0000

Estava criando um componente angular e pensei "Será que é possível pegar um método ou retorno de função sem precisar emitir um evento em si?".

Foi onde achei uma propriedade do angular que é o exportAs.

O exportAs basicamente exporta seu componente com todas as variáveis e métodos públicos.

Começando com o básico vamos criar um projeto Angular simples rodando o comando

ng new nameProject

Para este caso vou escolher as opções básicas do CLI.

para rodar o projeto execute o comando

ng serve

E ele irá rodar na porta https://localhost:4200

Feito isso, vamos criar nosso componente onde vamos exportar ele para o "pai".

Para criar um novo componente você pode criar na "mão" ou rodar o comando ng g c nameComponent ou ng generate component nameComponent ambos criam um novo component.

Quando inicia um novo componente vamos criar um método qualquer aqui que retorno uma informação. Vamos fazer o exemplo do Output primeiro para demonstrar a diferença de ambos.

O app.component.html ficaria dessa forma

<div class="content">
  <div style="display: flex">
    <app-user #exportUser="user"></app-user>

    <button (click)="exportUser.hideUser()">Hide User</button>
  </div>

  <div *ngIf="exportUser.user">
    <p>User:</p>
    <p>{{ exportUser.user.name }}</p>
    <p>{{ exportUser.user.age }}</p>
  </div>
</div>

No exemplo acima, estou importando o component app-user no html e criando uma variável nele chamada exportUser , o nome desta variável você quem escolhe e não precisa ter o nome “export” nela, usei apenas como exemplo.

Feito isso eu posso pegar os valores de variáveis e métodos publicos dentro do meu componente e poder fazer todas as interações com ele.

O user.component.ts fica dessa forma

import { Component } from '@angular/core';

interface User {
  name: string;
  age: number;
}

@Component({
  selector: 'app-user',
  templateUrl: './user.component.html',
  styleUrls: ['./user.component.scss'],
  exportAs: 'user',
})
export class UserComponent {
  user: User | undefined;

  clickedButton = '';

  showTextClickedButton = false;

  showUser() {
    this.user = {
      name: 'Joao',
      age: 18,
    };
  }

  hideUser() {
    this.user = undefined;
  }
}

O “Pulo do Gato” está em colocar o exportAs no decorator, exportAs: 'user' , o nome da variável que utilizei para atribuir ao exportAs é a qual voce vai usar dentro do app.component.html então o nome delas precisam ser iguais. Você também pode escolher o nome da variável que achar mais viável para o seu component.

Essa é uma forma que podemos trabalhar com eventos, além do Output e pegar o retorno de alguma variável específica, podendo facilitar assim para algo que precise.