Google unveiled its new plan to speed up the mobile web today — Accelerated Mobile Pages, or AMP — and it’s the latest attempt by a technology company to deal with the problem of the slow mobile web. Facebook has its Instant Articles to make certain news stories load more quickly in an app; Apple wants to move you into its slick new Apple News app. Google’s effort has more to do with changing the mobile web than building its own app or environment, which is why AMP is debuting with a ton of partners in technology (Twitter, Pinterest, LinkedIn, Chartbeat, Parsely) and publishing (The New York Times, Vox Media, the Financial Times, Gannett, Hearst, the Posts Washington and Huffington).

There are a ton of smart ideas in AMP. And it works — cutting the load times of article pages enormously.

But I have to say I’m a little conflicted about it. Google notes that AMP isn’t a business partnership the way that Instant Articles or Apple News are; there’s no ad rev share to consider. But AMP tries to do something maybe even more significant: change the way that the web is built, killing off some technologies and advantaging others. In a world of controlled platforms and walled app gardens, the web is the last open space standing, built over two decades, and there’s something irksome about a few Google engineers deciding which parts to ban.

Yes, publishers don’t have to adopt it, and yes, it’s an open source project, and yes, the performance gains are very real and very substantial. But publishers can choose to adopt Facebook Instant Articles and Apple News too. The point is that this is another stop on the path to powerlessness for publishers — another case of tech companies setting the rules.

It’ll take time and evidence to see how much my reaction is emotional — the fears of an old webhead who remembers browser wars and ActiveX and the battles over open web standards — and how much is strategic. Because maybe it really does take a giant like Google to be the one to save publishing from itself.

What’s the origin story?

Google’s incentive here is obvious: It makes its money on advertising, and the vast majority of that advertising is on the open web. If Facebook (or some other platform, but seriously, Facebook) provides a markedly better mobile experience than the open web does, those advertising opportunities (and that user data) disappears into Zuckerberg’s Walled Garden of Earthly Delights.

AMP grew out of a discussion at the most recent Newsgeist, the occasional Google-and-Knight-sponsored unconference of news and tech people to Think Big Thoughts and Talk Big Talk. If you look at this writeup of the May event by Austrian news exec Gerold Riedmann, it’s clear what was top of mind:

I’m happy to share that the big discussion at #newsgeist was on Facebook Instant Articles…Participants saw it as a clear sign that, after Google long ignored difficulties with news publishers, Facebook wanted to make friends in Europe. Participating media executives see it as an experiment, as a way to learn.

There was no discussion about the product quality. Everybody loved the look and feel, the loading speeds, and all other advantages Facebook Instant Articles offer for customers.

But there is a lot of controversy amongst news publishers in signing a deal with Facebook (also described in my previous post). Everybody knows the Facebook Instant Articles feature is a land grab, and it helps Facebook become “the Internet.”

The devilish offer is you keep all the money from ads sold by you, plus you get data. For some, that seemed too good to be true. Honestly, that sets new standards and makes Google think about how attractive its offers for publishers could/should be.

You can also see a seed of AMP in this Jeff Jarvis post from the same time:

Among other topics, we chose to talk about what Google could do for news, about Facebook as the new distributor — and sometimes editor — of the news, and about at least one idea to take advantage of that new reality.

That idea is something Google News chief Richard Gingras and I advocated at the last Newsgeist in the U.S., something I’ve been working on for years: the containerized, embeddable article that travels to any site with brand, revenue, analytics, and links attached. In other words, let’s take what Facebook has done with Instant Articles and open it up to any creator and any embedder. I was delighted to hear serious discussion of the notion at this Newsgeist, opening the door to reimagining the distribution of news so that instead of always requiring and depending on our users to come to us, we can now take our news to them.

So what is AMP?

AMP is a number of technologies rolled into one. The first and most important is what we might call code subsetting. HTML, the language webpages are built in, includes some things that load quickly and others that load slowly. AMP aims to kill off the slow parts, most notably JavaScript. Here’s Malte Ubl, the AMP Project tech lead:

The web today is many things: an application platform, an e-commerce platform, a content platform, a gaming platform, and so much more. We decided to focus entirely on static content as it lends itself to more radical optimization approaches that are easier to apply across the board.

We began to experiment with an idea: could we develop a restricted subset of the things we’d use from HTML, that’s both fast and expressive, so that documents would always load and render with reliable performance?…

One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn’t saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts.

No third-party scripts! Here are some things that use third-party scripts: essentially every ad, essentially every analytics package. When you see a page that is stuffed full with trackers, those are pretty much all third-party scripts.

The @chicagotribune literally has too many web trackers to fit on a 27” iMac screen pic.twitter.com/33TMw7FqPK

— Joshua Benton (@jbenton) September 8, 2015

Certain HTML tags are also banned: iframe, embed, object, and all script other than JSON (and the script that loads AMP in the first place). The main HTML5 multimedia tags, img, video, and audio, are replaced with custom elements amp-img, amp-video, and amp-audio.

Creating these new elements let AMP HTML treat images and video as assets that can be constrained at will for performance reasons:

We call them managed resources because whether and when they will be loaded and displayed to the user is decided by the AMP runtime….The runtime should prioritize resources currently in viewport and attempt to predict changes to the viewport and preload resources accordingly.

The AMP runtime may at any time decide to unload resources that are not currently in viewport or reuse the resource containers such as iframes to reduce overall RAM consumption.

CSS is also strictly limited in AMP HTML (“The restriction is in place to make overall performance easier to reason about. It may be opened up in the future”). Among the banned are the common CSS properties used for animation. Custom fonts are allowed but constrained in certain ways.

AMP is a turning point for the web. Stripped back pages, no Javascript, no tracking. Google did a great thing today.

— Owen Williams (@ow) October 7, 2015

By essentially supplanting the native rendering engine in a mobile browser, AMP can load or unload assets at will — not worrying about images until they’re nearly in view, for instance, or loading editorial text content first and ads second.

@gloddy JS allows controlling render time. AMP is extremely lazy and just won't render most things at all. Browsers are super eager.

— Malte Ubl (@cramforce) October 7, 2015

There are lots of clever ideas here, and it’s understandable why these constraints would help improve performance. For better and for worse, this is essentially a rollback of how HTML and web technologies have evolved over the past decade. It’s a little jarring that so many of the sample AMP pages on display this morning look a lot like the web of, say, 2002, shrunk down to a phone screen. Like an IE 5.5 emulator. I mean, this sample image from Twitter is ugly:

(There’s no particular technical reason you can’t build beautiful mobile web pages in AMP, though, even if the first examples fall short.)

But this stripping out out tags also reinforces a walled garden. AMP is an open source project, but tags like amp-img are killing and replacing elements that have been part of the open web for literally decades. It’s forking HTML.

As I said loudly at #ONA15, this is platforms dictating the forms of expression we can publish, full stop. https://t.co/Gs0Kxu42X0

— Justin Myers (@myersjustinc) October 7, 2015

I can't imagine that @timberners_lee's idea of "a subset of HTML" includes one that replaces <img> with a Google-specific version.

— Justin Myers (@myersjustinc) October 7, 2015

In the earlier days of the web, browser manufacturers (most notably Microsoft) tried to shape HTML so that it would only work properly in its universe — the days of “Best Viewed In Internet Explorer.” The web standards movement worked very hard for years to get browsers and developers on board with using agreed-upon open standards for how the web gets built and rendered.

Now, AMP essentially asks you to build a parallel-universe version of your site that strips out not just anything that’s slow, but anything that might be slow. You know how ad blockers block all ads, whether they’re perfectly reasonable or aggressively terrible? AMP HTML kills all JavaScript, not just bad JavaScript.

So, using AMP means having to publish content twice – once for web standards and then again with AMP markup? Sigh. https://t.co/esaBgYEp8D

