Clarify size limitation on “lazy load”

[gregersrygg]

The spec says:

Note: The size limitation is on the initial load. You can lazy load additional content, but for the first rendering this is the limit.

It is not clear what is meant by “initial load” and “lazy loading”, and when it is allowed to start loading data.

At FINN.no, we think initial load should be defined as every resource on the page has finished loading (a.k.a. the load event). We also think the javascript on the page should have time to render things dynamically before ads start loading extra data, so the spec should probably include a time delay after the load event. How long time would be reasonable?

Also, the spec should probably have a max total size before a user interaction. I've checked the price pr MB at Telenor, and one of the subscriptions has 5 NOK pr MB after the monthly included 200 MB is exceeded. So the limit should still be quite low. How about 200 kB? http://www.telenor.no/privat/mobil/mobilabonnement/mobilxs/

The kB-limit has to be for all devices including desktop. There is no way to know what kind of connection a user has, and the suggested navigator.connection.bandwidth javascript property has been deprecated by the W3C Device APIs Working Group.

The spec does not need to define a max size after a user interaction in our opinion. This should be clarified in the spec if others agree.

[tomsky]

I agree that "initial load" should be defined as when the load event fires.

A max total size for "initial load" needs to vary depending on the dimensions (height and width). Thus I think we need to resolve #23 before considering a max total size.

[gregersrygg]

@tomsky With responsive ads, what is the size? How can you know if a user is connected to a mobile network or wifi? The terms «desktop», «tablet» and «mobile» does not have a clear difference anymore. Windows computers comes in all sizes and flavors, and many laptops have touch. I think we have no other choice than one limit for everything.

[tomsky]

Of course we have other options. We don't have to know if a user is connected to mobile nettwork or wifi. We don't have to know what the users device is classified as either. All we need is the dimensions of the ad, the size should be relative only to the dimensions – not any other parameters. Although the html, css and js is likely to be the same regardless of dimensions, assets like images does not.

Media queries can be leveraged to load different images depending on the width/height. As the Picture element is slowly rolling out this can also be utilized.

I would rather see a formula for calculating what the size limit should be at any give width/height. A tool like that would make it easier to optimize assets for whatever breakpoints I (as a developer) decide suites the ad, without the spec making any assumptions about what these are.

[OleSan]

We have to take sales into account as well. I don't think they would like to go out to clients and say "The weight isn't fixed, it based on this algorithm that you have to calculate ". In a perfect developer world, this would work, but I can't see them going out to clients like this.

For setting a limit for lazy loading, what about we don't say a fixed weight (like 200kb), but rather say that you can double the initial load limit? And then just show an example:

If the initial load limit is 100kb, you can lazy load an additional 100kb after X seconds.

[tomsky]

A "one size fits all" solution for does not make sense. It either benefits large screens with high speed connections leaving the obverse with unnecessary high payloads. Or benefits small screens with slow connections, leaving large screens with e.g. pixelated images.

I vehemently believe that the size (kb) must be relative to the dimensions. If a decision is made, as suggested in #23, to not specify height and width, the spec should not specify a size either.

[OleSan]

That is my opinion as well, that we should rather define it as I said above, you can lazy load the same amount as the initial load after X seconds, rather than spesify that it is exactly 200kb or 300kb etc.

So if the initial load is 50kb, you can lazy load an additional 50kb. If initial load is 100kb, you can lazy load an additional 100kb.

Sounds ok?

Then we just have to find out how many seconds after the load event is appropriate.

[tomsky]

I don't see how "lazy loading" solves anything. It only creates a new set of issues. If an ad limit is 50kb and can load additional 50kb after the load event has fires – what do I do with the 70kb image I want to load when the ad is 2560px wide? Split the image in two segments and patch them together after load and have FOUC? I don't want to explain that to our sales department.

I'm thinking we should remove section 1 entirely from the spec.

[OleSan]

INMA wants to have a format in here, so we can't remove section 1.

I think for simplicity we should perhaps just remove lazy loading from the spec, and just keep

Resources loaded after a user interaction does not count against the total size of the ad.

That way they can load additional content after you've interacted with the banner. If they interact, they are intrested in the banner and it can download more content for the user.

Sounds OK?

If they want delayed loading of content, some sites can say yes if they want to. But as part of the core spec, its not allowed unless you interact with the banner first.

[gregersrygg]

@OleSan Where does the 50 kB limit come from? Looks like we only have 100 kB in the spec. What about cube-/gallery-banners that rotate the images? We'll basically force them to use vector-graphics if they can't load more images after onload. That would be nice in my opinion, but then we'll force the content creators to learn yet another web technology. Is it too strict?

Your previous comment sounds sensible. How about something like:

“Note: The size limitation is before onload. 100 ms after the onload event fired you can load yet another 100 kB. That gives the browser time to load the page and parse/execute javascript before loading the extra content.”

[OleSan]

The 50kb was just because I didn't think we would include a format in this spec. So at that time I thought it would be good to have a more general term where you could "load the initial size again after a set time", instead of saying a fixed size. Now that a format is included, your suggestion sounds more sensible.

I agree that delayed loading is something that ads like gallery banners would need, but I'm also afraid it will be abused for situations that don't really need it. It's also harder for AdOps departments to check, though the Validator should help here.

I'll try to get some info from more sites and perhaps a few creative agencies to see what they think about this.

[gregersrygg]

@OleSan :+1: