Hacker News Reader

Comment by acdha | Hacker News Reader

This is a valid point but ask whether Google couldn’t have had the same effect by telling everyone that page speed / bloat was a strong ranking factor. AMP forced a large amount of unreliable, slow JavaScript into the critical path so the benefits could have gone even further.

View on HN

They had already done that, perhaps for years. I don't know why it didn't work - perhaps there was a slowness oligopoly, where everyone was slow and no one was strongly incentivized to speed up.

If that were the case, there wouldn't have been incentives for them to implement AMP

They had it as a minor signal. They could have made it stronger. Posit, for example, that they’d said the carousel was only for sites which rendered in one second on mobile - do you think AMP would really have done more than that?

I think so, because the spec prevents "death by a thousand cuts" and makes it crystal clear what's allowed and what's not.

If your marketing department want one more tracking script and your execs want one more pop up banner etc and each change is bad but not egregiously so, then your average "web guy" at most non-big-tech companies will just do what they're asked to.

With AMP they get to say "it's not possible"

If Google penalized slow sites, they'd get to say that. I agree that none of this explains the need for AMP.

That social dynamic is real but it's trivially avoided: imagine if Google said that you had to consistently average, say, 1 second renders on mobile to be in the carousel or avoid being badged with a “This site is not recommended for mobile users” warning. Instead of saying “AMP doesn't allow it” you'd say “We're averaging 0.8 seconds already and this adds 0.4 seconds in our testing” and you could have a business decision about what makes the most sense for your project instead of outsourcing your project direction to Google.

If you think that’s trivial to implement, I’d love to hear where you’ve worked. Getting a change to the main .com at one company where I worked within a month was considered a rush job!

What mattered was that Google set a hard limit: do <x> to be in the carousel. I think that if they had done the exact same thing with a performance metric it would have unfolded very similarly because the key part was that it was a non-negotiable external mandate.

People might have had more room to negotiate on how to hit a performance target but the thing which would have mattered was a number in the webmasters tools console.

Or just mark slow pages. The same way everyone started using https once browsers marked http as insecure. I would bet that if Google results featured a turtle or red/orange/green indicator for the result speed, we'd see a massive shift in companies caring.

Exactly: if they had a turtle icon or a “not recommended for mobile users” warning (which would be even better fordata usage, too) it would have been a game change for many companies and it wouldn't have precluded doing anything which the AMP team didn't think they needed to implement.

Because they didn’t actually make it impact ranking. At least not in a meaningful way. This looks to be changing this year with Core Web Vitals, but it’s still to be seen if these scores will really have an effect on ranking.

Slightly irrelevant sidetrack/goalpost move: I wonder if page speed or page experience should even be a strong ranking factor, considering so much online time is spent in apps vs in mobile web [1]. There will be a time, perhaps in the past for many users, when most search results are just vehicles to open things in apps, and therefore ranking mobile results strongly by their mobile website performance/experience would make as much sense as ranking them by their non-Javascript experience.

[1] Stats for the US: https://www.emarketer.com/content/the-majority-of-americans-... (I wish I could find stats for India or other growing economies)

Reply on news.ycombinator.com