The only mechanism I have seen reliably prevent this is a budget: a number, agreed in advance, that fails the build when exceeded.

why "we should keep it fast" does not work#

Because "fast" has no threshold, so there is never a moment where a specific change is the problem.

Every individual addition is defensible. The library is 12 KB and saves a week. The query is 8 ms and enables a feature. The middleware is 3 ms and improves security.

Ten of those and your page is 400 ms slower, and no single change was wrong. There was no point at which anyone could say no, because the comparison was always "this change versus nothing" rather than "this change versus the budget."

A budget changes the comparison. Now the question is "what are you willing to remove to make room for this," which is a real conversation.

setting the numbers#

Derive them from user-facing outcomes, not from what you currently have.

For a web frontend:

For an API:

Per-layer budgets are the underrated part. A single end-to-end number tells you something regressed. Per-layer budgets tell you where.

total request budget: 200 ms
  auth:        10 ms
  validation:   5 ms
  database:    80 ms
  business:    40 ms
  serialize:   15 ms
  overhead:    50 ms

When the database layer goes to 120 ms, that specific budget fails, and the person who changed the query knows immediately rather than in a month when someone investigates a general slowdown.

This is borrowed directly from game development, where per-subsystem frame budgets have been standard practice for decades.

enforcement#

The budget must fail something, or it is a wish.

In CI, on every pull request:

- name: bundle size
  run: npx size-limit          # fails if over the configured budget

- name: performance test
  run: k6 run --threshold 'http_req_duration{p(99)}<500' load.js

Report the delta on the pull request. "This change adds 8 KB to the main bundle (142 KB → 150 KB, budget 170 KB)." Visible, in context, at the moment of decision.

Allow overrides with a written reason. Not blocking forever — blocking until somebody says why. The record of overrides is itself useful; if you are overriding every week, the budget is wrong or the system is losing.

the budget for query count#

The single most useful backend budget, and the least common.

Count database queries per request in tests. Assert a maximum.

with assert_max_queries(10):
    client.get("/api/orders")

This catches N+1 queries at the moment they are introduced, which is the only cheap time to catch them. An N+1 that reaches production is found weeks later by someone investigating a slow endpoint, and by then it is embedded in an ORM relationship that four other things depend on.

Almost every framework has a way to do this, and almost nobody does.

what happens when you exceed it#

The conversation that a budget forces, in order:

1. Can we make the new thing cheaper? Lazy load it, defer it, make the query better.
2. Can we remove something else? This is the valuable one. It surfaces the feature nobody uses and the library that is doing 5% of what it costs.
3. Should the budget change? Sometimes yes, deliberately, with a reason recorded. A budget that never changes is a budget that will be ignored.
4. Do we not ship this? Rare and it should be available.

Any of those is better than the default, which is that the change lands and the system is permanently slower.

the thing to measure first#

Before setting a budget, get the current numbers and the distribution. p50, p75, p95, p99. On real user hardware and real networks, not on a developer laptop on office wifi.

Then set the budget at roughly where you are, and ratchet it down over time rather than setting an aspirational number you fail immediately.

A budget you exceed on day one gets disabled on day two.

Enough time has passed to say what actually happened rather than what everyone predicted.

what changed#

The norm inverted. Before, crawling was permitted by default and robots.txt was a request. Now, for a large share of the web, crawling is denied by default and access is a negotiation.

That is a genuine structural change to how the web works and it happened through one company's configuration default rather than through any standards process, legislation, or public deliberation.

Licensing deals concentrated. Large AI companies negotiated bulk access with large publishers. That was always the likely outcome: the parties with lawyers and leverage made arrangements, and the arrangements are private.

Small publishers got very little. The pay-per-crawl mechanism works, technically. The revenue for a site with modest traffic is negligible — the arithmetic never supported anything else. The publishers who most needed a new economic model got the one that pays least.

Non-commercial crawling got harder. Academic researchers, archivists, and independent search projects have no licensing budget and no negotiating position. Carve-outs exist and are discretionary, which means the ability to study the web is now something you apply for.

That is the outcome I was most worried about and it is the one that materialized most clearly.

what did not change#

Training data supply. The frontier labs have enormous existing corpora, licensed sources, and synthetic generation. The marginal value of newly crawled web text was already declining. Restricting it did not create the leverage publishers hoped for.

Traffic. Referral traffic from search to publishers continued its decline, driven by AI answers in search results, which is a completely separate mechanism from training crawlers and which blocking crawlers does nothing about.

