Behind the animations at Hack the North
By: Hack The North
Tags: Web Development, Website Development, Animation, Website Design, Front End Development

Written by: Kelvin Zhang

At Hack the North, animations are a fundamental part of our brand and the first thing people see when they land on our site. A nice animation can make your brand stand out from the crowd and leave a lasting impression. As such, we put a lot of thought into animating and optimizing our assets! In this blog post, we’re going to dive a bit deeper into how we work with animations at Hack the North and give you ideas on how you can incorporate them into your site to give it that extra ✨ sparkle ✨

Our landing page animations from 2018–2021

Table of Contents

Types of Animation Formats

Over the years, many animation formats have been released, each with its pros and cons. We spent a lot of time testing out different formats and wanted to share our findings to help you decide on what you should use for your use case.

On our landing page, we had the following requirements:

Complexity: many of our animations are very complicated (like rotating helicopter blades) and would be near impossible to make using CSS

many of our animations are very complicated (like rotating helicopter blades) and would be near impossible to make using CSS Transparency : we need to support transparency since, in most cases, we want to be able to overlay our assets on top of a non-solid background

: we need to support transparency since, in most cases, we want to be able to overlay our assets on top of a non-solid background Small file size: we want our assets to load as fast as possible

we want our assets to load as fast as possible Vectorized: our animated assets need to scale to every screen size

our animated assets need to scale to every screen size Ease of handoff: our frontend team shouldn’t need to animate everything manually; not only is it time-consuming, but we want to shift that burden to the design team in case changes need to be made

With these in mind, let’s take a look at what options we have:

GIF

GIFs are the most common type of animation on the web — and for good reason. They can animate almost anything, have transparency, and can support 60 FPS playback. That being said, they don’t quite meet our needs because:

transparency significantly increases the file size of a GIF stretching GIFs to accommodate all screen sizes is a problem (raster format) GIFs only support 1-bit transparency, which means that a pixel is either transparent or not. This can lead to jagged edges, like here

A fun fact is that GIFs weren’t actually intended for animation! It initially started as a standard image format and animation was later tacked on. Since it’s a series of frames, it’s not very efficient with file size since inter-frame compression isn’t possible. This means that the GIF needs to store all the information for each frame, even if the contents between the two frames are very similar.

Video

Videos are another form of animation that can be used for longer animations, with more control over quality (and sound)! Videos do support inter-frame compression and, in many cases, are actually smaller than GIFs!

Comparing .gif and .mp4 sizes for the same animation. MP4s are 91% smaller!

That being said, videos are harder to render on the frontend side of things. They also don’t support transparency.

APNG

APNGs are a relatively new file format that allows you to animate PNGs. This allows for higher quality images than GIFs due to 24-bit colour and 8-bit transparency. However, due to being very similar to GIF, this format shares the same pitfalls: our initial 3-second animation would be 17.5 MB, which is way too large.

CSS Animations

Instead of exporting each frame in full, what if we just had a bunch of images and some code telling us precisely when and how to move each image around?

CSS animations accomplish this, and we use a fair bit of them on our sites. That being said, it’s hard to build complex animations using CSS since you’re restricted to CSS properties, and it’s hard to orchestrate multiple animations at once.

This brings us to…

SVG + JSON

Instead of CSS, we can use JSON to describe how we want to animate our assets. The benefit here is that you can export .json directly from After Effects! This means that, as a frontend developer, you no longer need to build out the animation yourself by guessing and checking. Your design team will also love you for this since they can make the changes on their end without needing to ping you. We can use Lottie to render JSON animations on the front end.

This format has the benefit of transparency, vector scalability, and small file sizes! Just what we were looking for 😄

Exporting the Animation

Now let’s using SVG and JSON to try and render a simple loading animation, which we used on our 2020 site:

If you want to follow along, you can download the After Effects File here.

In After Effects, you can use the Bodymovin plugin to export your timeline to a JSON file. After installing Bodymovin, this can be done through Window > Extensions > Bodymovin.

This should give you the following json file: data.json

Rendering the Animation

Using the json file from above, we can render it in React using the react-lottie-player library. If you’re not using React, you can check out these alternative libraries:

CodeSandbox Link

It’s as simple as that! We just rendered a buttery-smooth animation on your site with < 20 lines of code! If you play around with resizing the window, you’ll notice that it scales seamlessly to fit any viewport. Not only that, but the final size is only 63 kB! Compare this to a GIF with transparency, which would be 450 kB. That’s 86% smaller! 🔥

Optimizations

Canvas Rendering

If you look inside the DOM for our current animation, you’ll see something like this:

With every frame, the DOM updates the SVG properties. Since this is a simple SVG, it won’t cause any issues, but with more complex animations, many updates to the DOM every few milliseconds can be very resource-intensive. An alternative that you can use is to render to a <canvas> element instead.

This can be done by switching our renderer over to canvas, which will now stay constant as our animation runs!

Lazy-Loading Animations

Lazy-loading is the idea of having a temporary placeholder when your animation is loading so that when users land on your page for the first time, they don’t have to wait a couple of seconds to see the asset. With json files, our animations shouldn’t be too large, but if you do have an animation larger than a few hundred KB, it might be worth exploring lazy-loading in your animations. For this, you’ll take a static .svg or .png image to load in while the animation JSON is loading.

We can then dynamically render the placeholder or animation depending on whether the JSON is loaded or not:

CodeSandbox Link

dotLottie

dotLottie is a new format introduced by LottieFiles, the largest repository of Lottie files on the web. This new format ends with .lottie instead of .json and has the added benefit of being able to package multiple animations into a single file. It also uses an alternate compression method that makes your animation files considerably smaller!