I keep hearing from friends and colleagues that Flash is notoriously slow and the content it produces is hopelessly bloated. Of course this simply isn’t true but recently I’ve been finding out the hard way that it’s not easy to convince many of them otherwise.
Now I’m not attempting to turn this into a Flash v HTML5 debate but I do believe that some of these misconceptions have been borne out from the war that has erupted between those who support Flash and those who want it gone. However I feel most of the blame lies with those who use Flash and I do confess to being as guilty as the next man when it comes to writing large SWFs that use poor loading strategies.
It is all too easy to create unnecessarily large SWFs by producing hopelessly large vector images, packing your SWF with high-quality bitmaps, and forcing all your code and resources to load up-front. Ignore everything that’s great about Flash and you’ll soon have users yawning as they wait for the entire SWF to download before they’re able to try out your latest masterpiece.
So in an attempt to re-educate many of the non-Flash developers at WeeWorld I set myself the task of ensuring that any Flash content produced for our latest project would be as small as possible without a loss of perceived quality.
But first we had to decide if Flash was required at all. From the initial mock-ups it was clear that HTML, JavaScript and some server-side cleverness would take care of the majority. There was however one section right in the centre of the page that was screaming out to be done in Flash (or at least that’s what I believed).
Hey! I want to be Flash!!!
The centre panel in the mock-up above represents a little voting game where users get to vote for their favourite WeeMees during a fashion contest. Each time the user votes a new WeeMee is loaded from the server and slides into view. After voting, a panel is updated showing the current voting statistics for that WeeMee. To ensure the voting experience was as fluid as possible we decided to cache WeeMee SWFs up-front to reduce loading time between votes.
First I had to justify it. After all, some team members quite rightly stated that it could probably be done in JavaScript. In the end though we went with Flash for the following reasons.
- We’d need to load WeeMees, which are all dynamically generated on our server as SWFs.
- Flash would give us good cross-browser support without the need for any browser-specific code.
- The visuals could easily be reproduced using Flash’s vector drawing tools.
- The vector content would be a fraction of the size of bitmaps.
- ActionScript is compiled into a compact byte-code without sacrificing the legibility of the source.
- I moaned at my boss MacDog for two weeks straight until he relented.
So how did I get on? Well in the end I split the project into two SWFs – a preloader SWF and the main SWF. The preloader came in at 4K with the other being around 12K. The combined total was a minuscule 16K! To be honest given the tiny file size it was perhaps overkill having a preloader but heh, I’d rather the user had to wait for 4K to download before seeing something rather than 12K.
The point of the preloader wasn’t to actually feedback to the user how much of the content had loaded – after all everything loaded too quickly for there to be such a need. Instead it was created to force a visual onto the screen as quickly as possible therefore giving the user the perception that the content had loaded. I was eager to, as quickly as possible, plug the hole in the HTML page where the Flash content would be rendered, and the preloader gave me that opportunity.
High level breakdown of SWFs.
The diagram above shows roughly how each SWF looks and more importantly a high-level breakdown of sizes. The preloader’s (left hand-side) content is more-or-less split 50-50 by code and embedded fonts. The final size of the graphics within the preloader was perhaps the most pleasing, with the vector content only consuming 185 bytes!
It was a similar story with the main SWF (right hand-side). The ActionScript consumed the majority of the file size while the graphics consumed next to nothing. This time the vector artwork was a little larger but still comfortably under a kilobyte, coming in at 479 bytes. Unlike the preloader I was able to use device fonts for the main SWF, further helping to reduce the final SWF size.
I could quite easily reduce the total SWF size further by spending time shortening function and variable names. There are of course many other ways to squeeze the code down but I was eager to keep it as legible and maintainable as possible. The total size of the ActionScript source across both SWFs was 41K but was reduced to 13K after compilation.
I’m happy with the result along with everyone else at WeeWorld. Many were pleasantly surprised at the final SWF sizes and hopefully it has gone a long way towards making individuals realise that there’s absolutely nothing wrong with the Flash Player or the SWF format.
If you want to keep file sizes down I’d suggest you spend as much time and effort optimising your vector content – it’s certainly where the majority of savings were made on this project. Where possible re-use content by storing your artwork in movie clips and using instances of those clips. In fact take a look at the diagram below for a more in-depth breakdown of the vector graphics used within the SWFs.
Size breakdown across SWFs.
Also spend time thinking about your font usage. Only embed fonts if you really must. Where possible use device fonts, which will help reduce significantly the final size of your SWF. And although it wasn’t an issue with this project, if you find your byte-code size getting out of hand then you many want to split your code into separate libraries and load them at run-time when needed.
If you’re still in any doubt as to the compactness of the SWF format then perhaps this might give you some context. I examined the size of a single JPEG (260 x 274 pixels) loaded onto the front page of the WeeWorld site. It was a fairly compact 31K in size. Now compare that to the 16K total of our two SWF files (360 x 459 pixels). That’s right, our fully interactive Flash content with graphics, fonts and animation was half the size of a JPEG!
Anyone still want to argue that Flash can’t produce compact content?