Ample Concern

Dan Gillmor, writing for Backchannel:

Google, as noted, is no shrinking violet. And a big incentive for news organizations to participate in AMP is to satisfy their AMP “general partner” (my expression, not Google’s) on another front — better placement on Google’s search results. Google’s bread and butter is the ads it can sell based on search, and the company has made clear its intention to rank loading speed high in how it calculates search results. Google insists it won’t favor sites using AMP just because they’re serving up AMP pages, but that may become a distinction with little difference.

[Google news head Richard Gingras] told me last week that Google’s search bots had seen AMP pages from more than 1,000 domains — including many major media companies — and, so far, 33 countries. Sites will have to create separate versions of stories, including at least one for AMP mobile pages and another for regular (desktop/laptop) rendering. Kinsey Wilson, ‎the New York Times’ executive vice president for product and technology, calls AMP “probably the most publisher-friendly solution we’ve seen to date” from the big tech companies, but making it all work takes real effort and staff time.

The Times has ample staff to make it all work; smaller publishers face a bigger hurdle. Even if it’s (relatively) simple to build AMP pages alongside the regular ones going forward, they’ll suffer to some degree if they don’t do this for the archives. (And, as open-standards advocate Kevin Marks notes, by relying on Google JavaScript code, not traditional HTML, for page rendering, AMP pages could ultimately make parts of the web even more fragile and difficult to archive.)

I’ve been researching AMP extensively since it was announced late last year and I have so far emerged with vastly more questions than answers. As best as I can figure, AMP is a reduced, derivative version of HTML that doesn’t allow for many interactive elements — like forms and arbitrary JavaScript — and looks way faster because of “lazy loading” and prefetching techniques, as Google will shout at you in a blog post. That’s fine — speed is good.

But there are a lot of questions here. First, all AMP pages require a base JavaScript file that sets up a lot of the framework, lazy loading, and so forth. It’s even required to display images, video, and iframe elements due to AMP’s proprietary HTML tags. This file is 158 KB; for comparison, a typical page on my site is less than 100 KB, with all text, images, and the tiny amount of JavaScript I use. How is requiring a file larger than a reasonably-optimized webpage supposed to help speed up the web?¹

The people behind AMP will tell you that all AMP-enabled pages are cached around the world, so transmission times become vastly shorter.² But you could pick up an Amazon S3 bucket paired with CloudFront and get a similar effect.

AMP is designed to run only on smartphones — the “M” stands for “mobile”, after all — and its creators recommend serving different pages to desktop users. Why shouldn’t everyone benefit from a faster web?

What compels major third-party publishers to feel comfortable using a nonstandard, somewhat proprietary — if open source — variant of HTML, the development of which is primarily driven by a single company?

Most of all, what problems does AMP solve that could not be fixed through the careful optimization of resources? My site isn’t perfect, but a page almost always loads in about a second and weighs less than 100 KB. I use shared hosting on a single server, too — imagine if I had a dedicated host with a worldwide CDN.³

Between AdSense and DoubleClick, Google has a virtual monopoly on web advertising. They could easily implement strict limitations on what ads can contain, how large they can be, and how fast they need to load. They could optimize their own ad loading scripts and reduce resource consumption of their own advertising and analytics products. AMP’s goals are admirable, but I haven’t yet heard a compelling reason for why speeding up the web requires changing the fundamental architecture of webpages and places the control over their resources in the hands of a third party.

Also, there is a palpable irony in publishing an article about how slow and bloated the web has become on Medium.

Update: Clarified the role of the AMP JavaScript file in the second paragraph following the blockquote.