Even if you've never heard of AMP (Accelerated Mobile Pages), you've probably already come across them several times online without realizing it — and you might have even been put off by one of its minor annoyances. The AMP project was created by Google in 2016 as yet another initiative to make online browsing faster and more responsive. Put simply, it works by making an educated guess on which pages a user is likely to visit next and begin preloading them before they do — for example, by preloading the first Google Search links in the background. I guess you could liken it to a sort of speculative execution for webpages, minus the Earth-shattering security vulnerabilities.

While it does make browsing the web considerably faster on sites which support AMP, it's not without its drawbacks. The most noticeable of these is the way it hides the original URL of a website and instead presents one that points to the google.com/amp URL space; so a user might see something like "www.google.com/amp/www.example.com/amp.doc.html" in the address bar of their browser and not "www.example.com/amp/doc.html." There is obviously a good reason for this: if preload requests were sent directly to publishers' servers, that would give publishers information about what a user was searching for before they had even decided to visit their website. The workaround is to have pages be prefetched from Google's cached copy instead of the publisher's original version, which has the unfortunate consequence of hiding the original URL.

There have already been some changes made to the way AMP documents work to attempt to address this: last year, Google made it much easier to copy the original URL by adding it to the header bar within the AMP viewer. Of course, that doesn't actually fix the bigger issue that the URL in the address bar still isn't the canonical URL for the AMP page. Fortunately, Google has stated today that that will be changing soon, as it feels it's found a satisfactory solution which involves developing a new version of the AMP Cache using the Web Packaging standard.

Using this approach, Google will still be able to take advantage of the privacy and performance gains achieved from having pages cached on and preloaded directly from Google's servers and yet not have the drawback of masking the publisher's original URL. An initial prototype of the AMP Cache has already been built using Chrome, but there's still some work to be done until the build can be finalized and is working with other browsers beside Chrome, so we should hopefully begin to see these changes in the second half of 2018.