Steve Souders, the creator of YSlow and the author of the book High Performance Web Sites, is one of the most respected experts on website performance in the world. We here at Pingdom are big fans of his work, and decided to probe his mind about the excellent YSlow Firefox add-on for evaluating website performance (which he created while working at Yahoo), his work at Google, and his thoughts around the ever-important issues of website performance and optimization.
Pingdom: You recently started working at Google. What are your main responsibilities there?
Steve Souders: Google, of course, is very focused on making its pages fast. But it goes beyond that. Google also wants to promote a faster Internet for everyone, for every site they visit. An example of this is the announcement earlier this year that Google’s Quality Score for Adwords incorporates landing page load time. A large part of my role is to evangelize web performance best practices across the industry, which supports Google’s goal of a faster Internet. On the evangelism front I’ve started writing another book, I’m teaching a class on web performance at Stanford this fall, I just co-chaired the Velocity conference on web performance and will do that again next year, and I’m involved in various Open Source projects like Cuzillion and most notably Firebug.
In addition to these evangelism efforts, I continue to do research to stay ahead of the curve with performance recommendations. And finally, I do performance consulting and evangelism within Google. Our sites are fast, but we’re always working to find ways to make them even faster.
Pingdom: You visit a lot of conferences. What is more fun to you, being a speaker at a conference or working at the office?
Steve: I’m lucky to have the perfect balance. I need to write code to stay in touch with how today’s technologies help or hinder building performant web apps. When I find an area that’s a performance bottleneck, I need time to research ways to solve that. And I need time to go to conferences to share what I know and learn from other developers, and coordinate efforts that span companies and organizations. Luckily, I get to do all of this. I spoke at a dozen or so conferences over the past year, and it’s a rush to have a big audience that asks a lot of questions. But I get a rush at 2am when I finally figure out why something’s slow and how to fix it. Probably the most fun for me is when people come up at conferences or send me email and describe how they’ve read my book and used YSlow, and it made their sites faster.
Pingdom: How did the idea for the YSlow Firefox add-on come about?
Steve: I started consulting with development teams to share these performance best practices. Before meeting with a team, I would spend a few hours looking at their HTML document source and loading pages in a packet sniffer to come up with performance suggestions. It was clear that I would never be able to scale to reach every development team, so I wanted to make that few hours of analysis that I was doing something that each team could do themselves. YSlow takes that manual performance analysis and codifies it in a self-serve tool.
When Joe Hewitt released Firebug, it took off like a rocket. All the web developers I was trying to evangelize to were using it, so it made sense to add YSlow to the tool they were already using. I contacted Joe Hewitt, he came over for a demo, and we agreed to add it as an extension to Firebug. I initially thought we’d get about 10,000 downloads. Last I checked it was over 350,000.
My initial goal of a self-serve performance analysis tool was achieved, but there were other benefits I hadn’t anticipated. I was suggesting that, by following YSlow’s recommendations, you could make your site faster. Later I did a study and found that there was a high correlation between a page’s load time and its YSlow score. It’s great to be able to look at your production pages and see what could be improved, but it’s even more valuable to look at the build currently under development and get an idea if it’ll be faster or slower. This can be a challenge because the dev build doesn’t have real traffic, and hammering it with simulated traffic can be difficult and might not reflect what will happen in the real world. YSlow lowers the barrier to gauging the expected performance from your next build, and it does it in the tool that your web developers are already using (Firebug). Some people even setup 24×7 YSlow monitoring of their recent builds so they can be alerted to performance problems before the build goes live.
Another benefit I didn’t foresee was the creation of a vocabulary that made it easy for people across the organization to communicate about web performance. I hear stories about companies where executives have installed YSlow and can track how the dev team is doing just by watching the YSlow score. All of a sudden VPs in sales and marketing are asking developers about gzip and Expires headers. They might not know what it means, but they know they want it fixed.
Pingdom: Are there any improvements you’d like to see in YSlow to make it even more useful?
Steve: Definitely.
- The scoring algorithm (A-F grades) doesn’t translate to people who grew up outside the U.S. school system. Also, it should be possible to customize the scores to reflect your team’s own priorities.
- There are more rules that need to be added, and a plug-in model that enables teams to easily add their own rules.
- It’d be great if someone would open source their code that runs YSlow in a headless 24×7 monitoring instance.
- I’d like to see YSlow as an API and web service, so it could be incorporated in other development tools beyond Firebug.
- I’d like a way for people to run YSlow on any web site and share the score in a public database. There are a lot of challenges to doing this: privacy, gaming the system, etc. But it would be great for web users to know how competitive sites compared with regard to performance, and it’d be really interesting to watch trends.
- Internationalization.
Pingdom: What tends to be the worst performance hog for websites? The YSlow site often mentions the number of HTTP requests as a major factor, but aside from that.
Steve: The average YSlow score across the top Alexa sites has moved from F to D. That’s not great, but I believe the performance best practices from my book are gradually taking hold. Looking ahead, JavaScript is going to be the main performance bottleneck going forward. Web 2.0 is taking off, and the amount of JavaScript in popular web sites is growing. Furthermore, JavaScript is parsed and executed on 100% of page views, regardless of the state of the browser’s cache. The first three chapters from my next book, and the contents of my last few conference appearances, focus on performance best practices for JavaScript.
Pingdom: In your opinion, which is the most overlooked optimization technique for websites?
Steve: The easiest performance improvements to make that are often overlooked are adding a far future Expires header and turning on compression. Slightly more difficult but something that can result in huge savings is combining multiple CSS background images into one HTTP request by creating a sprite.
Pingdom: What are the essential tools for people profiling their website performance?
Steve: Firebug and YSlow are key. There are some known problems with Firebug’s Net Panel in 1.05. For that reason and for browsers other than Firefox a packet sniffer is necessary. I recommend HTTPWatch, Fiddler, and AOL PageTest.
Pingdom: Do you have any pet peeves in regards to website design and performance?
Steve: When weighing design and performance tradeoffs, it’s important to focus on what’s best for the user experience. Often, it doesn’t have to be one or the other, richer design or faster performance. In fact, revamping a web page’s design is the perfect opportunity to incorporate performance best practices, such as CSS sprites and image optimization. Before tackling the harder tradeoffs of features versus performance or design versus performance, make sure you’re doing the best you can with what you have. My pet peeve is missed opportunities: overlooking performance fixes that are easy to implement, have no recurring costs, and speed up the page without any loss of features and design quality.
Pingdom: What, in your opinion, are the major advantages of having a fast website?
Steve: Statistics from Amazon, Google, Jupiter Research and others show that a faster web site increases traffic, repeat visits, clicks, and conversions. There are two other motivations, in addition to these user metrics, that I give for always working to improve the speed of your web site. First, even if your site is fast enough for some users, there are always other users with slower connections. Mediocre performance in the U.S. means an unbearable experience in other parts of the world. If you hope to attract and retain a global audience, your site has to be blazingly fast under normal conditions so that under degraded conditions it’s still usable. Second, even if your web site is fastest across all competitors, there’s always someone looking to pass you by. To stay ahead of your competition, you always need to be working to make your site faster. Speed is today’s competitive advantage for web sites. There’s a saying at Google: “fast is my favorite feature.”
We would like to extend a big thank you to Steve for taking the time to talk to us and share his insights. You can learn more about him and what he does over at his website.
