Tag Archives: amp

Fixing AMP

When I first wrote about Accelerated Mobile Pages, there wasn’t a true implementation. Now we see how Google is rolling this out, and it has problems. John Gruber uses Ars Technica as an example:

On desktop browsers, these URLs do get redirected to Ars’s website. But on mobile they don’t. Share from one mobile device to another and nobody ever leaves google.com. Why would any website turn their entire mobile audience — a majority share of their total audience, for many sites today — over to Google?

Maybe this is inherent in how AMP works, and we should have predicted it. If Google’s AMP implementation must run in browsers, will there always be a layer of JavaScript and custom URLs that hide the original web site?

I’d prefer if Google added AMP support directly to Chrome. While it would be a much more limited rollout, it would feel more natural, with fewer drawbacks for publishers.

Competing news platform Apple News isn’t problem-free either. The apple.news:// shared links also add a redirect, with inconsistent behavior since not all platforms and countries even support Apple News. Apple News is an RSS reader that’s designed like a closed platform.

I want the web to be faster. Breaking links should not be part of the solution.

App review for the fast web

Facebook continues to roll out their Instant Articles format to more publishers. It’s now available to anyone, with this catch:

“You won’t be able to publish Instant Articles until your RSS feed has been approved.”

That’s just what we need: the worst part of the App Store approval process applied to the web. No thanks.

Google’s competing Accelerated Mobile Pages has problems too, as I mentioned in the last half of this post about the cost of links. Although unlike Facebook, which wants to trap content behind their own platform, AMP is at least more open and useful to the larger web.

I hate to say it but neither Instant Articles nor AMP are really good enough. I think we need a third standard for super-fast web pages. (Or do we? Maybe the web is okay as-is if we fight page bloat.)

Lighter, faster mobile web

Speaking of the health of the open web, Maciej Cegłowski gave a talk on web page bloat at the Web Directions conference, and he put the slides and notes online (via Daring Fireball). It’s fun to read and there are many great points, but I want to focus on Accelerated Mobile Pages:

“The AMP project is ostentatiously open source, and all kinds of publishers have signed on. Out of an abundance of love for the mobile web, Google has volunteered to run the infrastructure, especially the user tracking parts of it.”

Sarcasm aside, I think Google’s involvement is mostly transparent, and I was hopeful about it when I wrote about this in November. Google wants the web to be fast. A faster web includes more ad impressions and is more competitive with native mobile apps. I don’t think this disqualifies Google from proposing this project.

High Scalability has a long article exploring AMP:

“Google needs an open and rich ecosystem of knowledge. If that’s not there then Google search won’t be relevant. Which is Google’s direct self-interest, which is also the same objective of the publisher. Publishers need access to an open ecosystem of distribution. Otherwise they’ll have a harder time building audiences if they have to appeal to closed platforms. Yes, Google is a private company that has business interests, but that philosophy and that core similar objective is something very important when considering Google’s role in AMP.”

I’m willing to give Google the benefit of the doubt on AMP. The alternatives are too focused on specific platforms and so even less available to the rest of the web.

Accelerated Mobile Pages from Google

The project technical overview for AMP has the goals and basic info. In a nutshell, the new format encourages a return to more bare-bones HTML, with some added functionality for common web patterns. On the balance between bloated ad platforms and user experience:

“Embedding an ad or analytics often implies giving up control of what eventually happens to a site because they can typically inject any JavaScript they want into pages. AMP HTML does not allow this. We realize that both ads and analytics are an important element of monetization on the web, and so we need to support them: our goal is to realign monetization with great user experience.”

Instead, “tracking pixels” are used for analytics. These should be easily skipped by ad blockers, but apps that support AMP will need to use a custom web view anyway, where ad blockers on iOS aren’t allowed. This may continue to limit the appeal of Safari View Controller.

Wired covers the announcement and describes how AMP might be integrated into Twitter and other native apps:

“One surprise beneficiary of AMP may be Twitter. While it’s not a publisher per se, it’s becoming an increasingly important player in news, most recently with the launch of its Moments feature, which makes news easier to follow on Twitter by organizing Tweets in a chronological, coherent timeline. Now, Twitter will automatically load any articles that are compatible with AMP as AMP files, meaning they will benefit from the same speed inside the Twitter app.”

There’s more on GitHub. On the surface this seems like a more open approach than Facebook Instant Articles or maybe even Apple News Format (which is finally public). That WordPress is supporting AMP is a good sign.