Transitioning from Flash to HTML5 banners

Over the past few weeks I’ve been asked countless times how myself and my team are handling the transition from Flash to HTML5 banners. Here is my attempt at answering all those questions.

Is Flash really dead?

Well, not really – it just won’t be used to create banner ads anymore. It is perfectly alive and well in terms of web and mobile games through the AIR platform.

So, why do we have to make all banners in HTML5 now?

Chrome will be setting its power saver feature mode to default now. This means any plugin based (Flash) content on a web page will be paused by default. This also means Flash based games are fine as they will take up a large portion of the screen and therefore detected as important (Cue sighs of relief from Candy Crush addicts). Read more here: Chrome Blog: Better battery life for your laptop
Ironically, this procedure had already been mentioned by one of the creators of Flash; Jonathan Gay 5 years ago in response to Steve Jobs’ famous open letter to Adobe denouncing Flash: Flash co-creator responds to Steve Jobs
Firefox is sure to follow suit with this procedure soon, and the guys at Mozilla are quick to flick the “off switch” for Flash when a security issue is found in the Flash Player plugin.
Safari has been doing this for some time already.

How do we build banners in HTML5?

That’s entirely up to the skill sets available in your team. I personally handcraft my HTML, CSS and JS for each banner, because it gives me complete control over what the banner is doing.

But what about tools like Flash Professional CC, Google Web Designer, Adobe Edge Animate?

All are perfectly valid options, just be aware of the pros and cons of using each tool.

Google Web Designer

GWD is great if your banners are going on AdWords, DCM, or DoubleClick. You could integrate it with the likes of Sizmek and others, but would require you to have a bit of knowledge of the code involved (EBLoader.js etc).

The code is also fairly bloat free and optimised (yay!). It has a vibrant Google Group community where feedback is encouraged and it is in very active development.

Flash Professional CC

Flash HTML5 Canvas Mode has a hard time trying to keep file size down. The export currently doesn’t use an image optimiser, and it doesn’t automatically use the HTTPS versions of its CDN JavaScript code. The exported JS is also unreadable on its own, so you’d always have to go through the Flash Professional CC IDE to make an edit, then publish, and then making any amends you made to the HTML all over again.

(EDIT 25-08-15: Actually, there is a way to turn off overwrite HTML in the Publish settings)

Adobe Edge Animate

It is unknown what Adobe has planned for Edge Animate. It’s not in active development and is being left to sit on the back burner for the moment.

Previous versions of Edge Animate used to rely heavily on jQuery. jQuery is used quite widely in the modern web, so it seemed appropriate for it to be used in Edge Animate. However, the library offers (and loads) extensive functionality that would simply not be used in a run-of-the-mill banner. Consequently, the Edge team took it out of Animate; unfortunately, that created more problems than it fixed.

Like Flash Pro CC the code Edge Animate produces is quite unreadable, and there are few settings available in the IDE for you to change that. Again, all amends would have to be made via the IDE. It may also prove quite hard work to debug if something goes wrong.


Swiffy was an experiment by an engineering intern at Google in 2011 to see if they could convert Flash SWF files into a HTML5 ready format, his progress was so sufficient that he was hired full-time and Swiffy was released in 2014.

While Swiffy is great at replicating SWF banners in HTML5, it often leaves you with a HTML file that is over 200kb (depending on the creative). As IAB have recently set the recommended file weight of HTML5 ads at 200kb, this might seem okay, but we would still need publishers and ad platforms to agree to this.

There are ways in which you could modify a Swiffy export file in order for it to load in asynchronously (this was called polite loading in the Flash era). But this would require a developer to reorganise the HTML file and engineer this process.

Simply put, think of Swiffy as a short-term solution.

Why do they all produce unreadable code?

In order to produce an output file that can run everywhere, they built-in functionality and failsafes to ensure that it would. Unfortunately, this requires a lot of redundant code in order for it to work; hence the bloat-code.

If it spits out code that works, why should I care that its unreadable/bloated?

These tools are short-term stop-gap measures, and is basically brushing the problem under the carpet. The problem here is you would not learn the fundamental differences between Flash and HTML5 and how users have changed the way they consume content on the web.

Banner ads need to evolve and engage with people in a more meaningful way, and while banners transition from Flash to HTML5 this is the perfect time to do this.

Mobile Interstitial ads are the pop-up ads of the 90s in mobile form, they are disruptive and jarring to the content consuming user experience.

Handcrafting sounds like a lot of work!

At the moment yes. It is. It just relies on a whole different set of skills, a different mindset and a whole load of tools need to be created to make things faster.

