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

Page Weight Matters (2012)

blog.chriszacharias.com

Post reply on HN
Print view View original

161–170 of 171 posts

Re: Page Weight Matters (2012)

#161

Post by blakeyrat »

vans wrote: post #108
geocar wrote: post #87

Earlier quoted context omitted.

They know why readers complain. They wish you understood their perspective better. A significant problem is that content costs a certain amount of money to be produced, and web content is unable to command those prices. Ad fraud is a big part of it, and some of the companies in the best position to solve it (like Google) are benefitting so handsomely from ad fraud that I can't imagine them stopping it. Ad blockers wi…

I'm sorry, but watching an ad isn't just a payment like you do with money. It's a rape of your mind. It needs your personal data, to rape your brain deeper. So i block ads, not to see content, but because ads don't deserve to exist.

A rape of your mind?

Wow. Well, I'm glad you have your feet anchored down here in reality and aren't exaggerating at all.

Re: Page Weight Matters (2012)

#162

Post by vans »

sosborn wrote: post #145
vans wrote: post #108

Earlier quoted context omitted.

I'm sorry, but watching an ad isn't just a payment like you do with money. It's a rape of your mind. It needs your personal data, to rape your brain deeper. So i block ads, not to see content, but because ads don't deserve to exist.

> It's a rape of your mind. This is perhaps the most ridiculous comment I have read this afternoon.

Read more about ads, their perception by our brain, how they work and how they are designed to bypass our consciousness. Next, understand the concept of metaphor. And then, come back... or not.

Re: Page Weight Matters (2012)

#163

Post by spion »

acdha wrote: post #98
spion wrote: post #42

Earlier quoted context omitted.

JavaScript isn't the problem, but it seems to always take the blame. And its not even slow. Here are a couple of real culprits: * Advertising / analytics / social sharing companies. They deliver a boatload of code that does very little for the end-user. * REST and HTTP 1 in combination. A page needs many different types of data. REST makes us send multiple requests for different kinds of data, often resulting with th…

> * The DOM. Its slow and full of old cruft that takes up memory and increases execution time. I'm not going to say that the DOM is wonderful but … have you actually measured this to be a significant problem? Almost every time I see claims that the DOM is slow a benchmark shows that the actual problem is a framework which was marketed as having so much magic performance pixie dust that the developer never actually pr…

Good point. Lets see:

http://jsfiddle.net/55Le4ws0/

vs

http://jsfiddle.net/nem6tnv1/

Initialising about 300K invisible DOM nodes containing 3 elements, each with 3-character strings is ~15 times slower than initialising an array of 300K sub-arrays containing 3 elements, each being a 3-character string.

Additionally, paging through the created nodes 2K at a time by updating their style is just as slow as recreating them (the console.time results say something different, but the repaint times are pretty much the same and this is noticeable on slower computers or mobile.)

Thats a single benchmark that raises a few questions at best. But I think React put the final nail in the coffin: their VDOM is implemented entirely in JavaScript, and yet its still often faster to throw away, recreate, diff entire VDOM trees and apply a minimal set of changes, rather than do those modifications directly on the DOM nodes...

Re: Page Weight Matters (2012)

#165

Post by spion »

phamilton wrote: post #106
spion wrote: post #49

Earlier quoted context omitted.

Perhaps. But maybe, if you add googleads, amazon adsystem, moatads, rubicon project, taboola, scorecardresearch, krdx etc [1], then you start wondering why are users using adblockers, so you add pagefair, and at that point you want to find out what works better so you add optimizely... maybe, just maybe, at that point, you're actually losing money because your page is so damn slow, rather than getting more because of…

There's actually a lot of momentum on this from with the IAB (standards body for online advertising). The goal is to separate content from analytics. The result would enable publishers to prioritize loading the content before loading analytics.

Hmm, cool, didn't know they were working on it. That should help.

Re: Page Weight Matters (2012)

#166

Post by kragen »

titzer wrote: post #158
kragen wrote: post #133

Earlier quoted context omitted.

What would be super awesome would be a daily drumbeat about how to slim down and simplify applications, with working, open-sourced code. Here, I'll beat a drum a little. Maybe it will inspire somebody. I just wrote this tiny text-rendering engine, mostly yesterday at lunch. On one core of my laptop, it seems able to render 60 megabytes per second of text into pixels in a small proportional pixel font, with greedy-alg…

Impressive!

Thank you, but I don't think it's impressive! It's still nearly an order of magnitude slower than memcpy(). But if we want simpler systems, I think doing experiments like this is a big part of how to get there.

Re: Page Weight Matters (2012)

#167

Post by acdha »

spion wrote: post #163
acdha wrote: post #98

Earlier quoted context omitted.

