So I have a project where I'm trying to optimize a fairly plex Javascript function to the max - partly this is due to the fact that its supposed to run on smart-phones (Webkit) and every little bit counts.

I've been using various debugging and timing techniques to go through my code and rewrite everything that might be slow - like parts of jQuery based stuff where native might do better and so on. What the function does is basically take a string of html text and cut it up to fit exactly into 3 DIVs that do not have fixed position or size (a client templating mechanism).

At the moment the entire function takes around 100ms to execute in iPads browser (but in the production environment I need to ideally execute it 200 times) and the problem is that out of those 100ms at least 20ms are because of this single line of code (in 3 loops):

var maxTop = $(cur).offset().top + $(cur).outerHeight();

"cur" is just a reference to a container DIV element and the line above is calculating its bottom position (so where my text should break). From looking at the offset jQuery code I understand it uses getBoundingClientRect and even eliminating jQuery offset/sizing and calling it directly does nothing to speed it up - so its getBoundingClientRect fault (at least in Webkit). I did a bit of research on it and I understand it causes layout redraw.

But still - can't believe that I do multiple DOM clears/clones/appends and all of those are much faster than a simple element position lookup? Any ideas out there? Maybe something webkit specific? Or something that doesn't cause redraw?

Would much appreciate it!

So I have a project where I'm trying to optimize a fairly plex Javascript function to the max - partly this is due to the fact that its supposed to run on smart-phones (Webkit) and every little bit counts.

I've been using various debugging and timing techniques to go through my code and rewrite everything that might be slow - like parts of jQuery based stuff where native might do better and so on. What the function does is basically take a string of html text and cut it up to fit exactly into 3 DIVs that do not have fixed position or size (a client templating mechanism).

At the moment the entire function takes around 100ms to execute in iPads browser (but in the production environment I need to ideally execute it 200 times) and the problem is that out of those 100ms at least 20ms are because of this single line of code (in 3 loops):

var maxTop = $(cur).offset().top + $(cur).outerHeight();

"cur" is just a reference to a container DIV element and the line above is calculating its bottom position (so where my text should break). From looking at the offset jQuery code I understand it uses getBoundingClientRect and even eliminating jQuery offset/sizing and calling it directly does nothing to speed it up - so its getBoundingClientRect fault (at least in Webkit). I did a bit of research on it and I understand it causes layout redraw.

But still - can't believe that I do multiple DOM clears/clones/appends and all of those are much faster than a simple element position lookup? Any ideas out there? Maybe something webkit specific? Or something that doesn't cause redraw?

Would much appreciate it!

• javascript
• jquery
• performance
• html
• webkit

• 3 You could try cur.offsetTop and cur.offsetHeight, but those will probably suffer from the same problems because they still force redraw. Generally, best practice is to do all of your measurements all together, and not interlace them with operations that change the layout. And of course, if you know any values will be constant frame-to-frame, store them in local variables or in custom properties on the DOM object. Or if you can get away with it, I've used a strategy before of measuring something every 30 frames or so to see whether it changed. Depends on your application. – sethobrien Commented Oct 5, 2011 at 16:43
• 1 @sethobrien yeah thanks, thats what I'm trying now - found this jsperf./getelementpositiontest3 and it does appear that weirdly enough the older offsetTop/offsetHeight properties are a bit faster then getBoundingClientRect... thanks for the tip about grouping! Can't approximate unfortunately as my pages are based on (different) templates. – Michael Commented Oct 5, 2011 at 17:09

2 Answers 2

Since I also ran into a similar problem, I had a loop in which I was fixing a series (sometimes 1000+) of DOM elements (from float to absolute). I immediately applied the fixed styling to the elements, which was a big mistake to make: Every time something is written to the DOM the style has to be recalculated when your script asks for a position of an element. Hence, do all your reading, and then all your writing, even if that means two separate loops (you can safely write to the dataset property of your DOM element).

See also: http://gent.ilcore./2011/03/how-not-to-trigger-layout-in-webkit.html

did you try:

var maxTop = cur.offsetTop + cur.offsetHeight;

?

point is, offsetTop and offsetHeight are native dom properties, and so access should be faster than through a function.