This is the part that was most misunderstood at the time. The traffic problem and the training problem have different causes and blocking crawlers only addresses one of them — the one with less economic impact.

the thing to actually take from it#

Infrastructure defaults are policy. A configuration change at a chokepoint reshaped access to a large fraction of the web, with no process and no appeal.

That is not a criticism of the specific decision, which was popular and defensible. It is an observation about where power actually sits, and it generalizes: the entities that can change the web's behavior are the ones with concentration at a layer everyone depends on, and there are about five of them.

For your own site, the decision remains yours and it is worth making deliberately rather than accepting a default:

• Documentation sites frequently want to be in the training data. Being the thing the model knows about is worth more than the pageview you did not get.
• Original reporting and analysis has a stronger case for restriction.
• Anything you want found should still permit search crawlers, which are a different category and are frequently blocked by accident when people configure this.

Check what you are actually blocking. A meaningful number of sites blocked their own search indexing in the first months of this and did not notice for weeks.

the unresolved thing#

The web's economic model — publish freely, get traffic, monetize traffic — is breaking, and nothing has replaced it.

Crawler tolls are not the replacement; the arithmetic does not work at the scale of the actual web, where most content is made by people with no ability to negotiate anything.

Licensing deals are not the replacement either; they work for a few hundred large publishers and for nobody else.

I do not know what the replacement is. I am increasingly convinced that nobody does, and that the interval between the old model failing and a new one existing is going to be long and is going to be bad for the open web.

That is a genuinely pessimistic conclusion and I have not found a way around it in a year of thinking about it.

the distribution advantage, compounding#

The thing no competitor can replicate is that Google can ship a capability into products that billions of people already open daily, on launch day.

That is worth more than a benchmark lead and it is becoming more visible each year. A model that is marginally better but reaches users through a signup flow loses to a model that is marginally worse and is already in the search box.

The strategic implication for everyone else — including the other frontier labs — is that raw capability is not the competition anymore. Distribution, price, and integration are.

the search question, again#

Every year this conference makes the same thing more true: informational queries are increasingly answered on the results page rather than by sending someone to a site.

For anyone who publishes on the web, the consequences are now well past theoretical:

• Referral traffic to informational content keeps falling. This is measurable and it is not recovering.
• Your documentation is being summarized by a system you do not control, and users are acting on the summary.
• The feedback loop is broken. You cannot see what people asked, what answer they got, or whether it was right.

I do not have a satisfying answer. The mitigations available to an individual project are marginal: write documentation that is hard to summarize badly, keep a machine-readable changelog, make error messages self-explanatory so they do not require a search at all.

The structural problem — that the economic model funding web content is being removed without a replacement — is not solvable by any individual publisher, and the people who could solve it have no incentive to.

the developer surface#

The genuinely useful announcements, as always, are the boring ones:

Model pricing and the cheap tier. The cost-per-capability at the small end continues falling, and Google's TPU position means they can price below what competitors renting accelerators can match. If you run high-volume inference, the arithmetic is worth redoing quarterly.

Longer context, better retention. Incremental and real. The practical question is always the degradation curve, not the maximum, and that continues to improve.

Agent tooling in the cloud. Same category everyone is building: runtimes, memory, identity, observability. Evaluate against a real problem rather than a demo.

the thing to actually do#

The recommendation has not changed in two years and I will keep repeating it because it keeps being right:

Have an eval set in your repository. Fifty examples from your real domain, with expected outputs, run against every candidate model.

Every conference like this produces a new model that is claimed to be better. With an eval harness, evaluating that claim for your workload takes an hour. Without one, it takes a week of impressions and you will get it wrong.

This is a day of setup that pays back on every model release, forever, and the number of teams that have done it remains surprisingly small.

the honest summary#

A very good model, deployed extremely well, in a company with structural advantages that are getting stronger.

Whether that is good for the web is a separate question, and I keep arriving at the same uncomfortable answer.

what automated tooling catches#

Roughly a third to a half of real accessibility issues are detectable by a linter or a test:

• Images without alternative text.
• Form inputs without associated labels.
• Insufficient color contrast.
• Missing document language.
• Heading levels that skip.
• Buttons and links with no accessible name.
• ARIA attributes that are invalid or applied to the wrong role.
• Interactive elements not reachable by keyboard.
• Duplicate or missing landmark regions.

Every one of those is a fixed rule with a fixed check, and every one of them is a real barrier for someone.

Getting the automatable third fixed is not the whole job and it is a much better place than most applications are.