> * The DOM. Its slow and full of old cruft that takes up memory and increases execution time. I'm not going to say that the DOM is wonderful but … have you actually measured this to be a significant problem? Almost every time I see claims that the DOM is slow a benchmark shows that the actual problem is a framework which was marketed as having so much magic performance pixie dust that the developer never actually pr…

Good point. Lets see: http://jsfiddle.net/55Le4ws0/ vs http://jsfiddle.net/nem6tnv1/ Initialising about 300K invisible DOM nodes containing 3 elements, each with 3-character strings is ~15 times slower than initialising an array of 300K sub-arrays containing 3 elements, each being a 3-character string. Additionally, paging through the created nodes 2K at a time by updating their style is just as slow as recreating th…

It's not useful to compare the DOM to a simple array which doesn't do most of the real work which you need to do. Comparing rendering that text using canvas or WebGL would be closer if it also had a layout engine, dynamic sizing, full Unicode support, etc.

Similarly, React is significantly slower – usually integer multiples – than using the DOM. The only times where it's faster are cases where the non-React code is inefficiently updating a huge structure using something like innerHTML (which is much slower than using the DOM) and React's diff algorithm is instead updating elements directly. If you're using just the DOM (get*, appending/updating text nodes instead of using innerHTML, etc.) there's no way for React to be faster because it has to do that work as well and DOM + scripting overhead is always going to be slower than DOM (Amdahl's law).

The reason to use React is because in many cases the overhead is too low to matter and it helps you write that code much faster, avoid things like write/read layout thrashing, and do so in a way which is easier to maintain.

Re: Page Weight Matters (2012)

#168

Post by spion »

acdha wrote: post #167
spion wrote: post #163

Earlier quoted context omitted.

Good point. Lets see: http://jsfiddle.net/55Le4ws0/ vs http://jsfiddle.net/nem6tnv1/ Initialising about 300K invisible DOM nodes containing 3 elements, each with 3-character strings is ~15 times slower than initialising an array of 300K sub-arrays containing 3 elements, each being a 3-character string. Additionally, paging through the created nodes 2K at a time by updating their style is just as slow as recreating th…

It's not useful to compare the DOM to a simple array which doesn't do most of the real work which you need to do. Comparing rendering that text using canvas or WebGL would be closer if it also had a layout engine, dynamic sizing, full Unicode support, etc. Similarly, React is significantly slower – usually integer multiples – than using the DOM. The only times where it's faster are cases where the non-React code is i…

Most of the elements are hidden via display:none - there is no layout work to be done for them whatsoever. The rest of the overhead seems to lie entirely in allocating a lot of extra data per node.

Also, total time to repaint seems to be equally fast whether we're recreating the entire 2K rows from scratch or changing the display property of 4K rows. That seems concerning to me.

But yes, a more fair comparsion would be to write a WebGL or Canvas based layout engine in JS. If its less than 4 times slower (its JS after all), then the DOM is bloated.

Re: Page Weight Matters (2012)

#169

Post by spyder »

kuschku wrote: post #65
nostrademons wrote: post #56

When I joined Google in 2009, we were on the tail-end of a latency optimization kick that Larry had started in 2007. At the time, we had a budget of 20K gzipped for the entire search results page. I remember working on the visual redesign of 2010, where we had increased the page weight from 16K to 19K and there was much handwringing at the higher levels about how we were going to blow our entire latency budget on one…

Remember, http://google.com/custom still loads instantly ;)

For me, only the first page load is faster but the actual search is slower compared to the full version with AJAX for the instant search (around 400 ms for /custom vs. 80 ms ajax response).

Re: Page Weight Matters (2012)

#170

Post by acdha »

spion wrote: post #168
acdha wrote: post #167

Earlier quoted context omitted.

It's not useful to compare the DOM to a simple array which doesn't do most of the real work which you need to do. Comparing rendering that text using canvas or WebGL would be closer if it also had a layout engine, dynamic sizing, full Unicode support, etc. Similarly, React is significantly slower – usually integer multiples – than using the DOM. The only times where it's faster are cases where the non-React code is i…

Most of the elements are hidden via display:none - there is no layout work to be done for them whatsoever. The rest of the overhead seems to lie entirely in allocating a lot of extra data per node. Also, total time to repaint seems to be equally fast whether we're recreating the entire 2K rows from scratch or changing the display property of 4K rows. That seems concerning to me. But yes, a more fair comparsion would…

Also, remember that my position is that most applications are limited by other factors before you hit the DOM.

I certainly would expect that you could beat the DOM by specializing – e.g. a high-speed table renderer could make aggressive optimizations about how cells are rendered, like table-layout:fixed but more so – but the more general-purpose it becomes the more likely you'd hit similar challenges with flexibility under-cutting performance.

The most interesting direction to me are attempts to radically rethink the DOM implementation – the performance characteristics of something like https://github.com/glennw/webrender should be different in very interesting ways.

Post reply on HN