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

41–50 of 177 posts

Re: A new approach to web performance

#41

Post by iopq »

odiroot wrote: post #30
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…

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.

Opera did something like this, but instead of PNGs they gave custom markup that is precomputed so that the flip phones don't have to do layout. Or something like that. Opera mobile had server farms rendering content and re-compressing large images.

Re: A new approach to web performance

#42

Post by mattmanser »

This really comes across as some sort of elaborate joke. Their solution to a slow web is to circumvent the standards and use a javascript library?

My only contribution to the conversation is utter bewilderment someone thought this would be a good idea.

The improvements are because they've removed everything.

Also, side note but I thought there was already a proposal in HTML for reusable elements?

Re: A new approach to web performance

#43

Post by ducuboy »

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 is just broken HTML, hardly a standard.

https://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.theverge.c...

Re: A new approach to web performance

#44

Post by TeMPOraL »

Gigablah wrote: post #32
TeMPOraL wrote: post #25

Earlier quoted context omitted.

Then show them an AJAX spinner while fetching the static site in the background.

That's what one of the Blogger templates does, and I've seen people on HN complain about having to see an AJAX spinner just to load a blog.

Yeah, I'm such a complainer too. Blogs are one of the last places you should ever see such a spinner because they're just static content with sidebars. There should be little to none client-side rendering involved. And the spinner on Blogger is only a (very visible) symptom of the bigger problem - the whole site is incredibly slow and resource heavy.

Re: A new approach to web performance

#45

Post by NicoJuicy »

odiroot wrote: post #30
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…

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.

viewport size can only be detected when the page is loaded... Afterwards, the images are loaded.

It feels slow ;)

Re: A new approach to web performance

#46

Post by ducuboy »

mattmanser wrote: post #42

This really comes across as some sort of elaborate joke. Their solution to a slow web is to circumvent the standards and use a javascript library? My only contribution to the conversation is utter bewilderment someone thought this would be a good idea. The improvements are because they've removed everything. Also, side note but I thought there was already a proposal in HTML for reusable elements?

No joke, it's all about the money. https://news.ycombinator.com/item?id=10358945

Re: A new approach to web performance

#47

Post by pavlov »

AMP reminds me of "i-mode", a Japanese mobile HTML variant originally launched in 1999 that was hugely popular in the country for many years:

https://en.wikipedia.org/wiki/I-mode

Then, as now, regular HTML pages were considered too slow and complicated for mobile phones. I-mode was conceived by the large network operator NTT Docomo.

The big difference is that NTT Docomo were the exclusive gatekeepers for publishing content. Google also gives you the option of publishing AMP content on their CDN, but it's not mandatory.

Re: A new approach to web performance

#48

Post by mhw »

This is obviously Google's response to Facebook's Instant Articles and Apple's News. Behind all the technology is the main business goal of delivering a content platform that has the sponsoring company's ad network baked in to it.

Re: A new approach to web performance

#49

Post by pjc50 »

alkonaut wrote: post #8
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…

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…

No, the end product is an ad payment to the company producing and serving the articles.

That's where all the junk comes from: tracking the user and trying to upsell them into a mobile app so you can get more personal data and a spot on their home screen.

Re: A new approach to web performance

#50

Post by h679496 »

Confusion wrote: post #37
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…

Well, I would say the common argument is that you send an intermediate format to decouple yourself from the specifics of the receiver. HTML is an intermediate format and the client is free to render it how it sees fit for the device on which it is running, which allows compatibility with newer and different clients. It's like shipping some intermediate bytecode doesn't seem to make sense, because every client needs t…

Isn't it obvious? You just need an optimized templating engine that is implemented in the browser instead of js.
Post reply on HN