Banner ad file optimization: What are full.min.js and thin.min.js for?

Advertising
1

I’m using Hype 3 for the first time and wanting to use it for display banners. I’m still working on the final ads the publisher that I’m working at limits my files to 150k (all inclusive). I noticed that the “export as HTML 5” option creates a couple of obviously essential files, but a couple that I was able to delete and still run the animation. I’m wondering if these are important, or “just nice to haves” because at 150k, every little bit matters and slimming things down would really help.

Here’s what I’ve deduced so far:
4619AC-restorable.plist (25k - don’t think I need this)
HYPE-466.full.min.js (94k - appears to be the more robust version of the js library - I removed this)
HYPE-466.thin.min.js (54k - appears to be the base of the js library - kept this one because it was 40 smaller)
PIE.htc (45k - appears to be an IE specific support file but it’s big so I’d like to get rid of it… consequences?)
filename_hype_generated_script.js (4k - clearly the layout commands & structure - keeping this)

Oh, and BTW I have to say that I’m impressed with Hype 3 so far and the fact that the thin version of the .js library is already 50% smaller in file size that the one that Edge Animate kicked out is already a HUGE win for me.

5 Likes
2

You don't need this. You can turn it off the creation of this file in the preferences.

More info here... Tumult Hype Documentation

3

At load time, Hype will only download the smallest set of files it needs to run, so unless disk space is a concern there's no download penalty to keeping the files around.

Your deductions are pretty much correct, but I'll explain each file in a little more depth:

4619AC-restorable.plist

This is basically a representation of the .hype document for restoring from an export. We did this mostly for support reasons - often users would email us their exported document instead of the .hype document and it'd save us a couple emails. Also users sometimes accidentally would trash their .hype document and this is a nice way for them to get back to a working version.

The first few digits are randomized so that a casual browser cannot guess and download your source document; if you really don't want people getting at it then you can disable generation of this file in the preferences as @Photics mentioned.

HYPE-584.full.min.js

This is the full Hype javascript runtime. It is responsible for interpreting the animation data, building the DOM, and driving your entire animation. It is the same for every export. What makes it "full" is that it includes support for IE6-9 and Physics. So if you're deploying on IE or using Physics you must keep this around. In the future we may include more here too.

HYPE-584.thin.min.js

Same as above but does not include support for IE6-9 or Physics. In most cases this is what is loaded.

HYPE-584.waypoints.min.js

When an On Enter/Exit Viewport action handler is used, this file will be conditionally included and loaded to support the waypoints for those actions.

PIE.htc

Used for IE6-8 to provide some CSS3 effects.

blank.gif

Used for IE6-8 to properly display PNGs with alpha channels.

cache.manifest

When "Create offline application cache" in the Document inspector is checked, this file is created as a listing of resources which are to be cached for offline usage. Otherwise this file is not created.

filename_hype_generated_script.js

This document contains all your animation/layout data as well as a basic loader for choosing which HYPE.js runtime file to load. This one is absolutely critical! :smile:

Thanks! We spent a lot of engineering effort each release to make sure download size and network connections are as minimal as possible.

5 Likes
4

I should also mention you can use Chrome’s developer tools Network tab to see exactly what is being downloaded for your document. (Safari’s tends to report cache numbers so I don’t like it as much for this particular case).

5

Love it! Thank you for this.

It sounds to me like I’m going to need to leave in the “full” js library because of the IE 6-9 support, but at least I can confidently drop the “thin” library and the .plist file. Do you know enough about PIE.htc to predict which which elements of CSS3 will fail in IE with out it? Trying to figure out if I can just stay away from gradients or rounded corners or something else to make PIE.htc unnecessary?

Also, to respond to your original question/statement… disk space is exactly what I’m trying to address. When we deliver files to our ad network or web master their first check is the file size of the assets we provide. If we are above the 150k spec that they’ve mandated it gets sent back. So every little bit matters.

6

The loader script dynamically chooses between the thin or full when the page is loaded, so if you drop this you could easily wind up with an empty page. It isn't based on document settings (aside from the detail that if you have an element with physics it MUST choose the full version).

However a workaround is to insert a <script> tag in your head which loads the full HYPE.js file; the loader checks to see if it has already been loaded and if so it won't do anything.

The elements won't "fail," but these effects will not show up:

  • border radius
  • box shadow
  • Gradient fill color

Interesting to know! There might be some things we can do - I'll shoot you an email.

2 Likes
7

I can work with this. Thank you.

1 Like
8

I wanna bring this topic up again, since Google Chrome officially launched the “Death of Flash”. At our company, we have to switch from Flash to HTML5 with banners, but the problem is the file limits are still same as for Flash. Sometimes 50-60 kb. Insane. We are starting to give the option for our customers hosting extra material on Amazon S3. But that’s an extra invoice for them, so some just go with a GIF animation instead.

Reason why it cannot be turned up easily, is because the media firms have already purchased ad placement on websites for a whole year ahead. That limit was included in that price. Hopefully in a year, it will increase.

Getting file sizes down is very important for the ad industry!

3 Likes
9

I feel like this is going to be a big deal pretty quickly. Flash has been dying for years and Advertising was the last hold out. But in the last couple weeks I’ve watched our agency, our vendors and several other agencies all start paying attention and getting into HTML 5 banners. It has to happen.

There’s got to be a compromise between file size and functionality. Google’s Web Designer tool looked promising as the payload was something like 34k in my first test. But files didn’t run in any version of IE that I tested in so I’m back to using Hype 3. But were still no where close to 40-60k.

