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

21–30 of 177 posts

Re: A new approach to web performance

#21

Post by TeMPOraL »

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…

> 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 thousands computers redo the computation that could be done once on a server. This has some electricity cost aggregated over all users, which we externalize to society because of a fad. You can't really skip the HTML->pixels step because of data size issues, but there's little excuse for client-side rendering of static content.

Re: A new approach to web performance

#22

Post by TeMPOraL »

userbinator wrote: post #12
firasd wrote: post #7

Earlier quoted context omitted.

About static vs. dynamic rendering on the server side, the Movable Type CMS used to do exactly as you suggest and it was difficult to make changes on large sites. Imagine if you want to change a link on a sidebar and have to re-​build every HTML page served by your CMS to do that. Caching dynamic pages is a bit of a “hybrid” system where you can just publish your new sidebar, then clear cache on the first request for…

Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that. On the other hand, doing the processing on the client side means that work would be done every single time by every single client , and the result of that work isn't even preserved. As decades of programmers have had absolutely no problem compiling software with many, many more dependent files than pa…

> On the other hand, doing the processing on the client side means that work would be done every single time by every single client, and the result of that work isn't even preserved.

Exactly! If that amount of work on server seems big, then realize that doing it client-side means dumping a million[0] times more work on the society, with all associated electricity usage.

[0] - literally; if you have 100k visitors and each visited you 10 times, that's 1M times the work that should actually have been done.

Re: A new approach to web performance

#23

Post by mseebach »

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…

But the client side rendering isn't static, and it certainly isn't 1000:1 R:W. There are different browsers on different devices, with different resolutions, pixel densities, zoom-levels, minimum font sizes, window-sizes and orientations.

Static client side rendering at 1000:1 would mean that you could render an image file once and serve it to (at least) 1000 clients.

Re: A new approach to web performance

#24

Post by manigandham »

stdbrouw wrote: post #4
manigandham wrote: post #2

What's sad is that this is just optimized HTML + CDN packaged up by Google and heralded as some big innovation. If publishers spent a few hours they could make extremely lightweight pages too (even with media and ads). Here's an AMP page: https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r...

Well, most publishers actually use fairly optimized HTML/CSS and most publishers use a CDN. But there's only so much you can do if you don't want to get rid of those 5 ad networks, 7 analytics services, 2 sidebars and just generally a whole bunch of crap that has nothing to do with the article. The innovation of Facebook instant articles and AMP isn't technical, it's that they have been able to convince publishers th…

I disagree - most publishers I've seen (including large and mid-level) have some of the most bloated HTML with megabytes(!) of javascript and CSS just for rendering + all the other stuff you mentioned. They are definitely not optimized.

I dont think there is any innovation at all with either Facebook or Google, it's all about keeping the user on their service longer and by hosting the content themselves, they increase speed and claim more user time. It's a pure monopoly play with Apple, Google, Facebook having far more leverage than publishers (who have really none these days). Pubs need traffic to survive which is why they are willing to work with this, but the revenue potential is still up in the air so long-term sustainability is not anywhere near proven. I'm not convinced that this will work as a viable model, beyond the technical implementation.

Re: A new approach to web performance

#25

Post by TeMPOraL »

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.

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

Re: A new approach to web performance

#26

Post by TeMPOraL »

mseebach wrote: post #23
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…

But the client side rendering isn't static, and it certainly isn't 1000:1 R:W. There are different browsers on different devices, with different resolutions, pixel densities, zoom-levels, minimum font sizes, window-sizes and orientations. Static client side rendering at 1000:1 would mean that you could render an image file once and serve it to (at least) 1000 clients.

Static client side rendering means you render your site as HTML+CSS+utility JS on server once, and send a saved copy to people when asked, as opposed to client-side rendering in which you send them data, a template and JS that will build all HTML in browser.

Re: A new approach to web performance

#27

Post by creshal »

mseebach wrote: post #23
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…

But the client side rendering isn't static, and it certainly isn't 1000:1 R:W. There are different browsers on different devices, with different resolutions, pixel densities, zoom-levels, minimum font sizes, window-sizes and orientations. Static client side rendering at 1000:1 would mean that you could render an image file once and serve it to (at least) 1000 clients.

> But the client side rendering isn't static, and it certainly isn't 1000:1 R:W. There are different browsers on different devices, with different resolutions, pixel densities, zoom-levels, minimum font sizes, window-sizes and orientations.

Yeees, and? Response CSS designs solve a lot of that with zero server-side computation overhead, and (compared to JS templating/render engines) minimal client-side overhead.

Re: A new approach to web performance

#28

Post by microtonal »

manigandham wrote: post #2

What's sad is that this is just optimized HTML + CDN packaged up by Google and heralded as some big innovation. If publishers spent a few hours they could make extremely lightweight pages too (even with media and ads). Here's an AMP page: https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r...

What's sad is that this is just optimized HTML + CDN packaged up by Google and heralded as some big innovation.

I think AMP is useful as a standard: setting a set of requirements to be considered an AMP page. Having such a brand plus possible beneficial treatment in search engines, will encourage publishers to adopt it.

Sometimes a strong incentive is needed to change things.

Re: A new approach to web performance

#30

Post by odiroot »

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…

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.

Post reply on HN