Slate is taking steps to reduce its page load time by 75 percent

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

— 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 by 75 percent. How are you going about that?

Dan Check: It’s an ongoing process, and we’re working incrementally. First, we got connected our development environment connected 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.

Via: News

Speak Your Mind


Powered by WP Robot