Google Announces Plan to Improve URLs for AMP Pages, But Even If It Happens, Which Remains Uncertain, AMP Will Still Suck

Malte Ubl, tech lead for the AMP Project at Google

Based on this web standard AMP navigations from Google Search can take advantage of privacy-preserving preloading and the performance of Google’s servers, while URLs remain as the publisher intended and the primary security context of the web, the origin, remains intact. We have built a prototype based on the Chrome Browser and an experimental version of Google Search to make sure it actually does deliver on both the desired UX and performance in real use cases. This step gives us confidence that we have a promising solution to this hard problem and that it will soon become the way that users will encounter AMP content on the web.

The next steps are moving towards fully implementing the new web standard in web browsers and in the Google AMP Cache. Our goal is that Web Packaging becomes available in as many browsers as possible (after all Web Packaging has exciting use cases beyond just AMP such as offline pages, ES6 module loading, and resource bundling). In particular, we intend to extend existing work on WebKit to include the implementation of Web Packaging and the Google Chrome team’s implementation is getting started.

We’re super excited about getting this work under way and we expect the changes to first reach users in the second half of 2018. Thanks for all of your feedback on the matter and we will keep you all updated on the progress right here in this blog!

A bunch of readers have forwarded this story to me, based on my previous criticism of AMP. This announcement isn’t bad news, and might be good news, but at this point it’s all conjecture, particularly for browsers other than Chrome. Even if it all works out, it only solves one problem: URLs. It doesn’t solve the deeper problem of content being hosted on Google’s servers, rather than publishers’ own servers. In addition to ceding independence, think about what this means for search engines other than Google. One of AMP’s foundational tenets is that Google Search is the one and only search engine.

And at a technical level AMP still sucks:

I’m on the record as being strongly opposed to AMP simply on the grounds of publication independence. I’d stand by that even if the implementation were great. But the implementation is not great — it’s terrible. Yes, AMP pages load fast, but you don’t need AMP for fast-loading web pages. If you are a publisher and your web pages don’t load fast, the sane solution is to fix your fucking website so that pages load fast, not to throw your hands up in the air and implement AMP.

But other than loading fast, AMP sucks. It implements its own scrolling behavior on iOS, which feels unnatural, and even worse, it breaks the decade-old system-wide iOS behavior of being able to tap the status bar to scroll to the top of any scrollable view. AMP also completely breaks Safari’s ability to search for text on a page (via the “Find on Page” action in the sharing sheet). Google has no respect for the platform. If I had my way, Mobile Safari would refuse to render AMP pages. It’s a deliberate effort by Google to break the open web.

Seven months later and still none of these things work properly for AMP pages displayed on Mobile Safari. And I forgot to mention back in May that Mobile Safari doesn’t automatically show/hide its browser chrome as you scroll, like it does for any normal web page. AMP pages are also incompatible with Safari Reader mode, making them harder to read for some people, and impossible to read for others.

Sharing canonical URLs rather than google.com/amp URLs is just one of many problems with AMP, and the “fix” proposed here requires updated versions of every web browser in the world to work.

★ Tuesday, 9 January 2018