iOS 9 and content blockers
José M. Pérez / September 21, 2015
5 min read • ––– views
Everyone is talking about ad-blockers these days after the release of iOS 9. But we should talk more about the "content blockers" feature in general, which can, by default, block scripts, fonts or images. What you can do as a web developer is what you should have been doing until now: don't take anything for granted and follow a progressive enhancement approach.
I have read lots of articles about why it is a good or bad idea to use these blockers, and I can understand both sides of the discussion. I get that it can make things difficult for businesses that rely on advertising and tracking scripts to finance themselves, and I also understand that as a user I want to see web content quickly. If that comes with savings in bandwidth, double win.
If I were to choose a post with which I agree, I would pick Content Blocking Primer. It doesn't say that this is the end of the world, and encourages web developers to do what they should have been doing all this time.
There have been browser extensions to block certain content for a long time. But it's now when it gets built-in and easily accessible for everyone, not necessarily tech-savvy ones.
Our content (at least the most important bit) should ideally be rendered server side. This improves load time and makes all bots index our content.
Truth is that there are other bots out there that might not be that smart. Say someone shares a link to your site on Twitter. A Twitter bot goes and makes a request to that page and tries to use its metadata to show a nice Twitter Card. Facebook? Same story.
<div class="image" data-img="http://example.com/image.jpg"></div>
and use Javascriot to either replace the
<div/> with an
<img/> or set its
Now have a look at this snippet:
<div class="image" data-img="http://example.com/image.jpg"></div> <noscript><img src="http://example.com/image.jpg"></noscript>
It adds a
"But then you are downloading all the images" you say.
And you are right, but maybe that is better than not loading any image at all.
Tracking is something to think of too. A script like Google Analytics' wouldn't run, and the visit wouldn't be reported. This is a problem if you rely on these data, in which case you will need to make the request server-side using something like Analytics Measurement Protocol.
Are you really worried about custom fonts? You should already be providing a font stack with default system fonts that are used when the custom one fails to load (or after a certain timeout). In addition, you should be thinking of avoiding the "FOIT" (Flash of Invisible Text) if you want the user to be able to see the text quicker. I highly recommend you check Font Loading Revisited with Font Events, and make a couple of tests using WebPageTest to see the impact of custom fonts in your site.
"But I use custom fonts to show icons!" you shout.
Inline SVG vs Icon Fonts is a great post that compares SVG with icon fonts. tl;dr? you can use SVGs instead of Web Fonts.
Sometimes I believe we, as web developers, should do more in order to avoid third-party scripts from landing on the sites we build. The web has become a container where it is far too easy to drop things to, and it looks like one more script doesn't damage that much.
At the same time I wonder what the situation is in the native apps world. Everything seems so fast when you install an app. Make a quick test accessing your favourite newspaper from your phone, both on the web and through their app. If it's not The Guardian, which have done a great job with their website, chances are that the web is much slower than their app. And then everyone nods when the read about Facebook's Instant Articles and blames the web for its slowness.
The web is deliberately slower not because the technology behind it, but because of the bloated set of non-sense third-party stuff we have been putting into.
I am really looking forward to seeing where this takes us.