Hacker News Reader

I’m assuming you run an ad-blocker? Because the main difference in loading time is seen between a webpage with regular ads, and a webpage with ads that are forced to use the AMP ad framework. Without ads, sure, the difference in total latency before DOMContentLoaded is negligible.

> But it certainly doesn’t have any purpose.

“HTML” email is actually “email that renders HTML and CSS according to the semantics of Outlook 97’s HTML renderer that it borrowed from Word 97’s HTML editor.” Email clients stick to this because it’s a universal de-facto standard, and is still technically HTML. But it wouldn’t be AMP, since AMP specifies how a given blob of AMP should render in very fine detail. Standardizing on AMP for email would be one way of breaking free of the current legacy of email HTML rendering semantics.

There are other ways of doing that, but AMP is one of the only ones that does that while also specifying a packaging format for web-page archives that has MIME-compatible semantics (so that e.g. you can send all the media of a page embedded into the page’s envelope.)

Seems like a solution looking for a problem. The internet is plenty fast enough for loading simple news/blog posts. I haven't found find myself thinking "geeze I wish this article would load faster" in a long time.

Are you one of the hundreds of millions of people who browses the internet primarily on a 3g or slower mobile connection in Asia?

This would largely be a good case if not for the fact that it is pushed on everyone, everywhere; without a choice.

You should be able to disable the option in your e-mail client and get plain HTML e-mail instead. In Gmail, the option is 'Dynamic email.'

Western sites implementing amp (in terms of the general "web" amp) will likely influence local eastern websites to also implement it, along with the notion that "amp gets you to the front page of google results". As an eastern website, the cost to implement it is probably extremely low with plugins and companies [Cloudflare] that do it for you, so it makes sense to click a button and reap the rewards of letting Google's plans play out.

> Starting with google: AMP does not actually make loading any faster. Google just uses it's search monopoly to make it seem so. When you use google search with javascript enabled AMP results are both prioritized in the listing and pre-loaded in the background. This makes up the entire increase in load time you perceive. AMP pages not pre-loaded by google are just as slow to load.

You're missing the part where AMP's sandboxed design is required for Google to be able to safely pre-load results, which it can only do on its own origin due to browser restrictions. Which is one of the main reasons that AMP exists in the first place.

It's a nasty hack, but effective. The Web Packaging standard (also Google's work) might remove the need for it, when it's implemented in browsers... someday. Though with Mozilla against it, who knows what will happen.

Yeah I felt like GP was saying "combustion engines are not actually any faster than horses, they just use gasoline to make it seem like they are". The gasoline/preloading isn't a coincidental factor that can be ignored while judging the thing.

> outgoing links to third party domains will be mirrored onto cloudflare's servers and re-hosted

That sounds very shady... Do they only do this if the third party link has a amp page or do they just do this for all pages?

> AMP does not actually make loading any faster

Every AMP link i click on google loads crazy fast. I don't know why the implementation details or google's incentivizing it would make this not count for some reason.

I don't like what amp is doing to the web either but the user experience is really good, pages do load much quicker than your average page and I find myself preferring them a lot over the uncertainty and frustration when you click other links on a bad connection

Less JavaScript bloat, I think. AMP is mostly static content.

Plain HTML and one CSS file (read: one, not five, not ten CSS files) minus the JavaScript bloat would also load insanely fast. It doesn't have to be AMP.

Try the basic HTML verson of Gmail -- it loads about 5-10X faster than the AJAX version.

You're correct. No js bloat. In order to load Js files it has to be in accordance with the AMP spec and they have a strict list of js you can load.

> Less JavaScript bloat, I think. AMP is mostly static content.

That's actually completely untrue. Every AMP component is a web component and requires JavaScript in order to run at all. And many have their own .js file powering it. You literally can't use an <img> tag on an AMP page. You have to use <amp-img>, which has a JS dependency.

OP is right, the primary reason AMP is fast is because Google is preloading the page in the background. AMP pages themselves aren't all that static, or really all that bandwidth efficient.

Or the site you're already on: HN.

> When you use google search with javascript enabled AMP results are both prioritized in the listing and pre-loaded in the background.

Or Bing search or Baidu search or Yahoo! Japan search and so on. The whole point of AMP is that it can be safely preloaded and prerendered, making it faster than any other web page you can create for people coming from a link aggregator. One of the big advantages it has over Facebook Instant Articles or Apple News is that a publisher has to create an AMP page once and then gets to integrate with the multiple link aggregators that support AMP for free. If I want to create my own link aggregator, I don't need a FAANG's clout to get publishers to integrate with me for instant-loading pages — I can use their existing AMP pages.

You could do that with regular HTML. Google crawling everything would easily let them know if a page is light and easy to preload, giving and incentive to web dev to make it so, instead of creating a lock in solution.

> You could do that with regular HTML.

You ignored the safely qualifier. You would deanonymize a user to the publisher and the third party trackers on their page even if the user never clicks through to visit the page.

AMP can be preloaded because it's designed to be preloaded. Regular HTML pages have side effects that can't be accounted for.

lern_too_spel is right. That is literally what AMP was built for.

Let's watch as HN downvotes the correction while upvoting the misinformation in the top-comment.

edit: Downvote and flag. Very disappointing.

Side effects such as?