the setup#

// component test
import { axe } from 'vitest-axe';

test('checkout form has no automatically detectable a11y violations', async () => {
  const { container } = render(<CheckoutForm />);
  expect(await axe(container)).toHaveNoViolations();
});

Plus a linter for the static cases:

{ "extends": ["plugin:jsx-a11y/recommended"] }

Plus a crawl of key pages in CI against the built site.

That is an afternoon of setup. It will find violations on day one — every codebase has them — so run it in report-only mode first, fix the backlog, then make it blocking. Making it blocking with a hundred existing violations gets it disabled within a week.

what tooling cannot catch#

Being honest about the limits matters, because "we run axe" becomes a claim of compliance that it does not support.

**Whether the alt text is good.** alt="image" passes. It is useless. A screenshot of a chart needs a description of what the chart shows, not the word "chart."

Whether the reading order makes sense. CSS can visually reorder content while the DOM order stays wrong, and a screen reader follows the DOM.

Whether focus management works. Open a modal — where does focus go? Close it — does it return? Navigate to a new route — is focus reset and announced? These are the most common real-world failures in single-page applications and no automated check catches them.

Whether dynamic content is announced. A live region that updates too often is worse than one that does not update at all.

Whether it is actually usable. A page can pass every automated check and be completely impractical to navigate.

the manual checks worth doing routinely#

Three, each a few minutes, on every significant feature:

1. Unplug the mouse. Navigate the entire flow with Tab, Shift+Tab, Enter, Space, arrows, and Escape. Can you complete the task? Can you always see where focus is? Does focus ever get trapped, or jump somewhere unexpected?

This single test finds more real problems than any automated tool.

2. Zoom to 400%. Browser zoom, at a 1280px viewport. Does content reflow, or does it require horizontal scrolling? Is anything cut off? This is a WCAG requirement and it is failed constantly.

3. Turn on a screen reader for five minutes. VoiceOver on macOS (Cmd+F5), NVDA on Windows. You will be bad at it and that is fine — you are not evaluating your skill, you are listening to whether your page announces anything coherent.

Most developers who do this once are permanently changed by it, because the experience of hearing your own interface read aloud as "button, button, button, link, clickable" is clarifying.

the framing that gets it prioritized#

Not "it is the right thing to do." That is true and it does not survive a prioritization meeting.

It is a legal requirement in many jurisdictions, with an enforcement trend that is going up rather than down, and in the EU the European Accessibility Act now applies to a broad category of consumer-facing digital services.

It is a larger market than most product managers assume. Roughly one in six people has a disability. Not all of those affect software use; enough do.

It overlaps with quality generally. Semantic HTML, keyboard support, and clear focus states make interfaces better for everyone. Keyboard shortcuts are an accessibility feature that power users love.

It is much cheaper to build in than to retrofit. An audit that finds two hundred issues in a shipped product is a quarter of remediation work. Catching them at the component level costs minutes.

the single highest-value practice#

Use semantic HTML.

A <button> is focusable, keyboard-activatable, announced as a button, and works with every assistive technology, for free. A <div onclick> requires you to add a role, a tabindex, key handlers for Enter and Space, and focus styles — and you will get one of them wrong.

The overwhelming majority of accessibility problems in modern web applications come from reimplementing native elements badly. Use the element. It already works.

why they actually work#

The security property that matters is not "no password to remember." It is origin binding.

A passkey is a keypair. The private key never leaves the authenticator. When you authenticate, the browser signs a challenge, and the signature includes the origin of the site requesting it.

Which means: a phishing site at paypa1.com cannot use a credential registered to paypal.com. Not "the user might notice." Cannot. The browser will not produce a signature for the wrong origin, and the attacker has nothing to replay.

That eliminates the single most successful attack class in consumer security. Password reuse, credential stuffing, real-time phishing proxies that capture TOTP codes — all defeated structurally rather than probabilistically.

the implementation, briefly#

// registration
const cred = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,          // from your server, random, single-use
    rp: { name: "README", id: "readme.news" },
    user: { id: userId, name: email, displayName: name },
    pubKeyCredParams: [{ type: "public-key", alg: -7 },   // ES256
                       { type: "public-key", alg: -257 }], // RS256
    authenticatorSelection: {
      residentKey: "preferred",
      userVerification: "preferred",
    },
  },
});

Send the attestation to your server, verify it, store the credential ID and public key against the user.