— john holt ripley (@johnholtripley) October 7, 2015

You can embed things in an AMP page, using pre-approved extensions like amp-youtube and amp-twitter. But that advantages the companies that can build these sort of embeds and get them added to the spec. The open HTML tags being killed are available to anyone, anywhere — any startup, any publisher.

To be fair, Ubl acknowledges that AMP isn’t going to make sense for every webpage:

JavaScript is the core building block for advanced web apps, but for static content it may not always be required: for a headline, some text and an image you do not need JS. Looking further into the content being created on the web nowadays, there are, however, things like lightboxes, various embeds, polls, quizzes and other interactive features that cannot easily be implemented without JavaScript.

You won’t be able to build beautiful interactive maps or data visualizations in AMP; you probably wouldn’t try to build Snow Fall in AMP. But it might make sense for those day-to-day pieces that make up most of the journalistic production of most publishers.

AMP allows you to maintain two different versions of your webpages (HTML and AMP HTML) or just convert entirely to AMP. For example, The Verge’s article about today’s announcement is here, at the url http://www.theverge.com/2015/10/7/9467149/google-accelerated-mobile-pages-caching-preview. But the code of that page also includes this line that tells the browser there’s an AMP version of the page:

<link rel="amphtml" href="http://www.theverge.com/platform/amp/2015/10/7/9467149/google-accelerated-mobile-pages-caching-preview">

That page is stripped down.

On my iMac, the full version weighs in at 1.3 megabytes, renders the visible content in 2.60 seconds, and loads completely in 5.80 seconds. The AMP version is about half the size (777 kilobytes), renders in 0.47 seconds, and loads completely in 1.34 seconds.

That’s the kind of enormous speed gain we’re talking about. But…that page also includes a SoundCloud embed — which is just broken in the AMP version, presumably because there isn’t an amp-soundcloud, or The Verge hasn’t implemented whatever it needs to make it work. And…The Verge is giving up whatever benefit they were getting from all those ad trackers and analytics trackers and such.

It is possible to believe both that (a) there are too many ad tech companies and too many sloppy ad networks and too many duplicative analytics packages and the web is a giant mess, and (b) that publishers don’t add those things to their pages purely to annoy users, and they get some form of (financial, analytical, editorial) value from them. AMP makes those choices for them.

Ubl says there’s still room for some interactivity without scripting on AMP pages. I don’t have the technical chops to evaluate that, but if you’re, say, a news developer who has built all sorts of stuff that relies on JavaScript libraries (whether open source or your own), it must be a little disorienting to hear about a format where none of it will work.

AMP terrifies me. Such exciting work being done to bring mobile web to life. But not if you remove scripting. Hope you like your toast plain

— Julia Wolfe (@juruwolfe) October 7, 2015

@juruwolfe the custom elements allow for all kinds of interactivity and there is also an iframe fallback with certain restrictions.

— Malte Ubl (@cramforce) October 7, 2015

@juruwolfe yeah, it'll trail, but everyone can add more elements. Only thing is that they cannot be proprietary.

— Malte Ubl (@cramforce) October 7, 2015

@cramforce Sure it's great for basic pages. But I'm a data vis designer who loves weird, wonderful web. Terrified of being put in a sandbox

— Julia Wolfe (@juruwolfe) October 7, 2015

@juruwolfe absolutely. AMP isn't great for full fledged interactives. For smaller elements : <amp-iframe> and the future <amp-click-to-play>

— Malte Ubl (@cramforce) October 7, 2015

@cramforce Yeah, which is what crushes me. I'm sure you get why hearing 'there's iframes' doesn't calm me much.

— Julia Wolfe (@juruwolfe) October 7, 2015

What about ads? Essentially all ad networks use third-party JavaScript, which is banned in AMP. So there’s something called amp-ad to take its place:

Ads are loaded like all other resources in AMP documents, with a special custom element called <amp-ad>. No ad network provided JavaScript is allowed to run inside the AMP document. Instead the AMP runtime loads an iframe from a different origin (via iframe sandbox) as the AMP document and executes the ad network’s JS inside that iframe sandbox.

