Interview with Eitan Konigsburg — New York Times

 

Eitan Konisburg is a Frontend Software Architect for the New York Times and was recently involved in the responsive redevelopment project. Eitan was kind enough to answer a few questions and share his experience with us all.

You’ve been at the NYT for a few years now, can you tell us about your background before the NYT and how your role has changed over the years and what your main role is now?

Before The New York Times, I was studying Computer Science at Columbia University. I joined The Times as an entry-level employee in 2006 as a server-side application developer. After a couple of years of writing applications in a proprietary programming language, I discovered that configuring middleware and working on the backend wasn’t for me. So I made the jump over to client-side web development. Today, I’m a Frontend Software Architect where I focus on keeping nytimes.com functional, fast, and future-ready.

Were there any lessons that you learned from your server side application development that have helped you be a better fronted architect?

I was fortunate to get started on the server-side at a time when backend performance was a major focus and I learned a lot about architecting systems to be reliable and fast. So when Steve Souders comes along and demonstrates to us that the frontend has become the major performance bottleneck, that message really resonated with me. I also admired people who would encourage frontend developers to learn how the browser really worked in order to discover techniques to help speed up our sites. 

I’ve found that my familiarity with server-side systems helped me better understand the browser, which has become more of a platform every day. As browsers gain functionality that traditionally is provided by an Operating System, I think that server-side experience will start to become very handy when working client-side.

You’ve recently undergone a fundamental redesign at the New York Times. How long was that in the pipeline for?

This was a huge project for us, not just in terms of the UI changes that everyone can see, but also in the technology stack that powers it behind the scenes. As you may imagine, starting over with new systems and code for a site of our size isn’t an easy or short process. The intent of our work on the redesign was to build a solid foundation for projects going forward so this is just the beginning and an ongoing process. 

Was it always intended to be a full stack overhaul, UI/UX/Design as well as the backend technology? Or did one beget the other?

I think it became pretty clear early on that both would have to happen together. While the earliest interest in redesigning came first, we were granted the amazing opportunity to redo the technology stack soon after. We wanted to get to a place where we could make further iterations to the site in less time and we couldn’t do that with our old stack. 

You’ve gone big and content focussed on the site, while still allowing for comments, related stories, huge images and such… did you set yourselves a performance budget when undertaking the project? What are the things you’ve done to ensure it’s still performant across various devices?

While we had set a performance goal for the project, there wasn’t a specific budget for various features. The technology overhaul allowed us to make some big performance improvements by simply adhering to fundamental techniques such as combining files and deferring script execution. The goal was to get to the “page ready” event to fire as soon as possible and load everything else after that.

Our new technology stack allows us to tweak our pages as a whole and with less delay, so as the performance profile changes, we will be able to adjust accordingly. For various reasons, we weren’t able to do that before. We keep a close eye on our page performance and now that the barriers to making changes have been lowered and the big-ticket items are in place, we can focus on more targeted optimizations to make further improvements.

I hear a lot of people ask what the “Performance Budget” should be. 500kb, 900kb, 1Mb, 1.5…. what did your team decide on? Was there any reasoning behind this?

In our specific case, we weren’t really able to set an exact budge that we wanted to aim for. This technology overhaul was such a dramatic change from what came before that we weren’t really sure what kind of constraints to set. Instead, we took a relative goal of trying to be faster than our previous design by a certain percentage. While I’m happy with the performance profile of where we ended up, we now have a baseline against which we can set some goals. 

It sounds like you made a tonne of performance improvements. Could you share a few key updates you made that you would recommend? Either for large scale sites such as this or standard improvements for even a simple site?

The biggest improvement for us was figuring out a way to take our advertisements out of the page-load flow and load them asynchronously. (I recently wrote about our ad optimizations on our Open blog.) 

This allowed us to serve our primary content first followed by everything else. We’ve also implemented a lot of the features in JavaScript, so having an asynchronous script loader helps keep blocking to a minimum. We also found that reducing the number of resources that page had to download led to bigger performance gains than reducing the size of those resources.

Could you share how you worked, things that worked well and things that you might change if you could go back

The team used the Scrum methodology to manage the development of the project, and I think it was the first project of this magnitude at The New York Times to do so. 

I think it was really important for everyone to be on the same page with regard to overall status, and it was super helpful to have the sprints to help us figure out when to set our milestones. However, I think this may end up being a unique situation that might not get repeated as we’ve focused on allowing more iterative improvements instead of developing everything all at once. 

The project management and development teams did an excellent job and we hit all our internal milestones which led to a very smooth launch day. This project also included integrations by other departments and I think we did pretty well at coordinating and accommodating all interested parties.

If you could pick one aspect of the front end implementation that your most proud of, what would it be?

I’m incredibly thrilled that our “page manager” turned out to be extremely helpful. 

We needed an object that would handle page-level functionality (such as reading meta tags, query string and/or hash parameters, event handlers such as scroll or resize, etc) and one that also served as the hub through which all modules can communicate with each other. We wanted to avoid modules registering the same event handlers or accessing the DOM to get the same information. 

We also wanted to allow modules to stay loosely-coupled and emit events that other modules can listen for and react accordingly. For the first time, our JS modules could work together and be aware of each other instead of sitting in isolation. This is a really handy thing to have on our pages.

A huge thank you to New York Times and in particular Eitan for sharing his experiences with us.