More benefits of using translate3d()

1 Comment

So, I’m working on some code for doing a progressive render for HTML.  What that means is that rather than using pagination a user will simply scroll down and when they get to the bottom more data will be rendered at the bottom of the screen.  I was playing around with pagination and really did not like the way it was looking.  So I did a Google search and I came upon a blog post that said that for modern web applications you really shouldn’t use pagination.  Google does, but Google’s goal is to get you the information you need on the first page, not page 606.  So progressive rendering really doesn’t matter.  Google Images, on the other hand, does use progressive rendering.

The reason for this is that you can get something up (the shell of the site) and get small pieces of information up as they are needed rather than loading it all at once.  This drastically increases the overall render and load time, but because there is data on the screen quicker it makes for a better user experience.  The user can start interacting with the screen almost immediately while lists of things load.

The progressive rendering was working quite nicely.  You got close to the bottom of the screen and the additional content would magically appear.

Except on my iPad2.Chrome, Safari and IE all rendered the page fine.  But that’s on the desktop.  On my iPad the content would load but it would be another second or two before the images popped up.  And it didn’t happen on my Galaxy S3 or my S1.

Earlier I wrote about how you can use translate3d() to suggests the use of the GPU for rendering CSS3 animations.  Works beautifully.  And since this was a rendering issue I figured I’d see what the GPU had to say with the DIV element that I was appending the data to.  So I added style=”-webkit-transform: translate3d(0,0,0); ” to the container DIV and voila!  The images were rendered immediately.

I don’t know why the images weren’t loading quickly beforehand and I was quite ready to blame Apache (until I switched over to Nginx and the same thing happened).  But adding  -webkit-transform made it work nicely.

Transform performance on mobile applications

Leave a comment

Just a quick one today.  I have read on several web pages that if you want to speed up the rendering of your site that you need to add -webkit-transform: translate3d(0,0,0) to the page elements to have the browser use the GPU to render the page instead of the CPU.

I tried this trick several times and it never seemed to work.  But I think that today I figured out why not.

I would apply this trick to a container element that houses the things that were animating.  This may not seemed to have been the correct way of doing it.  I had a DIV with a UL and several LI elements in it.  I applied the trick to the DIV under the assumption that it would accelerate everything in the container.

I think I was wrong.  It almost looks like you need to apply the trick to the individual element that you are animating.  In my case, the LI elements because they start out with a height of 0px and are expanded to Xpx.  The animations worked fine beforehand, but as soon as it was coupled with automated scrolling of the container the performance would drop tremendously down to around 6-8 frames per second.  When I moved the translate3d() trick from the DIV to the LI elements the animations and the scrolling became quite smooth.

So the lesson of the day is that if you want to use the GPU trick, apply it directly to the elements you are animating and not their container.

Additionally, it seems like applying the GPU trick also messes up CSS fixed position elements.  In other words, position: fixed ends up being not so.