Top all-time · #13407
Fastersite
Personal blog · gent.ilcore.comwebprogramming
Fastersite is a personal blog at gent.ilcore.com about web and programming. Since 2011, 5 different Hacker News readers have linked it 8 times, most often “Finding memory leaks”. The last post was in 2012, but the archive is still widely read.
on web performance
Most-linked posts?
- Finding memory leaks3 people · 3 mentions · first linked 2011-08-08
What Hacker News says?
They do perform this "back-buffering" natively. When you manipulate the DOM in a modern (post-2009 or so) browser, it's just changing a pointer and flipping a dirty bit. The problem is that it's very easy to force a full recalculate of the whole page layout. Whenever you call .offsetHeight or .offsetWidth or .getComputedStyle, you're doing it. The full list of properties is about 2 dozen strong: http://gent.ilcore.c…
Comment linking /2011/03/how-not-to-trigger-layout-in-webkit.html
on “Virtual DOM in Elm”Submitted Finding memory leaks as a story · 158 points
HN discussionProblem is the DOM API can't solve this - not in the general case. Or rather, they're already solving it as well as they can. Modern browsers don't cause a reflow when you set a property: they invalidate the DOM so that it reflows at the end of the script block. However, they also have to reflow whenever you get a DOM property, because the value of that property might have changed based on the DOM manipulations you…
Comment linking /2011/03/how-not-to-trigger-layout-in-webkit.html
on “Preventing 'layout thrashing'”Submitted Fastersite: Chrome's 10 Caches as a story · 3 points
HN discussionYou can take a look at the diffs between this and what the list was in 2011 for Webkit: http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-... They look basically the same to me - this part of a browser layout engine hasn't changed much, and probably isn't likely to unless Chrome goes all GPU-rendering. And it includes Webkit browsers as well, so it's also Safari, mobile Safari, Opera, and Android Browser.
Comment linking /2011/03/how-not-to-trigger-layout-in-webkit.html
on “What forces layout/reflow in Chrome”Sometime I want to do a big, detailed blog post full of supporting data on this topic. Unfortunately, all the data I have on this I left behind at my ex-employer (Google), and I don't yet have time to write the code to compile new data. The short answer is that the DOM is not slow. Adding & removing a DOM node is a few pointer swaps, not much more than setting a property on the JS object. However, layout is slow. Wh…
Comment linking /2011/03/how-not-to-trigger-layout-in-webkit.html
on “Why is the DOM slow?”Link to the source, not some crap re-tweet page. http://gent.ilcore.com/2011/08/finding-memory-leaks.html
Comment linking /2011/08/finding-memory-leaks.html
on “a thread”Direct link: http://gent.ilcore.com/2011/08/finding-memory-leaks.html
Comment linking /2011/08/finding-memory-leaks.html
on “a thread”
