Jump to content
Search Community

Search the Community

Showing results for tags 'ads'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • GreenSock Forums
    • GSAP
    • Banner Animation
    • Jobs & Freelance
  • Flash / ActionScript Archive
    • GSAP (Flash)
    • Loading (Flash)
    • TransformManager (Flash)

Product Groups

  • Club GreenSock
  • TransformManager
  • Supercharge

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Twitter


CodePen


Company Website


Location


Interests

Found 8 results

  1. Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements including a much smaller file size! Please see the GSAP 3 release notes for details. In recent months, the whirlwind shift to HTML5 in the banner ad industry has prompted a slew of policy changes. Publishers and networks are scrambling to answer questions from designers who want to build things "properly" (a term whose meaning can vary wildly these days). Growing pains abound. Shortly after we published an article describing the state of affairs and offering recommendations for a path forward, the IAB released a draft of their new HTML5 ad specs which echoed many of those recommendations. For example, the file size limit for standard ads was raised to 200kb. This was cause for much celebration across the industry. But we're not out of the woods yet. There is still a persistent mindset about how we look at kilobytes that's crippling the web. This article aims to challenge the old paradigm and explain why it's so important to re-assess kilobyte costs. Why limit kilobytes? Conventional wisdom says that kilobytes have a direct impact on load times and consequently user experience. File size limits exist to promote better performance. Period. Does conventional wisdom apply the same way in the HTML5 era? As we modernize our kilobyte-count policies, let's remember what the goal is: performance...or more accurately, better user experience. Not all kilobytes are created equal HTML5 has unique strengths that challenge us to move beyond the simplistic "aggregate total file size" mentality of yesteryear. We need to look at kilobyte cost in a new, more nuanced way. There are four primary factors: Cache status When is 35kb not really 35kb? When it's cached. A cached file has absolutely zero bandwidth cost regardless of its size. It loads immediately. This is particularly relevant in banner ads because there are certain chores common to almost every ad (like animation management tasks) that can be encapsulated and shared among many, many banners. The end user only loads that shared resource once and then it's cached and completely "free" thereafter...for all ads pointing at that file...on all sites. Does it really make sense to penalize ads for using those ubiquitous shared resources even though they're so pervasively cached that they don't typically affect load performance? In the modern world, file size limits should apply to the banner-specific assets that have a direct impact on loading times, not standardized shared resources. Location Kilobytes loaded from a CDN (Content Delivery Network) are typically "faster" because they're geographically dispersed and automatically loaded from the closest server. Plus CDNs have inherent redundancies leading to better reliability. Spread 200kb spread across 24 files will take longer to download than 200kb spread across only 4 files. This isn't particularly relevant in the discussion about shared resources (which should be cached very quickly), but is an argument in favor of loading TweenMax rather than the combination of TweenLite, CSSPlugin, EasePack, and TimelineLite even though they collectively use fewer kilobytes. If the industry remains focused solely on aggregate total file size, it pushes designers/developers toward less capable solutions that use fewer kilobytes even though they don't necessarily affect load times and could be replaced by more robust options that allow more creative expression. Performance yield Some kilobytes are cheap in terms of the initial load but expensive for runtime execution. If our goal is better user experience, this factor should weigh heavily into the overall kilobyte cost equation. Would you rather have a banner that loads 200ms faster with janky animation or one that's super-smooth at runtime but takes a fraction of a second longer to load? Are publishers primarily concerned with displaying ads faster initially or ensuring that their site runs smoothly once loaded? Of course there are reasonable limits either way (waiting an extra 30 seconds for a huge file to load would be intolerable even if it made things run buttery smooth), but in most cases we're only talking about fractions of a second difference. For example, GSAP contains "extra" code that automatically GPU-accelerates transforms, applies lag smoothing, leverages 3D transform matrices, avoids layout thrashing, organizes things internally to make auto overwriting super fast, etc. - would removing those features for the sake of milliseconds on initial load (and zero savings once it's cached) be a step forward or backward? Incentivizing the wrong things If the IAB and publishers don't embrace a common set of shared resources that get excluded from file size calculations... It creates inefficiencies and redundancies - thousands of ads may each contain their own [duplicate] copy of a library like TweenMax, squandering valuable bandwidth. It penalizes the use of robust, industry-standard libraries in favor of custom JS and micro-libraries that probably aren't nearly as capable, well-tested, cached, compatible, or performant. When something breaks, it will be more difficult for the various ad networks and publishers to troubleshoot and support custom JS and diverse micro-libraries. Lots of APIs to learn (or in the case of custom JS, more advanced expertise would be required). GreenSock would likely need to create a minimalistic version of TweenMax that has a tiny subset of the features. We feel strongly that this is a step backward and explain why here. So ultimately, an "all-inclusive" file size policy could actually hurt load times as well as runtime performance. Yet the primary goal of file size limits is to protect performance. Hm. If the industry rallies behind a few popular, well-maintained and performant libraries, exempting them from file size calculations because of their ubiquity, it would not only deliver a better overall user experience, but also make it easier to create high quality banners. There would be fewer headaches for networks and publishers too. TweenMax (GSAP's largest file) technically weighs around 34kb but those kilobytes are the remarkably inexpensive kind. TweenMax is widely cached, it's on multiple CDNs, it packs various tools into a single file (zero "spread"), and it has an extremely high performance yield because of its many runtime performance optimizations. There are so many ads using it already that it has little or no effect on load times. Should it really cost banner ad designers/developers 34kb against their file size budgets? Is it wise to incentivize cooking up their own custom code for handling animation tasks instead? The good news Every major ad network we’ve contacted understands the value of shared resources and is very GSAP-friendly. In fact, virtually all of them have GSAP on their own CDNs and don't count its file size against ads unless the publisher insists otherwise (which is rare). One notable exception is Adwords, but we have been told they're working on a solution. 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 Google DoubleClick is even pioneering a process that will automatically detect when GSAP is used in an ad and swap in its own CDN link to maximize caching benefits. Pretty cool stuff. Conclusion Let's embrace the unique strengths of HTML5 and modernize the way we count kilobyte costs. Let's support policies that incentivize better performance and user experience rather than a race to the smallest total file size for each individual ad. Caching, CDNs, kilobyte spread, and performance yield should all factor into the way we view kilobytes the HTML5 era. FAQ Isn't it unfair if the IAB only recommends a few popular libraries? What about newer or lesser-known libraries? This is an entirely valid concern. The list should be reviewed regularly and the IAB can assess each library's industry support, performance profile, compatibility, and track record for ongoing updates and bug fixes. New contenders could be submitted for consideration anytime. But remember that the key to realizing the performance benefits is keeping the list short so that caching is focused and pervasive. If there are too many "standardized" libraries, it dilutes caching and defeats the purpose. There's no way that everyone will agree on which libraries should be on the list but if we get hung up on not offending anyone or being afraid to appear biased, we'll miss the opportunity to move the industry forward. The list won't be perfect, but not having a list at all is much worse. What happens when a library gets updated? Wouldn't it need to be re-cached? Yes. And trust me - we want libraries to be updated somewhat regularly to work around new browser inconsistencies, patch library bugs, and implement new features that drive things forward. But these updates wouldn't need to interfere with existing or legacy ads - when a library is updated, a new CDN URL would be generated and new ads could optionally point to that version. Those ads would indeed trigger browsers to cache that new version but this should happen very quickly. Most likely within a matter of days the new version would be pervasively cached across the web. Yes, each end user would pay that kilobyte tax once on the first load and then it would be "free" thereafter. Would GreenSock still recommend this policy if GSAP wasn't included in the short list of exempt libraries? Absolutely. This isn't just about getting GSAP an exemption - this is what we believe is best for the industry overall even if GSAP isn't on the list.
  2. Just thought I'd share some banner examples from my day-job https://www.andyfoulds.co.uk/banners/html5_banners/ Reckon every one has GSAP to thank to some extent! Andy___F
  3. Hi all, What measures do you take to optimize your banner ads in terms of file size? Do you optimize the file size of your images? Do you minify the HTML, JS and CSS? Any other things? We've recently integrated an image optimizer into our platform which optimize all images (PNG and JPG) in your HTML5 ads. Just wondering what the experts do more
  4. Hello GSAP community! Been learning GSAP as of late and really loving it however i am stuck in developing this particular banner. I have set up all my html, css and JS created my ids and variables and developed a single timeline for animation. However it seems for some reason the timeline only plays the first 2 tweens and then stops even though i have more animation to follow. have a look at my codepen to see what i am trying to achieve here: https://codepen.io/Caderial/pen/LbYRVZ What i would like is to at first set mainScene, NYScene, NJScene, PAScene all to beoffscreen to the left by 322px. then the animation should kick in and slide in each scene and slide it back out then slide in the next scene and so on. But for some reason my first two timeline events happen with mainScene but then it stops? Please advise. I am also open to any alternative methods of bringing in pages/scenes into and out of view that may be better then my solution. thanks everyone!
  5. Please help us gauge if it would be worthwhile to get more involved with creating some products / services for banner developers. Perhaps that would be templates, videos, podcast new tools for fancy effects…we're not sure. Our goal is to better understand the needs out there and see if we can address the pain points, perhaps with a partner of ours who has a ton of knowledge in the banner ad space. http://goo.gl/forms/2ZZ3c3vzRt Please take a few minutes and fill it out; be as brutally honest as possible. If you want to chime in with other ideas that aren't mentioned, that's totally fine too (drop them in this thread below or in the survey itself). Thanks!
  6. Hi! We have been working on a new way to export faster, smaller HTML5 from Adobe Animate. As we are nearing launch we would love to hear about your experiences with Flash and Animate for HTML5. https://www.surveymonkey.com/r/Z3DNNQB Be sure to enter your email for a chance to download the product before launch!
  7. Hi, i am doing tons of online advertising banner stuff. Sometimes I have to use local JS GSAP libraries, but often i can use the CDN path to Tweenlite etc. to save file size when delivering to the advertiser. There are two methods - to link to the latest GSAP eg <script src="http://cdnjs.cloudflare.com/ajax/libs/gsap/latest/plugins/CSSPlugin.min.js"></script> <script src="http://cdnjs.cloudflare.com/ajax/libs/gsap/latest/easing/EasePack.min.js"></script> <script src="http://cdnjs.cloudflare.com/ajax/libs/gsap/latest/TweenLite.min.js"></script> <script src="http://cdnjs.cloudflare.com/ajax/libs/gsap/latest/TimelineLite.min.js"></script> or link to the version # of GSAP when coding the banner <script src="https://cdnjs.cloudflare.com/ajax/libs/gsap/1.18.0/TweenLite.min.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/gsap/1.18.0/TimelineLite.min.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/gsap/1.18.0/easing/EasePack.min.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/gsap/1.18.0/plugins/CSSPlugin.min.js"></script> What is more save to ensure the banners will work, when they show up later "live" at the browsers. Today i had some trouble when using the CDN Links with version # and got a error in Google Chrome's Browser ERR_SPDY_PROTOCOL_ERROR where the JS scripts did not load at all - so did not the banners! This should never happen when the work is "live"...
  8. I was asked on Facebook about using GSAP in banner ads that are created for/in the MRAID system, and since Facebook is really bad for tech support and posting code, I figured I'd start a topic here so others could benefit too... You can create and test an ad in a browser-based simulator here: http://webtester.mraid.org/. I noticed that there was a problem with the simulator or MRAID itself that was causing it to trigger the ad BEFORE 3rd party libraries had finished loading. So in this case, TweenLite wasn't defined yet, thus no animations would work. The simple workaround is to add some conditional logic so that your animation code doesn't run until both MRAID is ready and TweenLite/CSSPlugin has loaded. Here's a simple example that seems to work fine in the simulator: <script src="http://cdnjs.cloudflare.com/ajax/libs/gsap/1.11.7/TweenLite.min.js"></script> <script src="http://cdnjs.cloudflare.com/ajax/libs/gsap/1.11.7/plugins/CSSPlugin.min.js"></script> <div id="box" style="background-color:green; width:100px; height: 50px; position:absolute;"></div> <script> //this method gets called when the ad is ready and should run. function runMyAd() { TweenLite.to("#box", 2, {y:100, opacity:0.5}); } //this function keeps checking to see if mraid is ready and TweenMax has finished loading. function doReadyCheck() { if (mraid.isViewable() && window.TweenLite) { runMyAd(); } else { setTimeout(doReadyCheck, 100); } } doReadyCheck(); </script> Useful link: Common problems and best practices: http://www.iab.net/media/file/MRAID_Best_Practices_Final.pdf
×
×
  • Create New...