Hacker News Reader

Okay but let's be realistic-- you are not a major publisher trying to make money off these pages. You can say "yes my page loads in 100k and 300ms until DOMContentLoaded" all you want, that doesn't change the fact that when you slap a couple of pieces of advertising on there, it's going to slow down.

To give you an idea-- the New York Times page without any advertising on it is 2MB and has a DOMContentLoaded event at 1.29s, approximately 1 second slower than your page. With advertising, it is 3.9MB and 1.82s.

When ad networks are able to run without almost 2MB of Javascript, then we can talk about how AMP isn't needed.

> you are not a major publisher trying to make money off these pages.

Hate to break it to you, but major publishers aren't making any money of the AMP'd version of their pages - most of the monetization is stripped out, and readers aren't even actually on their site so they won't stay and click around.

They have AMP-approved ads that can be loaded.

The spec for amp specifically has an "amp-ad" tag for displaying ads. There are multiple ways they can be shown in an AMP page. The nice thing about AMP ads is they will not cause the page to change layout/flow as they load. I believe a size must be declared for ads to prevent bad behavior.

https://www.ampproject.org/docs/reference/components/amp-ad

I didn't say they couldn't show ads, but basic ads aren't the only way that these places monetize. Trackers, 'you might also like' panels, etc all feed in to the overall monetization strategy. A couple of amp-approved ads on an amp-page don't necessarily make up for all that...

I'm pretty sure 'all that' is what users are trying to avoid with AMP.

I'm not trying to avoid anything. As a user I don't even get a choice for AMP or no AMP. In fact, I changed my search engine on my phone to DuckDuckGo specifically to get rid of AMP pages.

You very clearly said "aren't making any money of the AMP'd version of their pages" and that's not true.

They can put ads, they can even put analytics and links back to their main site. The brand lift they get from all the views also has value.

Trackers work in amp too.

If you're loading ads in AMP, there's nothing stopping you from loading equivalent ads in your POHTML either.

Unless Google won't let you load lightweight ads outside of AMP, which is its own issue.

As a dev at a major publisher I can confirm that we are making money off these pages, and readers are actually clicking on more recirculation links. The monetization isn't stripped out at all, it's just all sandboxed in iframes.

>> When ad networks are able to run without almost 2MB of Javascript, then we can talk about how AMP isn't needed

AMP pages run ads....

But doesn't AMP force ads to be async?

Majority of the ads nowadays are async, just bloated and record your every move and slow down the experience.

    page without any advertising on it is 2MB and has a 
    DOMContentLoaded event at 1.29s

    With advertising, it is 3.9MB and 1.82s

This does not support your core argument about ads being the issue.

The ads load in 602ms.

The page loads in 1290ms

The ads are 1.9MB of data

The page is 2MB

Yes the ads are very heavy. But how are the ads slowing the page down exactly? The page is already INCREDIBLY slow without them.

Only ~30% of load time is spent with displaying the ads. The other ~60% is what ever brain damage the NYT web team cooked up. If anything you are enforcing parent poster's point.

+1. What's more, you can choose advertisers according to the size of their ads. And if you are big enough, you can ask them to modify them.

I doubt the payload is the problem in most cases. The ads load asynchronously, in most cases, and cause other types of performance issues. When an ad loads and causes your scroll position to be lost, or when the ad takes over the screen and can't be closed, or when you get a malicious ad that starts running JavaScript that starts opening alerts and redirects you, all of these things simply don't happen with AMP.

^^^And THAT RIGHT THERE is why I load the asynchronous Adsense script at the very bottom of my pages, after everything else, and why I load my core JavaScript synchronously, just before that, so it can schedule key tasks before getting swamped with third party guff.

I mean, sure, Adsense loads asynchronously and Google claims it won't slow your page loads, but once it starts loading advertising assets and scripts it's the Wild West. Some - not all, by any means, but some - of those third party scripts are extremely badly behaved and, yes, they do measurably slow your page load down.

Okay, but let's be realistic—this absolutely ruins any online experience. AMP just ads another layer of suck over an already sucky experience.

I disagree with that. AMP pages load and work for me without fail. Most non-AMP news sites are unreadable on my phone. Saying it adds a "layer of suck over an already sucky experience" doesn't give AMP nearly enough credit.

How do you find the URL of an AMP page? What's the point of it if I can't? Sharing content from mobile is near impossible without also tracking the sharing.