Anything that could be affected by prerender[1]. Analytics and statcounters, but also state changes executed by visiting a page.

It'd be quite problematic to load www.example.com/delete-account/confirm, for example.

[1] https://www.w3.org/TR/resource-hints/#dfn-prerender

You are right about analytics, but that's an extremely easy problem to solve - simply disregard stats coming from the search engine bot. In fact both Chrome and Safari currently have a prefetch feature that I think is enabled by default, that's clearly not an issue.

For state, I don't see the connection to AMP here. RFC 7231 which defines the HTTP protocol specifically states that GET is idempotent, and should not cause any state changes in the server. The majority of servers conform to that, and if they don't, it's a bug with worse consequences than messing up prefetch.

Unfortunately I think you're being a little too optimistic. The reality I've seen is that GET is used for all sorts of things, including state changes and irreversible consequences.

Analytics could check for useragent (and probably already does), but it just introduces a lot of noise.

Plus the other concern is that it'd be a huge privacy issue to have analytics being triggered just by performing related searches.

So what’s your take on Chrome and Safari link preload which are in use by the millions at this exact moment?

That it shouldn't be used on a search engine's results page.

Preload within a domain is reasonable. Preload across domains is, imo, a security concern, but maybe acceptable if the domains are trusted. Preloading untrusted, unknown content is a terrible idea.

This correction does little to refute the original point so...

superkuh said:

>Starting with google: AMP does not actually make loading any faster. Google just uses it's search monopoly to make it seem so.

This is a complete misunderstanding of how AMP works. Google isn't abusing a monopoly to make AMP-pages appear artificially faster; they actually are faster. That's because they're safe to preload by design, as lern_too_spel explained already.

The monopoly comment makes even less sense when you consider that other search engines do the same, and even host their own AMP caches.

Most people here disagree with you, hence why you’ll be down voted. Would AMP be used if it wasn’t for the news carousel - nope - so Google is definitely using their position to embrace and extend open standards.

>Most people here disagree with you, hence why you’ll be down voted.

No doubt. And it's really unfortunate that bias is trumping facts in this case.

>Google is definitely using their position to embrace and extend open standards.

There's nothing wrong with embracing or extending technologies. WebComponents, in this case. But if you're hinting at a third step then I'm sorry but open-source by definition cannot be extinguished.

I believe this is a reference to https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu.... Open source does absolutely nothing to resist this approach.

Do you know the definition of the term “contextomy”?

You’re fixating a point that is not the crux of the argument.

Not to mention, it’s hard to imagine AMP existing if it wasn’t for Google's search monopoly.

It wasn’t until late last year that AMP was really governed by true committee, well after it had been established in Googles image.

But that’s also all tangential to the original comment.

It solves the preloading problem just fine. It then goes on to create a crapton of new problems.

Your comment was correctly flagged for breaking the site guidelines. Downvote-baiting is equal parts tedious and supercilious, and is off topic here.

https://news.ycombinator.com/newsguidelines.html

Hi dang,

Thanks for your comment. I wasn't trying to bait any downvotes though. I have no desire to be downvoted. I was frustrating that another user was being incorrectly downvoted and ganged up on simply for explaining how something worked, and I was trying to defend them.

I tried editing the comment before I went to bed to soften it but HN would not allow me to do so. If that were possible, I don't think we'd be having this chat.

Other users in this thread have similarly been flagged simply for explaining how AMP works. I'd ask that you review the other flagged comments in this thread to review if they were done in respect to the site guidelines as well.

Thank you.

AMP is slower for me because I have to press on my screen twice to get to the actual page I wanted to go to.

Hence AMP requires at least 0.5s between the time I click on a Google link and get to my real destination?

When it doesn't crash in chrome on an android phone from GoogleNews. When that happens only the amp is available and because it didn't render you can't get the actual site...

Why does it make sense for Google to control this prefetch mechanism rather than just using a browser built in <link> with prefetch type setup

In what way does google control this prefetch mechanism?

If you mean why does the cache (of which there are 3: google, cloudflare, and Microsoft/Bing) get to control the preloading, the amp limited set of html can be safely cached in it's entirety.

So when I visit a search engine and an amp page is preloaded, it doesn't communicate with that domain.

This ensures that cross domain preloading is possible without leaking my information to any third parties (where third parties in this case is "random sites on the first page of Google").

If link preload was used, any time you made a search, it'd be equivalent to opening all the results on the page, from a tracking perspective. That's pretty awful from the point of view of privacy.

If all the information about us all ultimately percolates out into the environment and everyone who cares knows the size of your bowel movement this morning can we properly say we have improved privacy because they have 2 sources instead of 3 on your morning movement?

> outgoing links to third party domains will be mirrored onto cloudflare's servers and re-hosted

This sounds like an open and shut copyright lawsuit to me, if a DMCA request doesn't take care of it

>AMP is bad for everything.

Not everything. I get all the arguments against it and I don't disagree but man ... AMP is fast. It is really fast, and there is something to be said about forcing content providers to build their web application that makes them this fast.

>AMP does not actually make loading any faster.

What are you talking about. It does make it faster. You feel it, even on my modern Pixel 3 on LTE. Can you imagine if you're running a feature phone on 3G?

Google pre-loads the AMP pages before you have clicked on them, regardless of if you will or you want it to.