Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...

Solutions for Banner Ads in the Post-Flash World


| GreenSock
106675

Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements. While it is backward compatible with most GSAP 2 features, some parts may need to be updated to work properly. Please see the GSAP 3 release notes for details.

Solutions for Banner Ads in the Post-Flash World Published: 2015-08-07 Google sparked an urgent and rather violent shift away from Flash technology when it announced that Chrome will pause "less important" Flash content starting as early as September 2015. Flash has served as the de facto standard for banner ads for more than a decade. Firefox also blocked Flash after major security issues were discovered and Facebook's security chief called for Adobe to kill Flash once and for all. Amazon says it will no longer accept any Flash ads after September 1. Clearly Flash is on its way out of web browsers. Advertisers can no longer afford its liabilities. Now what? Modern browsers are remarkably capable of handling slick animations natively using HTML, JavaScript, and CSS (collectively referred to as “HTML5” or just “H5”), making them the obvious choice as the tag-team successor to Flash. No more plugins. However, a few barriers are clogging up the transition. Some are technical, some are political, and some have to do with a glaring lack of information. Let's address things head-on, identify some solutions, and get things moving in the right direction. GreenSock has a rich heritage in the banner ad industry, serving as its most popular animation library in both Flash and HTML5. In fact, it’s one of the fastest-growing JavaScript tools on the entire Internet and it was originally born out of banner-specific needs. We obsess about animation in the browser, studying the technical challenges, performance benchmarks, and workflow. Consequently, we’re in a unique position to lend a hand during this transition and perhaps illuminate the path forward.

40 kilobytes? Are you kidding?

Years ago, when bandwidth was a tiny fraction of what it is today, the ad industry codified a set of standards for banner ad file sizes. A common limit was 40kb (sometimes even 30kb) including all images, fonts, animations and scripts which Flash compressed into a single amazingly small swf file. Technically each publisher determines its own file size policies, but almost everyone looks to the IAB (Interactive Advertising Bureau) as a standards-setting body, like the W3C for web browsers. The IAB exists to help guide the industry but they don't mandate or enforce anything. When Flash ruled the banner ad landscape, certain file size specs were recommended by the IAB and the system worked well. However, the technology landscape has changed drastically.

Bandwidth, page size, and banner budget over the yearsBandwidth (Mbps)Banner budget (kb)Page size (kb)2008200920102011201220132014201540kb33Mbps40kb1,795kb
Year Bandwidth (Mbps) Banner budget (kb) Page size (kb)
Jan 1, 2008 5.86 40 312
Jan 1, 2009 6.98 40 507
Jan 1, 2010 9.54 40 679
Jan 1, 2011 10.43 40 788
Jan 1, 2012 12.7 40 1081
Jan 1, 2013 15.62 40 1529
Jan 1, 2014 20.83 40 1622
Jan 1, 2015 32.78 40 1795
 

Since 2008, average bandwidth has grown by a factor of 5.6 which is remarkably on-pace with the growth of the average web page size (5.7), but the IAB has been cautious about declaring HTML5 specs due to all the complexities involved. They released a set of HTML5 guidelines in 2013, but omitted any file size specs, saying only that HTML5 ads weigh "more" than swf ads. Without specs, many publishers clung to the safe limits of yesteryear. The gatekeepers who impose the 40kb budgets often do not have the authority or wherewithal to allow more than what the latest IAB spec dictates. Consequently, developers are forced to shoehorn HTML5 banners into archaic Flash specs which isn't what the IAB intended. This must change. From our vantage point, fear is driving the industry. Publishers and networks are afraid to raise the file size limits without IAB approval. Some do it anyway, but disagree on exactly how much, leading to wild variations. Developers have no choice but to build for the least common denominator in their ad campaign which is either totally unclear or ends up being the dreaded creativity-crushing 40kb. (UPDATE: The IAB released a draft of its new HTML5 specs.)

HTML5 is fundamentally different...embrace that

HTML5 banners often weigh 3-5 times as much as a Flash swf but far too many people myopically focus on the aggregate total file size. They miss the unique strengths of HTML5 technology that we should be exploiting - shared resources and browser caching. These have a tremendous impact on loading time and overall performance which is the whole point of the file size limits anyway! Flash compiled all assets into a single swf meaning that if 10 different banners on a site all used a certain library, it got baked into each and every swf. End users paid the file size price 10 times. Multiply that by millions of ads and it gets pretty crazy. In HTML5, however, a library can be dropped onto a CDN (content delivery network) and shared among all banners, thus end users only load it once and it’s completely "free" thereafter...for all ads pointing at that CDN...on all sites. This is a BIG deal. It means that common animation chores like the requestAnimationFrame loop, timing, sequencing, intelligent GPU layerizing, lag smoothing, compatibility workarounds, performance optimization, etc. can be extracted and shared among them all (much like what the Flash Player did for swf files). The unique banner-specific code can be much more concise, reducing overall load times and improving performance. shared-resources-pie-chart.svg File size limitations should be applied to the banner-specific assets, excluding the shared resources that drive common functionality. Imagine how silly it would have been if the 17MB Flash Player download was included in the aggregate file size for each swf banner. Ad networks and publishers can put a certain subset of tested-and-approved libraries onto their CDNs and exempt them from file size calculations. We're thrilled to see industry leaders like Advertising.com/AOL, Google DoubleClick, Flashtalking, and Sizmek already taking this approach with GSAP. This strategy allows developers to avoid burning hours manually cooking up their own proprietary libraries to fit within the ad specs. Ad networks and publishers win because load times (and costs) are lowered and it's easier to troubleshoot problems when a common toolset is used. They reap the benefits of all the compatibility and performance optimizations in tools like GSAP. End users get ads that perform better, load faster, and look more appealing.

Animation technologies and approaches

For those tasked with building HTML5 banners, the choices are perplexing. Is it best to use a visual IDE like Adobe Edge Animate, Google Web Designer, or Tumult Hype? Even Flash is capable of outputting HTML5 content. These tools can make building ads easier (especially for designers who don’t want to write code), but a common complaint is that the resulting output is bloated and slow, making them ill-suited for banner ads. Some networks explicitly state that they won't accept ads built with these tools. We'd love to see the visual tools mature and export concise, performant, ad-friendly code because plenty of designers aren't comfortable hand-coding banners yet. Ideally, they'd tap into GSAP under the hood so that designers and developers could collaborate on the same files without worrying about runtime redundancies. There are also network-specific banner-building tools but their proprietary nature makes them impractical for many campaigns. If an agency uses one network’s proprietary tool and then their client asks to run the ad on another network too, it must be rebuilt. Learning how to use each network's proprietary tool can be cumbersome. Hand-coded animations are usually much lighter-weight, performant, and universally accepted, but building them requires a particular skill set. And which underlying technologies should be used? CSS animations? jQuery? GSAP? CreateJS? Once again, answers vary wildly among ad networks and publishers. The goal of this article isn't to provide an in-depth review or comparison of the various tools. Each has its own strengths and weaknesses, but let's briefly touch on some of the major runtime animation technologies:

  • CSS transitions and CSS animations - these are supported in all modern browsers, but not IE9 or earlier. They're cheap from a file size standpoint and they perform well. For simple animations like button rollovers, they're great. However, file size rises quickly and things get cumbersome when you attempt even moderately complex animations. Simply put, they will take longer to build, they won't work in some older browsers, there are bugs (particularly when animating SVG elements), and certain tasks are outright impossible. Additional reading: https://css-tricks.com/myth-busting-css-animations-vs-javascript/ and http://greensock.com/transitions/ and https://css-tricks.com/svg-animation-on-css-transforms/
  • jQuery - it was never intended to be a robust animation tool, so jQuery suffers from poor performance and workflow issues. Most ad networks strongly advise against using it. GSAP is up to 20x faster. Additional reading: http://greensock.com/jquery/
  • CreateJS - Adobe Flash can optionally export to this canvas-based library. You can't just publish existing Flash banners to CreateJS (you must do some conversion work and leverage JavaScript instead of ActionScript) but for designers who are already used to the Flash interface, this can be a boon. One down side to canvas-based libraries is that you lose accessibility (the browser sees it as essentially a blob of pixels), but that's probably not a top priority for banners. File size can also become a concern (possibly mitigated by CDN standardization). You can use GSAP to animate CreateJS content. Additional reading: http://createjs.com
  • Zepto - like a lightweight version of jQuery that uses CSS transitions under the hood for animations. Zepto is better than jQuery for banners, but it suffers from similar workflow issues as well as the inconsistencies/bugs inherent in CSS transitions/animations (like with SVG transforms). Active development seems to have stalled. Additional reading: http://zeptojs.com
  • Web Animations - a new spec being worked on that has a lot of promise, but it just isn't a realistic contender at this point because it is in flux and several browser vendors remain noncommittal about ever supporting it. The polyfill has performance problems. Additional reading: http://w3c.github.io/web-animations
  • GSAP - Widely recognized as the performance leader, GSAP solves all kinds of real-world animation problems from browser inconsistencies to workflow headaches (far too many to go into here). The Flash banner ad community is full of designers and developers who use GSAP daily, making it much easier to transition to HTML5; no new syntax to learn. Ongoing development and support have a solid track record for over 7 years. Additional reading: http://greensock.com/why-gsap/

