Step one is caring about the performance of your websites. Step two is doing things to make it better. Step three is staying on top of performance for the long haul.
That means not just poking at trying to improve your web performance a few times a year, but making it a part of your active development and trying to prevent regressions. Certainly something that gets harder the more actively developed your site is.
I’m no master of this. I fall into the camp where I tend to work on performance a whole bunch for a short period, then forget about it. It’s tempting to think you’ve got it licked and you’re good now. That would be true if the web never changed and you never touched your site again. But of course neither of those things is likely to be true.
Here’s some ideas I’ve been collecting. Remember this is all about strategies for staying on top of performance, not specific performance-increasing tips.
Have a Budget
Perhaps you’ve heard of the concept of performance budgets? The idea is to have real numbers that you must stay within. Perhaps it’s something like this:
Tim Kadlec has more information about the metrics you could choose. And here’s the section of a Katie Kovalcin talk about the subject:
When you have this, performance work isn’t just “maybe I’ll see if I can poke around and make things faster” it’s “I’m working toward this goal, or fixing something that made us break this budget.” The latter encourages this long-term performance-monitoring spirit we’re after.
Use Performance Monitoring Services
SpeedCurve is a pretty sweet one. SpeedCurve allows you to build really beautiful and useful dashboards for monitoring your sites performance over time. It uses the all-powerful Webpagetest, which we all know and love, but is pretty darn ugly and doesn’t help much with tracking over time.
Most relevant to our topic of staying on top of performance, SpeedCurve offers performance budget monitoring. You set up certain metrics you want to watch, and how you want to be alerted if you break them.
SpeedCurve has a ton of other awesome features to check out. Like comparing your site to competitors, testing your site at different screen width breakpoints, testing performance when you deploy, and lots more.
Calibreapp is another awesome site for this.
You can set specific budgets for specific things and be alerted when you exceed them.
Of course, being alerted is great. Even better: fix it.
Put Performance On Display
Lara Hogan wrote Designing for Performance and is the Senior Engineering Manager of Performance atEtsy. She shared with me this hallway snapshot from the Etsy offices where they have a big monitor set up to display some performance metrics.
But notice it’s not just graphs and charts…
Celebrate Performance Wins
Not only do they put performance on display at Etsy, Lara says they have a (quarterly)Performance Hero. I dig this a bunch, as it’s a way to positively reinforce doing good things. If someone in your organization does something big for performance, perhaps…
- Blog about it. Explain what they did, how they did it, and why it matters.
- Credit the heck out of that person.
- Show everyone in the company. Tell the world.
That will incentivize the next person that is in position to do the same.
Have Other Incentive (or Punishment) Systems
Certainly positive incentive stuff is a good idea. Is your company at the scale where you can offer real incentives like money or vacation time to performance heros? Performance wins both make companies more money (increased conversions) and save them money (bandwidth), so sharing the wealth seems in good order.
I’d probably recommend against actually nasty punishments for performance regressions. Other than the obvious (negativity sucks), it discourages people from trying things and also encourages hiding the truth when it comes to investigating what happened.
But perhaps there could be some in-between, like a “you broke it, you own it” culture. Meaning if you caused problems in a certain area of a site, that area is now under your watch from here on out.
Automate Everything
If there is a performance-related task that is an obvious best practice and can be done automatically (rather than a person needing to do it), do that.
For instance, images should be optimized. That’s an easy one that most of us know we should be doing. Why do it by hand? Can your CMS automatically optimize images as you upload them?. Can your build process do it for you? Can your DevOps team build something fancy to help? Perhaps a service like ReSRC?
I would lump into this category any service that automatically garners performance wins. I’m thinking of things like CDNs, things like CloudFlare, things like fancy managed DNS, tools like W3 Total Cache that do CMS-specific things to improve speed, things like SPDY, and the like.
Make Calendar Appointments
Rather than wishy-washy resolutions to check in on performance, literally put it on your calendar. Make it a repeating event.
Put it on meeting agendas. Make a Slack-bot to remind you. Do something real.
Blocking Bad Deployments
If you have a sufficiently advanced build and deployment system, perhaps you can build a system to prevent performance-busting builds from ever going out in the first place.
It’s fairly common to run a suite of tests before deployment, which frequently involves firing up something like PhantomJS / a headless browser to check things. Presumably you could also test certain performance things. The easiest would probably be things like number of requests and total page weight.
Influence the Higher Ups
I tried to find a good source for this, but I came up short. My note was a quote something like this:
If all CEO’s were forced to only use their phone to browse the web for a month, sites would get faster.
The sentiment being that the people in position to effect the most change are often unaware of the problem at all. Or at least don’t prioritize it like they probably should.
I heard Lara Hogan say once:
Send a VIP an important stat every day for two weeks.
Peppering them with little important truth nuggets is probably a better approach than a monolith email that’ll get TL;DR’d faster than a cached HTTP request (see what I did there).
Influence your Colleagues
Brown-bag it! Have a little lunch n’ learn with your fellow co-workers. You’re not in this alone and it will be a lot easier fight if everyone is understands and is on the same page.
Keep Learning
Some fuel for this fire is to keep on learning more about web performance. The more you know, the more there is to know. I know personally I need to level up my HTTP/2 knowledge, as that seems like a worth thing to get moved to if possible.
