Safari Will Remove AMP Links
Written by Mike James   
Friday, 25 August 2017

Browsers are supposed to simply read the standard HTML and render it faithfully - but of course we know they don't. Now Apple's Safari is starting to rewrite URLs from Google's AMP cache to point to the original material. This might be good in this case, but the general principle is a slippery slope.

This is a story that has two completely different interpretations and neither is provably correct. The facts of the matter are fairly straightforward.

amp1

 

Google introduced AMP to speed up the web - or, if you are a sceptic - to control the web and make it its own.

AMP is technically very simple. Reduce the HTML, CSS and JavaScript that can be used in a page to a "standard" subset. This subset is claimed to be fast, but its real advantage is that it is standard and therefore much of it can be served via a content delivery network.

So far so good, but Google goes two steps beyond these basics. The first is that Google caches AMP web pages and serves them from its own web servers. The second is that AMP web pages are prioritized in search and the search links point to the Google served version of the content.

In other words, Google's AMP cache isn't transparent as it changes the URLs to point to Google's own copies of the content. This sounds bad if your concern is keeping control of the content. For example, you now no longer have access to your own analytics. Only Google knows how many times an AMP page has been viewed. The other side of the coin is that you no longer have to serve all of the page accesses and Google is essentially offering you a free web server.

You can see that AMP has enough plus points for its supporters to be enthusiastic and enough negative points for its detractors to really hate it.

A particular negative point is that the Google URLs for a web page are sticky in the sense that if you share them or copy and paste them the AMP version of the page gets priority over the original. This is the problem that Apple has stepped in to solve. It has been noticed that in iOS 11 Safari modifies the AMP URLs and converts them back into the original or canonical URLs when the user shares an AMP page.

This is good, or is it? Apple is a striking a blow for web freedom, or is it? Apple isn't exactly known for freedom and is as controlling of its platform iOS, as Google apparently would like to be over its platform - the web. You can view Apple's action as not pro-web user but anti-Google and this seems very plausible.

However there is a small problem with this interpretation. Google seems to want browser makers to convert its AMP links back to standard, canonical links when they are shared! Malte Ubl, "creator and tech lead of the AMP project", tweeted:

"I personally asked for this feature. I have also asked all other browser vendors of course."

Now this is getting silly!

Google uses AMP links to cached versions of web pages and now wants browser makers to add a feature that converts the link to a loaded page into the canonical link to the original web page. Compare this to the usual way of implementing a page cache used by CloudFlare for example, which is to change the DNS records to make the canonical URL point at the local cache server. Google doesn't ask AMP users to change their DNS to its cache servers it simply uses alternative URLs in its search results. It is as if the search results are being used as an alternative DNS. To close the loop Google now needs browser makers to rewrite the URLs that point to the cached version back to the original URLs.

You cannot be serious!?

But it seems they are.

While the URLs aren't rewritten, Google gets an AMP advantage and this means it is no surprise that Apple is the first to implement the rewriting feature.

Will any of the the other browser makers implement the same feature?

Will Google implement it?

We will have to wait and see.

What is clear is that browsers shouldn't be distorting the web pages they are trying to serve for so many reasons it is difficult to know where to begin - but the need to implement standards is probably the top of the list. 

It is a matter of personal taste and irrational loyalty which side you ascribe the evil doing to. What you cannot be so emotional about is the technical lunacy of using a non-transparent, DNS hijacking, caching system and then expecting browser makers to supply the fixup needed to put the URLs back as they were.

 amp3

More Information

@Federico Viticci

@Malte Ubl

Related Articles

Google Speeds Up Mobile HTML With AMP

Google Launches Fast Web Page Technology AMP Early

 

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

 

Banner


Run WebAssembly Components Inside Node.js With Jco
28/03/2024

Jco 1.0 has been just announced by the Bytecode Alliance.It's a native JavaScript WebAssembly toolchain and runtime that runs Wasm components inside Node.js. Why is that useful?



Apache Shiro 2.0 Released
21/03/2024

Apache Shiro 2.0 has been released. The Java security framework now requires at least Java 11, and has added support for Jakarta EE 10.


More News

raspberry pi books

 

Comments




or email your comment to: comments@i-programmer.info

Last Updated ( Friday, 25 August 2017 )