Only five ad networks are supported at first, four of them owned by Google, Amazon, and AOL. Google says any ad network can join, but again, the big guys have an advantage at the starting line. There’s more development to be done here, and people with more ad-tech knowledge than I have can better evaluate the impact.

Okay, my brain hurts a little. What else is in AMP?

So that code constraint is the main part of AMP. What’s another one? Caching. It’s an optional part of AMP, but Google will cache a copy of your AMP webpage for you on its servers and send its copy of your page to your user rather than yours. I think we can safely assume Google knows how to run servers better than your IT crew does, and its distributed network of server farms should make cached delivery substantially faster. (Google notes that other companies are free to set up caching systems to use with AMP, but given that Google’s will be free and, one imagines, pretty good, broad competition here seems unlikely.)

It’s unclear exactly how that will work, since AMP is still a work in progress (particularly around advertising and analytics). But it’s optional; you can run AMP without any caching at all.

Another issue: How will Google treat AMP’d pages? Google showed off a new carousel of AMP’d news stories in search results:

The AMP version of Google http://t.co/wnZtCgQ3dn is blowing my mind. This might finally kill 10 blue links pic.twitter.com/JmkLMr3zWM

— Danny Sullivan (@dannysullivan) October 7, 2015

But it’s important to note that Google specifically said that’s a demo, not necessarily what a real implementation would look like.

Google said it won’t prefer AMP pages over non-AMP pages in search…but reminded us hint-hint-nudge-nudge that page speed is already a factor in Google results, with faster pages getting preference. Very similar to how Facebook says that Instant Articles won’t get any favors in its algorithm, but notes that faster load times and better user experiences do. When sites still get ~30 percent of their traffic from Google search, a tech implementation that gives any real SEO boost becomes alluring.

Finally, how does this interact with the publishing bête noire du jour, ad blocking? AMP promises to make advertising nicer (primarily by killing off all that scripting cruft), but it doesn’t block ad blockers.

@pkafka In the demo version at least I can block Ads in the AMP articles using an Ad Blocker. So there's that.

— Karan Bhasin (@KaranBhasin13) October 7, 2015

You can make an argument that a faster smoother mobile web would lead to more people turning off their ad blockers or whitelisting AMP’d sites. But that feels like a triple bankshot, and I suspect user behavior would be hard to shift here.

What’s it all mean for publishers?

As I said, AMP is full of terrific ideas. It really does speed up load times.

But that success comes with tradeoffs. For most publishers, you’re being asked to set up two parallel versions of your stories. (Unless you really think you won’t need to ever do anything outside what AMP allows on any page, which is unrealistic for most.) That takes significant time and resources. You’re being asked to set aside most or all of the ad tech and analytics that you use. You’re trading in open web standards for something built by Google engineers who, despite what I don’t doubt are the best of intentions, have incentives that don’t line up perfectly with yours. And you’re becoming an disempowered actor in a larger Silicon Valley battle over ad tech. (Google advocating something that blocks enormous slices of contemporary ad tech can’t be viewed in isolation from the fact Google is the dominant force in online advertising, and as interested as any company is in extending its power.)

And it’s yet another case of a technology company coming along to promise a better experience for users that takes one more bit of power away from publishers. That is, of course, a reasonable and good thing for technology companies to do! Blogger and WordPress empowered anyone to publish online; this hurt professional publishers but the tradeoff was a net gain for users. Google, Facebook, and Twitter created amazing platforms for discovering interesting content; this hurt professional publishers but the tradeoff was a net gain for users. Apple created an app platform that promised amazing experiences for people with iPhones and iPads; this hurt professional publishers but the tradeoff was a net gain for users.

And we who read things on our phones will be better off if AMP or something like it gets wide adoption. But that’s a different question than whether it’ll make sense for publishers. Which is why I’m conflicted.