Read on Twitter
1/ Was not enough said about this news from @ChromiumDev last wk? As a former maker of JS- & asset-heavy HTML ads, I have opinions on limiting the amount of local machine resources that ads consume. My opinion is that Chrome is RIGHT to impose limitations. https://blog.chromium.org/2020/05/resource-heavy-ads-in-chrome.html
2/ These features from Chrome seem focused on "abusive" ads (crypto-mining, I guess?), but there's plenty that can probably be done to reduce the bandwidth and processing burden imposed by all manner of resource-hogging legitimate ads.
3/ When everyday ads load, I don't think most "normal" people or even digital ad professionals know how much shit consumer web browsers are forced to download. For the purposes of this thread, I'm going to ignore video, which is by its nature resource-heavy.
4/ Ad HTML is usually minimal. Probly a few K. But then that HTML starts to call other resources...
5/ First up: images. When I did DCO, I resized and compressed my platform's images (usually tens of thousands of product images for dynamic retargeting ads). This was out of self-interest: I wanted to minimize CDN costs.
6/ It was ALSO out of the interest of clients: smaller images = faster load time = better campaign performance. Simple. But I expect many published creatives are lazy about this (ad tech has a lot of lazy players...more on this further down) and don't bother optimizing images.
7/ Consumers & advertisers end up paying for this. Big images = slow ads which might still be waiting for images to load AFTER the impression has been bought & paid for. Consumer internet bandwidth is wasted downloading 2000x2000px images that are then rendered at 100x100px!
8/ How many advertisers are able to test browser download/render time on their ads? Not many I'd wager. It's not that easy to do (I won't get into why).
9/ OK, that was just images. Now the fucking code libraries. Many developers don't write much of their own code any more. They load code libraries that someone else wrote and then call features with an API.
10/ This is great. I used to use TweenLite and JQuery a lot. Super useful and huge time-saver. EXCEPT...even to use the smallest feature of JQuery in an ad, the consumer has to download ALL of JQuery! These JS libraries are super inefficient. https://greensock.com/tweenlite/
11/ In many instances, the ad can check to see if a needed library is already cached on the consumer's browser. However, trust me, when you're seeing ads all over the web every day, chances are you're downloading multiple MB of redundant JS all day.
12/ Not to mention all the other resources that are piggy-backed into these libraries. Fonts, CSS, images, icon sets, vectors, more JS, etc.
13/ Speaking of fonts, that's another one. Some fonts are reasonable in terms of size, but again, when you see ads all day, you may in fact be downloading dozens or hundreds of FULL font sets all day long. Again, sometimes they're cached, but I'm betting often not.
14/ By the time a seemingly innocuous display ad has rendered, the total bandwidth could balloon to several MB! For a display unit! We're not even talking video/audio.
15/ OK, that's just bandwidth usage. The consumer's browser then has to process all this. The ad HTML+CSS+images+fonts+vectors have to render. Then the JS needs to run. Yikes.
16/ JS is an interpreted script. You'd don't compile JS, so it's inefficient and brute-force. Analogy: with a compiler you get a single sheet w/ the answer to "When was Mark Twain born?" With an interpreted script, you have to carry a WHOLE ENCYCLOPEDIA home from the library.
17/ I'm not a comp sci person, but I play one on TV. Here's more on why compiled code is more efficient than code run through an interpreter: https://www.freecodecamp.org/news/compiled-versus-interpreted-languages/
18/ How do consumers experience this? Usually with a hot computer (literally physically hot) and whirring fan as the CPU works overtime to crunch through megabytes of JS code libraries downloaded by a single ad creative. It's preposterous.
19/ Thematically, #adtech to-date has relied overly on pushing its computational workload onto people's browsers whenever and however possible. Make the consumer's browser do all the HTTP calls to sync data. Make the consumer's browser download and run all the JS, etc...
20/ This is why I've always considered much (NOT ALL) of ad tech to be kind of "lazy." When you distribute the compute resources for your platform across millions/billions of devices, that's a lot cheaper than building and paying for real backend infrastructure.
21/ The pixels are coming home to roost, though. Because one side effect of all these new browser privacy features is that they will collectively lessen the extent to which ad tech can leech off consumer's bandwidth and CPUs.
22/ End side rant about client-side laziness...back to the ads. Hopefully I have convinced you that ads can and probably should be made more efficient for consumers.
23/ Also: if ads are consuming fewer resources, then the PUBLISHER browser experience ought to improve, getting faster and less choppy. (setting aside the fact that publishers are loading their own multi-MB payloads of "lazy" ad tech that consumes browser resources...tsk tsk)
24/ Now what could be done to improve ads, aside from @ChromiumDev simply blocking the most egregious abusers?
25/ First: block the abusers. I think this is a fantastic idea. Barring sheer incompetence, no legitimate ad campaign is going to be hobbled by this.
26/ Second: perhaps force ads to use pre-built browser features like CSS animations. Negate the need to download bloated JS libraries and other parlor tricks. https://www.w3schools.com/css/css3_animations.asp
26/ Third: do more proactive detection of the download/rendering experience. Are ads inefficiently downscaling 2000x2000px images down to 100x100px in the HTML?
27/ Fourth: pre-cache / pre-install all kinds of standardized resources in the browser itself. Fonts, JS libraries, vector assets, etc. This is probably already done to an extent and I'm not enough of a browser geek to know about it. Mea culpa.
28/ What you end up with is a more prescribed toolset for building ads. Kind of like an AMP for ad creative. This could result in a FAR more efficient experience for consumers with respect to bandwidth, CPU usage, UX choppiness/slowness, etc.
29/ CC @JamesHercher thanks for covering this. I was intrigued! https://www.adexchanger.com/online-advertising/chrome-to-block-data-greedy-ads-as-more-control-moves-to-browser-software/
30/ CC @thezedwards in case you have opinions. You know FAR more about browsers than I do!
