You already learned some of the pitfalls of animation. By way of review, those were alpha tweens (fade in and fade out) and shape tweens, both of which are processor-intensive. Brightness and tint tweens can also consume file size. But here's one you may not have considered: Animating vectors can consume CPU as if it's the last slice of cheesecake at a sweet-tooth convention. Here's why.
Vector graphics have to be completely redrawn from frame to frame. If you are motion tweening a vector graphic, each vector object that makes up the image has to be completely redrawn in its new position. Add to that vector background graphics in a different layer just sitting there while the animation occurs above it having to be redrawn for every frame, and you have an over-tasked CPU. A frame rate of 12 fps (frames per second) will begin to look more like 12 fpy (frames per year). So what to do?
Runtime bitmap caching will treat movie clips, buttons, and even components as bitmap images after they've downloaded to the browser cache. This is a more efficient usage because the computer then has to turn pixels on and off only when a cached button or movie clip is moving, or even remaining stationary, rather than redraw each object of which the graphic is made.
You should not use runtime bitmap caching on movie clips that contain animation or on buttons that contain animated movie clips.
Sometimes it is quicker to create an animation using ActionScript than it is to painstakingly motion tween and animate movie clips on the Timeline. Using ActionScript sometimes (but not always) decreases the file size and workload when you have to animate something; however, your ActionScript might use up much more CPU than an animation tween in a Timeline. Most ActionScript-based animations use either an interval or a movie clip enterFrame event, both of which must be explicitly deleted when the animation is over. Neither setInterval nor enterFrame can stop on its own and will continue to run, even though the animation is over, eating up CPU. You have to delete them to make them stop. setInterval and enterFrame are beyond the scope of this book, but you should be aware of their pitfalls just the same.
Different processor speeds can also affect the playback of a SWF file. Older processors might play the SWF file back at a snail's place compared with a fast modern processor. The best ways to control for that are to test the SWF file on several different computers and examine how the SWF file runs on each machine. Some older computers have a difficult time playing a SWF file regardless of whether you use ActionScript or tweening to create animations. Something fading in or moving might play back very slowly and choppily on these machines. If you have a firm understanding of your target audience, you can produce your application for the lowest common denominator, as painful as that might be.