Do not implement the verification yourself. Use a maintained library — the spec has enough subtleties that a hand-rolled verifier will have a bug, and the bug will be an authentication bypass.

the part that is still hard#

Account recovery. This is the unsolved problem and it is where every real deployment struggles.

If a user loses access to their passkeys, what happens? The options are all imperfect:

• Fall back to email. Now your security is your email provider's security, and the phishing resistance you bought is gone for the recovery path.
• Backup codes. Users lose them or store them insecurely.
• Multiple passkeys on multiple devices. Good, and requires the user to have set that up before the loss.
• Identity verification. Expensive, invasive, and a social engineering target.

The honest position: an authentication system is only as strong as its recovery path, and most passkey deployments have a recovery path that is substantially weaker than the primary path.

That is not an argument against passkeys — the primary path being strong still eliminates the bulk attacks. It is an argument for thinking about recovery as a first-class design problem rather than a fallback you bolt on.

the practical guidance#

Offer passkeys as an option, not a requirement, unless you control the device fleet. Users on older devices, shared computers, or unusual configurations need an alternative.

Allow multiple passkeys per account. A user with a phone passkey and a hardware key has a recovery path that does not weaken the security model.

Do not delete the password immediately. Let users add a passkey alongside, then prompt to remove the password later once they have used the passkey successfully a few times.

Use conditional UI (autofill-style passkey prompts) rather than a separate button. The friction of "which sign-in method" is a real conversion cost and conditional UI removes it.

For enterprise, device-bound keys. Synced passkeys follow the user's cloud account, which is convenient and is a different trust model. Hardware security keys with attestation are the right answer where the threat model warrants it.

the thing that took ten years#

WebAuthn was standardized in 2019 and the underlying FIDO work started earlier. The technology was ready long before adoption happened.

What changed was not the protocol. It was that the platform vendors implemented syncing, which turned "a credential on one device" into "a credential you have," and that removed the objection that killed every previous attempt.

The lesson for anyone building security infrastructure: the cryptography is usually the easy part. The reason things do not get adopted is almost always a user experience problem, and solving it is real work that security people frequently consider beneath them.

It is still worth understanding what it actually changed, because a few of the consequences affect how you build.

the problem it solved#

HTTP/2 introduced multiplexing: many logical streams over one TCP connection. That fixed head-of-line blocking at the HTTP layer.

It did not fix it at the TCP layer. TCP delivers bytes in order. If one packet is lost, everything behind it waits, including data for streams that were completely unaffected. On a lossy connection — mobile, congested wifi — HTTP/2 could be worse than HTTP/1.1 with six connections, because one loss stalled everything instead of one sixth of everything.

QUIC moves the transport to UDP and implements reliability, ordering, and congestion control per stream. A lost packet stalls only the stream it belonged to.

what else came with it#

Encryption is mandatory and integrated. TLS 1.3 is part of the protocol rather than a layer on top. The handshake is one round trip, or zero for a resumed connection.

Connection migration. A QUIC connection is identified by a connection ID, not by the four-tuple of IP addresses and ports. Change networks — wifi to cellular — and the connection survives. Your download does not restart.

This is the feature users notice without knowing why. Walking out of a building while a video plays used to stall it.

Better loss recovery. QUIC distinguishes between packet loss and reordering more accurately than TCP, and its acknowledgment format carries more information. Recovery is faster.

Evolvability. TCP is implemented in kernels and middleboxes and cannot change, because the internet is full of devices that will drop anything unfamiliar. QUIC is in userspace and encrypted, so its internals are invisible to middleboxes and can actually be updated.

That last point is arguably the most important long-term consequence. Transport protocol ossification was a genuine crisis and QUIC is the escape hatch.

the practical consequences for you#

Domain sharding is now actively harmful. Splitting assets across static1.example.com and static2.example.com was a workaround for HTTP/1.1's connection limit. Under HTTP/2 it was pointless. Under HTTP/3 it is worse than pointless, because each domain requires a separate connection with a separate handshake and separate congestion state.

One origin. If you still have sharding from a 2014 optimization guide, remove it.

Concatenating and spriting are counterproductive. Same reasoning. Many small files multiplex fine and cache better individually.

Priority matters and is under-configured. HTTP/3 has an extensible priority scheme. Most servers use defaults. If you have a page where certain resources are critical, priority hints (fetchpriority) are worth setting and are widely supported.

UDP blocking is real but small. Some corporate networks block UDP/443. Clients fall back to HTTP/2 automatically, so this is a performance issue rather than a correctness one. Do not build anything that requires HTTP/3.