I mean, really, that's most of AMP: a restriction on a bunch of elements that may slow things down and a bit of special mark up so things can be further accelerated.

If most websites actually did load quickly, then I don't think AMP would have a reason to exist. But if most websites can't manage to slim down their bloat, then one potential answer may be to take away some of their toys (and I'm not saying it's the right answer, just a large part of AMP).

Ok, so the solution is to create a standard subset of elements and create an open tool to test your site against the standard. If your page meets the requirements it gets the pagerank boost. If it doesn't meet the requirements somewhere then it points out what you need to change. No need for AMP.

Why wouldn't this work?

That would work (and personally I would prefer if AMP went in that direction) but it would be merely fast instead of crazy fast because apparently prerendering is only possible if you use the Google CDN.

Why? Chrome has been prerendering pages on search results for years. The only thing I could think of that would make it slower is that you may need to do a DNS request for a different domain, where google's domain is already resolved. (And google probably has a better CDN.)

google could have opted to create a standard that matches the amp standard, but not host the pages, and not put a "X" bar at the top, and not create new urls. they could have put the lightning icon on the serps next to all pages that are fully compliant with the standard.

the difference in speed between google-hosted amp and what i suggest above would be minimal.

the reason google didnt do it this way is because amp is not about speed. speed is just the thing they pitch to you to get you to look past all the negative aspects of the system.

Google could have, indeed. We were aiming at instant loading, though, and for instant loading we needed to do pre-rendering, and the only known way to do that does not allow for changing the origin (has to stay https://www.google.com).

We are working on a few ways how to both make access to the base URL easier and how to eventually even get the right URL in place.

plus the removal of another dns resolution.

We're not talking about developer/technical blogs, which are generally very lightweight, and the person making it likely takes pride in things like efficiency. Your typical content publishing platform on the other hand, is a giant mess of wordpress plugins, tracking, ads, and scripts that pull in other scripts that pull in other scripts. Is it efficient from a technical perspective? No, but it gets the job done for them. AMP is a solution that makes it dead simple for these shops to get a reasonable load time for their content on mobile, which translates to less time spent, which at the end of the day is more important to them.

The problem is that their framework is too big and bloated. Your suggestion is to have them add another layer on top of that, rather than remove the bloat?

Welcome to the real world my friend. Good engineering takes a backseat to clicks and pageviews in the online publishing industry.

> we can accomplish fast loading pages with plain, uncomplicated HTML and CSS?

Sure, but news sites don't. That's the problem. They're loaded with bullshit that makes them mostly unreadable on many devices, screws with your scrolling, and takes insane amounts of bandwidth. The problem is that these news sites are fiscally incentivized to make their experiences bad. The more crap you load, the more money you make.

The hook here is that Google gives priority to AMP pages. "Make your page be provably not terrible and we'll rank you higher than your competitors" is a really juicy proposition, and it makes the user (who just wants to read their news) happier. To a news site, you're faced with the decision of having more revenue with a terrible UX or potentially less revenue with more traffic.

You already know they're dang fast :P

Version B was noticeably slower for me on desktop, but still 100% okay in my book. Version A was near-instant. My eye caught that the image didn't magically appear fully loaded, but after a split second loading was complete and the page (and layout) look great!

Thanks for trying out these test pages! When I created them, I tried loading them in different locations on my phone. Surprisingly, even in busy city-centre locations (using 3G), the pages weren't always loading instantly - but they were fairly fast, enough to feel usable.

Anecdotally, this article for me took about 5 seconds after loading the text to apply its CSS and fonts, which was kinda jarring when reading. I don't need an exotic font to read basic content. I'd most like a simple lightweight site, but I'd take AMP over this site's clunkiness.

Version A was excruciatingly slow. Version B was very quick.

I wonder if original dns resolution wasn't to blame... or either load or lack of a recent one on your server. I know I'm a little late to the party in this thread.

> Do we really need Instant Articles (Facebook) and AMP (Google) when we can accomplish fast loading pages with plain, uncomplicated HTML and CSS?

Can you suggest frameworks that help me do this automatically? Please no, raw html. I daresay that those would recommend developing without frameworks have no experience maintaining other people's projects.

We need it like we needed "use strict" in JS, which is to say not really, but it really helps. I think of AMP as "HTML Strict", a means of enforcing the rules and practices necessary for faster web sites.

So having to include another JS file to use a form or input element is best practice now?

Source: https://www.ampproject.org/docs/reference/components/amp-for...