If you use RSL to externalize parts of the Flex framework or assets into other SWFs, which can be a godsend for large Flex projects, please test carefully in as wide a range of browsers as possible (not just your browsers but get some colleagues or friends to take a look). I've seen odd errors and behaviors from Flex applications deployed in this manner, where the externalized SWFs don't load, etc.

Again, RSLs can be a good choice and, when used properly, significantly reduce the size of your SWFs, but your users still have to download those SWFs the first time they use the application (they're cached after that -- just like your 2MB SWF will be cached, so this can sort of negate some, not all, benefits of the RSLs).

As for performance, in general a 2MB Flex application isn't that huge, I don't think and, once it's downloaded, it's 'local' to the users browser, so no issue there. The bigger performance issue with SSL is what type and how much data are you moving to and from the application?

Personally, I wouldn't worry about performance over HTTPS with those specs.

I have a current Flex project that is similar. It'll be about 1-2 MB when finished, probably 1.25-1.5 MB (sits at just under 1 MB now but a few more features have to be added). We're getting all our data from .NET-backed Web Services over HTTPS (the app receives either XML data or ByteArray data, when images are returned).

It moves pretty well and I haven't noticed a difference between HTTP and HTTPS (I test on HTTP and deploy to a staging server that has HTTPS enabled and test further there before we push to the production server).

The only performance issue I found, and it wasn't much better over HTTP, was when grabbing a HUGE data set, that .NET was returning as XML (as opposed to JSON, etc.). Again, I don't know how much of that was XML bloat in general versus being on an encrypted connection (that and I really didn't notice a huge speed increase, if any, under standard HTTP).