I’d be happy with a truncated capabilities set and a really small js library. I don’t need a physics engine for a banner ad… and I can figure out how to work around drop shadows and rounded corners, if the file size issue is addressed.

The problem is that the software that’s out there (including Hype 3) wasn’t built for advertising. And the stuff that was built for it is still really buggy. Advertisers are about to figure this out and the first developers to hear us and adapt will get my business (probably for a long time).

3 Likes
10

We agree and are working on some ways to reduce the weight!

1 Like
11

What about a CDN for the Hype JavaScript? Would that solve the problem? It's common for popular JavaScript libraries, like jQuery. I don't use CDNs, as I don't want to leak visitor data to third-parties. But if Tumult hosted the Hype JavaScript, they probably could get a better idea of how Hype is being used - and possibly one massive bill for bandwidth.

This is the window of opportunity for Hype though. Flash is dying. Developers and designers are going to be settling on their replacement tools soon. Hype mostly works for what I do, but it is a bit heavy for simple banners. The JavaScript should be generated based on the features used in the Hype project. Unfortunately, that's a challenging task.

Also, the main advantage Flash has over Hype is that a Flash project is a single file. It has compression. Hype projects have lots of files. Converting Flash to Hype typically involves the use of SVG images. They're so much larger than an equivalent vector image in Flash.

3 Likes
12

Off loading the JS to a third party doesn’t solve the problem ( I wish it did). The way it’s been described to me is… “your entire payload should run without an internet connection”(from W3C). Any third part scripts/assets will count against your 40-60k file limit.

1 Like
13

I agree with your assessment though… the clock is ticking, lets hope Hype gets there first.

1 Like
14

Measuring ad weight is a bit of a mess right now; there doesn’t tend to be standards on what different ad networks use.

As I mentioned, we are looking to improve how Hype deals with ads; I agree this is a limited window. If you have any thoughts or feedback in this use case and how it pertains to the ad system you’re using, feel free to either post on the forums or shoot me a personal email (jonathan@tumult.com). Thanks!

15

IMPORTANT EDIT: Adform sets file size limits based on uncompressed files, MINUS external Javascript libraries. So as long you can host them externally, it’s quite easy now to even make 60 KB limits. I would recommend deleting all scripts and then linking to the thin javascript in Head HTML. See this post:

http://forums.tumult.com/t/banner-production-live-support-please/3905/4?u=fakepilot&source_topic_id=2202

Have been emailing with Adform about the file size limitations. Summary is; You can use external libraries. But that doesn’t fall out of the file size limit. What is measured is the total file size of the zip containing all the local and external files.

Which is good and bad. You can fit maybe twice as much in a zip.

My question:
What is measured in that limit? The zipped folder? The images, html file and javascript?

Adform Answer:
According to IAB guidelines the weight of the banners should be intended as zipped file:

The maximum weight can change according to publisher specs, but it’s a good practice to follow IAB specifications:
http://www.iab.net/displayguidelines

On Adform platform the limit is set on our clients contract, so it can change according to their needs.

Banner weight is comprehensive of all external files, JS, CSS, images…retina images can be used.

We are aware that animated banners can weigh a lot comparing to old flash creativities, you can use your favourite tool as far as you make the banner according to Adform specs:
http://creative.adform.com/support/documentation/build-html5-banners/other-building-tools/

If you have more questions feel free to ask, you can find FAQs here:
http://creative.adform.com/support/

1 Like
16

Seems strange that they're using the Zip file size, and not some measurement of user experience (average time to first frame, or something). Luckily, Javascript zips up very nicely due to frequently-repeated strings.

17

Actually, this is no longer correct. Sorry, I think I mentioned it in another post.

They measure the weight of the folder, but not the weight of the external scripts (hosted yourself) or one’s linking to CDNs. The first guy I talked with at Adform, wasn’t right. We had Adform here at the office and they explained it better.

So, no total weight of zip’s.

18

Hi there,
This is very helpful, thanks. I am a little new to all this ad banner malarky. If I host my .min.js file externally, can that just be on my clients ftp or do they need to be hosted somewhere else instead.
Also it would be great to read that “Banner production - Live - support please” but i “don’t have access to that topic” any ideas?! Does it give any advice on how to make the files compatible with IE9 when linking from the Head HTML… is it not possible to add the .full.js and PIE.ht too?

Many thanks in advance
Dave

19

As I read the IAB spec, it seems to me that they are suggesting that publishers should embrace CDN’s and exempt commonly referenced scripts from the file load calculation, This is important because there are a couple key points in the way they state it:

  1. Files must be common enough that a significant portion of the Internet is already referencing them and they are already being cached on larger server networks (I read that as something like jQuery, Moo Tools or YUI which are very common and found in many CDN caches). If we can get the Hype resources added to that “certified” or “exempt” list we are golden, but until then they’ll still be counted.
  2. The spec is referring to CDN’s, so posting your own files to your own server won’t help (it’d be nice if it did, because you could dump anything you wanted on an external server and never have to worry about file size again).
  3. As of the 2015 Guidelines, IAB is suggesting that this exclusion should be considered but they say that until publishers come on board and agree to this, the external files may still be counted against your file size limits.
20

hi @TheJensen
Thank you for your reply. it’s very much appreciated. So it looks like CDNs maybe our saviour… eventually.
For anyone else reading this thread who isn’t familiar with CDNs (like me) I found an article that helps explain it and gives a list of commonly used and even free ones:
All about CDNs for dummies

1 Like