Transitioning Display Ads from Flash to HTML5 – A Comprehensive FAQ

Thunder guide to transitioning Flash to HTML5 display ads

The advertising shakeup on September 1st has accelerated plans across the industry to transition display ads from Flash to HTML5. As a result, a lot of questions have surfaced about the finer details of HTML5 ad production and trafficking.

Below we’ve compiled the most common questions and answers into a comprehensive FAQ. Many of the entries here have come directly from customers. If anything about HTML5 is unclear to you, we hope you find your answer here.

Why is HTML5 adoption now a must?

Though Flash has been relied on as the major advertising medium for the past decade, its days are finally coming to an end.

The news that rocked the advertising world came in June 2015: in order to extend laptop battery life, on September 1st, Google Chrome began to “intelligently pause” Flash animations that aren’t central to the webpage. In other words, Chrome is going to stop Flash advertisements. In July 2015, Mozilla announced that Firefox would immediately begin blocking all versions of Flash due to the discovery of three different ways to exploit the plug-in over a five day period. A few days following Firefox’s action, Adobe quietly released patches to Flash’s vulnerabilities, restoring the plugin’s status in the Firefox browser. Amazon also announced they would no longer accept Flash ads on Amazon.com or in their ad network.

To ensure that ads continue to be viewable across all platforms, digital marketers have been and will be scrambling to make the switch to HTML5.

What is the impact of the changes to how browsers handle Flash?

Google Chrome is the world’s most popular web browser, with a substantial lead in usage over other options like Safari and Internet Explorer. According to StatCounter, a well-respected data source for browser adoption, as of June 2015, Chrome 43 has a 27% share of US desktop computers, and Firefox has close to 10%. Because Chrome auto-updates when new patches are available, we can theorize that approximately 27% of US desktops will begin to auto-pause Flash ads once the Google update proliferates. The outlook is far bleaker for international advertisers, where Chrome has a stronger presence with a share of over 40% and Firefox is up to over 12%.

Safari, one of the other three leading web browsers, already offers an option to pause Flash content instead of auto-playing it. The option is not turned on by default (yet), but it seems reasonable to expect they may follow the lead of the other dominant browsers.

What will happen if my Flash ads are not built in HTML5?

Flash ads viewed on Chrome will be paused and greyed out, with a play button in the center, as shown below.

Flash to HTML5 Thunder ads

In some scenarios, Flash ads will risk facing a skyrocketing “default rate” for their ads whereby a static image is served instead of the dynamic, animated ad that was originally paid for. Not only will cheaper ad versions be served despite more expensive execution, but also as a result, media performance will likely suffer.

Additionally, Flash is already effectively blocked on most of mobile. According to a leading ad server Sizmek, 90%+ of Flash ads served on mobile fail to run as intended and instead, they default to a static generic backup image. Flash’s inability to run on mobile combined with the increasing inability to run on desktop means it needs to be replaced for ad assembly.

What are the benefits of building ads in HTML5?

HTML5 is an open web standard, and not plagued by the security vulnerabilities that have crippled Flash and brought about this rapid transition. It is likely to remain the standard for many years.

HTML5 renders cleanly on mobile devices, which is where users are spending an increasing amount of time. HTML5 also frees consumers from extra plugins and extensions like Adobe Flash Player or Microsoft Silverlight. This ensures a positive and seamless user experience for customers.

What issues should I be aware of for this transition to HTML5?

All teams, clients, and stakeholders will need to be educated and stay abreast of HTML5’s unique technical requirements. For example, complex animations and custom fonts built in HTML5 require larger file weights than those created in Flash, which means that publisher ad specifications will need to be updated to accommodate HTML5 files.

In order to meet the timeline of an advertiser’s execution, a new quality assurance workflow will also need to be put in place. Rigorous QA testing needs to be completed across browsers on desktop, tablet, and mobile devices, which can potentially double the development timeline. Otherwise, if the ad is not QA’d properly, it is possible to devastate an entire website.

Why is the QA process so different for Flash and HTML5?

The main difference is the file organization. Flash is built as a single executable file, which means that once an ad has been successfully tested on a few desktops, it can be confidently served across devices.

HTML5, on the other hand, is a set of multiple files, similar to a mini application. Because each browser supports its own individual features for HTML5, ads need to undergo a complex QA process. The ad will need to be tested across every possible platform, including mobile, which can mean up to 15 different devices. Making last minute changes will restart this QA process, requiring the need to test another 15 times.

Do HTML5 ads created using ad tech require the same QA process?

We can’t speak for vendors apart from PaperG, but it is likely your ad technology already has a rigorous QA process in place for ads built in their software. The majority of bugs will be stopped before you could ever see them. Because all users of the platform can contribute to finding edge cases, it is as if the QA process is crowd-sourced across the entire user base. A streamlined round of QA can still be helpful, as browsers are constantly being updated and can potentially create issues that were not previously there.

If you do encounter an issue, record as much information as you can about it so that your technology partner can reproduce and troubleshoot the issue.

What are your recommendations for ad servers that don’t support HTML5 today in terms of enabling uploading raw assets?

In this case, it’s likely that they are already failing to deliver on the growing mobile audience. This can be mitigated by serving HTML5 ads through ad tags, which are supported by all ad servers. The ad tag would then deliver the HTML5 ad without the need for uploading separate files to the publisher’s ad server.

Can you provide a single list of HTML5 dependencies that work across all browser types/versions that we can forward to the creative agencies? Right now, many browsers are having issues.

For organizations that are setting up their own QA process, http://caniuse.com/ has a lot of information but it can be time-consuming to sift through. We’re not aware of any advertising-specific resources to help with this.

