Lazy and Prompt

Chrome 148 shipped this week, and in the release notes you’ll find one of the best things to happen to web performance in a long time: loading="lazy" for <video> and <audio> elements.

Scott Jehl, an engineer at Squarespace focusing on performance and accessibility, has been the driving force behind this. Scott and a small team of engineers proposed the spec change, wrote the implementation, and got it through the WHATWG HTML spec process with positive signals from all three major browser engines. If you want to understand the full story behind it, Scott talked about it in detail on ShopTalk Show and Squarespace published an excellent post on how to use the feature today. This is what working with the web platform looks like: identify a real problem, propose a solution, build consensus, ship it. A good story.

But that’s not the story of Chrome 148. The story of Chrome 148 is that Google – in the very same release – shipped the Prompt API, a feature that was met with explicit opposition from both Mozilla and WebKit, that the W3C TAG raised deep concerns about, and that the web community has been vocally and overwhelmingly against.

Mat Marquis wrote the definitive piece on this, and I won’t retell it here because he puts it in much better words than I ever could. Go read his post. But to understand the scope of the problem: the Prompt API, as shipped, is not a standardized interface for interacting with language models in general. It’s an API for interacting with Google’s Gemini Nano – a 4 GB model that Chrome has already silently downloaded to your machine, without asking, and that it will re-download if you remove it. Any website you visit can now send prompts to that model, using your processing resources, without requesting permission. When both other browser engines explicitly oppose a feature, calling it a “web standard” is a bit of a stretch. I’m not involved in any of this. But after working on the Web for over 25 years, I know how web standards work. This is not one. This is a Chrome feature wearing the costume of a web standard.

And that’s not all. To use the API as a developer, you must agree to Google’s Generative AI Prohibited Uses Policy – a corporate policy attached to what is supposed to be a web platform API. Jake Archibald, who is now at Mozilla, called this out explicitly (and got over 800 likes for it btw): elements of this policy go beyond law, and it sets a dangerous precedent for APIs that come with vendor-specific terms of use. As Mat writes, imagine the Geolocation API requiring you to agree to Google Maps’ Terms and Conditions. Think about what this means if we accept it: the next browser API could come with its own corporate terms, too. And the one after that. The web platform has always been open, implementable by anyone, and governed by specs – not by a single company’s usage policy. This is a line that, once crossed, is very hard to uncross.

There’s also the question of what the browser is even for. A browser is a user agent – it’s supposed to act on behalf of the user, not the vendor. Silently downloading 4 GB of AI model to your machine, re-downloading it if you remove it, and then letting any website access it without your permission – that’s Chrome acting as Google’s agent, not yours. And it’s hard not to notice how many Google products stand to benefit from having an LLM pre-installed on every Chrome user’s machine. With opt-out, of course.

And how did Google justify shipping it over the opposition of the other browser makers? By listing developer sentiment as “strongly positive” in their Intent to Ship. But the evidence behind that claim doesn’t really hold up. The blink-dev thread where the feature was approved consisted entirely of browser engine insiders – Chrome engineers and one Microsoft Edge representative. No external developers participated. A GitHub issue Google created specifically to capture developer interest in the API received exactly two responses in seven months. Satisfaction scores came from a survey Google administered to its own Origin Trial participants — self-selected early adopters who had actively signed up to test experimental Chrome APIs — with no sample sizes disclosed. The stakeholder feedback page cited one promotional blog post, one post on Twitter, and a now-broken link. This seems to be the foundation on which “strongly positive” was built.

Jeremy Keith has documented this pattern over the years: Google’s habit of shipping first and standardizing later, or not at all. AMP. FLoC. Privacy Sandbox. Chrome ploughing ahead and unilaterally implementing whatever it wants, even if there’s no consensus from other browser makers. The Prompt API isn’t an exception. It fits the pattern.

What makes this particular instance so frustrating is that the contrast is right there in front of us, in the same set of release notes. There’s lazy loading for audio and video: carefully proposed, properly standardized, welcomed by all implementers. A true gift to the web community. And then, there’s the Prompt API: rammed through despite broad opposition. One feature shows how the standards process can and should work. The other shows what happens when a company with dominant browser market share decides that the process doesn’t apply to them. The fact that my posts on Bluesky and Mastodon sharing Mat’s article are (still) getting hundreds of reactions while Google's own call for developer interest in the Prompt API received two responses in seven months tells you everything you need to know.

Chrome 148 could have been a celebration. It should have been about lazy loading. About the power of the web standards process. Instead, Google made sure that all anyone’s talking about is how they’ve once again shoved something down our throats that nobody asked for.

~