Recommendations

Based on our experience and the results from our survey, we suggest the following:

Standardize a few JavaScript libraries

Ideally, the IAB would equip the community with a short list of recommended libraries that get CDN-ified and exempted from file size calculations. Historically, the IAB has been extremely reluctant to officially endorse any third party tools. That's understandable - it could be seen as playing favorites or unfairly excluding someone's favorite library. However, without specific recommendations, the HTML5 landscape is so fractured and complex that it will result in a free-for-all (which is basically what it is now). The IAB can set the tone and move the focus away from aggregate total file sizes and into the modern era that leverages shared resources and browser caching to deliver excellent performance. It is imperative that this list of "recommended" libraries be very short, otherwise the caching impact will be diluted. The IAB can run their own independent tests and look at performance, features, compatibility, support, workflow benefits, and overall industry demand to determine which libraries get recommended. Of course we feel strongly that GSAP belongs on that list because:

  • It is the top performer.
  • It has widespread industry acceptance, both in Flash and HTML5. It's recommended by Google, used by the biggest brands in the world, etc.
  • It is framework-agnostic, super flexible and robust, able to animate anything.
  • It is professionally supported, yet free to use in banner ads.

Modernize file size specs

Given the 5.6x growth factor of bandwidth and page size since 2008, it seems entirely reasonable to adjust the old 40kb limit to 200kb (5x) for the modern HTML5 era. This is entirely consistent with some in-depth testing that has been done recently aimed at identifying the file size threshold at which real-world users perceive a dip in performance. The results showed that the threshold was upwards of 250kb. Combined file size isn't the only issue that contributes to slow load times; the number of server requests can have a significant impact. A single 300kb file can often load faster than 200kb split among 20 files. HTML5 banners can't realistically mash everything into one file, though. Doing so would kill the benefits of caching and resource sharing. So a reasonable compromise seems to be a 10-file maximum. Sprite sheets can be used to combine images. Given all the factors, we'd recommend the following for standard (non-rich media) ads:

  • 200kb combined total (gzipped)
  • Maximum of 10 files. Any additional must be loaded "politely" (after the parent page finishes loading)
  • Shared CDN resources like GSAP don't count toward these totals.

