Jonathan Snyder is the Macromedia Flash development manager for macromedia.com.
- Introduction
- Reducing the File Size and Number of Downloads
- Improving Performance Through Browser Caching
- Results From Our Performance Tuning
Improving Performance on the New macromedia.com
As Al Ramadan communicated in his Beta Progress Report 4, we have been working diligently during the past month to improve the performance of four Rich Internet Applications, powered by ColdFusion MX and driven on the front end by Macromedia Flash Player:
- Product Registration
- Trial downloads
- Membership
- Exchange
For the Beta 4 release, we have focused on two areas in particular: reducing file size and the number of files downloaded for each application, and increasing the amount of data cached in the browser so that applications load more quickly on subsequent visits.
Reducing the File Size and Number of Downloads
For Beta 4, the development team's primary focus was to reduce the file size of the Membership application. For the Beta 1 launch, the Membership application contained all of its code in a single SWF. For the Beta 4 launch, we split the Membership code up into four separate SWFs, one for each part of the application. This limits the code that loads initially to only the functionality required for that view. Accordingly, we were able to reduce the size of the initial download by over 60K for the Membership application.
The version of the global navigation that we launched for Beta 1 was very large (over 26K) and was composed of multiple SWFs. This complexity stemmed from the desire to make a single version of the global navigation that could be easily localized for all 11 versions of the website. Since the global navigation rarely changes, we decided to radically simplify it by producing separate static versions of the global navigation, one for each locale. The lesson we have learned here is that it is very important when designing Macromedia Flash content, or even HTML or DHTML content, to maintain a balance between performance and flexibility. Where something will not change that often, as is the case with our global navigation, it is always a good idea to make the code simpler even though it may make things less flexible.
Our Macromedia Flash applications all make use of a Preload manager built as part of our Macromedia Flash shell. This manager preloads assets and Runtime Shared Library SWFs that must be loaded multiple times during the course of creating a view within one of our applications. Preloading SWFs ensures that they are properly cached in the browser and will only be loaded once from the server before they are actually used. Without this feature, we would have many files loaded multiple times during the course of building a view, which would reduce the speed at which our applications load. For this release of our site, we have further optimized our Preload manager to ensure it preloads assets only once for each application.
Improving Performance Through Browser Caching
Our Macromedia Flash applications are fully dynamic. That is to say, the SWFs that we load to display data are separated from the data itself. Accordingly, any piece of text that we display in our applications can be changed without having to re-export the SWFs we use to build our applications. This makes our front-end code extremely reusable and localizable.
The applications that went live in the initial
Beta 1 release received and sent nearly all of their data via Macromedia
Flash Remoting. The data types for which we used Macromedia Flash
Remoting included:
- Localized strings for displaying headers, form labels, and other static lists of data such as countries, states, and provinces
- Site model data for informing the macromedia.com shell how to construct a particular view (e.g. which SWFs to load for a particular application and where to place them, which Runtime Shared Library SWFs to load, etc.)
- Form data sent to the server for tasks such as creating new membership accounts and registering new products
- Application data for populating user interface controls such as pop-ups and lists of links
After Beta 1 of macromedia.com went live and we reviewed the initial responses to the site satisfaction surveys, we looked at our use of Macromedia Flash Remoting to see if there was anything about it that could help explain the performance problems experienced by many of the survey respondents.
We found in our analysis that there was a sizable amount of Macromedia Flash Remoting data sent from the server every time a user visited one of our applications, even if they had been to that application before. The types of data we were concerned about were localized strings and site model data. It was all static data that changes rarely, if ever, so it was a good candidate to be cached locally. We could have cached it using Local Shared Objects, but we didn't, because the data added up to more than 100k and we did not want to be forced to prompt users to allow us to use more than the default amount.
Rather than continue using Macromedia Flash Remoting to retrieve static data, we decided to load this data into our applications as XML, which gets cached in the browser. We modified the NetServices code that the applications use to send remoting calls to the server to catch requests for static data. Where static data is being requested by one of our applications, the request is automatically redirected to load XML. We also modified the NetServices code to process returning XML data and pass it on to the application SWF requesting the data. That way, the vast bulk of the work needed to accomplish this change occurred in a single location in our code set.
On the back end, we used ColdFusion to process these requests for XML. The data returned from ColdFusion was formatted with a last-modified header such that a browser would think that it was coming from a static text file containing XML and cache it.
It is important to note that our use of XML rather than Macromedia Flash Remoting to obtain static data from the server by no means implies that we are moving away from Macromedia Flash Remoting as one of the core technologies used by macromedia.com. On the contrary, we have found it to be an extremely useful and appropriate technology for passing dynamically generated data to and from the server, such as membership and product registration data, Exchange search results, and data for the main product exchange sections.
Results From Our Performance Tuning
The work we have done over the past few weeks to improve the performance of our applications has produced great results when viewing the site over a fast connection (see the charts Al included in his report). Over the coming weeks, we will continue to examine our code with particular attention to improving performance for dial-up users. The areas in which we plan to devote our attention include:
- Consolidating SWF and Macromedia Flash Remoting calls as much as possible to reduce the number of trips to the server
- Loading additional data via XML to cache data where that data is static and does not change often
- Optimizing our code to download, execute, and render content more swiftly
Lastly, we will continue to work with members of the Macromedia product teams to review our approaches to building Rich Internet Applications as well as share new discoveries and developments with you as much as possible.
