Reader TTS

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. > The @chicagotribune literally has too many web trackers to fit on a

> 27” iMac screen pic.twitter.com/33TMw7FqPK >  > — 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. JOSEPH LICHTERMAN: You’re trying to reduce the load time on Slate.com by 75

percent. How are you going about that? DAN CHECK: It’s an ongoing process, and we’re working incrementally. First, we connected our development environment to page speed measurement tools,

so we could immediately see the impact of anything that we do. We found that it wasn’t so much the third-party beacons [slowing us down] as things we’d done ourselves. We are our own worst

enemy in terms of font size, image size, Javascript, other pieces like that. It all adds up to a fairly slow user experience. There are ads on top of that, but a lot of stuff at the core is

slowing our site down. 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. LICHTERMAN: What have you

done to reduce the load? CHECK: One of the first and simplest things we did was around font loading and font caching. We found a better way to do that, which resulted in substantial

improvement, especially for repeat visitors. To be kind of technical for a moment, the big thing we see with our pages is that we’re not actually bandwidth limited. We wind up maxing out CPU

on page loads. That’s a sign that we’re manipulating the page, or we have Javascript running aggressively enough that it makes scrolling through the page fairly slow. We’re looking for ways

to be less reliant on Javascript over time. We can be simpler with our HTML, simpler with our CSS, and lighter with respect to some of our images. LICHTERMAN: It seems that beacons and

third-party trackers are the main elements slowing down a lot of sites, so it’s interesting to hear that that’s not really the problem for you. CHECK: A couple of years ago, we required that

all third-party scripts be loaded asynchronously, which meant they were no longer in a position to block page loads. So if a beacon provider was misfiring for some period of time, [a

visitor] wouldn’t end up in a position where their browser was waiting 10 seconds for the request to time out before loading. LICHTERMAN: A lot of people are using ad blockers, and there’s

more concern about that with the rollout of iOS 9. Is Slate worried about ad blockers? CHECK: It’s a concern, but it’s not our most pressing concern right now. It’s something that we are

watching and experimenting with. 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. LICHTERMAN: Are you looking at ways to do advertising that don’t slow things down? CHECK: That’s definitely a big part of it.

Speeding up the site is about making the whole user experience better, and we would hate it if somebody turned on an ad blocker because they found the performance of the site to be

unacceptable with it off. That’s something we have to guard against. 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. LICHTERMAN: You’ve already made your site 25 percent faster. How do you get the rest of the way? CHECK: That’s where we start to look at some of the third-party providers

that are part of the core site experience. We need to look more closely at the full feature set we’re providing on site and figure out which aspects of that are most important. 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. LICHTERMAN: What’s the goal? Is there a time you’re hoping to get to? CHECK: We’re looking to be

among the fastest in our competitive set. For us, that means getting down to a four-second load time. LICHTERMAN: It’s early days, but have you seen any differences in user behavior as a

result of the changes you’ve made? CHECK: We’ve asked around, and from what we’ve heard, the benefits associated with going from ‘pretty slow’ to ‘not quite as slow’ are minimal to

non-existent. It’s going from ‘not quite as slow’ to ‘very fast’ where you see the gains. We believe there’s a hockey-stick moment where user engagement and satisfaction really rise as

page-load times become more instantaneous. You can’t go from 16 seconds to 12 seconds and expect to see any real change. The change happens when you get from eight seconds to four seconds.

LICHTERMAN: Were you at a 16-second load time before you began this process? CHECK: Yes, depending on how you measured it. That went beyond visible changes that the users would see; it was

the point where all the scripts had finished running and everything was ready and done. 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. LICHTERMAN: As people consume more

mobile content, load time is even more important, and platforms like Facebook’s Instant Articles and Apple News have promised to improve it. CHECK: We’re committed to Apple News, Instant

Articles, and other syndication opportunities, but we also really want people coming to our website, and if reading Slate on Slate is the slowest way to read Slate, [they’re not going to

come to our site]. It’s been good for us because we’ve been forced to focus on performance and our users first. Six months from now, we’ll all be much happier for it. 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. LICHTERMAN: Is there anything else you’re working on to improve the speed of the site? CHECK: We’re testing out infinite scroll right now.

We’re looking at single-page application frameworks to see if we can make reading multiple articles on Slate fun, fast, and friction-free. Photo by Nathan E. used under a Creative Commons

license.