Live data from Hacker News

Google AMP case study: leads dropped by 59%

kinsta.com

141–150 of 163 posts

Re: Google AMP case study: leads dropped by 59%

#141

Earlier quoted context omitted.

Which is fine but not a substitute to Facebook's or Apple's solutions. People want their articles to load instantly, not merely quickly, which means you need a subset of HTML, CSS, and JavaScript that can be validated to be safe to preload, which is exactly what AMP is.

Preloading is just making server calls which is already possible, and preloading the HTML of the page will give you most of the experience of an instant transition without any need to validate anything.

> preloading the HTML of the page will give you most of the experience of an instant transition without any need to validate anything.

It will also deanonymize the user to the publisher. I said AMP validates as safe to preload, not possible to preload.

Re: Google AMP case study: leads dropped by 59%

#142

Earlier quoted context omitted.

> how would sites track you on pages you don't visit? As I stated in GGGP, the benefit of AMP is that it allows a user to safely preload pages.

Because you never leave Google's domain, thereby allowing it track you far more. Preloading is a minor detail considering how much privacy is removed.

Google already scraped the page to show the snippet, so they know what you're looking at. Whatever the privacy loss might be, people are happy to make that tradeoff with Facebook Instant Articles and Apple News. Similarly, they're happy to make that tradeoff on the web, which explains why AMP is used by so many search engines and link aggregators, not just Google.

Re: Google AMP case study: leads dropped by 59%

#143

So another problem with AMP delivered via Google is it tends to utterly booger your analytics... first pageview (via the Google cache) is viewed as a different domain than your site. This can play havoc with optimization efforts. In terms of performance... this is a situation where the AVERAGE AMP site is much faster than the AVERAGE site not using AMP... but that's a rigged game given the volume of non-optimized Wor…

You can’t beat its load times. Google pre-renders the web page before the user clicks, which isn’t safe to do with pages created by your own elbow grease.

Re: Google AMP case study: leads dropped by 59%

#144

Earlier quoted context omitted.

Because you never leave Google's domain, thereby allowing it track you far more. Preloading is a minor detail considering how much privacy is removed.

Google already scraped the page to show the snippet, so they know what you're looking at. Whatever the privacy loss might be, people are happy to make that tradeoff with Facebook Instant Articles and Apple News. Similarly, they're happy to make that tradeoff on the web, which explains why AMP is used by so many search engines and link aggregators, not just Google.

People have no choice in the matter. Facebook and Google trade higher visibility for publishers that participate, in exchange for the same data tracking capabilities and limitations in 3rd-party ad networks from making money.

Apple News is entirely different and more comparable to using any other news app (like Flipboard) or an RSS reader rather than a website.

Re: Google AMP case study: leads dropped by 59%

#145

Earlier quoted context omitted.

HackerNews loads instantly, as do many other sites. HTML works fine. The problem is the stuff on the page, like ads delivered by Google AdX. Removing or optimizing those will make any page faster. No AMP necessary. Slow sites are not a technical problem, they are a business and marketing problem.

> HackerNews loads instantly, as do many other sites. HTML works fine. They load quickly, not instantly. That's the fundamental mistake you have in understanding why people prefer AMP, Facebook instant articles, and Apple News.

The average human response time is roughly 250ms so page loads within 1-2 seconds do not make a major impact on user interaction, especially if the actual text content is available immediately which can be done easily.

AMP has little benefits to anyone but Google and the work it requires only takes away from the effort that could otherwise be spent on making the original website faster.

We work with 1000s of publishers and every major adtech company, and over the years we've built the fastest ad network on the planet using techniques from TCP window sizes to counting bytes in HTTP2 streams. AMP is not necessary for speed, it only requires business prioritization, but you can't fix that with technical standards.

Re: Google AMP case study: leads dropped by 59%

#146

Earlier quoted context omitted.

And none of the things you mention will amount to anything if the site is still pulling dozens of trackers and ad scripts. The average JS dev (like average anything dev) may not write performant code, but the functional parts of the website are not where the main problem lies.

That is a business and design problem not a programming problem. And if one thinks the functional part of a web site cannot be tuned to substantially increase the speed of a web site then one is part of that jQuery plugin crowd who does not know or understand the pipeline from browser to network to server and back.

Website performance will be limited by the parts you're not allowed to improve, i.e. ad & tracking junk. It's basically Amdahl's law. I'd thought understanding that would be even more important.

Re: Google AMP case study: leads dropped by 59%

#147

So another problem with AMP delivered via Google is it tends to utterly booger your analytics... first pageview (via the Google cache) is viewed as a different domain than your site. This can play havoc with optimization efforts. In terms of performance... this is a situation where the AVERAGE AMP site is much faster than the AVERAGE site not using AMP... but that's a rigged game given the volume of non-optimized Wor…

You can’t beat its load times. Google pre-renders the web page before the user clicks, which isn’t safe to do with pages created by your own elbow grease.

Load times ain’t everything, and it’s a terrible pitch for something that breaks basic rules of browsing.

Re: Google AMP case study: leads dropped by 59%

#150

Earlier quoted context omitted.

> HackerNews loads instantly, as do many other sites. HTML works fine. They load quickly, not instantly. That's the fundamental mistake you have in understanding why people prefer AMP, Facebook instant articles, and Apple News.

The average human response time is roughly 250ms so page loads within 1-2 seconds do not make a major impact on user interaction, especially if the actual text content is available immediately which can be done easily. AMP has little benefits to anyone but Google and the work it requires only takes away from the effort that could otherwise be spent on making the original website faster. We work with 1000s of publishe…

I was with you 100% about the AMP stuff, but a statement like "page loads within 1-2 seconds do not make a major impact" is just so laughably wrong that I have to wonder where you source your information. If you actually work in the space, it would behoove you to do some A/B testing on different page load speeds. You will quickly see that it does indeed make a huge impact on user interaction.

That is leaving aside the fact that nobody is actually investing the time they'd spend in AMP to make their website faster. It's simply not something the really bad publishers (for example, a lot of the news space) care about, for reasons I have never managed to follow.

Post reply on HN