I picked me up a copy of Lara Hogan’s new book Designing for Performance (Amazon), as it’s a subject I’ve very interested in these days. As I write this, I’m just off the heels of doing quite a bit of performance related work here on CSS-Tricks as well as on CodePen.
I thought I’d give the book a read, learn some more, and be inspired to do some more. Here’s some choice quotes and how they relate to stuff I’ve been doing, wanting to do, and thinking about.

Speed matters
Web performance impacts more than just ecommerce sites; improvements from page speed optimization apply to any kind of site. Users will return to faster sites
We just kind of know websites need to be fast, right? I enjoy the old adage where web performance is one of those features that no customers ask for but all customers want.
Some of the most compelling evidence for working on web performance are statistics are from site where sales go up after improvements. I like that Lara notes that it’s all websites that benefit from speed, because return visitors and SEO rankings go up, and regardless of what metrics you like to use, traffic is always one you want going up.
Not to mention, particularly with global mobile usage skyrocketing, that performance improvements might be the difference between people being able to use your site at all or not and how efficient it is.
The bottom line is that your efforts to optimize your site have an effect on the entire experience for your users, including battery life.
Response timing
A user clicks a link or taps a button… it takes some time for something to happen. How do people feel about that? This makes a lot of sense:
A delay of less than 100 milliseconds feels instant to a user, but a delay between 100 and 300 milliseconds is perceptible . A delay between 300 and 1,000 milliseconds makes the user feel like a machine is working, but if the delay is above 1,000 milliseconds, your user will likely start to mentally context-switch.
“Mentally context-switch”. That’s scary isn’t it? They click a button. It takes ever so slightly too long for something to happen. “What should I cook for dinner tonight?” You might have lost them.
In my recent redesign of CSS-Tricks, I was noticing delays (and obnoxious behavior where only the :focus states would trigger on tapping links) so I implemented Fastclick. Though note that this isn’t the answer to site performance, it’s just free way to reclaim a whole bunch of milliseconds in browsers that aren’t helping with this already.
Who’s responsible?
Even if your job title doesn’t include the word designer, if you are making decisions about the look and feel of a website, you are making decisions that directly impact the performance of that site. Performance is a shared responsibility, and everyone on your team impacts it.
I think of the three of us at CodePen. I’m doing stuff like optimizing images, reducing the size and number of requests, and generally doing more with less. Alex is in there trimming down the size of files and keeping an eye on tools like YSlow and PageSpeed and their recommendations. Tim is watching the servers making sure requests of all kinds come back fast. Everyone’s part is vital to performance.
Later, Lara reminds us to be a mentor. This is about images, but it goes for anything:
You are likely not the only person creating and updating the images on your site. There may be other designers and developers who need to understand these techniques…
Persistent connections
Your browser fetches some JavaScript, then uses this open connection to also grab a font file, and then an image, before needing to establish another new connection to get more content.
…
It’s important to see how many connections it takes to load your page. If you see lots of connections, then your content may be spread out over too many domains…
I don’t consider this one as often as I should. I remember in the not-so-olden-days, it was considered a best practice to split up assets over multiple domains (e.g. assets1.site.com, assets2.site.com) in order to increase simultaneous connections, as those were limited by domain. That sounds like it’s not a good plan anymore.
I’m sure putting assets on a cookieless subdomain CDN is a good plan though. And between that and your root domain, you’re probably OK (don’t need to add extra subdomains just for parallel downloading).
Tracking over time
… it’s important to keep track of your page weight over time to make sure that there are no large and surprising changes as your site evolves and more content is added or the design iterates.
I’m guilty of not doing a great job here. I tend to focus on performance in little sprints where I make it a big deal for a week or two and then kinda forget about it. Then I revisit it only when it’s starting to be a problem.
Tools are starting to emerge that will make this easier to manage. Check out SpeedCurve and Calibre. Lara has a whole chart in the book with different tools and at what points and intervals it makes sense to use them.
Critical rendering
When your user initially loads a page, it will be blank. Blank space is a poor user experience; it makes the user feel like nothing is happening. To fix this user experience issue, you’ll need to optimize your critical rendering path.
That’s the best way to put it. From blank to at least something, so the person viewing your site knows something is happening. Perception is everything; milliseconds count.
I’m both obsessed with this idea and have done nothing about it.
Deferring JavaScript loading is (fairly) easy. Put it at the bottom of the page. Deferring non-critical CSS is hard. You need a good system of declaring critical CSS. There are tools for finding critical CSS for you, which are cool, but then do you just put that in the head and repeat it in the deferred stylesheet? Or do you remove the repeated bits from the deferred stylesheet somehow for more efficiency? Or is it smarter to pick types of CSS that are most important, like layout and colors, and let the rest come later.
I’m letting little stuff get in my way of trying things.
Epidemic growth
The number of image bytes has grown by more than 30% on the average web page in the last year.
The rate of growth in the weight of websites is insane. It’s interesting to think about why this is happening, but maybe we can do that another time.
…optimizing images is arguably the easiest big win when it comes to improving your site’s page load time.
Agreed – and it’s so damn satisfying. I do this every once in a while: download every single image used on the entire site, anywhere. Run them through ImageOptim. Push back live. Ideally optimization would happen as part of the workflow, and it usually does, but this makes sure the whole site is covered once in a while.
Fonnnnnnts
Custom fonts are the most love/hate relationship I have right now. We’ve gotten ourselves into this place where you almost have to use them. Sites look a little off when they don’t. Yet, they can be just as big or bigger than images, are harder to implement correctly, and load worse.
I had never considered this little trick in the book:
@media (min-width: 1000px) {
body {
font-family: 'FontName', Fallback, sans-serif;
}
}
Browsers are smart enough (citation needed) to only load fonts that they know they are going to use, so perhaps only use them on large screens where you are likely to have better performance anyway.
Similarly with all assets:
For your responsive site, consider your smallest screen sizes first. Reorder your CSS to deliver small screen styles first, and use progressive enhancement to add content and capabilities as screen sizes get larger.
There is way more in here
Remember I was just picking out somewhat random parts that stuck out to me. There is stuff in there for everybody.
For instance, there is the best section I’ve ever read on which image format to use and what settings you can tweak to get the most out of them. There is clever stuff in here on avoiding images at all using alternative drawing techniques. Dealing with the potentially extra assets needed for responsive web design. Even stuff on being more efficient with your HTML and CSS in general.
I enjoyed the bit about the 95% percentile. I guess you’ll have to buy it to read that.
(╭ರ_•́)
We have an excellent course at Udacity called “Web Performance” that covers the Critical Rendering Path quite extensively (taught by Google’s Ilya Grigorik).
This is great!
Hey Michael, I did your tutorial and it really helped with my understanding of what was render blocking and not, but I’ve always heard that the media attributes on link tags weren’t that reliable, is that true? or have browsers fixed this. Thanks for a great link!
Nice article, might have to give that book a read. From my experience, front end performance is about doing as many of the huge amount of little things that increase performance well. Little things that on their own will only make minimal impact, but when you do 100 similar things elsewhere, they add up to impact performance.
Especially true if your server supports SPDY ( and a reasonable number of your visitors are using browsers that support it ).
The book looks really interesting. A good present for Christmas :)
Funny, I have done a few of these things already. As a web developer, performance is as much my job as the designers. And I am personally full stack, so both front end and back end optimizations are important. Back end concerns can kill your first byte and initial render times as much as anything else.
As for the subdomain, I implemented for a series of sites, and on the heaviest one it took away a second or more from the load time, which is huge. For the marginal investment, it was well worth the slight added hassle.
As for images, I find the biggest problem is content contributors and lazy CMS designs. Content contributors need to be sizing their images properly, and the CMS needs to be running optimizations on every image uploaded.
this book is great
thank you for sharing
I would really like to read up on CDN stuff as I have never done that before. But I didn’t really find any good resource where somebody would address this issue from A to B. I mean what is the workflow here, when it makes sense to go into troubles with it, etc? :)
I bought this book when it was still a tonal cover, and love it to this day. #Webperf is the emerging dark art, which is having massive impact on web, and this book is a perfect outline for that designer who once upon a time, would be given a blank check. We agreed to a mobile 1st approach the last few yrs, this might be the time for a performance 1st era – since we are doing this for mobile as well. Every design decision needs scrutiny and must answer that question: do we need this? Either way, it will change the way you think, and I recommend this to anyone curious about #webperf.
I’ve recently become obsessed with performance.
The “Mentally context-switch” concept is super fascinating to me. Short delays can definitely hurt the rhythm of your website’s story.
I can’t wait to read this book.
Quick edit, Chris:
Under the code example in Fonnnnnnts, looks like you forgot to add a citation for “Browsers are smart enough”. I only noticed that because I do the same thing. All. The. Time. :)
I left that there on purpose because I don’t have a good citation for that remark. I know it’s true because I’ve run some tests on it myself, but I guess I never published anything on them. If you know of any, let me know! (re: browsers only downloading fonts they know they need.)
I don’t know of anything off the bat. Lots of factors to consider. That’s what a clueless person says to deflect.
I’m guessing you could tell by monitoring HTTP requests?
I like the min-width trick for fonts, but doesn’t that make assumptions about connection speed being related to screen width? Min-width is a great tool for optimizing layout, just not so sure about optimizing performance.
It’s certainly true that small screen ≠ slow connection speed. But I also don’t think it’s that awful of an assumption, especially since we’re just talking about some fonts. There are other factors at play, like memory, rendering power, latency, etc. All of which tend to be worse than larger screens.
Very true. I’m going to have to check that book out.