Relating to “Designing for Performance” by Lara Hogan

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.

(╭ರ_•́)