Some have suggested slicing the 200kb standard limit into two parts - a 50kb initial load, and then the rest "politely" loads. However, we advise against this for standard (non-rich media) ads because it unnecessarily complicates the design and production process as well as QA and enforcement. Rich media ads will likely require more files and kb than the limits mentioned above, and those should be polite-loaded. By "rich media", we mean ads that contain video or expand or perform API calls (like feeding the viewer's zip code to a backend script), etc.

Update documentation and guidelines

It is surprisingly difficult to get answers to some of the most basic questions when preparing a banner ad campaign for even the biggest networks and publishers. What are the file size limits? Which libraries can be used? Do CDN resources count against the total file size? Is there a network-specific CDN link for common libraries? Online docs either have outdated information or none at all related to HTML5.

Drop support for IE8

Legacy IE support is not just painful for developers, it's exceedingly expensive for advertisers. Certain effects are outright impossible, so creatives must learn about the IE8 pitfalls and adjust their designs. Developers are forced to rebuild entire portions, implement workarounds and perform extra testing, all to accommodate a tiny fraction of the web audience who probably don't represent the demographic that advertisers are targeting anyway. This was never an issue for Flash, but it's a HUGE issue for HTML5 because it relies on native browser technologies that are absent from older browsers like IE8. Our recommendation is to draw a line in the sand and drop support for IE8 for sure, and potentially even IE9.

Consider SVG instead of iframes

Displaying ads inside an iframe is nice for security, but it forces ads into a strict rectangular space (ruling out fancy overlays with transparency/mask effects that show the main web page behind) and there's a performance price too. SVG is widely supported and it has some excellent transparency/masking capabilities, plus it can serve as a single container for an entire ad (see Chris Gannon's blog post and video)! Further testing needs to be done to better understand the performance and security implications, but it certainly seems like a worthwhile contender.

Create a gallery of sample banners and templates

Rather than pouring over specs and instructions and then building something from scratch, most developers prefer to analyze banners that already conform to the standards and use one as a template for their own project. Each network has different API's and ways you must track clicks, etc., so it would be lovely if each one provided a gallery of demos at each standard size. Codepen.io is a great place to host a collection because it's so easy to see (and edit) the HTML, CSS, and JS as well as the result all in one place. Developers can simply click the "fork" button and start producing their own version of that banner immediately in the browser. Codepen even integrates nicely with crossbrowsertesting.com for easy QA.

Adjust client expectations

As the industry transitions from Flash to HTML5, clients must be made aware of the design, budget, and schedule implications. HTML5 banners take more time to produce and test, therefore they will be more expensive. Plus there are certain effects that were easy in Flash but are virtually impossible in HTML5, so creative expectations need to be adjusted as well.

Common GreenSock Questions

With the broader discussion out of the way, let's narrow our focus to GreenSock for a moment and address some of the most frequently asked questions:

Which networks support GSAP?

All networks that we're aware of allow GSAP, and most even exempt its file size from the ads and host it on their CDNs. Google DoubleClick recommends GSAP for complex animations. Here's a breakdown of how some of the major players stack up:

  Allows GSAP Excludes GSAP from file size calculation* Hosts GSAP on CDN
Advertising.com/AOL YES YES YES
Google DoubleClick YES YES YES
Flashtalking YES YES YES
Sizmek YES YES YES
Flite YES YES YES
Cofactor YES YES YES
AdWords YES YES YES
*Unless publisher objects which is uncommon

TweenMax is too big! Where's TweenNano?