Your observability may not see it. A lot of network monitoring tooling was built for TCP. Check whether your tools actually understand QUIC or are silently reporting nothing.

the parts that were harder than expected#

CPU cost. QUIC's userspace implementation and per-packet encryption use more CPU than kernel TCP. This has improved substantially with offload support and better implementations, and it is a real cost at high volume.

Middlebox hostility. Some networks throttle or block UDP because it looks like something they should throttle. This is improving as QUIC becomes normal traffic.

Debugging is harder. You cannot read a QUIC connection with tcpdump the way you could read HTTP/1.1. qlog and browser devtools help. The tooling is younger.

the assessment#

For a user on a good connection, HTTP/3 is roughly a wash. For a user on a bad connection — mobile, congested, high latency, lossy — it is a substantial improvement, and those users are a large fraction of the world.

That is exactly the right kind of improvement: invisible to the people who were already fine, meaningful to the people who were not.

Enable it, remove your HTTP/1.1-era workarounds, and go back to not thinking about the transport layer.

Here is what is now safe, and what it lets you delete.

CSS that replaces JavaScript#

Container queries. Style based on the container's size, not the viewport.

.card-grid { container-type: inline-size; }

@container (min-width: 30rem) {
  .card { display: grid; grid-template-columns: 8rem 1fr; }
}

This is the feature that makes genuinely reusable components possible. A component that adapts to the space it is given, wherever it is placed, without knowing about the page. Media queries never could do this and every component library worked around it with JavaScript resize observers.

Delete the resize observers.

:has(). The parent selector, requested for twenty years.

/* a form field that has an invalid input */
.field:has(input:invalid) { border-color: var(--error); }

/* a card that contains an image gets different padding */
.card:has(img) { padding-top: 0; }

/* style a label based on its checkbox */
label:has(:checked) { font-weight: 600; }

An enormous amount of state-syncing JavaScript exists purely to add a class to a parent based on a child's state. All of it can go.

Nesting. Native CSS nesting works. For a lot of projects this removes the primary reason to run a preprocessor.

:is(), :where(), cascade layers. Specificity is finally manageable. @layer in particular lets you define an explicit cascade order rather than fighting specificity with !important.

interaction without JavaScript#

Popover API. Declarative popovers, tooltips, and menus with top-layer rendering, light-dismiss, and focus management handled by the browser.

<button popovertarget="menu">Options</button>
<div id="menu" popover>...</div>

That is the whole implementation. No positioning library, no click-outside handler, no focus trap, no escape-key listener, no z-index arithmetic.

Anchor positioning. Position an element relative to another element, in CSS, with automatic flipping when it would overflow the viewport.

#menu {
  position-anchor: --trigger;
  top: anchor(bottom);
  left: anchor(left);
  position-try-fallbacks: flip-block, flip-inline;
}

Combined with popover, this deletes an entire dependency category. Positioning libraries exist because CSS could not do this. Now it can.

Dialog element. Modal semantics, focus management, backdrop, escape handling. Native.

View transitions. Animate between states, including across page navigations in multi-page apps.

document.startViewTransition(() => updateTheDOM());

The cross-document version means a plain server-rendered site can have smooth transitions between pages. That removes one of the last genuine advantages of client-side routing, which was always a lot of complexity for an animation.

the things to still be careful about#

Feature detection over version detection. Always.

@supports (anchor-name: --x) { /* enhanced */ }

Progressive enhancement still applies. A popover without JavaScript works. A view transition without support just does not transition, which is fine. Build so the absence degrades rather than breaks.

Check your actual audience. Baseline "widely available" means roughly thirty months across all major browsers. If you support enterprise environments with pinned browser versions, your baseline is different and you should measure it rather than assume it.

the bigger point#

The gap between "what the platform can do" and "what developers think it can do" is the widest it has ever been, and it is costing enormous amounts of unnecessary JavaScript.

A meaningful fraction of what frontend frameworks and utility libraries provide is now in the platform. Not all of it. More than most people realize.

Before you install a package to solve a UI problem, spend ten minutes checking whether CSS does it now. The answer has changed, recently, and probably more than once since you last looked.

That is a bigger change to web application architecture than it first appears.

what it replaces#

The default architecture for a data-heavy web application is: the browser holds almost nothing, every view is a request, and the server does the querying.

That produces:

• A round trip for every interaction, at whatever latency the user's network has.
• An API endpoint per view, because generic endpoints are inefficient and specific ones proliferate.
• A loading state for everything, and the accompanying skeleton screens.
• Nothing works offline.
• Server cost proportional to reads, which are the overwhelming majority of traffic.

If the client has the data, all of that changes. A view is a query against local storage. It returns in a millisecond. There is no loading state because there is no load.

the practical setup#

import { sqlite3Worker1Promiser } from '@sqlite.org/sqlite-wasm';

const db = await sqlite3Worker1Promiser.v2();
await db('open', { filename: 'file:app.sqlite3?vfs=opfs' });

await db('exec', {
  sql: `select id, title, updated_at from notes
        where project_id = ? order by updated_at desc limit 50`,
  bind: [projectId],
  rowMode: 'object',
});

Run it in a worker. The synchronous access handle API — which is what makes durable storage fast — is only available off the main thread, and you did not want to block the main thread with database I/O anyway.

the design questions this forces#

How much data does a client get? All of it is fine for a personal notes app. It is catastrophic for a system where a user may see a tiny fraction of a large corpus, and it is a security problem if the partition is not enforced server-side.

The general answer is a working set: the user's own data, recently accessed shared data, and lazy loading for the rest. Deciding what is in the working set is the hard design problem and it is application-specific.

How does it sync? This is where the complexity lives. Options range from "pull changes since a watermark and last-write-wins" to full CRDT-based merge. The right answer depends on whether concurrent edits to the same record are possible and what should happen when they are.

Start with the simplest thing that is correct for your data. Most applications have very little genuine concurrent editing and do not need CRDTs.

What about permissions? The client has the data, so the client can read the data, so anything the client should not see must not be synced. Your sync layer has to understand your authorization model.

This is the constraint that rules out local-first for a lot of enterprise applications, and pretending otherwise is how you build a data leak.

What about migrations? Users have databases on their machines in old schemas. You need versioned migrations that run on the client, and you need to handle a client that has been offline across four versions.

Build this on day one. It is very painful to retrofit.

what it is genuinely good for#

• Applications with a personal working set: notes, tasks, editors, trackers, design tools, dashboards over a user's own data.
• Anything where the user expects instant interaction.
• Anything that should work on a plane.
• Anything where read traffic dominates and server costs scale with it.

what it is not good for#

• Large shared datasets with narrow per-user views.
• Anything requiring server-authoritative state.
• Anything with fine-grained dynamic permissions.
• Regulatory environments where data on client devices is restricted.

the performance note that surprises people#

For a dataset that fits — and "fits" is generous, tens of megabytes is unremarkable — local SQL queries are faster than a network request by roughly three orders of magnitude.

That is not an optimization. It is a different category of user experience, and users notice it immediately even if they cannot say why.

The application that responds instantly to every action feels like a tool. The one with a spinner on every click feels like a website. That distinction is worth more than most features.

The actual killer application is running untrusted code with a capability-based security model and a language-agnostic interface, and the component model is the piece that makes it usable.

the problem it solves#

Every extensible application faces the same question: how do I let third parties add functionality without letting them own my process?

The historical answers are all bad:

• Dynamic libraries. Full process access. One bad plugin corrupts everything.
• An embedded scripting language. Better isolation, but you have committed everyone to Lua or JavaScript, and the FFI boundary is a source of both bugs and escapes.
• Subprocesses with IPC. Safe and slow, with serialization overhead on every call and a lot of plumbing.
• Containers. Very safe, very heavy. Startup in the tens or hundreds of milliseconds, memory overhead per instance.

WebAssembly gives you: a sandbox with no ambient authority, sub-millisecond instantiation, memory measured in kilobytes per instance, near-native execution, and a compilation target for a dozen languages.

what the component model adds#

Core WebAssembly can only pass integers and floats across its boundary. Everything else — strings, structs, lists, results — requires a hand-written serialization convention on both sides. Every host invented its own and none of them interoperated.

The component model defines a real interface type system, described in WIT (WebAssembly Interface Types):

package readme:plugin@1.0.0;

interface transform {
    record document {
        title: string,
        body: string,
        tags: list<string>,
    }

    variant error {
        parse-failed(string),
        unsupported,
    }

    process: func(input: document) -> result<document, error>;
}

A component written in Rust exports that interface. A host written in Go imports it. Neither knows about the other's language. The types are checked at composition time.

That is the missing piece. It turns WebAssembly from "a fast sandbox you have to build a protocol on top of" into "a plugin system."

the capability model#

A component gets nothing by default. No filesystem, no network, no clock, no random numbers, no environment variables. Every capability is explicitly granted by the host, and can be granted narrowly — this one directory, this one host, read-only.

That is a genuinely different security posture from every mainstream plugin system, and it is the right one. The failure mode of "a plugin can do anything the process can do" has produced a very long history of incidents.

WASI provides the standard interfaces for the capabilities a host chooses to grant, so components are portable across hosts that grant the same things.

where this is actually being used#

• Edge compute platforms, where cold start time is the product and containers are too slow.
• Database extensions, where you want user-defined functions without letting them segfault the database.
• Proxy and gateway filters, where the same filter should run in several different proxies.
• Plugin systems in developer tools, where users want to write extensions in their own language.

the honest state of it#

Good: the core specification is stable, the toolchains for Rust and C are mature, the runtime implementations are production-quality.

Mixed: language support varies enormously. Rust and C are excellent. Go works. Anything with a garbage collector and a large runtime — Python, Ruby, the JVM — produces large binaries and slower startup, though the WasmGC work improves this substantially for languages that adopt it.

Still rough: debugging across the component boundary, async and streaming interfaces, and the tooling story for anyone who is not writing Rust.

the recommendation#

If you are building anything extensible — an editor, a data pipeline, a platform, a game — evaluate this before you design your own plugin API. The security model alone justifies it, and the language-agnostic interface means your plugin ecosystem is not limited to people who like your language.

If you are not building anything extensible, this is not for you, and the browser-performance story is much less interesting than the marketing suggested in 2017.

Cloudflare sits in front of roughly a fifth of the web. A default change at that position is not a product launch, it is a policy change for the internet.

the mechanism#

Two pieces.

Default blocking. New zones get AI crawler blocking on unless the operator opts out. Cloudflare maintains the bot classification — separating search crawlers, which drive traffic back, from training crawlers, which do not.

Pay-per-crawl. A site sets a price. A crawler that wants the content gets an HTTP 402 Payment Required with terms. Cloudflare handles settlement.

HTTP 402 has been "reserved for future use" since 1997. It is genuinely funny that this is what activated it.

why the old system failed#

robots.txt is a request, not a control. It works because well-behaved crawlers choose to honor it, and that consensus held for thirty years because search engines had an incentive to be well-behaved — they needed publishers to not block them.

AI training crawlers have no such incentive. The content is valuable to them and the traffic they return is zero or nearly so. Multiple studies found training crawlers ignoring robots.txt, rotating user agents, and using residential proxy pools. Once a norm has no enforcement and no incentive, it stops being a norm.

Cloudflare's move replaces a request with a control. That is the actual innovation and it required no new technology at all — just someone at a chokepoint deciding to enforce.

the case against#

Concentrating the ability to gate the web at one CDN is not obviously good, even if this specific use of the power is popular.

The precedent is: an infrastructure company can unilaterally change how content is accessed for a large fraction of the internet, and the mechanism generalizes to things other than AI crawlers. Cloudflare has been thoughtful and has taken public positions on not being an arbiter, and the concentration is still real.

There is also a smaller-player problem. Large AI companies can negotiate licensing deals directly. Researchers, startups, the Internet Archive, and academic crawlers cannot. A tollbooth is regressive: it is a rounding error for the incumbents and a barrier for everyone else. Cloudflare has carve-outs for some of these and the carve-outs are discretionary, which is the point.

for developers#

Two practical items.

If you run a site, decide deliberately. Blocking training crawlers is now the default; that may not be what you want. Documentation sites in particular may prefer to be in the training data, because being the thing the model knows about is worth more than the pageview you lost.

If you build anything that crawls, expect 402s and expect your user agent to matter. Identify honestly, respect the directives, and set up billing if you need paid access. The era of scraping quietly is ending, and the enforcement is technical now rather than legal.

the bigger shift#

The web's economic model was: publish freely, get traffic, monetize traffic. AI answers break the second step, which breaks the third, which will eventually break the first.

Pay-per-crawl is one proposed replacement. Licensing deals are another. Neither is obviously going to work at the scale of the actual web, where most content is made by people with no ability to negotiate anything.

What replaces it is genuinely unresolved, and 2025 is the year everybody stopped pretending otherwise.

This ends a five-year process that reshaped the web advertising industry's roadmap and consumed an enormous amount of engineering attention across the entire ecosystem.

the timeline, compressed#

