Blog Post:We've recently run tests for two clients in which we've tested a "static" version of a homepage vs. their default Flash version. "Static" simply means that we served users a non-Flash version of the homepage. The desire of our clients to run these tests probably has a lot to do with the state of the economy. It's no secret that a Flash homepage is much more expensive to maintain and to make changes to. It's also makes it more cumbersome to make quick updates to the page, or to test new concepts. Don't get me wrong - no one loves a useful Flash homepage more than I do. But most companies simply don't have the in-house skills to keep a Flash page updated. For each of our clients, the tests were very simple. Point 50% of users to the default, Flash version of the homepage, and point the other 50% of users to a static version of the homepage. In both cases, the static version retained much of the functionality of the Flash version; however, the static versions often got users to content faster. For example, on an insurance company's website, the Flash version played a video when a user clicked on a type of coverage, while the static version took people directly to the coverage page. In both tests, the business users behind the tests were rooting for the static versions to win. They wanted the ability to update their pages more easily, without having to go through a lengthy production process. Essentially, the original decision to use Flash on their site was taken without a clear business need. And the results? For the major insurance company that we worked with, we were able to declare the "static" version as the clear winner. There was no negative impact on leads generated for new policies when serving the static version. More impressively, pageviews to internal site pages increased by more than 40%. This led us to start planning a new test to optimize lead generation from those internal pages. For the office products supply company, the static version also performed better than the Flash version on all key metrics, although by a smaller margin. However, this test was definitely a win for the client. By moving to a static page, our client now has much more freedom to quickly update the homepage with new content and offers, sparing precious internal resources. Remember that a static page by no means implies a boring page, or a page without a lot of great features. In fact, the static versions for our clients often maintain much of the most important functionality of the page. So, when does Flash make sense for your site? First of all, look at your site from your users' perspective. Is the Flash serving a real purpose for your users, by adding meaningful functionality? If so, Flash will likely outperform a static version of your homepage. If, however, you're using Flash for eye candy, or because you've been told that everyone is doing it, then a test might be in order. If you can give yourself more control and flexibility without sacrificing performance against key metrics, why not try it? Author: Date Created:June 19, 2009 Date Published: Headline:When a Static Page Beats a Flash-based Page Social Counts: Keywords: Publisher:Adobe Image:https://blogs.adobe.com/digitalmarketing/wp-content/uploads/no-image/no-image.jpg

We’ve recently run tests for two clients in which we’ve tested a “static” version of a homepage vs. their default Flash version. “Static” simply means that we served users a non-Flash version of the homepage.

The desire of our clients to run these tests probably has a lot to do with the state of the economy. It’s no secret that a Flash homepage is much more expensive to maintain and to make changes to. It’s also makes it more cumbersome to make quick updates to the page, or to test new concepts. Don’t get me wrong – no one loves a useful Flash homepage more than I do. But most companies simply don’t have the in-house skills to keep a Flash page updated.

For each of our clients, the tests were very simple. Point 50% of users to the default, Flash version of the homepage, and point the other 50% of users to a static version of the homepage. In both cases, the static version retained much of the functionality of the Flash version; however, the static versions often got users to content faster. For example, on an insurance company’s website, the Flash version played a video when a user clicked on a type of coverage, while the static version took people directly to the coverage page.

In both tests, the business users behind the tests were rooting for the static versions to win. They wanted the ability to update their pages more easily, without having to go through a lengthy production process. Essentially, the original decision to use Flash on their site was taken without a clear business need.

And the results?

For the major insurance company that we worked with, we were able to declare the “static” version as the clear winner. There was no negative impact on leads generated for new policies when serving the static version. More impressively, pageviews to internal site pages increased by more than 40%. This led us to start planning a new test to optimize lead generation from those internal pages.

For the office products supply company, the static version also performed better than the Flash version on all key metrics, although by a smaller margin. However, this test was definitely a win for the client. By moving to a static page, our client now has much more freedom to quickly update the homepage with new content and offers, sparing precious internal resources.

Remember that a static page by no means implies a boring page, or a page without a lot of great features. In fact, the static versions for our clients often maintain much of the most important functionality of the page.

So, when does Flash make sense for your site? First of all, look at your site from your users’ perspective. Is the Flash serving a real purpose for your users, by adding meaningful functionality? If so, Flash will likely outperform a static version of your homepage. If, however, you’re using Flash for eye candy, or because you’ve been told that everyone is doing it, then a test might be in order. If you can give yourself more control and flexibility without sacrificing performance against key metrics, why not try it?