Let's face it: TweenMax (the most robust tool in the GSAP suite) is overkill for many banners that are only doing simple fades and movement. Wouldn't it be smart for GreenSock to create a super-small animation engine that's targeted at banners and only has the basic features? In the Flash days, we did exactly that and called it "TweenNano". It weighed about 2kb. On the surface, it sounds like a great idea but there are several reasons we avoided TweenNano in the HTML5 toolset:

  • Caching - this is the biggest factor; loading the JavaScript file is a one-time hit and then the browser caches it, mitigating the entire loading issue on every page thereafter. Realistically, TweenNano must include a subset of TweenLite and CSSPlugin features and weigh at least 8kb; how much longer would it take for the average user to load an extra 25kb for TweenMax? It's not even noticeable (less than one second). So it doesn't seem like a worthwhile tradeoff to rip out all those features just to gain a fraction of a second only the first time it loads, especially for banners where caching and resource sharing could be used so effectively. If networks toss TweenMax.min.js on their CDNs, it effectively becomes "free" (zero load time) very quickly, giving them instant access to all the timeline tools plus a bunch of advanced plugins. Thus it seems smarter to press the full-featured, super-fast TweenMax engine into service rather than a sliced-down TweenNano with limited effects.
  • Performance - GSAP has been engineered with a huge priority on performance which sometimes comes with a file size tradeoff. We could accomplish the same tasks with less code in places, but runtime performance would suffer. We feel strongly that when it comes to animation, it's wiser to pay a small up-front kb tax (only a fraction of a second in most cases) in order to get maximum runtime performance. Animations must look smooth and conserve battery power. Think of it this way: would you rather buy a computer that boots up 2 seconds faster or one that's 30% faster all the time (after it boots)?
  • Flexibility/Creativity - what if you want to animate a non-essential CSS property like boxShadow or slide along a curve or scrub through a timeline? Even if there's just one part of your banner that needs a more advanced feature, it presents a dilemma. Creativity is hampered. Again, the fraction of a second one-time cost difference for TweenMax seems well worth it for the added flexibility and peace of mind.
  • API confusion - years ago, Adobe created a lightweight version of the Flash Player dubbed "Flash Lite" with similar aspirations (bake only the essentials into a lighter weight flavor), but it was a complete failure. One of the problems was that developers couldn't remember which features were available in the regular Flash Player versus Flash Lite. Likewise, TweenNano's feature disparity would create some confusion/frustration.

What about creating a tool that lets users select only the features they need, and then it spits out a customized stripped-down version of TweenMax? Again, this sounds appealing, but it would likely lead to worse load times because instead of having one common TweenMax that gets shared and cached, every banner would have its own different (and partially redundant) flavor to load. Ultimately, we're committed to delivering the tools that are needed most, so if the broader industry decides not to leverage shared resources and publishers insist on sticking to all-inclusive aggregate file size totals, we're open to creating TweenNano. Luckily, it looks like there's excellent momentum behind TweenMax getting CDN-ified and exempted from file size limits. In our opinion, that's definitely the smartest approach.

What's so special about GSAP?

