Chrome's Built-in AI: 11-Second Cold Start On A Fresh

By Lazar Milicevic · Published July 28, 2026 · 7 min read

Google demoed three Chrome AI features at I/O 2026 and every single one returned in under a second on stage. I wired the same three into a live invoicing pipeline on a fresh Chrome profile, and one of them took 11 seconds to spit out the first token. If you're about to rip out your paid AI API because the keynote said "free and local," you're about to inherit a UX tax nobody mentioned.

The three Chrome AI features that actually matter for small-business tools

Here's the map before the benchmarks. At I/O 2026, three Chrome updates matter if you're shipping tools for solopreneurs or small teams: WebMCP (a standard handshake that lets a page expose tools to an agent), Built-in AI (Gemma 3 and Gemini Nano bundled in the browser so you call a model without touching a server), and Skills in Chrome (register reusable task templates the browser invokes on demand).

Each one replaces something real in a small-business stack:

• WebMCP replaces the custom API glue between your web app and an assistant.
• Built-in AI replaces per-request calls to a cloud LLM (OpenAI, Anthropic, Groq).
• Skills replaces the ten little utility functions you keep pasting into every project.

On paper, all three cut your infra bill. In the keynote, all three return instantly. That's the story Google wants you to leave with. So I ran them against a workload I already have in production and measured what actually happens on a first-time user's browser.

The workload and the test conditions (this part matters)

The workload is a receipt OCR + categorization step from a live invoicing tool I run for small businesses. Same input receipt image, same expected JSON output, four different backends: the cloud API baseline (currently in production), WebMCP tool call, Skills invocation, and Built-in AI via window.ai.

The cloud API baseline returns in about 900 ms end-to-end. That's the number to beat.

Test conditions — do not skip this:

• Fresh Chrome profile every run. Not my dev machine. Not a warm profile. A brand-new profile on the home server, spun up for each test.
• Chrome 141 stable, Built-in AI flag enabled, no extensions.
• Wired 1 Gbps down, so download time isn't a fair excuse.
• Median of 10 runs per backend, reported below.

Why the fresh profile obsession? Because your customers are not you. They open your web app on a new laptop, a new phone, an incognito window, a work machine IT just handed them. First-run isn't an edge case — for a lead-magnet or onboarding flow, it's the majority of traffic that matters. If you benchmark on your daily-driver Chrome where Gemini Nano is already resident in RAM, you are lying to yourself.

The numbers: cold vs warm vs cloud

Here's what came back:

Read that Built-in AI row twice. Cold: 11 seconds. Warm: 240 ms. The gap is not a rounding error — it's a factor of 45×. It exists because on first use, Chrome has to pull Gemini Nano into memory (and on some profiles, finish downloading the model shards), and your first inference call sits behind that entire chain.

Warm, Built-in AI is the fastest option on the board. Cold, it's the worst UX in your entire funnel.

Why the fastest demo is the slowest in production

The keynote does not tell you any of this because the keynote runs on a machine where Nano has been warm for weeks. That's not dishonest, it's just a demo. But it becomes dishonest the moment you take it as a UX benchmark.

Think about where this hits you:

• Daily-driver tool (an internal dashboard your team hits 40 times a day): cold-start happens once per session, warm wins the other 39. Built-in AI is a straight upgrade. Ship it.
• Onboarding / lead magnet ("generate your first invoice in under a minute"): every new visitor eats the full 11 seconds on their first click. That's a churn event dressed up as a free tier. On mobile with a colder CPU, it's worse.
• Server-rendered marketing page with an inline AI demo: the demo IS the first interaction. 11 seconds is a bounce.

This is the same trap as unoptimized images in 2012 or blocking JS in 2016. The feature works. The default UX loses you money.

The shipping decision: what goes in, what waits, what needs a prefetch

Here's what I'm actually deploying across three client projects this quarter:

WebMCP → ship immediately. 380 ms cold, no API cost, no warmup problem. This one is a straight win. If you already have a web app and an assistant that needs to trigger actions in it, replace your custom postMessage glue this week.

Skills → ship for anything that runs after 2+ seconds of user interaction. The 1.2 s cold cost is invisible if it happens while the user is reading a form or picking a file. Don't put it on the critical path of a first click.

Built-in AI → ship behind a prefetch warmup. This is the one that requires actual engineering. On page load, before the user clicks anything, fire a throwaway inference to warm Nano into memory. By the time the user submits the real request, you're in the 240 ms regime.

Warmup pattern that converts 11 s into 240 ms

// Fire this once on page load, ideally in an idle callback
// so it doesn't compete with initial paint.
async function warmNano() {
  if (!('ai' in window) || !window.ai?.languageModel) return;

  try {
    const canCreate = await window.ai.languageModel.capabilities();
    if (canCreate.available === 'no') return;

    const session = await window.ai.languageModel.create({
      systemPrompt: 'You are a receipt parser.',
    });

    // Throwaway prompt. We only care about the side effect:
    // Nano is now resident in memory.
    await session.prompt('ok');
    session.destroy();

    window.__nanoWarm = true;
  } catch (e) {
    // Nano not available — fall back to cloud silently.
    console.debug('Nano warmup skipped:', e.message);
  }
}

if ('requestIdleCallback' in window) {
  requestIdleCallback(warmNano, { timeout: 2000 });
} else {
  setTimeout(warmNano, 500);
}

Two rules to go with this:

• Always have a cloud fallback. If window.ai is undefined, the user has Nano disabled, or the warmup fails, route to your existing API. Do not gate features on browser AI availability yet — the Prompt API is still origin-trial in Chrome stable and coverage on mobile is thin.
• Never rely on warmup for the first paint. Warmup is a background gift. If the user clicks before it finishes, show a loading state and complete the request — don't block on it.

The generalizable lesson: cold-start is a first-class UX problem

Every I/O keynote demo for the next two years is going to run on warm state and pretend that's the user experience. It isn't. The teams that win on on-device AI won't be the ones that adopt fastest — they'll be the ones that architect around cold-start as a first-class concern.

A simple pre-migration checklist that will save you from shipping a regression:

1. Measure your current cloud baseline end-to-end (median + p95). Write it down.
2. Measure the local alternative on a fresh profile, not your dev machine. Cold and warm, separately.
3. Classify the workflow: is it daily-driver (warm dominates) or first-touch (cold dominates)?
4. If cold matters, design the warmup path — prefetch, idle callback, or an honest loading state — before you cut over.
5. Keep the cloud path wired as a fallback for 90 days minimum.

Don't migrate on vibes. Treat model warmup the same way you treat image lazy-loading and font swap: a solved problem, but only if you actually solve it.

Where this fits into a real SMB stack

At bizflowai.io I build automation pipelines for solopreneurs and small teams — invoicing, lead capture, receipt parsing, the boring workflows that eat 10 hours a week. When I evaluate a new browser or model capability, the question isn't "is it faster in the demo," it's "does it survive the first-time user on a fresh profile with a cold cache." That's the filter that decided WebMCP ships now, Skills ships behind interaction, and Built-in AI ships with a prefetch. The API bill matters, but a churned onboarding funnel matters more.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.