• 2020 — Google announces third-party cookies will be phased out within two years.
• 2021 — FLoC proposed. Universally criticized. Withdrawn.
• 2022 — Topics API replaces FLoC. Deadline slips.
• 2023 — Privacy Sandbox APIs ship. Deadline slips again.
• 2024 — UK CMA oversight formalized. Google announces a "user choice" prompt instead of deprecation. Deadline slips.
• 2025 — No prompt. Cookies stay.

why it failed#

Not primarily technical. The Privacy Sandbox APIs — Topics, Protected Audience, Attribution Reporting — were real engineering and some of the ideas were genuinely clever.

They failed because of an unresolvable structural conflict. Google needed the replacement to satisfy simultaneously:

• Privacy advocates, who wanted cross-site tracking to stop.
• Publishers, who needed their ad revenue not to collapse.
• Advertisers, who needed measurement to still work.
• Regulators, who needed to be convinced Google was not using a privacy initiative to advantage its own first-party data — which it has enormous amounts of and which is unaffected by any third-party cookie change.

That last constraint was the killer. Any third-party cookie deprecation strengthens Google's relative position, because Google has logged-in users everywhere and its competitors do not. The CMA was never going to wave that through, and Google was never going to ship something that hurt its own ad business.

Meanwhile Safari and Firefox blocked third-party cookies years ago and the web did not end. It just meant the tracking moved to fingerprinting, first-party data exchanges, server-side tagging, and CNAME cloaking — which are all worse for users because they are invisible and unblockable.

the lesson worth extracting#

Privacy improvements that come from the browser with the dominant market share and an advertising business will always be structurally compromised. That is not a claim about anyone's intentions. It is a claim about incentives, and incentives are more predictable than intentions.

The improvements that actually shipped came from browsers without advertising businesses. Safari's ITP. Firefox's Total Cookie Protection. Those did not require a five-year multi-stakeholder process because there was no internal conflict to resolve.

for developers#

Nothing you need to do. If you built for a cookieless future, that work is not wasted — Safari and Firefox users are already there, and they are a meaningful share of traffic for most sites.

If you are choosing an analytics stack, the interesting development of the last two years is that first-party server-side measurement is now easier and better than third-party client-side measurement for almost everything, cookies or not. Fewer requests, no ad blockers, better data, and you own it.

That transition was going to happen regardless of what Chrome decided.

This has been announced, delayed, re-announced and re-delayed since 2019. It is now happening.

the technical core of the fight#

MV2 gave extensions the webRequest API with blocking behavior: an extension could intercept a network request, run arbitrary JavaScript, and decide what to do. That is enormously powerful and enormously flexible.

MV3 replaces it with declarativeNetRequest: the extension registers rules ahead of time, and the browser evaluates them. The extension never sees the request.

Google's argument is performance, privacy and security: an extension that cannot see your requests cannot exfiltrate them, and rules evaluated in browser code are faster than a round trip into an extension's JavaScript context. All of that is genuinely true.

The counter-argument is capability. Content blocking that requires dynamic decisions — matching on response bodies, generating rules from observed traffic, handling sites that actively rotate their ad-serving domains — is harder or impossible under a declarative model. The rule count limits, though raised several times under pressure, are still limits.

where it actually lands#

uBlock Origin's MV3 version, uBlock Origin Lite, works well for most users and is meaningfully less capable in the tail. Its author has been consistent and unusually clear-eyed about this: Lite is not Origin, it is a different product with a different capability envelope, and calling it a drop-in replacement would be dishonest.

For most people the difference will be invisible. For the people who notice, the difference is the whole point.

the part that is actually about power#

It is possible to believe all of the following simultaneously:

• MV3's security model is a real improvement.
• The declarative approach is the right architecture for most extensions.
• A company whose revenue is advertising should not be the sole arbiter of what ad-blocking extensions can do in the browser used by most of the world.

The third one is not a technical claim and cannot be resolved with a benchmark. It is a structural conflict of interest, and it will keep producing this exact argument every time Chrome makes a platform decision, regardless of the merits of that specific decision.

what to do#

Firefox supports MV3 but kept blocking webRequest, which means full-featured content blockers still work there. Safari has its own model. If content blocking is load-bearing for you, that is now a browser choice, not an extension choice.

For extension developers: the migration is done, stop hedging, port it. The compatibility shims are worse than a real rewrite and you will maintain them forever.

For everyone else: this is a useful reminder that "the web platform" is a set of decisions made by a handful of engineering organizations, and the parts you rely on are only as durable as their continued interest in supporting them.