![]() ![]() …but that code looked unfinished and was commented out. Looking at the code, I could see that there had been some effort in trying to do the correct thing by caching image references and then attaching one scroll event listener that looped through all parallax images. Don’t put scroll/resize event handlers inside a loop On scroll translate3d’s y value is updated for only the currently visible image ( creating a parallax effect). Inside a scroll event handler there is a “visibility” check, so that only one parallax image is visible when user scrolls. Each new div element has CSS transform: translate3d(0px, y, 0px) set, where y is the vertical position for parallax effect in pixels (e.g. On Javascript side jQuery is used to loop through those elements and read a data- attribute that holds a filename for an image.Įach parallax background image is then asynchronously loaded with Javascript by creating a new img element and setting the filename to its src attribute.Ĭreated image elements get appended to a new div element that is appended to the page. There are div elements on the page that all share the same. Let me try to explain the parallax scrolling technique that the website is using. * If you are not familiar with the timeline view in Chrome dev tools, take a look at the official documentation (helps to understand the images in this blog post). The bad thing is that there are three long, low FPS bars (< 30 FPS) in a row for each parallax image. Longer bars (that go above the 30 FPS mark) happen when a parallax background image gets shown. The y-axis of the image: green color of the bars indicate that the browser mostly spends time on doing “paint”: painting the content on user’s screen. The x-axis of the image: represents time, in this case something close to 5 seconds of scrolling. It is better that I explain what is going on here. This is the initial FPS recording of the website:* Obviously if you have things moving as you scroll, like in a parallax site, then you’re potentially damaging a large area, possibly across multiple layers, and this can result in a lot of expensive paint work.Ĭhrome’s developer tools help a lot when investigating problems like this, so I used Cmd + Opt + J ( Ctrl + Shift + J on Windows) to open dev tools on the page and went to “Timeline” and clicked “Frames”. By grouping things into layers we need only update that specific layer’s texture when something inside that specific layer has changed, and where we can we want to only paint and rasterize the part of a render layer’s texture that’s been damaged rather than the whole thing. …Whenever you scroll a page the browser will probably need to paint some of the pixels in those layers (sometimes called compositor layers). HTML5 rocks article called “Scrolling Performance” gives some explanation for low parallax scrolling FPS: It can be caused by almost anything related to your page: images, CSS or Javascript (or all of them). Finding out what is wrongįirst of all, what causes bad scrolling performance (low FPS)? Well, that is a tricky question. I’ll show you five fixes that give the website a nice performance boost. I was interested to see what I could do to increase performance by modifying the original code as little as possible. Why? Simply because it is a live website and they can change their parallax implementation at any moment, and that would probably distract people reading this blog post. I’m not going to link to that website or tell you its name. I suspected that there would be room for improvement in their parallax implementation, and I wanted to take a look to see if there was anything I could do to improve it. ![]() One thing that I immediately noticed was that the scrolling FPS of that page was really bad. I recently visited a parallax scrolling website that was just one of thousands of different parallax scrolling websites out there.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |