Page speed is an underrated part of user experience. A fast website is a website readers will return to more often and feel better about using. (Add WPO to SEO and SMO in your mental acronym storage case.)

We’ve shared before about efforts at The Guardian and The New York Times to get faster, and now we’ve got a new slide deck from Times developer Eitan Koningsburg on the sometimes counterintuitive things they’ve done to speed up NYTimes.com (including the earlier [thanks, Allen] strange-sounding-to-me use of an intentional blocking script to load ads better):

The current mantra in performance thinking is “Tools not Rules.” The premise is simple: The path to faster websites is not only about fast requests, but how they interact with paints, animations, and script execution. But tools are only part of the solution. What The New York Times discovered is that performance is about truly understanding your product and users, and the sum total of your site. Following this approach can lead to surprising results.

The New York Times underwent a major redesign that involved a rewrite of the entire technology stack. The Product team not only bought into the idea that performance should be a goal, but mandated that it be part of the product’s success. While we implemented many of the community’s best practices, our biggest wins were a little surprising, and at first glance, counter to community best practices. Front-end software architect Eitan Koningsburg covers those changes, what worked, what didn’t, and how we got there.