There’s more to the new look of Slate than the logo, layout, colors, and new URL pattern. The new site sits on top of a new content management system that completely changes both the way editors and writers create stories and all the technology that puts that work on a webpage.
There are loads of fun new technologies behind the buildout. Where the previous site was built in Adobe’s Java-based CQ CMS (now called Adobe Experience Manager), the new site is written entirely in JavaScript. Where the previous CMS was using a Java content repository to store data and run searches, the new one uses Redis and Elasticsearch. Even better, we’ve built flexibility into our new system. The new CMS is backed by services that we can replace if our needs demand it. For example, if we decide that Redis isn’t satisfying our needs, we can switch to Postgres or any of the various open-source databases that are compatible with the abstraction layer we’re using.
Our project to move off of our existing CMS (which we’d been using since 2011) began more than a year ago. After looking at various options and doing some prototyping around a new writing interface, we eventually decided to try a CMS called Clay that New York magazine has been developing since 2015. We were wooed by Clay’s approach to component-based architecture and the fact that it was running on node.js rather than the Java or PHP alternatives we’d seen so many of. Our development team still does a lot of work in Python, but the burgeoning JavaScript ecosystem was a big draw. The rising popularity of node.js makes it easier to find talented developers to join our team, and its asynchronous engine makes it a naturally good fit for the request/response nature of the web.
Even better, Clay is fast. It composes an article consisting of hundreds of components in less than a second. The total transfer size of our home page is half of what it was on the old site. In fact, in our quest for improved site speed, we managed to cut almost everything on the site in half. From our “first paint” (the time at which your browser starts actually rendering the pixels that make up a page) to the total number of requests your browser makes to render an article.
We still have a way to go on speed. By bundling all of the CSS and JavaScript for our components into the initial response, we get a highly cacheable page. While this is valuable for only having to calculate the page once and knowing our users will get exactly what we expect every time, this choice also makes our initial page size big. We know we can get better by moving some of our commonly used JS and CSS into their own files. We’re also researching faster ways to serve images, like the new WebP format and the srcset HTML attribute, so that we never unnecessarily send images that are too large.
Rebuilding Slate.com with a new design and a new CMS in less than a year was a tremendous effort. I want to offer a huge thank you to the team at New York magazine for helping us get our footing when working with Clay. And I want to praise Slate’s ingenious and hard-working software engineers, designers, and product team, who put in lots of late hours and long meetings to get this far. We’re just getting started.
