Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I think I understand what it's trying to do.

It's appifying the WWW on Google's domain and allowing them to dictate how sites are monetized. On the most basic level, it isn't motivated by speed.



Fast page loads means a better UX on the web.

Better UX on the wide web means people enjoy using Google more. If I'm using Google, it means I want to find something. If Google has encouraged the entire web to be faster, I will find what I'm looking for faster.

People using Google and enjoying it is good for Google.


> Fast page loads means a better UX on the web.

Not necessarily. AMP has terrible usability. For people who block 3rd party JS from loading, AMP pages take 8 seconds to load.

AMP will hurt publishers in the long run:

- giant back button to take users back to Google Search instead of deeper into your site

- broken referrers

- bad inbound links (that point to google.com)

- someone else dictates your monetization strategy

- someone else limits how you publish online

- not faster than DIY optimization

- etc. https://www.google.com/search?num=100&q=amp+sucks


> On the most basic level, it isn't motivated by speed.

So you think Google has no interest in making search results load faster and this factor is just a ploy?


There are employees there who probably buy the idea that it's motivated by speed, but the project wasn't created primarily for speed, just like Chrome wasn't primarily motivated by the need to make a better browser. (Both are about advertising.)


Okay so lets _actually_ look at the market when judging AMP and deciding what Google's purpose of it is.

We have a mobile web where publishers are very bad at making websites. The fill them full of various trackers, ad networks, bad practices and slow them down. This is bad because it makes the web a bad experience on mobile and drives users into native apps.

Facebook and Apple 'realised' this as well and launched their own proprietary solutions for their native platforms (for slightly differing reasons): Facebook had Instant Articles and Apple had their News app, all entirely closed platforms operating outside of the 'web' and without Google. This is a fundamental threat to Google as a business.

If you're in Google's shoes, what do you do? The web standards just don't provide a compelling enough solution to compete with FB Instant Articles and Apple News, which get to leverage being native apps, defining their own formats (fun fact: Apple News articles are JSON!) and preloading content however they Desiree.

AMP was their solution - based on 'open web standards', combined with a shitty hack to preload content when coming from their search results. They said from the beginning their taking the efforts of their AMP project and proposing standards for it, and that's what they're doing.

You can't properly judge Google's AMP efforts without first looking at what they were up against from Facebook and Apple.


> There are employees there who probably buy the idea that it's motivated by speed, but the project wasn't created primarily for speed, just like Chrome wasn't primarily motivated by the need to make a better browser

You have evidence of these two claims or you're speculating?


AMP tech leads especially. For a quick glimpse you can read this: https://amphtml.wordpress.com/2018/03/08/standardizing-lesso...


Where does this say AMP wasn't motivated by speed? From the link:

> We started working on AMP because we were seeing the mobile web feel clunky and slow, falling behind the tightly-integrated, highly-optimized user experiences that walled garden platforms can offer. Yet we also knew there wasn’t a fundamental technology problem: you could build great experiences on the web with the right knowledge, resources, and management support. Thus we set out to create a framework that would provide a well-lit path to building great web-based experiences: AMP would be well documented, easily deployable, validatable, and opinionated about user-first principles.


I was actually just pointing out the "There are employees there who probably buy the idea that it's motivated by speed" :)

If the project was motivated by speed, it:

- wouldn't be implemented in a way that breaks Google's own speed guidelines

- would be implemented in a way that favours speed, not placing in search and inside Google's ecosystem

- would be open to input from the web community, not in through an entirely opaque process inside Google


> - would be implemented in a way that favours speed, not placing in search and inside Google's ecosystem

How? How do you 'load' pages instantly without their search iframe hack?


Indeed. "Search iframe hack". That's basically all you need to know about their "instant loading" and "caring for speed".

See, they are not really optimised for speed. They are optimised for being pre-loaded from Google's CDN in search results. Or, as OP's article says: "the incentives being placed on AMP content seem to be accomplishing exactly what you would think: they’re incentivizing AMP, not performance"

Actually recently I wrote quite a long comment about what's wrong with AMP: https://news.ycombinator.com/item?id=16549828 that covers that, and more.


What's your point? Of course the user gets superior performance - you tap a link and it 'loads' instantly.


My point is: AMP was never really motivated by speed. Proof is in all other discussions around AMP, the OP article, the links in the comment I linked to etc. etc.

The only reason AMP is perceived to be fast/instant is because Google lies.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: