High performance javascript parallax
Hello!
I am Fedor furikuretsu Ananyev, web developer at Hot Dot, and today I will give some simple tips for those who want to make their JS-parallax application very, very fast.
The story will be based on the experience gained from creating the main page of our new site hotdot.pro . This page is divided into several slides, with each slide taking the size of the browser window. Each slide may or may not have floating parallax layers. The background of the page also moves according to the laws of the parallax layer.
The first, obvious problem that I want to solve is scripts.
')
- Why do we want to solve it?
Scripts are responsible for changing the position of the layer in our parallax model and making changes to the DOM. There are many layers in a more or less impressive application. And the logically closer the code in front of your eyes is to the drawing code of one layer, the more times per second it will be called by the browser and the more you will want to increase its speed.
Such mathematics motivates to keep on account every operation in frequently used code points.
The 2D model of the floating layer in the container has been tested for a long time, it is not difficult for a high school student and will be omitted in this article. What is worth noting, however, is that the rule of thumb applies to the layer:
To update the position of the layer, two operations are enough:
- Why is this rule important to us?
Because thanks to him, we do not need to construct the position of layer X with each change of the position of the viewer from the width of layer X, the position of layer X in the parent, the position of the viewer and the width of the parent. Instead of five or more operations, we only need to do the two mentioned above. It is only necessary to select the coefficient specific to the layer X and the initial displacement at the layer initialization.
For your mental state, another rule of thumb applies:
If we are optimizers who came to the world of development for browsers not so long ago, then the discovery for us will be that the drawing of elements that are even outside the screen still happens.
We are accustomed to the classic techniques in 3D engines, we can think that everything outside the screen will somehow be optimized removed from the draw queue. But it will not be removed.
Corollary:
If you have the ability to hide (that is, impose display: none css-rules) at the moment X those elements that do not appear on the screen at the moment X - please, do it in all possible ways.
In the case of parallax, the elements are slides, and for our luck, the definition of the property “is outside the screen” is rather trivial.
We are also well aware that when we switch to the
It is very valuable to know that a very small change in the DOM — including nodes closer to the leaves than to the root — causes a very expensive redrawing of everything and everything on the screen.
- What does this mean for me in practice?
If, in the process of sliding the user through our page, we leave some harmless little animation to be played in a slide that is far from us and hidden from us , the browser will start the process of rebuilding our page and the subsequent redrawing. Runs every time the animation takes a step. And this is when the user scrolls the page, and the processor tries its best to move layers in large quantities quickly. The frequency of the step, for example, in jQuery is 13 milliseconds. Brace yourselves : it will hurt.
- Is it possible to change at least something while the user slides on the page?
Yes. You can change the position of elements without large expenses, because such changes will not cause redrawing, but only re-composition of elements. Recomposition occurs very quickly, does not require redrawing of the layers and can be done entirely on a video card, which definitely represents a benefit for us.
Moving the layers, however, our ability to modify the DOM ends up if we monitor performance.
Beautiful solution:
Disable all animations while the user moves around the page. So very expensive for the animation processor will be played only when the user does not move anywhere, and the parallax stays in statics. When the user moves, the processor will focus only on moving the parallax layers.
Let's look at Chrome statistics for two versions of our studio page: with optimizations disabled and enabled . Let's be generous and we will not turn off the optimized JS in the first version, and let us leave to it absolutely small drawing optimizations.
The test was brief. I drove the site from left to right, not in a hurry. But therefore the test was also very cruel with the second version , because it must constantly hide and show, hide and show slides!
What do we see first? The entire first chart is filled with green. Very, very much drawing and redrawing every frame. The huge work for the browser, done on the central processor, and very unpleasant feelings for the user.
On the second graph of green at times less. Much more empty gray rectangles. Which is on the first chart, but not at all that high. What do they mean? The fact that in the second case, on very, very many frames, the browser does its job so quickly that it can do something else most of the time allotted to the frame. In the first case, the browser barely has time to take a breath.
Rare cases of high color columns in the second graph , when the browser spends a lot of time to work, are due to the need to switch the visibility of the slides and are the price we pay for amazing performance when sliding back and forth between two slides.
Let's look at the colossal difference in framerate: if the browser rarely gives out more than thirty frames per second on the first chart , then it rarely gives less than thirty frames per second on the second chart .
This is a great result.
Techniques that we considered, demanded a lot of work and thought.
But they literally pulled us out of the swamp of brakes into the realm of productive web applications.
I hope that my work will be useful for you in your projects, and thank you for your attention to the development of our studio.
Good luck!
I am Fedor furikuretsu Ananyev, web developer at Hot Dot, and today I will give some simple tips for those who want to make their JS-parallax application very, very fast.
The story will be based on the experience gained from creating the main page of our new site hotdot.pro . This page is divided into several slides, with each slide taking the size of the browser window. Each slide may or may not have floating parallax layers. The background of the page also moves according to the laws of the parallax layer.
It all starts with JS
The first, obvious problem that I want to solve is scripts.
')
- Why do we want to solve it?
Scripts are responsible for changing the position of the layer in our parallax model and making changes to the DOM. There are many layers in a more or less impressive application. And the logically closer the code in front of your eyes is to the drawing code of one layer, the more times per second it will be called by the browser and the more you will want to increase its speed.
Example:
If there are five slides in our parallax, there are on average three layers in each of the slides, and we update the parallax with the minimum acceptable movie frequency of 25 FPS, then your code responsible for rendering one layer will be called
5 × 3 × 25 = 375 times per second.
Such mathematics motivates to keep on account every operation in frequently used code points.
The 2D model of the floating layer in the container has been tested for a long time, it is not difficult for a high school student and will be omitted in this article. What is worth noting, however, is that the rule of thumb applies to the layer:
To update the position of the layer, two operations are enough:
- multiplying some constant coefficient inherent in this layer by its displacement within the parent
- adding the result of the first operation to some constant initial position inherent to this layer.
- Why is this rule important to us?
Because thanks to him, we do not need to construct the position of layer X with each change of the position of the viewer from the width of layer X, the position of layer X in the parent, the position of the viewer and the width of the parent. Instead of five or more operations, we only need to do the two mentioned above. It is only necessary to select the coefficient specific to the layer X and the initial displacement at the layer initialization.
For your mental state, another rule of thumb applies:
When you perform two operations instead of five + 375 times per second,
you feel much better.
The browser draws faster than your familiar freelancer, but still not fast enough
If we are optimizers who came to the world of development for browsers not so long ago, then the discovery for us will be that the drawing of elements that are even outside the screen still happens.
We are accustomed to the classic techniques in 3D engines, we can think that everything outside the screen will somehow be optimized removed from the draw queue. But it will not be removed.
Corollary:
If you have the ability to hide (that is, impose display: none css-rules) at the moment X those elements that do not appear on the screen at the moment X - please, do it in all possible ways.
In the case of parallax, the elements are slides, and for our luck, the definition of the property “is outside the screen” is rather trivial.
Video card
- In webkit and gecko browsers, you get an instant performance boost if you organize the movement of absolutely spaced layers using
translate3dinstead of left. - In Opera, only the two-dimensional version is available -
translate. In my case, the performance gain from its use was questionable. - Internet Explorer perfectly does all other browsers when using the classic left to offset layers. Quite interestingly, in my case, using
translate3dreduced its performance.
We are also well aware that when we switch to the
translate we will lose the ability to set the coordinates or offset in percent. Let us keep in mind that in some cases this restriction is rather painful.Disability
It is very valuable to know that a very small change in the DOM — including nodes closer to the leaves than to the root — causes a very expensive redrawing of everything and everything on the screen.
- What does this mean for me in practice?
If, in the process of sliding the user through our page, we leave some harmless little animation to be played in a slide that is far from us and hidden from us , the browser will start the process of rebuilding our page and the subsequent redrawing. Runs every time the animation takes a step. And this is when the user scrolls the page, and the processor tries its best to move layers in large quantities quickly. The frequency of the step, for example, in jQuery is 13 milliseconds. Brace yourselves : it will hurt.
- Is it possible to change at least something while the user slides on the page?
Yes. You can change the position of elements without large expenses, because such changes will not cause redrawing, but only re-composition of elements. Recomposition occurs very quickly, does not require redrawing of the layers and can be done entirely on a video card, which definitely represents a benefit for us.
Moving the layers, however, our ability to modify the DOM ends up if we monitor performance.
Beautiful solution:
Disable all animations while the user moves around the page. So very expensive for the animation processor will be played only when the user does not move anywhere, and the parallax stays in statics. When the user moves, the processor will focus only on moving the parallax layers.
Statistics
Let's look at Chrome statistics for two versions of our studio page: with optimizations disabled and enabled . Let's be generous and we will not turn off the optimized JS in the first version, and let us leave to it absolutely small drawing optimizations.
The test was brief. I drove the site from left to right, not in a hurry. But therefore the test was also very cruel with the second version , because it must constantly hide and show, hide and show slides!
What do we see first? The entire first chart is filled with green. Very, very much drawing and redrawing every frame. The huge work for the browser, done on the central processor, and very unpleasant feelings for the user.
On the second graph of green at times less. Much more empty gray rectangles. Which is on the first chart, but not at all that high. What do they mean? The fact that in the second case, on very, very many frames, the browser does its job so quickly that it can do something else most of the time allotted to the frame. In the first case, the browser barely has time to take a breath.
Rare cases of high color columns in the second graph , when the browser spends a lot of time to work, are due to the need to switch the visibility of the slides and are the price we pay for amazing performance when sliding back and forth between two slides.
Let's look at the colossal difference in framerate: if the browser rarely gives out more than thirty frames per second on the first chart , then it rarely gives less than thirty frames per second on the second chart .
This is a great result.
Techniques that we considered, demanded a lot of work and thought.
But they literally pulled us out of the swamp of brakes into the realm of productive web applications.
I hope that my work will be useful for you in your projects, and thank you for your attention to the development of our studio.
Good luck!
Source: https://habr.com/ru/post/175341/
All Articles