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.

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.

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.

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.

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.

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.

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.

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.

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.

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.