Like anything we developers do for the world wide web, file size must always be a strong consideration. It helps ensure that the user receives their content before they get impatient and hit the back button. And they will. In the case of banners, sites often won’t allow anything larger than a 40k initial load. So how can we keep our file sizes down without our swf’s looking like doggy doo?
Optimization is a delicate balance. We need a small files, but we (and our clients) also want them to look good. So we obviously can’t just recklessly compress all of our raster images until all detail is destroyed. Also, we have to balance file size with performance. Sure, we can apply drop shadows, glows, and other filters in Flash, rather than baking them into png’s with transparency, but it comes at the cost of decreased performance. This is okay if you don’t have too many processes running simultaneously, but if you do and it starts to bog, dropped frames aren’t much better of a user experience than muddy images. So what can we do to keep performance and quality high, yet still meet or size requirements?
Don’t Just Guess
I’m always amazed by how many experienced Flash developers have never heard of Flash’s size reports. Simply go to your “Publish Settings”, expand “Advanced”, and check “Generate Size Report”. When you compile, Flash will generate a text file (displayed in your output window) that details every element and every frame contributing to that file size. Pretty helpful.
Vector vs. Bitmap
There’s a common misconception that vectors are always smaller than raster images. Often times, it is true, but certainly not always. The real question is how many points that vector has. Sometimes a png8 (with alpha transparency and a limited color pallette) will be smaller than an equivalent vector with a bajillion points. If the vector has too many colors and a png8 just won’t cut it, then you may try scaling that vector down inside of a group or MovieClip, then scaling the container back up to the proper size. Scaling down the vector will reduce the number of points, but it will also reduce the detail of the vector, so, again, this is a balancing act much like image compression.
Another thing to consider is the font. It’s rare, but certain fonts may increase you file size much more than creating a bitmap of the text. This comes at the cost of simple text edits requiring a re-export of the image. And scaling up the text in animation also becomes less viable, unless it’s fast and blurry. Make sure eliminating the font will actually save you kilobytes before going through the trouble and dealing with the limitations of raster text.
If you need transparency in an image, but it is too large as a png24/32, or has too many colors to be a png8, you do have other options. If the shape is simple enough to be cut out as a vector shape, you “break apart” a non-transparent jpeg in Flash (converting it to a vector) then adjust the shape of the vector to clip off the parts that need to be transparent. This works especially great if you need the edges to be nice and crisp, allowing you to compress the jpg even more than you normally would, since the artifact-y edges will be clipped off.
If you have multiple transparent images with a similar enough color pallette, you can combine them into one png8 or jpg, then break apart in flash and only cut out the part you need.
These methods above all take a bit of practice to understand which will work best in which situations, but will save you a lot of headaches in the future. Really though, good optimization starts with design. Before you even start step #1 of building your fla, make sure your designer has a good understanding of these concepts as well. Pretty easy for them to hand you a psd with 10,000 different transparent images, tons of complex filters, already approved by the client, without understand what that means for you, the developer. A little communication goes a long way.