It's beyond the scope of this article to explain all the benefits of using GSAP; see http://greensock.com/why-gsap/ for a summary. If you're still wondering what the big deal is, we'd encourage you to find someone who is proficient with it and ask about their experience. Usually people who take the time to learn it have a "light bulb" moment pretty quickly and never want to go back to using other libraries or CSS. It's difficult to explain to the uninitiated - lists of features don't really do it justice. It's not merely about performance (although that's a biggie) - it's about feeling empowered to animate almost anything you can imagine with minimal code.

Do I need a commercial license to use GSAP in banner ads?

GreenSock's standard "no charge" license covers usage in banner ads even if you get paid a one-time fee to produce the banners. We fully encourage the use of GSAP in banner ads and beyond. You may want to check out Club GreenSock for some bonus plugins that allow you to easily achieve advanced effects.

Is anyone building a GUI for GSAP?

A visual tool for building GSAP-based animations is a popular request, and we have been approached by several large and small companies about the possibilities, but there's nothing rock solid to report yet. We hope that companies like Adobe and Google will offer export options from their tools that leverage GSAP as the runtime engine and produce well-formatted, concise code. There's a pretty neat tool called Animachine that's in alpha and can be installed as a Chrome extension. It shows promise, but isn’t entirely stable at this point. There are also several online GSAP-based banner builders: http://html5maker.com/, https://tweenui.com/, and http://www.loxiastudio.com.

Where can I get GSAP training?

You can have GreenSock come directly to your organization and sit with your team to get them up to speed quickly. We can even convert one of your Flash banners and then teach you how we did it which is an excellent way to learn banner-specific tricks. The Q&A sessions are invaluable. We have limited slots available, though, so contact us as soon as possible to get your event scheduled. There are plenty of other learning resources available:

The GreenSock forums are a fantastic place to not only ask your question(s), but also poke around and see what others are saying. It's one of the best places to learn even if you never ask a question. There are plenty of demos on codepen.io as well. For inspiration, we'd suggest following these people:

UPDATE: The IAB released a draft of its new HTML5 specs and is soliciting public feedback before finalizing the document. The outstanding news is that they agreed with our assessment regarding a 200kb limit for standard ads. The IAB is expected to release an update to its HTML5 Best Practices guide soon which will likely contain a short list of JavaScript libraries that are recommended for exemption from file size calculations. We're confident GSAP will be on that list.

Get an all-access pass to premium plugins, offers, and more!

Join the Club



User Feedback

Recommended Comments



I've been working on a Yeoman workflow to get a DoubleClick banner project started quickly using GSAP. You can check it out here: https://github.com/johnfmorton/yeoman-doubleclick-banner-starter
Link to comment
Share on other sites

I read through the article and I agree with all points. But what exactly are you guys saying is the solution? A shift in thinking by publishers? Whats the solution right now given the 40kb restriction? Recommend clients only use those networks the exclude GSAP from file size calcs? Thanks!
Link to comment
Share on other sites

Excellent article. Please try to work with RM vendors on informing the users about the libraries they can use without counting towards your total file size. Also if you can create some documentation to educate clients on designers on what can be achievable with HTML5 Banners (as opposed to Flash) you will be doing a lot of good for the community.
Link to comment
Share on other sites

Take a look at our LoxiaStudio animation gallery: simple ready-made templates for ads makers, with small footprint (usually less than 150KB: GSAP and all stuff, including images), and a limited number of required files. We decided do forget IE8 support, but IE9 support is still expected by our customers. We also worked on a multi-resolutions images concept (without using new HTML5 tag, it's too early for that...), so that an animation rendered in small size (responsive design) delivers smaller images than the same animation rendered in bigger size. Yet no highly-creative templates, but it's a first step for us. By its recommendations, this article consolidates our strategic feelings and our technical choices. http://www.loxiastudio.com
Link to comment
Share on other sites

@hhdev, our recommendation at this point is to help educate those who are still dragging their feet and imposing the archaic 40kb limit. Send them a link to this article and/or have them talk with the major networks to see that these strategies are being adopted widely. From our research, almost all of the big players are on board and modernizing specs even without IAB input. Leveraging the ubiquity and performance of GSAP will not only make those networks/publishers more appealing to advertisers, but ultimately it will allow them to improve loading times and runtime performance. We'd definitely encourage folks to favor networks that have realistic HTML5 specs and allow tools like GSAP without counting the file size against the ads. The publishers that persist in dragging their feet will have less and less business, putting pressure on them to modernize (at least in theory). The market needs to send a message.
Link to comment
Share on other sites

Jack, this article should be recognized as the official manifesto for html5 banner ads moving forward. Everything in this post is absolutely spot on. I'd like to add that finding a good png compressor (I use Pngyu combined with ImageOptim), and getting comfortable with Photoshop's Save for Web feature, are absolutely critical in terms of hitting the low file size specs for an html5 banner ad. On a side note, some ad networks offer different price points for various file-size tiers If you're lucky, your clients will be willing to pay the extra amount to run larger file size ads. I'm currently involved with a campaign that has a 110k file-size spec. As Jack mentioned, our ad network is not counting external JS loads against us, so even with the 110k file size spec, I'm able to build all the standard sized units using TimelineMax, which is an extreme time saver. Thanks again for you and your team's great work on GSAP Jack, it keeps me in the game!
Link to comment
Share on other sites

Interesting article, but of course one can almost feel your bias. Although I have been constantly struggling to fulfill file size restrictions for banners for almost 10 years now, I strongly disagree with you. I don't think it would be a wise decision to raise the mark to 400kB. On a "normal" website there is not just one but several of these banners and the amount of data transferred only for ads would easily sum up to several MB (even considering everyone would use the same frameworks and libraries). For mobile devices this would do nothing but promote the use of ad blockers. My suggestion would be a tiny raise to maybe 100-120kB at most. This would promote a more subtle and more user friendly approach in ads which I believe is - in the long term - the much better solution.
Link to comment
Share on other sites

@EarMaster, I'm not sure where you got that 400kb figure (we suggested half that), but I agree that it'd be unwise to raise the limit so much that bloated banners clog up our connections. It's always a balancing act. With HTML5, it simply isn't realistic to get rich, creative banners down to 100kb including all the assets. Bandwidth is constantly rising and the 40kb limit was last updated back in 2003. Even if we only look at the numbers since 2008 (and that's being VERY generous), the bandwidth has risen by over 5.5x. Thus the 200k limit is actually far less proportionally than the original 40kb limit. When you look at the ratios, 200kb is quite conservative. Perhaps you can crank out creative animated banners in 100-120kb, but I think for the average designer/developer out there, it's VERY difficult to do in HTML5.
Link to comment
Share on other sites

I wanted to raise a couple of things that are making HTML banner production a nightmare at the moment. 1. Compatability - Our clients are expecting their banners to work on basically every browser at the moment. In reality we are supporting back to ie9, ie8 shows a backup GIF. This is increasing the file size in the form of not being able to use .svg's and also fonts and fallbacks. As well as massively complicating the build process. 2. Fonts - Has anyone figured out font's yet? There are two option that I have found. Illegally convert a font you don't own the proper licensees for via font squirrel. That is, if the font is not blocked by the site. However due to the above point, you need to include 3 or 4 different font formats. .ttf, eot, woff and possibly and svg font. This can total up to 250k already, before you've even started. Technically according to the font licenses you are not allowed to remove characters from the font to reduce file size either. Apart from the fact converting to the different formats is illegal, as is putting the font on a domain that you do not own. Which is obviously a nightmare for agencies as we don't own any of the sites we put banners on. Dispite the illegality, this appears to be how everyone is doing fonts. The other alternative is to use fonts.com, the only problem being they require a tracking code. I spend 4 days on the phone with Flashtalking sorting out the fact that they do not like any external calls in their ads, but in the end we reached a solution that works on secure sites and normal ones. I lied their is another problem, you have to track page impressions, so for us to use 1 font in a banner getting 12 million impressions, costs us about £500 a month. Which may or may not seem like a lot of money to you. 3. I would love to use css transitions and keyframes to keep animation size down, but problem 1 means it has to work in ie9. The only solution left to use is to use GSAP. So with the font's and TweenMax we are sitting on at least 150k, before even getting nay images or assets in.
Link to comment
Share on other sites

I didn't respond to the initial survey because I have yet to build a H5 banner. I've spent many years using your great AS2 + AS3 libraries to build fantastic flash banners. One thing that concerns me is browser differences... Those of you who have built HTML5 banners have you run into layout issues? Fonts rendering slightly different causing layouts to not be pixel perfect? With Flash you always had that feeling that what you created will look the same across all browsers. With HTML5 Banners... I havent a clue? Or is this not really a problem at all? Thanks guys
Link to comment
Share on other sites

@ Wiplash: our current workflow for displaying text in html5 banners is to convert all text to SVG (create outlines of the text in Illustrator first). We embed the SVG into the html with a standard image tag. We then use CSS to set the width and height of the text for each ad (you can reuse the same SVG text element and just resize for each different ad, since it's vector!). In my experience, using SVG for text results in a bit larger file size than the alternative of using pngs for images, but png image texts appear blurry on retina displays. I definitely wouldn't want to deal with all the hassles of embedding fonts, legal issues, etc. If you do use SVG, you do need to make sure that whoever is hosting your ads has the SVG mime type added to their server.
Link to comment
Share on other sites

@Tim when you use SVG for text I assume that means the design maintains the same breaks across the banner sizes? Or do you have diff SVGs for say a leaderboard as opposed to a skyscraper? Lots of great information here guys! Thanks. Also if you guys have links to trafficked examples could you post them? Thanks!
Link to comment
Share on other sites

@hhdev: yes, when reusing the SVG outlined-text elements across banners, we have been using the same text layouts across banner sizes (luckily). If the text layout was different across banners, then yep- we'd have to save out unique SVG outlined-text elements for each different layout (have the banner's designer do this for you!).
Link to comment
Share on other sites

This is super useful, guys - thanks for posting this. It seems like this post is getting a lot of traction, so hopefully we start to see some movement in the industry - starting with upping that ridiculous 40k file size spec. One question about gzipping - what are the implications of gzipping banner files for trafficking? Isn't there a mime-type that has to be installed on the server to enable support for that? @Tim - good call on using svg for type. I'll give that a shot next time.
Link to comment
Share on other sites

One other thought - @Wiplash brought up browser compatibility. Maybe it would be worth it for you guys to amend the article with a browser-targeting matrix (beyond the very reasonable request to ditch IE 9 and below).
Link to comment
Share on other sites

@flysi3000: gzipping is a server-side thing, yes. You don't actually zip your files manually or anything. As for the browser-targeting matrix, could you provide more details? What were you envisioning specifically? Like something that showed what CSS properties are available/tweenable in each major browser? If so, caniuse.com is excellent.
Link to comment
Share on other sites

I'm used to using TweenMax on websites where there is no file size limitation. I now find myself trying to figure out the bare minimum size i need to use GreenSock for animation in standard banners. We are seeing some requests for HTML banners where they wan't all the assets to fit in a single 40kb zip file (with no CDN use). The way it works is you zip all your assets and then upload the .zip file to DoubleClick DCM. To use TweenLite effectively in a banner, it seems you need to at least include the CSS Plugin. When you zip TweenLite.min and CSSPlugin.min, you end up with a 25kb zip file. That only leaves us with 15kb for everything else we need in a banner, which isn't realistic. It seems like there might still be a case for TweenNano for creating standard banners (versus Rich Media). It would need to include base functionality to animate css properties. Like you said, 40kb is just not a reasonable amount. Unfortunately it is a hurdle we face for the time being. It is definitely a bit of a nightmare at the moment when it comes to file size.
Link to comment
Share on other sites

@noco, I totally see why TweenNano is appealing in your situation, but as I tried to explain in the article, creating it could actually cause a lot of problems. Within a matter of weeks (or maybe months), it should be a non-issue. If we cave and create it because of the short-term pressure, it could have long-term consequences and ultimately be bad for the industry. I know, it sounds weird. But we're trying to take a longer-term view. If publishers or networks are forcing you to fit HTML5 ads into 40kb, I'd strongly recommend that you have them read this article.
Link to comment
Share on other sites

In regards to web fonts and file size, i am also finding great discrepancies between ad server platforms and publishers spec and recommendation. It would seem as though in actual fact - nobody knows! Our approach currently is to locally store webfonts (ttf, woff, eot and svg) and load them using @font-face - this will only load up the format that's needed. I am setting a standard spec to work within, and will have to liaise with publishers on this as we go along, but i am aiming to do the following: Count file size as being js files, css, images and html, as well as the largest font format file. Llink GSAP via CDN. I aim to be within 200k on this. which would mean everything bar fonts in the zip file is is going to be around 100-140k in size.
Link to comment
Share on other sites

@Jack, yeah I definitely see your side of it. It is very frustrating at the moment, but hopefully it gets better soon. I've actually already sent out this article several times, thanks for breaking it down so clearly.
Link to comment
Share on other sites




Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×