I can’t stress how important this is if you’re attempting a more complicated animation. You want to avoid the situation where you’ve spent several days building an animation, only to discover at the 11^th hour that it doesn’t run well in a browser. At that stage of the game, you’ll have a very difficult time determining the point at which things became too complicated or what you should do to attempt to fix the performance issues.

If instead you export frequently after making significant changes, you’ll be less likely to waste days building a bad animation and you’ll be able to identify and resolve issues before it’s too late.

Let’s imagine that you want to make an animation with falling snow and you want each snowflake to have some variation.

One approach could be to make 50 different snowflakes, each as a highly detailed transparent image. You could then import them, scale them each to a different size, and animate them individually so that they fall and rotate at the same time.

While this might create a realistic-looking snowfall effect, it does so in a way that creates a lot of strain on the browser. Each snowflake has to be held separately in memory, and then each one must be translated during each step of the animation.

Another approach that could accomplish something very similar is to create one large image with snowflakes of different designs, sizes, and rotations, and simply animate it so that it moves downward, thus creating the illusion of falling snow. This approach requires much less effort on behalf of the browser and would allow you to create several additional animated elements in your animation before reaching its performance limitations.

If you’ve developed anything for the Web in the past, you know the value of maintaining a low kilobyte weight to ensure fast load times. Wallaby exports your assets in the same form that you include them in your project and makes no effort to appropriately size or compress them beyond what you have prepared. Make sure you apply the same care and consideration to preparing and handling the assets for animation as you would for anything else. For example, you would want to avoid including needlessly large or uncompressed images if the way in which you are using those images doesn’t necessitate such a high quality.

Naturally the browsers and devices that your audience is using aren’t all created equally.

Here’s an example. Safari, unlike Chrome, supports GPU acceleration, giving it some advantage in rendering some more complex animations on devices equipped with a powerful GPU such as an iPad or iPhone. On the other hand, the optimizations of the V8 JavaScript engine within Chrome coupled with the more powerful CPUs found in desktops and newer tablets offer some advantage as well.

The trick, however, is not to determine the browser and device combination that will run your animation the fastest, but rather to determine the slowest browser and device combination that you wish to support. You’ll need to draw a line as to the minimum hardware and browsers that you expect to support, and this is how you can determine how complicated your animation can be and how much effort you’ll need to put into tuning its performance.

If, on the other hand, you only intend to target a specific device and browser combination, you’re free to create animations that leverage the full potential of each.