What is the weight recommendation for HTML5 creatives? Will publishers eventually increase the file size limitation from 40K since it’s so difficult to build HTML5 banners to that size?

The IAB is working with its partners to redefine creative specs across the advertising industry for HTML5 creatives and recently released a document for public comment proposing new specs. 200KB was the proposed new initial load, with user-initiated subsequent loads varying based on the ad format. Until these specs are adopted, you will need to work publisher by publisher, since each is in charge of setting up their own standards.

One way to get more mileage from your HTML5 ads is to carefully compress image assets and load some of the additional file weight as a subsequent load, both of which are enabled by default with PaperG ad tags.

What tools are available to easily convert my existing creatives to HTML5?

For standard HTML5 ads, popular tools today include Swiffy, and Adobe Edge.

What are the drawbacks of using Swiffy and Adobe Edge to convert Flash ads to HTML5?

Simple conversion tools from Flash to HTML5 may help temporarily band-aid the transition but they can ultimately introduce more delays and errors. A word of caution: Flash and HTML5 are fundamentally different technologies, and the results of conversion can range from inconsistent to totally broken. In the event that the conversion has issues, the producer is often thrust back into an HTML5 authoring program like Adobe Edge or Google Web Designer in order to fix any problems in the conversion, requiring parts of the ad to be rebuilt from the ground up.

How easy is it to learn Google Web Designer or Adobe Edge Animate?

HTML5 coding platforms like Google Web Designer and Adobe Edge Animate require a fair amount of programming knowledge, making it hard for Flash developers to learn HTML5 ad production easily. These tools are optimized for high impact rich media units and can be overkill for more standard executions.

Is there a better solution for building creatives in HTML5?

Using a creative management platform like PaperG, agencies can start the interactive design in a single platform or convert the ads into HTML5 in an editable form so future changes can be easily made. Users can rapidly put together or edit elegant HTML5 ads without ever having to touch the code. This is recommended if you have a high volume of work (sizes, versions, and campaigns), a larger staff, and set of accounts that need to make the transition to HTML5.

I 100% understand (and agree) that making a change to HTML5 is necessary, but I’d love to hear from Google as to why the extremely short timeline was announced. Advertisers are having to do a 180 to get Fall/holiday creatives re-built. Why not Q1 2016?

Not much has been said about the sudden notice. We do know that the Chrome team wanted to help extend laptop battery life, and this may be as simple as different branches of Google having different priorities.

What is the state of font selection in the new world? How will it affect the creative options during development?

Fonts are one of the areas where HTML5 ads struggle, as font libraries can increase file weights. While some advertisers are comfortable using the publicly-available Google fonts, many brands require their custom font to be used in all advertisements.

Right now multiple ad tech vendors like PaperG have projects in progress to mitigate some of these issues, such as hosting custom fonts in the cloud via CDN.

Can you speak a bit more about Publisher acceptance of HTML5? 96% of browsers accept HTML5, but we’ve heard through some of our clients that not all Pubs support HTML5.

It’s most likely the case that these publishers don’t support HTML5 in terms of first party serving. They are probably already trafficking HTML5 creatives from 3rd party creatives via iframe, and don’t even know it. Not accepting HTML5 as a blanket restriction is not necessary right now—it’s maybe just a lack of understanding. Smaller publishers might not be able to support it directly purely based on scale because they don’t have a tech department.

As a rule of thumb, all publishers should be able to accept 3rd party HTML5 creatives that are trafficked via iframe ad tags.

When will Google Web Designer be moved out of beta? It is still very buggy and cumbersome to use.

As far as we know, no announcement has been made regarding the general release of this product. We did attend a recent Q&A webinar where Google revealed their next steps are to increase GWD’s capabilities for making more complex rich media ads.

Is DFP planning to make set up of HTML5 creatives easier? Right now there’s no easy way to set up HTML5 creative.

DFP currently doesn’t have any preset specifications setup for using HTML5 creatives.

As a producer, what are some benchmarks we should keep in mind when it comes to scope, timing, and budget? It seems QA has more prominence than it did in the past.

Depending on the scope of the project, there is typically a “30% rule.” It usually takes approximately 30-40% more effort to complete the process with the current state of technology. There’s more overhead with planning, budgeting, developing timeline, finding the right solutions, QA, etc.

With tools like PaperG, that percentage goes way down and we believe that we are in a place now where HTML5 ad production is actually much faster than Flash ad production.

Do you think using animated GIFs would be a viable backup/long term option, given that our client is considering using that in the event HTML5 units are not ready by the timeline?

Using GIFs would simply be a temporary solution. Many advertisers will not find the quality of GIFs acceptable as a long-term strategy.

Should you build ads responsive, so that the client can use the banner for any size unit?

A best practice is to start with the smallest desktop ad size first and create the best user experience in that size. Then, resize it up to get the most innovation in the largest ad sizes. The majority of the industry is built around fixed sizes, and at this time responsive advertising doesn’t appear to be worth the effort, but having multiple versions of an ad in different sizes will definitely help optimize your ad spend.

For trafficking out HTML5 ads do you need to include a backup .gif/.jpg, just like with Flash/.swf ads (to the ad server)?

Broadly speaking, yes. In the unlikely event that the user’s browser has javascript disabled, for instance, a backup image can be served. PaperG users don’t need to worry about this—we automatically capture a backup image for every ad.

How is viewability measurement affected by the shift to HTML5? Are there any substantial consequences from the shift in formats?

There are no differences we know of between how viewability is measured on Flash ads versus HTML5 display ads. The javascript tags used to measure viewability are fully compatible with HTML5 environments.

Thunder Essential Guide to Programmatic Creative Ebook