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 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
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