The thing about bulky sites
Sometimes you gotta wait for the load
One of our designers at Jam3 (Roger Dario) brought a certain blog post to my attention. In this blog post they specifically single out Heart Of The Arctic a website I was lead developer on.
All in all the site turned out quite well. Are there things I don’t like about the site. Of course there are. There always are on every project I do. In fact many of my co-workers laugh at the fact that I can’t even look at some sites I’ve worked on because I get frustrated by the things I’d like to fix. This includes some of the most successful projects we’ve worked on.
The article I reference above basically states that load time must be managed by proper load sequencing and that we didn’t do it right on Heart Of The Arctic. I couldn’t agree more on the importance of proper load techniques. In fact it’s something I suggested during development to pause the user in between every environment and load the next. There was a lot discussion about this and ultimately it was decided not to go that route.
When mid experience loading ruins the experience
The first thing with Heart Of The Arctic that you have to realize is that it’s for kids. Although kids are less patient than adults they will sit through an initial load. Kids will actually get more frustrated if they’re going through the experience and they get cut off due to a loader coming up.
The next consideration in putting mid experience loaders is that there are instances where you just want to “zoom” from one side of the map to the other. If you decided to go from the base camp to the final ship environment and you had to sit through 4 loaders along the way it would suck. Of course we discussed the fact that we could perhaps just take the user from one location to another when a button is clicked but it was decided that it wouldn’t give the user a sense of environment if we did that.
We don’t have the tools yet
Have you ever thought about tooling and libraries for HTML/JS dev. There’s a crap ton of utility libraries, mvc frameworks, and productivity tools. How many animation libraries are there? How many animation tools are there? One of my fav tools that I’ve seen is Spine. Spine is really nice. It’s a bone based animation tool. The nice thing about bone based animation is that your animation file size will be very small because essentially you’ll just be exporting bone deformations and those will be applied to images which are different parts of a body for instance. Low file size with high quality animations.
The problem with animation in HTML/JS is that the tools are new and most animators don’t use them. Most animators are use to the Flash IDE or After Effects. What do those tools produce well? Sprite sheets. The bane of my existence. The problem with sprite sheets are that they are MASSIVE in file size, they are not able to run frame rate independent (you export the animation at 24fps it must run at 24fps even if your site performs at 60fps), and they are bad on performance on mobile. (more on that in a bit)
So what did we try to do to stay away from Sprite Sheets. We created our own After Effects to JS exporter. Basically we wrote our own exporter in JS to look at an entire composition/animation in After Effects and export a JSON representation of the entire scene. If you’ve been on Heart Of The Arctic you might’ve seen a massive giant that wakes up and screams at you. That giant was not a sprite sheet. That giant was fully exported out of After Effects.
So in other words we took the best parts of Spine and brought them to AE. Why? Well because we were working with Tendril. One of the best motiongraphics studios in Toronto (if not the world). You’re not going to go to a carpenter and give them a new set of tools because you think they are better. It would be the same thing as a typist giving a developer MS Word. Changing toolsets is a long haul process it doesn’t happen on one project. I hope some day we’ll have really solid animators that focus fully on animation for the web.
That being said doing certain animations such as the bear raising on it’s back paws is almost impossible without Sprite Sheeting at this point so we had to live with it even though mobile dev was hell because of it.
Large Images On Mobile
If you’ve ever had the joy of working with current mobile browsers and large images such as sprite sheets. You’ll quickly realize that image decompression is horrible. What that means is that if you load and render a large image the very first time it’s rendered there will actually be a significant drop in performance. Tools like ImageOptim will help with image decompression (I believe they remove some meta data from images and do other magical things) but still the fact of the matter is that a Tablet/Phone CPU is no where near as capable as a desktop CPU.
All this being said what does image decompression have to do with loading images? Well in an ideal world we’d actually load most images for animations and other assets in the background and then hot swap them in once they’ve loaded. The issue is that you’ll see noticeable jank (I got the secret word in there Addy Osmani) on mobile devices as images get decompressed. So if in heart of the arctic on mobile (and desktop with VERY VERY large images) scrolling across the screen would be almost impossible. Believe me because that’s the way Heart Of The Arctic was developed at one point. Actually I believe still a bulk of the animations are being loaded in the background and being pulled in once they are loaded.
To help mediate the problem of Image Decompression performance drops on mobile we decided to take a big deep breath and do the unthinkable. We resized our images to be much smaller than they should be and then upscaled them in the experience. In other words if one of the characters is 200 x 200 we saved them out at 100 x 100 and scaled them up to be the original size they needed to be. (sometimes you gotta do what you gotta do) On mobile devices when working with Canvas we also noticed that the VRAM of the GPU would get heavily over burdened by our very large images causing a lot of swapping again making performance bad even after decompression. (note working with Canvas + GPU is much more performant than CSS3 Transforms + GPU)
Block Busters vs Documentaries
This is not the first time in my career that I’ve heard “Why is the load so long!!!” Believe me I have never grown to accept it nor do I still not cringe at the load on some of the sites I’ve worked on. You can optimize the crap out of all your images. (TinyPNG, ImageAlpha, ImageOptim) Render out all your videos at the lowest acceptable quality. The site is still going to be heavy… Why? Because we’re building Blockbusters vs Documentaries. Have you ever thought of video games compared to back in the day to now? We had like 5 disks we’d swap in and out and now Star Craft fills half my hard drive. Have you ever seen that annoying message on iOS where it states “You can’t download this app because it’s more than 100mb” meanwhile it’s like Candy Crush (Candy Crush is actually 40mb. Wait how is Candy Crush 40mb???). The fact of the matter is not every website now a day is utilitarian we have websites that are purely for entertainment. I’d hate it if I went and hit up Google.com and I had to sit through a load screen. But sometimes I want to be entertained vs looking for information. Thank goodness we have web tech that we can do that on now. I think there are a lot of people out there that will sit through a load to be entertained on the web. Think of Youtube + our Internet connection speeds a few years back (I’m sure we all sat around waiting for a load to finish). The expectation shouldn’t be that every website will load in 39kb or less. Of course we should strive for that.
If there’s one thing I would change is deploy HOTA to a stronger CDN ;) Hint hint.
