Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new approach to web performance

ampproject.org

Post reply on HN
Print view View original

141–150 of 177 posts

Re: A new approach to web performance

#141

Post by gorhill »

tombrossman wrote: post #130
gorhill wrote: post #107

I personally choose to block ubiquitous 3rd parties by default[1], to fight both bloat AND privacy exposure. This AMP project reduces the bloat but at the cost of increased privacy exposure. If I globally block `ampproject.org` when visiting a AMP-enabled web pages, the pages do not render at all. My understanding is that now all "Google and its partners" have foiled the ability of visitors to protect their privacy w…

I'm curious why you say "when visiting a AMP-enabled web pages, the pages do not render at all" . I'm not seeing the same result. The first two 'AMP' pages I tested loaded very quickly and were easily readable. I use Firefox with NoScript, which is definitely blocking the JS from ampproject.org. I also use Privacy Badger and uBlock Origin (thanks btw) and I'm not having any trouble at all. Here are the figures for th…

This is what I get if I block `ampproject.org` (which -- given its purpose -- is meant to become ubiquitous): A blank page.[1]

In reality, the speed gain (which is the advertised benefit of AMP) is just a matter of avoiding to pull all the optional 3rd parties.

For example, a non-AMP random article from the same site[2], the page loads quite fast when I block all 3rd-party scripts/frames, except those from `vox-cdn.com` and `voxmedia.com`. The page renders fine -- with the virtuous "side effect" that 18 more 3rd-party are not logging network requests from my IP in their server logs (in this specific case).[3]

[1] https://cloud.githubusercontent.com/assets/585534/10397383/6...

[2] http://www.theverge.com/2015/10/9/9486505/california-calecpa...

[3] The total number of 3rd-party in this specific case climb to at least 48 without a blocker.

Re: A new approach to web performance

#142

Post by bmn_ »

ducuboy wrote: post #59
ducuboy wrote: post #43

Earlier quoted context omitted.

AMP is just broken HTML, hardly a standard. https://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.theverge.c...

What about RSS? That offered good performance, was widely adopted and was a real standard working for both publishers and consumers. Remember who actually killed it? Yeah, that was also Google.. by discontinuing their Reader - a very good tool with lots of users but no revenue. That's how much open standards matter. Too bad @aaronsw is not around anymore, he would have said something about AMP.

RSS never was an open standard like you would expect from a real standards organisation, e.g. IETF or W3C.

Because of dominance posturing and fights between the multiple parties involved in the development of RSS, it is a train wreck of ad-hoccery and incompatibilities, and serves as a prime example of how not to do things. https://web.archive.org/web/2004/http://diveintomark.org/arc...

> Remember who actually killed it?

Atom.

Re: A new approach to web performance

#143

Post by cramforce »

scrollaway wrote: post #140
cramforce wrote: post #136

Earlier quoted context omitted.

One of the things that AMP allows is to know that is it save to prerender a page. Documents can be instructed by a viewer to e.g. only load resources visible above the fold and absolutely no external JS. With general web content prerendering is pretty dangerous and you certainly cannot do it with say more than 1 doc at a time because it may use arbitrary bandwidth and CPU. That allows for instant feeling loading of p…

You're not "combining" standards though. As other comments pointed out, this is not a subset of html. It's a separate spec, based on a subset of html, which is different enough that it's not quite compatible. For example, what's with the amp-prefixed tags? Why amp-img instead of img with data-amp- attributes? You also didn't address my first point: If you're building this for people who don't make the effort right no…

I think the other comments are wrong. Custom elements are a part of the web platform http://www.w3.org/TR/custom-elements/

We use amp-img instead of the img tag to be able to control when resources load (read not load them unless actually needed). Doing this with a different hack like is possible but a less explicit hack.

To your first point: It might have been just the right point in time, but maybe it isn't. I argue that if adoption is good users will win. It could totally fail, but then it was still worth trying.

In case you haven't tried, check out this video https://www.youtube.com/watch?v=i2_lAEzmOPo&feature=youtu.be I so much want my experience to be like that (or try g.co/ampdemo on your phone yourself).

Re: A new approach to web performance

#145

Post by scrollaway »

cramforce wrote: post #143
scrollaway wrote: post #140

Earlier quoted context omitted.

You're not "combining" standards though. As other comments pointed out, this is not a subset of html. It's a separate spec, based on a subset of html, which is different enough that it's not quite compatible. For example, what's with the amp-prefixed tags? Why amp-img instead of img with data-amp- attributes? You also didn't address my first point: If you're building this for people who don't make the effort right no…

I think the other comments are wrong. Custom elements are a part of the web platform http://www.w3.org/TR/custom-elements/ We use amp-img instead of the img tag to be able to control when resources load (read not load them unless actually needed). Doing this with a different hack like is possible but a less explicit hack. To your first point: It might have been just the right point in time, but maybe it isn't. I argu…

Good demo. The benefits are indeed attractive, but you still have not sold me on why this is a better approach than ... well, everything that's been suggested in this thread. This stuff is possible without what you're proposing, as you yourself admit. What I see amp giving is a framework in which it is impossible to "mess up", which can be beneficial but I agree with the general sentiment here: New tech has a cost to it. Learning it has a cost. Implementing it in browsers has a massive cost (because I'm sure this will eventually find its way in Chrome, which means Firefox will follow suit, which means a larger potential for technical debt and a higher bar to developing a web browser from scratch).

Like someone else said: If Google wants performance, Google can start aggressively penalizing article-type websites which make unnecessary requests etc. I know you guys already penalize slow sites, so what's wrong with that approach? Especially since such an approach has a much higher chance of actually working.

Re: A new approach to web performance

#146

Post by spacecowboy_lon »

onewaystreet wrote: post #13
radicalbyte wrote: post #3

Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user. These are systems where the read/write ratios are often 1000:1. Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated…

Because many publishers found that visitors wont wait the few extra seconds it takes to load the content on the server. They need to see something loading in their browser or they abandon the content.

I think you mean publishers built a slow site and are bemused by why they don't have any traffic.

Its a lack of repsect for techies and quality and not understanding that the web is not a glossy brochure that you can't optimize by shouting at a printer over the phone.

Re: A new approach to web performance

#147

Post by cramforce »

ducuboy wrote: post #38

What annoys me is how Google is selling this project. At least Facebook is honest about their Instant Articles. This isn't an "open standard" guys, and it's not about performance! It's about the single piece of js that's allowed on AMP pages and the amp-tags such as and that only Google controls. Performance is just the story they are selling in exchange of absolute control of the Web. After all, any publisher can ea…

First of all this is not a Google-only project. There are many partners. See e.g. https://blog.twitter.com/2015/introducing-accelerated-mobile...

supports all kinds of tracking. You just give it a URL. Ironically it does not work with Google Analytics but we'll fix that eventually. Most others should work.

currently supports these ad networks https://github.com/ampproject/amphtml/blob/master/builtins/a... We are super happy to add more. We want to support all networks.

You suggest elsewhere there is revenue sharing involved, but that is not true. amp-ad just loads an ad. This is controlled by the publishers and and their agreement with the advertiser. Google only plays a role if it happens to be the ad network (or the advertiser) involved.

Re: A new approach to web performance

#148

Post by spacecowboy_lon »

flipp3r wrote: post #54
ducuboy wrote: post #43

Earlier quoted context omitted.

AMP is just broken HTML, hardly a standard. https://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.theverge.c...

I think this tweet from the AML project lead sums up pretty well how much they thought about standards https://twitter.com/cramforce/status/651769139204259840

So its Google they cant even implement the sitemaps.org standard fully to spec or handle robots.txt files with BOM markers.

I wonder what the average Googler would make of OSI standards like x.400 and x.500.

Re: A new approach to web performance

#149

Post by cramforce »

scrollaway wrote: post #145
cramforce wrote: post #143

Earlier quoted context omitted.

I think the other comments are wrong. Custom elements are a part of the web platform http://www.w3.org/TR/custom-elements/ We use amp-img instead of the img tag to be able to control when resources load (read not load them unless actually needed). Doing this with a different hack like is possible but a less explicit hack. To your first point: It might have been just the right point in time, but maybe it isn't. I argu…

Good demo. The benefits are indeed attractive, but you still have not sold me on why this is a better approach than ... well, everything that's been suggested in this thread. This stuff is possible without what you're proposing, as you yourself admit. What I see amp giving is a framework in which it is impossible to "mess up", which can be beneficial but I agree with the general sentiment here: New tech has a cost to…

I totally agree that the "penalizing" approach is important.

But I like to present both a solution "this is how you make it fast" as well as the penalty.

If you only take AMP as a guide or tutorial that puts current best practices in a neat package that is fine with me. We are totally not claiming to have invented a new wheel.

Browsers could do what AMP does (e.g. super lazy prerendering) but I'm an impatient person and I don't like waiting for what a browser with a yearly release cycle might do.

Re: A new approach to web performance

#150

Post by bitmapbrother »

ducuboy wrote: post #38

What annoys me is how Google is selling this project. At least Facebook is honest about their Instant Articles. This isn't an "open standard" guys, and it's not about performance! It's about the single piece of js that's allowed on AMP pages and the amp-tags such as and that only Google controls. Performance is just the story they are selling in exchange of absolute control of the Web. After all, any publisher can ea…

What annoys me are people who speak out of ignorance without really knowing what they're talking about, but like to give the impression to others they do.

AMP is an open source project any publisher can use and tailor to their needs. If you don't want to factor Google into the solution then you don't have to.

But, keep on praising Facebook because you at least got their agenda right.

Post reply on HN