Much like websites, HTML5 banners need to be tested against browsers for compatibility, and as such you need to plan out which browsers you will be testing against, and which ones you can happily ignore. Banners might not even look the same in each browser, and sometimes there’s not much you can do about it. That’ss just how the web works.

This transition requires a level of client education and, dare I say it, account team education. You simply can’t do some of the effects in HTML5 that were possible in Flash. HTML5 banners take more time to produce and require a lot more testing.

How can I start handcrafting my banners?

Start learning the basics of web development; try an online course at, or Check out CodePen for inspiration and keep up-to-date with how browsers are changing with CSS-Tricks.

Learn JavaScript and GSAP, don’t use jQuery (You’ll thank me for that later). For those who have developed Flash banners using GSAP (Greensock) you’ll be ahead as the syntax is the same as it was in ActionScript. It’s currently one of the fastest growing JavaScript tools on the Internet and the guys at Greensock have opened a new forum specifically for banners.

But I’m a designer not a developer!

Play to your strengths; try a free online course and see if it makes sense. If it doesn’t, don’t worry about it – it’s not for everybody.

But what you can do, is Design with Developers in mind:
This article is aimed at website design and development, but the sentiment in the headline still applies: “Sure, just about any design is possible as a website _banner – but it doesn’t mean it’s necessarily the best design for the medium”._

Talk through your designs with a developer before a client sees the designs/animation proposal. It might be that you’ve designed some amazing animated kangaroos bouncing around the stage area, but you would need to find out whether the creative has the file weight limits possible for someone to implement.


Photoshop CC 2015 has introduced artboards and these are perfect for laying out banner storyboards. When you copy a layer from one artboard to another, it remembers the exact position that layer was in the previous artboard, allowing all your “furniture items” (CTA’s, Logos etc.) to remain pixel perfect.

Also, if you haven’t noticed Photoshop CC also has a tool called Generate Assets. You can label each layer as a .PNG or .JPG and with auto generation on, these will be spit out files at the exact size you have them in the PSD. With JPGs there are also modify codes to adjust the quality, such as JPG80%. This also works on groups as well as layers, so if you had two items that were always set together you can group them up and it will produce them together. You can even implement a simple folder structure into the name: Folder/Folder_Image.png. Read more: Photoshop: Generate Assets

With the auto generation feature, any time you save the PSD new assets will be generated, allowing a folder to be kept up-to-date with the latest versions.

Image Optimisation

The one major issue about banners is file weight. Keep the weight and the bloat down at all times. One of the best ways to do this is using TinyPNG (works on JPGs also): TinyPNG. They have a plugin for Photoshop too!

Animation/Visual Tests

As with Flash there are multiple ways of achieving the same visual outcome. Unlike Flash, however, HTML5 implementations may have vastly different penalties (file weight, performance, compatibility) and requires extra time to ensure what is being developed will match up with the creative idea.

Web Fonts

Ad building platforms like Celtra/BannerFlow allow you to upload fonts to their severs to be allowed to linked into your creative. For others, using Google Fonts is okay too.

I generally use a PNG for copy (sound of leers from front-end purists), rather than adding more fonts to the creative. In most cases this is fine; most likely you don’t need the full character set a font file gives.

Licensing is also a big issue here, as fonts are generally billed out as page views per site, so your better options are Google Fonts, or a TypeKit licence that covers use for banners. TypeKit has restrictions on sites it’s allowed to be shown, however, which can be set up in the kit settings.

While SVGs have generally been accepted in most browsers for a while now, I would always make sure the ads are not going to be served below IE9!


Render-blocking is when your HTML (in this case the banner ad) is being read by the browser line-by-line and, whenever it comes across an external asset (CSS, JS, Images), it pauses and thinks “hold on I need to grab that first before I read the rest of the page”.

It’s always good practice to limit page blocking and speed up page loads. I tend to load up enough CSS/JS at the top of the page for the banner’s initial frame/a loading wheel to load, before loading in heavier library JS and CSS items, then execute the animation from the bottom of the page. This way the user gets to see the ad messaging as soon as possible, even if the animation isn’t ready yet.

Google has a nice article on speeding up page loads:

CDN Scripts

Using CDN hosted scripts such as GSAP or Zepto is great to reduce the load times of your creative, alway remember to use the HTTPS version of that script to ensure that your ad would not be susceptible to the Man-on-the-side attacks.

It’s always safe to request HTTPS assets even if the publisher site is on HTTP, however the reverse is not true.

Further reading:

Getting started with HTML5 Toolkit


Greensock: Solutions for Banner Ads in the Post-Flash world

Converting your Flash Ads to HTML5 Canvas

IAB Display Advertising Creative Format Guidelines

Creating an HTML5 Banner Ad with GreenSock (GSAP)

Petr Tichy – Greensock Workshop