Few people can say they’ve made as much of an impact on web performance as Steve Souders. He’s the author of High Performance Web Sites and a corollary Even Faster Web Sites with great tips for frontend web developers.
His work history includes major Internet companies like Yahoo! and Google, along with open source projects that have forever changed the way we build websites(YSlow comes to mind). From this work grew a Performance/DevOps conference named Velocity which Steve co-chairs & supports in various cities the world.
I was lucky enough to get a very educational & didactic interview to publish here for WDL readers. In this Q&A Steve covers his early beginnings in the tech field and how he’s risen to where he is today.
You’ll find many handy resources, a couple brief anecdotes, and some great tips from one of the web’s most knowledgeable talent on topics of website performance and scalability. Enjoy!
Q: Can you share a little about your youth and what got you interested in technology?
There wasn’t anything in my youth that particularly pushed me towards technology. My personality has always been, you know, thinking in a very logical organized fashion.
Computers were just coming out by the time I reached college so there wasn’t really any access to them. I went to the University of Virginia and halfway through college they started the CS department. They had a CDC Cyber mainframe that you programmed with cards and paper tape. I started using that and I liked it because it was a way of thinking in a very logical, organized fashion.
I like the idea of being able to think in that way and codify your thoughts in programming. The work is done in a very scalable way where you’d write a program that could run hundreds of thousands of times, but you only had to write the code once.
So I got into computers when I was in college, and I really enjoyed them because that’s the way my brain works.
Q: What is your current area of expertise and what type of work are you doing nowadays? When people ask “what do you do” how do you answer without getting too technical?
Up until early 2002 I had been mostly a programmer and technical manager. Then in 2002-2003 I was at Yahoo! running the My Yahoo! team, and I was asked to focus on performance. I thought this meant backend scalability because that was my area of expertise running My Yahoo!, which at the time was the #1 web portal. But it turned out the Chief Product Officer who asked me to do this was talking about the user experience of performance – and I had never thought about that before.
Frontend engineering didn’t exist back then. There was some JavaScript & CSS but it was pretty new. We were mostly C programmers doing JS and CSS work. So I started changing my perspective. Rather than looking at it from the backend perspective, I started looking at websites from the user’s perspective. And that’s when I noticed the performance golden rule: 80-90% of the time the user waits for a page to load is on the frontend, so that’s where we need to focus.
Up until that time I had been focused on how quickly Apache could retrieve the My Yahoo! HTML page from the server. And it was like 27 milliseconds or something like that, it was fantastically fast. But when I looked at it from the end user’s perspective and saw it took 10 seconds to load the page I was gobsmacked. It was surprising and revealing to me, and that’s when I started looking at how browsers work & how the web works.
Since 2003 and for the last 12 years I’ve focused on web performance. I work to make that experience as fast as possible. And it’s really easy to explain to people, even non-technical people because everyone uses the web these days. And they’re frustrated when it’s really slow.
It’s even easier to explain that now because it’s more prevalent since more and more people are now accessing the web from mobile devices. I tell people I make website’s faster. Right away we have a connection, and they start telling me how frustrated they are & the websites they use that are really slow. So yeah, it’s really easy to explain.
Q: What was your goal when first writing “High Performance Web Sites” and do you feel the book has achieved this goal?
In the first 3 or 4 years of my web performance work at Yahoo!, I was able to discover many interesting techniques that could make websites a lot faster. Turns out many of these techniques were pretty straightforward and not that hard to implement.
I started sharing these techniques across the company, and of course Yahoo! has a bunch of different properties like Sports and News, YMail, etc. And we had those in countries all around the world. There were hundreds and hundreds of properties with hundreds of teams of web developers. And every one of those teams could benefit from these best practices.
So I started documenting them to make sharing easier. There was no way I was gonna be able to sit down and talk to hundreds of development teams – so this worked really well.
The techniques were straightforward and easy to explain. People just hadn’t thought about it from the end users’ perspective before.
From that we realized this would be really beneficial to share with the web development community at large, to make the web overall a lot faster and more enjoyable. The goal was to share these fairly straightforward techniques that most people weren’t aware of; and I do think I’ve achieved this goal. The book has sold very well, it’s been published in 8 different languages and most of the techniques are still applicable today.
Q: What provoked you to write your 2nd book “Even Faster Web Sites” and was it meant to be a follow-up to “High Performance Web Sites”? How would you compare the two?
Even Faster Web Sites covers another set of web performance best practices.
Comparing the two books, I think readers should definitely start with High Performance Web Sites. It lays the foundation for how websites work: HTTP, DNS, Round Trips, thinking about requests like how many requests are in a page.
Even Faster Web Sites came out of the next round of best practices that we learned from working on web 2.0 websites. That sounds so out of date today. Back then we called it DHTML, which sounds even cornier!
As we built these more complex websites, we found that they often got slower. That’s when I started focusing on these insights about how JavaScript could be loaded asynchronously, how complex CSS could affect page performance. Plus Ajax was just becoming really popular back then around 2008-2009.
I just wanted to share these other best practices covering newer development techniques that were just coming out.
Q: Can you share a little about your time working at Google? How did you land that gig and was it a tough transition to get settled into that role?
Yeah I was really lucky!
I was at Yahoo! for 8 years and Google for 6 years, both of them fantastic companies.
While I was at Yahoo! open source really took off. I was really excited to work on open source projects, write books, speak at conferences and really share with the broader development community. When I first got to Yahoo! In 2000 there wasn’t very much of that. But with the Yahoo! Developer Network and YUI, open source became very popular across the industry. The idea of companies sharing their technology became more accepted.
I really benefited from Yahoo! being early adopters and being willing to share technical advances that had been developed internally, to share those externally.
And of course same thing at Google. So the transition was very smooth because at Yahoo! I was still researching new web performance techniques to benefit the teams internally. But unless those had some very specific competitive advantage, 90% of that work was just general information that was perfectly acceptable to share publicly.
I was spending time doing web performance research, developing techniques, doing some patents for internal competitive advantage – but mostly sharing things by open sourcing code, speaking & writing.
And that’s exactly what I did at Google: work on specific projects that were meant to make certain Google properties like Docs or GMail faster.
As I found new performance best practices, Google was very motivated to share those to make the web faster and help all websites become faster. So I was essentially doing the same thing: research, speaking publicly, open sourcing code, and writing.
My 1st book was published while I was at Yahoo!, my 2nd was published while I was at Google. So yeah that transition was very smooth.
Google wasn’t young when I switched, but it was much smaller when I switched in 2008. And they had this culture of performance and optimization, really working to make things fast. So everyone there was very open about doing more work in that area and sharing it across the company and externally.
Both were great jobs to have, I was really lucky. I think they both produced a lot of valuable knowledge about how to do high performance web development.
Q: Do you think web performance work is growing fast enough to warrant full-time positions at most tech companies? Or would a performance expert be better off working as a contractor?
I think most tech companies do have fulltime dedicated web performance staff. Probably not small companies, but any company with over 100-150 developers probably has someone working full-time on performance.
If I was an individual and I really liked web performance, I would try to get into one of those companies and do that focus. To me we’re still learning a lot about web performance. There’s a lot of work that hasn’t been done yet – some stuff we still don’t even know about! And working at a big company allows you to do that kind of research. To explore areas that haven’t been opened up to see which new performance techniques we should be evangelizing.
I think it’s a little harder as an independent consultant to make time to do research that isn’t dedicated to a specific contract. Also most clients hiring a consultant don’t want to pay for research that may not benefit their website. So I think working at a company that has the resources to let you do research and find new areas of learning is a great way to go.
I’ll also say that every week I get asked several times to recommend web performance consultants. I know a lot of people that go back and forth, working somewhere a few years then going back to consulting.
In truth, both paths can work well.
Q: Is there any particular project or job that’s given you the greatest amount satisfaction?
I think the project I’m most proud of is YSlow.
My early career back in the 80’s was doing Artificial Intelligence. So we were building expert systems and I spent years interviewing domain experts, codifying their knowledge in rule-based systems, and other ways of capturing intelligence in computer systems.
And while I wouldn’t say that the logical programming I’ve done in the last 10 years is A.I., certainly there’s a lot of this codifying of knowledge. And that’s what YSlow was.
There was no way for me to personally analyze the thousands of websites that people were asking me to help them with. But I knew the 14 rules inside-and-out. I knew that most of them could be executed through code. So I captured that logic in YSlow and first released it internally at Yahoo!.
It was really successful. People were able to analyze their websites and figure out the most important things to fix. Then Yahoo! agreed to open source it. I was lucky enough to connect with Joe Hewitt who wrote Firebug, which was the first real frontend development tool out there. He agreed that YSlow was cool and he helped me integrate it with Firebug and it became really popular.
I think there’s still a lot of interest in the idea of helping people turn data into actions. Although I think that’s a bigger conversation we could have. In many ways, we’re right at that cusp again today where we’re getting better and better tools for capturing metrics and monitoring our systems, especially in terms of performance. But what’s lacking is a conversion of that data into actions. Diagnosing problems and recommending actions to fix them.
I think YSlow, and also Google’s product PageSpeed, have atrophied from a lack of attention these past few years. I think we’re gonna see a resurgence in those kinds of tools over the next two years.
Q: What are your thoughts on full-stack JavaScript frameworks like Node.js? Do you think these offer serious competition to backend languages such as PHP, Python, etc.?
Oh yeah. I think JavaScript is still the #1 programming language for the web.
Before Node it only ran on the browser side. So everyone had to write their backend using some other language – PHP, Java, C – then write their frontend code in JavaScript.
When we moved into Web 2.0 we wanted to do a lot of those backend actions like using Ajax to generate refreshed HTML for a mailbox. We wanted to do that on the frontend, so we swung that pendulum from having all the HTML generated on the backend, to having all the HTML generated on the fronted. But we found out that was way too slow, you had to download a MB of JavaScript before you could see the inbox.
Then we realized the right answer was a compromise of delivering HTML stitched together on the backend when people first land on a website, and then lazy-loading JavaScript to generate HTML (DOM) after that initial HTML delivery.
So you could have a single-page webapp using Ajax to keep the user in a single-page context. And that was a great solution. Gmail, Google Docs, tons of websites got much faster by adopting this hybrid approach.
The problem was that it got difficult for developers because now they had to write code on the backend to create HTML, and then duplicate that code on the frontend in JavaScript.
Node.js has been so successful because it’s solved that problem. It lets us build the app logic on the backend in the same language used on the frontend.
So yeah I think Node is the preferred platform for people building web-heavy user experiences where you’re gonna have a lot of JavaScript involved. It’s a no-brainer to use Node.js to keep one language on both the frontend & backend.
Q: When a developer starts coding a new project, what should be kept in mind to ensure the fastest load times for all pages?
That’s hard to answer because there’s so much to keep in mind.
I guess there are some high-level things like “make sure to have performance metrics from the very beginning”.
Also don’t optimize too early. If you’re prototyping and it’s loading slowly, at least be aware that it’s loading slowly. Maybe even look into which areas are causing the slower load time – but you don’t have to optimize yet. Maybe you’ll end up using a completely different JS framework or slim down the CSS.
Definitely track performance metrics from the beginning, and also make sure that everyone on the team – marketing, design, content, sales – is aware of the importance of performance. They should have access to these performance dashboards to check metrics. So these are some process things to keep in mind.
When it comes to actual development advice the #1 thing is the user experience. That matters most and it’s all about rendering. When is the user able to see & interact with the content you’re delivering?
When it comes to rendering it’s all about JavaScript & CSS. Your external scripts and stylesheets play a big role. Fonts can have an impact too, but most rendering problems stem from external JS & CSS files. That’s the #1 thing to pay attention to in terms of performance, those external render-blocking resources.
Q: What are some of your favorite tools for checking load times & locating problems in a website’s performance?
The #1 performance tool in the world is WebPageTest; I use it multiple times every day. My new company, SpeedCurve, is built on top of WebPageTest. It’s fantastic, and it’s free. There are some things missing like ACLs and trending results over time. Those features aren’t in WebPageTest so that’s why Mark Zeman and I are doing SpeedCurve.
Many times I’ll use WebPageTest, but most of the time I’m in SpeedCurve working on our website and our customers’ websites to track performance problems.
WebPageTest lets me see a lot of the rendering performance. But when it comes to debugging what’s causing performance problems I use Chrome Dev Tools. It’s fantastic and they’re always releasing new features, so I really like Chrome Dev Tools.
And when I’m on the web, especially mobile, I’m using bookmarklets all the time because you don’t always have the ability to drop into those developer tools. I grouped some of my favorites into the Mobile Performance uber-bookmarklet. A newer favorite is Performance-Bookmarklet. I’ve got two new ones I’m working on now.
Q: Are there any modern web development techniques that you feel are still surprisingly archaic or just inefficient?
When High Performance Web Sites came out in 2007 it was based on the first 14 best practices I found about web performance. I think it’s surprising that many of those are still the #1 things that people have to work on today. It would seem like if they’ve been around for 8 years we would’ve tackled them. But you still find a lot of requests without caching headers, or sites that aren’t gzipping their responses.
I think that’s surprising and certainly inefficient. But it just tells us we have to be constantly vigilant and evangelize these best practices with our customers and our fellow developers.
I think the biggest archaic problem with the web today is ads. There might be some people who would debate that, and to them I’d say document.write. The fact that the entire ad system infrastructure relies on document.write shows how inefficient and insecure it is.
Because of ads we have blocking scripts on almost every popular website that exists today. And until we fix that, the web ecosystem is broken. Users and website owners are subjected to poorer performance they don’t want, but they’re forced to endure it simply because ad networks haven’t adopted basic performance best practices.
It’s really rather ironic because there are studies that show if you make ads faster, they’re actually more successful. You make more money & you get more clickthroughs. So the ad networks are not only producing bad user experiences by forcing them on people who don’t want them – but they’re also hurting their own business metrics.
Until website owners, developers, and users really get up in arms, the ad networks aren’t gonna change. I do hope we’ll eventually see them change, but I’ve been talking about this for 10 years and there’s been almost no progress.
I think that’s the #1 most archaic, inefficient problem when it comes to performance on the web.
Q: There’s no denying that conferences have taken over the web design/development industry. What do you look for in a conference and what factors contribute to the best experience for attendees?
When it comes to conferences there’s no single best model.
I co-chair Velocity. It’s the world’s #1 web performance conference. It’s fantastic, I really enjoy it. It’s a pretty big conference. Here in Santa Clara we get almost 3,000 people. In NYC, Europe, and China it’s smaller – maybe 700-1,500 people at each event.
The benefit of a big conference is that most of the big leaders in the space are there. So you can be assured if you go to that conference, you’ll be able to listen to & talk with most of the leaders in that space.
On the other hand, there are smaller conferences that I really enjoy as well that are single track – maybe 300 people. They’re more intimate. You get to have more conversations, learn more from the attendees. But because they’re smaller you’re also gonna have only a fraction of the world’s gurus speaking & attending. So you won’t be able to see everyone, but the people who are there you’ll be able to meet and connect with closely.
I think the main thing about going to a conference is looking at the speakers. Do they know what they’re talking about? Are they good presenters? Will they give you good information that’s thought-provoking & actionable?
Those are the kinds of conferences that I like going to.
Q: What have been your major contributions to O’Reilly’s Velocity conference? How much impact has Velocity made on the field of website performance?
When YSlow and High Performance Web Sites proved to be so popular, I asked the folks at O’Reilly if we could talk about organizing a conference around that content. Someone at O’Reilly, maybe Tim or Brady Forrest, wisely saw that just focusing on web performance was only part of the conversation. There was also this group of people who back then were called “IT” or “sysadmins”; people running the infrastructure that all these websites ran on.
Both of those groups – people working on JavaScript performance & people working on Apache/MYSQL performance – were after the same thing: efficiency, optimization, scalability, faster experiences.
We had that kickoff meeting and we pulled in folks like Jesse Robbins and Artur Bergman from the operations side of the conversation. Out of that came the first conference in 2008 with two tracks: Performance and Operations. And out of bringing those two groups together we formed the term DevOps. Now that’s one of the leading themes around web development: bringing development and operations closer together.
I think that’s the most important thing that has come out of Velocity and it’s been hugely important to the world of web development.
Q: It seems you give a lot of talks at various conferences all around the world. How do you stay fresh covering interesting topics without running out of things to say?
I spend a lot of time on the web. I tell people you always have to give yourself time to explore. You might not understand why you want to explore/investigate something. You might not know ahead of time if anything valuable will come of it. But when you poke at things that you don’t understand, you learn. And you learn about how systems work. And that’s the full stack developer which is a big part of DevOps.
So for me, I spend a lot of time on the web and usually have Chrome Dev Tools open. So I notice stuff! And I’ll think “Why did that happen? Why was that slow, why did it break? Why did it load twice?” And I’ll spend hours off on a tangent exploring why this browser, or this web stack did this thing that was unexpected and obtrusive to a good experience.
Sometimes there’s no takeaway except “well I learned more about how TLS works. Didn’t know that before”. But a lot of times there are takeaways like “even dynamically-loaded stylesheets block rendering.”
So when I see things that are weird or interesting I stop and poke, and try not to worry about spending a few hours exploring. At a minimum I’ll get smarter and best case I’ll find a new technique we can use to make the web faster.
Q: The Internet is an ever-changing medium that seems to grow faster with each passing year. Do you have any personal opinions on the type of changes we might see 3-5 years in the future?
As I said before, I think we’re entering a phase where we’re gathering a lot of data. We have things like Hadoop and Redshift. But I think what’s lacking is that codification of knowledge to take that data and produce conclusions & actions from it. So I think we’re going to see a real focus on that in the next few years.
I think that we’re going to get systems that are much more interactive. Right now I primarily use a mouse, a trackpad, and a keyboard to interact with computers. We’re going to get a lot more wearable technology, and technology that we have easier ways of interacting with. Maybe vision tracking. Maybe more gesture-based interactions. Methods that are just healthier for human interaction.
I’ve got a lot of problems with my hands and fingers and wrists and shoulders from typing 8 hours a day. I think we’re gonna see a lot of progress there.
I also think we’ve had a lot of progress in this shift that I’ve been trying to lead in focusing on the user experience. I think we’ve made a lot of progress there. I think we’re gonna see even more emphasis and awareness on what the end user is experiencing; How to improve the user experience and how that can make businesses more successful.
Q: Can you name a couple people whom you greatly admire in the field of IT & web performance?
I’ve been chairing Velocity for 8 years, and every speaker that we’ve had is someone I admire and I think should be listened to. That’s why invited them to speak! So that’s hundreds and hundreds of people right there.
A lot of times people ask me who they should follow on Twitter or RSS to stay on top of web performance. The answer I give there is Stoyan Stefanov who I worked with at Yahoo! (he’s now at Facebook). He runs this website called perfplanet.com. It’s an open source list of performance-related blogs. People can add their own blogs and the community maintains who’s in it. There’s also a Twitter account: @perfplanet.
If you follow those you’ll be tracking the latest advances in web performance, and the people who are leading those advances. That’s my recommendation.
Q: Since we’re from Web Design Ledger, anything specific you could share to folks who design websites and user experiences?
Oh yeah. It’s my main area of focus right now.
I think we’re gonna see two big changes in this area of web design & user experience.
The first is design integrated with DevOps. I talked about how DevOps grew out of Velocity from bringing the performance and operations communities together. I think we’re gonna see design pulled more into that relationship as well.
Sometimes there’s almost a contentious relationship where designers create beautiful, content-rich designs that can be challenging for developers to implement in a high performance way. So I’d like to see those two groups closer together – sharing more skills with a common vocabulary and just working together on more tasks. Perhaps bringing designers and developers to the table at the beginning of projects, rather than bringing them on at different stages.
I think that’s one big change we’re going to see in the in the world of web design. And in fact it has already started marked by Lara Hogan’s book Designing for Performance which came out about 6 months ago. It talks about this overlap between design and development. And for the last year at Velocity we’ve had people like Katie Kovalcin, Lara Hogan, and Jason Grigsby talk about how design and performance are related.
The second big change we’re gonna see in this space involves better metrics around user experience and design.
It used to be that a request was sent to an HTML endpoint to track how quickly the first byte of that HTML document came back. And that was considered the website’s performance. Yet we know that HTML document triggers another 50 or 100 HTTP requests. And it’s not until most (or all) of those requests are completed that the user experience is actually delivered & ready. That was around 2005.
Around 2010, we shifted off that single request ping to the world of DOM where we got better metrics. So instead of just the first byte we started tracking window.onload. And 5 years ago that was a pretty good measurement for user experience.
Now we have web pages that are very complex, they have a lot more JavaScript and CSS than 5 years ago. There’s a lot more dynamic behavior, asynchronous loading, lazy loading, proactive loading. So it’s become very hard to have standard metrics built into browsers that we can use across all websites as a way of measuring the user experience – and yet we know it’s really this emphasis on the user’s experience that’s most important. It’s what the user experiences that’ll determine how much they’re gonna buy. Or how frequently they’ll come back.
So we need better metrics that approximate that user experience. And that’s what Pat Meenan of WebPageTest pioneered – the film strips, and Speed Index metrics.
So I think that’s gonna be the 2nd big thing that will evolve in the design space: what I like to call user experience metrics; metrics that help us track what the user experience is like, both single-page and multi-page websites.
We’re trying to include more designers at Veloctiy and trying to think about these new types of metrics that we can track that’ll give us a better idea of what users are experiencing when they visit our sites. I’m really excited to be helping out with that.
Steve made a lot of time for this interview and I’d like to personally thank him for all his efforts. There is so much great information here, and it pertains to such a wide audience that I’m very proud to be able to present this to WDL readers.
If you’d like to learn more about Steve you can visit his website or follow him on Twitter @souders. And if you have any interest in reading Steve’s books you can buy copies from Amazon or at most retail bookstores.
