Wednesday, February 13th, 2019
Sunday, February 3rd, 2019
A spot-on description of how targetted advertising works …or rather, how it doesn’t.
They are still trying to sell me car insurance for my subway ride.
Tuesday, June 26th, 2018
Name That Script! by Trent Walton
How many third-party scripts are loading on our web pages these days? How can we objectively measure the value of these (advertising, a/b testing, analytics, etc.) scripts—considering their impact on web performance, user experience, and business goals? We’ve learned to scrutinize content hierarchy, browser support, and page speed as part of the design and development process. Similarly, Trent will share recent experiences and explore ways to evaluate and discuss the inclusion of 3rd-party scripts.
Trent is going to speak about third-party scripts, which is funny, because a year ago, he never would’ve thought he’d be talking about this. But he realised he needed to pay more attention to:
any request made to an external URL.
Or how about this:
A resource included with a web page that the site owner doesn’t explicitly control.
When you include a third-party script, the third party can change the contents of that script.
Here are some uses:
- A/B testing,
- social media,
- content delivery networks,
- customer interaction,
- tag managers,
You get data from things like analytics and A/B testing. You get income from ads. You get content from CDNs.
But Trent has concerns. First and foremost, the user experience effects of poor performance. Also, there are the privacy implications.
Why does Trent—a designer—care about third party scripts? Well, over the years, the areas that Trent pays attention to has expanded. He’s progressed from image comps to frontend to performance to accessibility to design systems to the command line and now to third parties. But Trent has no impact on those third-party scripts. That’s very different to all those other areas.
Trent mostly builds prototypes. Those then get handed over for integration. Sometimes that means hooking it up to a CMS. Sometimes it means adding in analytics and ads. It gets really complex when you throw in third-party comments, payment systems, and A/B testing tools. Oftentimes, those third-party scripts can outweigh all the gains made beforehand. It happens with no discussion. And yet we spent half a meeting discussing a border radius value.
Delivering a performant, accessible, responsive, scalable website isn’t enough: I also need to consider the impact of third-party scripts.
Trent has spent the last few months learning about third parties so he can be better equiped to discuss them.
UX, performance and privacy impact
We feel the UX impact every day we browse the web (if we turn off our content blockers). The Food Network site has an intersitial asking you to disable your ad blocker. They promise they won’t spawn any pop-up windows. Trent turned his ad blocker off—the page was now 15 megabytes in size. And to top it off …he got a pop up.
Privacy can harder to perceive. We brush aside cookie notifications. What if the wording was “accept trackers” instead of “accept cookies”?
Remarketing is that experience when you’re browsing for a spatula and then every website you visit serves you ads for spatula. That might seem harmless but allowing access to our browsing history has serious privacy implications.
Web builders are on the front lines. It’s up to us to advocate for data protection and privacy like we do for web standards. Don’t wait to be told.
Categories of third parties
Ghostery categories third-party providers: advertising, comments, customer interaction, essential, site analytics, social media. You can dive into each layer and see the specific third-party services on the page you’re viewing.
Analyse and itemise third-party scripts
We have “view source” for learning web development. For third parties, you need some tool to export the data. HAR files (HTTP ARchive) are JSON files that you can create from most browsers’ network request panel in dev tools. But what do you do with a
.har file? The site har.tech has plenty of resources for you. That’s where Trent found the Mac app, Charles. It can open
.har files. Best of all, you can export to CSV so you can share spreadsheets of the data.
You can visualise third-party requests with Simon Hearne’s excellent Request Map. It’s quite impactful for delivering a visceral reaction in a meeting—so much more effective than just saying “hey, we have a lot of third parties.” Request Map can also export to CSV.
Know industry averages
Trent wanted to know what was “normal.” He decided to analyse HAR files for Alexa’s top 50 US websites. The result was a massive spreadsheet of third-party providers. There were 213 third-party domains (which is not even the same as the number of requests). There was an average of 22 unique third-party domains per site. The usual suspects were everywhere—Google, Amazon, Facebook, Adobe—but there were many others. You can find an alphabetical index on better.fyi/trackers. Often the lesser-known domains turn out to be owned by the bigger domains.
News sites and shopping sites have the most third-party scripts, unsurprisingly.
Trent realised he needed to listen and understand why third-party scripts are being included. He found out what tag managers do. They’re funnels that allow you to cram even more third-party scripts onto your website. Trent worried that this was a Pandora’s box. The tag manager interface is easy to access and use. But he was told that it’s more like a way of organising your third-party scripts under one dashboard. But still, if you get too focused on the dashboard, you could lose focus of the impact on load times. So don’t blame the tool: it’s all about how it’s used.
Establish a centre of excellence. Put standards in place—in a cross-discipline way—to define how third-party scripts are evaluated. For example:
- Determine the value to the business.
- Avoid redundant scripts and services.
- Fit within the established performance budget.
Document those decisions, maybe even in your design system.
Also, include third-party scripts within your prototypes to get a more accurate feel for the performance implications.
On a live site, you can regularly audit third-party scripts on a regular basis. Check to see if any are redundant or if they’re exceeding the performance budget. You can monitor performance with tools like Calibre and Speed Curve to cover the time in between audits.
Make your case
Do competitive analysis. Look at other sites in your sector. It’s a compelling way to make a case for change. WPO Stats is very handy for anecdata.
You can gather comparative data with Web Page Test: you can run a full test, and you can run a test with certain third parties blocked. Use the results to kick off a discussion about the impact of those third parties.
Talk it out
Work to maintain an ongoing discussion with the entire team. As Tim Kadlec says:
Everything should have a value, because everything has a cost.
Thursday, April 27th, 2017
This is a great free service for doing a bit of performance monitoring on your site. It uses WebPageTest and you do all the set up via a Github repo that then displays the results using Github Pages.
Sunday, March 26th, 2017
A lot has been written about the future of journalism, the importance of businesses like the LA Times being profitable as a way to protect American democracy. I agree with that in theory. But this sort of incompetence and contempt for readers makes me completely uninterested in helping their business.
Like Craig says…
between personal data suction and total disrespect of bandwidth, I'm not sure how you can *not* run ad blockers and browse the web— A Walkin' Dude (@craigmod) March 26, 2017
Monday, July 27th, 2015
On The Verge
Quite a few people have been linking to an article on The Verge with the inflammatory title The Mobile web sucks. In it, Nilay Patel heaps blame upon mobile browsers, Safari in particular:
But man, the web browsers on phones are terrible. They are an abomination of bad user experience, poor performance, and overall disdain for the open web that kicked off the modern tech revolution.
Les Orchard says what we’re all thinking in his detailed response The Verge’s web sucks:
Calling out browser makers for the performance of sites like his? That’s a bit much.
Nilay does acknowledge that the Verge could do better:
Now, I happen to work at a media company, and I happen to run a website that can be bloated and slow. Some of this is our fault: The Verge is ultra-complicated, we have huge images, and we serve ads from our own direct sales and a variety of programmatic networks.
But still, it sounds like the buck is being passed along. The performance issues are being treated as Somebody Else’s Problem …ad networks, trackers, etc.
The developers at Vox Media take a different, and in my opinion, more correct view. They’re declaring performance bankruptcy:
I mean, let’s cut to the chase here… our sites are friggin’ slow, okay!
But I worry about how they can possibly reconcile their desire for a faster website with a culture that accepts enormously bloated ads and trackers as the inevitable price of doing business on the web:
You realize that “bloat" pays the salaries of editorial, product, design, video, etc etc etc, right?— nilay patel (@reckless) July 20, 2015
I’m hearing an awful lot of false dichotomies here: either you can have a performant website or you have a business model based on advertising. Here’s another false dichotomy:
To be clear: I’d pick a slow open web loaded with trackers and ads over a walled garden 100 percent of the time.— nilay patel (@reckless) July 21, 2015
If the message coming down from above is that performance concerns and business concerns are fundamentally at odds, then I just don’t know how the developers are ever going to create a culture of performance (which is a real shame, because they sound like a great bunch). It’s a particularly bizarre false dichotomy to be foisting when you consider that all the evidence points to performance as being a key differentiator when it comes to making moolah.
It’s funny, but I take almost the opposite view that Nilay puts forth in his original article. Instead of thinking “Oh, why won’t these awful browsers improve to be better at delivering our websites?”, I tend to think “Oh, why won’t these awful websites improve to be better at taking advantage of our browsers?” After all, it doesn’t seem like that long ago that web browsers on mobile really were awful; incapable of rendering the “real” web, instead only able to deal with WAP.
As Maciej says in his magnificent presentation Web Design: The First 100 Years:
As soon as a system shows signs of performance, developers will add enough abstraction to make it borderline unusable. Software forever remains at the limits of what people will put up with. Developers and designers together create overweight systems in hopes that the hardware will catch up in time and cover their mistakes.
If anything, browser makers might have to take more drastic steps to route around the damage of bloated websites with invasive tracking.
- swapping out images when the user moused over a link,
- doing really bad client-side form validation, and
- spawning pop-up windows.
Tracking and advertising scripts are today’s equivalent of pop-up windows. There are already plenty of tools out there to route around their damage: Ghostery, Adblock Plus, etc., along with tools like Instapaper, Readability, and Pocket.
That option is basically stealing. Don’t feel good about that.— nilay patel (@reckless) July 21, 2015
I’m sure that business owners felt the same way about pop-up ads back in the late ’90s. Just the price of doing business. Shrug shoulders. Just the way things are. Nothing we can do to change that.
For such a young, supposedly-innovative industry, I’m often amazed at what people choose to treat as immovable, unchangeable, carved-in-stone issues. Bloated, invasive ad tracking isn’t a law of nature. It’s a choice. We can choose to change.
Every bloated advertising and tracking script on a website was added by a person. What if that person refused? I guess that person would be fired and another person would be told to add the script. What if that person refused? What if we had a web developer picket line that we collectively refused to cross?
That’s an unrealistic, drastic suggestion. But the way that the web is being destroyed by our collective culpability calls for drastic measures.
By the way, the pop-up ad was first created by Ethan Zuckerman. He has since apologised. What will you be apologising for in decades to come?
Tuesday, May 27th, 2014
Documenting depictions of dystopian futures and tracking which ideas are turning out to be predictions.
Monday, April 12th, 2010
Purely for my own benefit because I keep needing this URL, here are the current outstanding issues registered at the W3C for HTML5.
Wednesday, February 13th, 2008
Garrett's bug tracking software is one step closer to completion.