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

71–80 of 177 posts

Re: A new approach to web performance

#71

Post by spankalee »

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…

AMP tags are custom elements, they're not invalid. See http://www.w3.org/TR/custom-elements/

Re: A new approach to web performance

#72

Post by JustSomeNobody »

I feel this is Google's response to Apple's ad blocking push (maybe push is too much here, what's a better word?).

Neither AMP nor ad blocking are what is needed. We need sensible ads that are unobtrusive. We need web pages that do not track the consumer. We need smarter designs that don't use huge images everywhere. We need JS where it is needed and not just because it's cool.

We don't need two behemoths fighting over the control of our web.

Re: A new approach to web performance

#74

Post by spankalee »

TazeTSchnitzel wrote: post #66

This isn't an HTML subset, it's some freakish pseudo-HTML JS library weirdness. Why not define an actual subset of HTML? You know, like XHTML Strict Mode? Why must everything be a JavaScript library?!

It _is_ an HTML (and CSS) subset.

JavaScript is used to implement custom elements, like amp-image. That's just how custom elements work.

Re: A new approach to web performance

#75

Post by uptown »

masklinn wrote: post #69
odiroot wrote: post #30

Earlier quoted context omitted.

Crazy thought: detect viewport size on first load and serve pre-rendered PNGs to skip the rendering on client part. Someone probably already developed that.

That is essentially what Opera Mini does/did: requests went through Opera's render farm which would request page and render them (with adaptations) to a packed binary format and send that back to the device. There was also rudimentary JS support in the rendering farm, the device essentially got an image with an interaction map, and interactions would be sent to the server for processing. Not very configurable though,…

Not to mention the enormous privacy trade-off of having Opera monitor and screenshot every webpage you visit.

Re: A new approach to web performance

#76

Post by ducuboy »

scrollaway wrote: post #70
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 are they selling, exactly? Why does this need to be a framework, with js and all that? I'm not asking cynically, and following it up with "oh, they should just do x instead".... I legitimately do not understand what's going on here. What's the added functionality? I read the article twice, I don't get it. I'm going through the spec, I don't get it. I looked at the article source, I really don't get it, it's just…

A platform for sharing ad revenue.

They deliver all the amp-ads via that single piece of js, and will share some of the revenue with the publishers. It's not a bad idea after all, if only they had presented it for what it is: a Google fork of the Web. The "performance story" is just the bullshit.

Re: A new approach to web performance

#77

Post by pjc50 »

ducuboy wrote: post #76
scrollaway wrote: post #70

Earlier quoted context omitted.

What are they selling, exactly? Why does this need to be a framework, with js and all that? I'm not asking cynically, and following it up with "oh, they should just do x instead".... I legitimately do not understand what's going on here. What's the added functionality? I read the article twice, I don't get it. I'm going through the spec, I don't get it. I looked at the article source, I really don't get it, it's just…

A platform for sharing ad revenue. They deliver all the amp-ads via that single piece of js, and will share some of the revenue with the publishers. It's not a bad idea after all, if only they had presented it for what it is: a Google fork of the Web. The "performance story" is just the bullshit.

If they're putting ads in custom tags that makes it extremely easy to block them.

I think it's nothing so sinister as a "fork of the web", but a badly thought out approach of going back to faster loading web1.0 by recognizing that quite a lot of JS adds no value to the end user.

Re: A new approach to web performance

#78

Post by moonchrome »

TeMPOraL wrote: post #21
alkonaut wrote: post #8

Earlier quoted context omitted.

It's easy to forget that html isn't the end product, the end result is lit pixels on some screen (usually). If we send json then that needs to be converted to html and that html needs to be layout and rendered. If we send html we just skip the first step. Displaying a web page isn't "free" for the client just because it's html. The question is this: what kind of overhead is a template rendering task (in js) for a mod…

> It's easy to forget that html isn't the end product, the end result is lit pixels on some screen (usually). If we send json then that needs to be converted to html and that html needs to be layout and rendered. If we send html we just skip the first step. Displaying a web page isn't "free" for the client just because it's html. JSON->HTML rendering may be only one step, but by not skipping it, we're making hundred…

Who says you're doing JSON->HTML ? Both HTML and your data format need to get deserialized to DOM - depending on use case it can be faster/smaller to do the deserialization in JS from some format rather than using browser HTML parser.

HTML is actually non-trivial to parse and isn't really optimized for anything.

Re: A new approach to web performance

#79

Post by noir_lord »

betageek wrote: post #19

I'm tremendously not keen on this, but am willing to be persuaded otherwise. I don't want to have to build my sites using Google's AMP framework and their custom elements just to get good SEO. I don't want to cache my content in Google's network so they can 1) track everything my users are doing without any indication on the front end and b) start serving ads from the cache and make every ad blocker stop working over…

No, this is exactly my concern with this as well, particulary the ad-blocker thing (most sites already use google analytics).

Re: A new approach to web performance

#80

Post by JustSomeNobody »

pjc50 wrote: post #51
microtonal wrote: post #18

Earlier quoted context omitted.

Quite a bold decision there! Ultimately this will fail, of course, because the vast majority of sites that attempt to make money will need third-party scripts in some form. I don't think it will necessarily fail, if AMP has a good ad story. I think some publishers realize that ad blocking is taking off in an accelerated pace since iOS 9. If they have to choose between a universe between no ad revenue (because ad bloc…

"Google is not yet sure exactly how advertising will work within AMP" says that article.

They can say that, but this is clearly targeted at the ad blocking conversation that is occurring.
Post reply on HN