About two months ago, Slate began an ambitious project: It wanted to reduce the load time of its website by 75 percent by the end of the year.
On average, it took about 16 seconds for Slate’s entire site to load (though much of that occurred after the page was already visible to users). Slate wanted to reduce the time to about four seconds, Dan Check, vice chairman of the Slate Group, told me.
As more people consume news on their phones, load time is increasingly important. If a page takes too long to load, users may move on to another site or just go open up Instagram. Apple’s introduction of ad blockers in iOS 9 means that publishers are even more concerned about intrusive ads and web trackers bogging down their sites.Page load time was at the heart of Facebook’s pitch for its Instant Articles (though, of course, there’s also a strong business imperative for the social network to get users to spend more time inside its app). Earlier this month, Recode reported that Twitter and Google are working together to develop their own open-source competitor to Instant Articles.
So far, Slate has reduced its page load time by about 25 percent, and Check said he’s confident the magazine will be able to meet its goal by the end of 2015.
— Joshua Benton (@jbenton) September 8, 2015
Slate doesn’t use as many trackers as some other sites do: Its homepage has 20 to 30 trackers, according to Ghostery, a plugin that counts them — and Check told me Slate is mostly looking for reductions in other areas, such as the third-party services it uses to run things like its paywall or commenting system.
Check and I discussed the steps Slate is taking to reduce page load times. I also asked him about Slate’s thinking when it comes to ad blockers and distributed platforms like Apple News. A condensed and lightly edited version of our conversation follows.
So for us, it isn’t as simple as removing a set of beacons. We have to evaluate third-party scripts that provide functionality, think about the features on the site, and approach everything from a performance-first mindset. We have a speed where we want the site to be, then we figure out what we can provide within that speed.
We have a membership program and we’re figuring out ways to surface prompts to that program. We’re figuring out if there are other ways we can derive value from that set of readers. Ultimately, we would like it if people would turn off their ad blockers, but until there’s a larger solution in place, we want to look for meaningful opportunities for those users to contribute to keeping the magazine going.
This also pushes us more toward native apps [which Slate has had for awhile now], because ad blockers don’t exist inside native apps yet.
We use third-party tools for login, commenting, and our paywall. All of those apps are loaded inside of the page. To increase speed, we might conditionally load those things, or we might find other providers. When we consider a third-party vendor, the first thing we do is look at their scripts and measure their impact on page load, as opposed to doing that after we evaluate other features. If the script slows down our page significantly, we’re just not going to go there.
We’re taking a somewhat pessimistic view of page load in part because it was the fashion, a few years ago, to figure out the marker that people were measuring toward and then push a whole bunch of things to the other side of the marker. Numbers-wise, it looked better, but it didn’t really lead to a better user experience: The page was loaded, but if you tried to scroll, everything jammed up. We’re trying to avoid that kind of situation.
If we see an opportunity to reach a new audience or reach our existing audience in a way that’s faster, we’ll take that opportunity, especially in cases where we can share in the revenue associated with it. That’s been something of a sea change for us.