How Google may be slowing down AMP by not using direct links to publishers
What’s in a name? A URL that’s not the publisher’s may not smell as sweet, when it comes to AMP.
One of the biggest disadvantages for publishers in using AMP — the accelerated mobile pages format — is that Google will not show a publisher’s actual URL when displaying AMP pages. Google says this is so AMP pages load quickly. However, using a publisher’s URL might hardly slow a page down. In fact, using Google’s URL might actually cause AMP pages to load more slowly.
The Google cache: why AMP at Google uses Google URLs
To understand the issue, consider this search for “google tag manager amp” on Google:
You’ll see a Marketing Land article that appears, one that’s in the AMP format. If you click on this article, it loads quickly. But the URL isn’t for our sibling site, Marketing Land. Instead, it’s for Google:
What’s happening is that Google is serving the page from its cache. It does this because Google claims that this means the page will load more quickly than if it’s served from the publisher’s site.
Would skipping the Google cache really hurt? What if Google didn’t use its own cache? What if it sent people directly to a publisher’s AMP page on the publisher’s site. Would that really slow the experience down that much?
For instance, instead of loading the page in the example above from the Google cache URL here…
Google could instead send people to where the AMP page lives on our own site:
http://marketingland.com/google-tag-manager-now-supports-amp-accelerated-mobile-pages-196062/amp
I asked Google about this for this article. It never gave me an answer about what the speed savings was in using its own cache versus serving a publisher’s URL directly. That left it to me to rely on some other methods of estimating.
Testing shows Google’s cache might slow AMP pages
Google own mobile-friendly testing tool wouldn’t provide me with actual load times, but it did give general speed estimates. When I compared the two URLs above — cached versus non-cached — the results were as follows for mobile speed:
Cached: 88/100
Non-Cached: 68/100
That suggests that a non-cached page is about 23 percent slower than a cached version, if I’ve done my math correctly. While that might seem huge, you have to also consider just how fast a cached page loads.
Google has said that AMP pages load in “two eye blinks,” which translates into about two-thirds of a second. The non-cached page being 23 percent slower means it’ll load in about a second. That’s still super-fast. It’s so fast that I’d say most people wouldn’t notice the difference.
Using the Pingdom page speed tool — and testing both pages twice — I got scores like this:
Cached: 2.52 and 2.38 seconds
Non-Cached: 554 and 492 milliseconds
With this tool, not using Google’s cache actually served the AMP page up to five times faster.
Using another tool from Keycdn — and again testing both pages twice — I got these scores:
Cached: 779 and 492 milliseconds
Non-Cached: 157 and 166 milliseconds
Once again, loading an AMP page through Google’s cache seemed to actually slow it down. Not using the cache meant the page loaded about two to four times faster.
UPDATE: After this article was written, Paul Shapiro suggested another and perhaps more accurate way to measure the difference:
In short, using the cache might serve a page up in about 1.5 seconds versus around 3 seconds without it. That would mean the cache is faster but again, not that much faster relatively speaking. The purpose of AMP was to reduce load times for mobile pages from the 19 second average that one Google study found.
Time to ditch the cache?
I went back to Google twice with these findings, to make sure I wasn’t missing some type of technical issue that invalidates them. The company never refuted them.
Given this, it’s hard to understand why Google doesn’t ditch the cache. My best guess is that it’s mainly because most publishers haven’t complained.
The issue drew some attention back in October after this blog post complained that Google was somehow stealing mobile traffic from publishers.
That’s also when I began asking Google why it doesn’t serve AMP pages with a publisher’s URL. The concern largely died down, mainly I suspect because it’s not like Google is actually stealing traffic. Even the post’s original author,, Alex Kras, updated to say he felt his original headline was incorrect.
If you have AMP pages properly configured with analytics, ads and other goodies you might want, the traffic remains essentially yours. The cached URL might be shown, but everything on the page remains in the publisher’s control and is served from the publisher’s own site. It is your page, except for the URL.
As for the URL, it will redirect to a publisher’s site if someone tries to go to it directly (though as a 302 “temporary” redirect, rather than a 301 “permanent,” which I feel would be better). AMP pages themselves also carry a form of source attribution in their canonical tags. Should someone share an article using options within the actual article, the publisher’s URL is used.
Google also said in November that it was exploring changes that might mitigate publisher concerns, such as somehow showing a direct URL to a publisher’s page.
Still, the URL issue remains. Direct links still haven’t been implemented, making it difficult for those wanting to share or copy a direct URL to obtain it. It also remains worrisome that in the long term, any bookmarked Google cache URLs could fail to redirect, if Google fails to support this in the future.
Yesterday, the editor-in-chief of MacStories announced that his publication was abandoning AMP over these types of concerns:
Replies to his tweet show that it’s not just a publisher concern. Some people clearly don’t know how to share AMP stories, because they’re used to sharing by copying a link out of a browser’s address field — and that’s Google’s link that they don’t want to use.
Why Google says it won’t change
It’s worth noting that if you’re using Google’s search app on iOS or through the built-in search feature on Android, a publisher’s URL is shown, not the Google cache URL. But in a regular browser, it’s not. This is something Google told me would be impossible for it to do, if the company wanted to continue to prerender AMP pages and to support features like swiping from one AMP story to the next.
I get why Google would want to make it easy for people to swipe through stories, but from what I can tell, this is something only supported for AMP stories that appear in Google’s “Top Stories” box for news-related content, not with regular search listings. There’s no reason I can see that it has to go with a Google cache URL for regular listings.
As for prerendering, that’s loading a page up in advance before it’s actually requested. It’s unclear why Google has to use only URLs from its own cache to make this happen. Plus, given how fast AMP pages already are, it’s unclear how much losing prerendering would slow things down.
Why Google should offer a choice
In the end, I think Google should leave the choice to publishers.
Those who don’t care about the URL that is shown can go with the Google cache and trust that Google says their pages will load more quickly.
For those who want their own URLs to show, Google should come up with mechanism within AMP allowing for this to be indicated, something similar to how meta tags exist to indicate if a publisher prefers their own page description over those from the Open Directory.
AMP on its own is super-fast, even without caching. Giving publishers the choice would hardly impact speed, yet it would engender a great deal of trust among publishers who are wary of a Google-backed project that, on the face of it, seems to rob them of their own URLs.
[Article on Search Engine Land.]
Marketing Land – Internet Marketing News, Strategies & Tips
(29)
