iOS 9, El Capitan, Safari Content Blockers, and Shit-Ass Websites ⇥ murphyapps.co

Developer Dean Murphy spent an hour tossing together a quick content blocking extension for Safari on iOS 9, testing it against iMore:

With no content blocked, there are 38 3rd party scripts (scripts not hosted on the host domain) running when the homepage is opened, which takes a total of 11 seconds. Some of these scripts are hosted by companies I know, Google, Amazon, Twitter and lots from companies I don’t know. Most of which I assume are used to display adverts or track my activity, as the network activity was still active after a minute of leaving the page dormant. I decided to turn them all off all 3rd party scripts and see what would happen.

After turning off all 3rd party scripts, the homepage took 2 seconds to load, down from 11 seconds. Also, the network activity stopped as soon as the page loaded so it should be less strain on the battery.

That’s a big difference, which means only one thing: iMore is another one of those shit-ass websites. John Gruber in 2011:

One article at TheNextWeb weighed in at over 6 MB and required 342 HTTP requests. 73 different JavaScript scripts alone. Absurd. I did a reload on the same page a few minutes later and it was up to 368 HTTP requests but weighed “only” 1.99 MB.

So how are we doing now, four years later? That same article is now 11.0 MB requiring 236 HTTP requests. (I turned off all of my desktop Safari extensions before running these tests.)

For their part, iMore didn’t ignore Murphy’s article. Rene Ritchie:

To answer the obvious questions, yes. Everyone here and at our network, Mobile Nations, saw it. Everyone here and at our network were also well aware of it, and have been working for months already to improve it. That we haven’t made it further, faster is an indication of how hard it is when you’re talking about websites visited by tens of millions of people, and companies that employ more than a dozen writers. Of course, everyone here is going to continue working to find better, smarter ways of solving the problem, because that’s our jobs. I’m sure other large websites are doing likewise.

His “response” article — which, I should point out, is entirely text-based, unlike a media-heavy review — weighs in at a whopping 14 MB with 330 requests. That’s one shit-ass website, largely because it’s bogged down by unnecessary tools.

As someone who operates a website with an advertisement served by JavaScript, you may see me as a hypocrite: on the one hand, I’m looking forward to a faster web via content blockers; on the other, I directly profit by a lack of script blocking. But the Carbon ad on the right doesn’t seem to have noticeably degraded performance on this site, and it’s a tiny static image in the sidebar.¹

By contrast, a glance through the changelog of my blacklist clearly shows certain ad networks and utilities that are disrespectful to performance and, consequently, readers. With increasing amounts of web browsing being done on mobile devices — and with iOS devices occupying a significant chunk of the mobile web market share — the pressure is going to be on for the makers of inefficient scripts and utilities. With any luck, the web will be better for it.