Well, this is kind of exciting. :)
I’ve been toying with the idea of some sort of weekly digest or newsletter for awhile now and I’m excited to get things kicked off.
Thanks to everyone reading this for being willing to tune in right at the beginning!
One thing I’d like to do in the future with these is to answer the occasional question from you all. So if you’ve got one that’s top of mind, feel free to hit reply and I’ll try to answer it in an upcoming newsletter.
Might as well start off with the big personal news: after 2.5 amazing years of heading up the engineering and product efforts for WebPageTest, I’m excited to return to performance consulting.
There’s been a ton of interesting changes in the performance industry the past few years—new metrics, new challenges, new opportunities—and I’m eager to help folks make sense of them.
I want to be work who want to not just make their sites faster, but who want to build up the internal culture, knowledge, tooling and processes that will help them stay that way.
As I’ve only just announced this, it does mean that I’ve got some immediate availability (at the moment, at least). So if that sounds like you, or an organization you know, let’s chat.
Priority hints are a pretty recent, highly impactful new standard with minimal risk. Kind of the perfect combination. And now they’re coming to Safari.
They work by using a single attribute (fetchpriority
) to “hint” to the browser that you would like it to give it a higher or lower priority than what it might by default. If you haven’t tried them out yet, it’s worth taking a look to see what impact they might have for you.
As an example, Ebay saw a 150ms reduction in their Largest Contenful Paint (as measured with real user data) by adding it to their image—not bad for a 20 character optimization!
According to Webkit’s release notes for preview release 167, it looks like we’ll have priority hints support in Safari soon. Priority hints (so far) appear to be a really big performance win in Chrome—I’m eager to try them out in Safari as well!
Of course, since Safari doesn’t yet support LCP, the performance impact might be a bit less obvious than in Chrome—I always tell organizations not to optimize without being able to measure impact, and that’s kind of what Safari is doing with this at the moment. But by focusing on First Contentful Paint, or with some clever use of the User Timing API, it should be possible to still measure the impact in most situations.
As an aside, they also fixed a bug where CSS @imports that don’t have quote marks were getting hidden from the preload scanner. It’s a funky little bug that Harry wrote about 5 years ago if you’re interested in going down that rabbit hole.
There was a little chatter on Twitter that lead to me wondering whether the performance golden rule (”80-90% of the end-user response time is spent on the frontend.”) still applied.
I queried HTTP Archive (always a good geeky time) and it looks like it absolutely does. In fact, for the top 10,000 URL’s or so, it’s starting to look like the 85-90% rule instead of the 80% rule.
I’m not 100% sure it matters much though. The line between “backend” and “frontend” performance work is increasingly blurry, and if you’re choosing to focus exclusively on one or the other when trying to improve performance, you’re almost certainly leaving some meaningful performance wins on the table.
At the last WebPerfWG, Pat Meenan gave a great overview on compression dictionaries. It sounds geeky, it is kinda geeky, but Pat does a great job of explaining it and making the topic very approachable.
It’s also highly impactful. The examples he tested show anywhere from a 51-90% savings in compressed file size when using them. This optimization has been a long time coming. My first research into Brotli compression came back in 2016, when I was still at Akamai. I remember having conversations internally about dictionaries, but mostly about the potential. Pretty sure there have been attempts to figure out how that would actually work in a standardized way ever since so it’s exciting to see an approach that looks like it might land.
I definitely recommend watching the presentation. The explainer doc is also a good place to start if you’re more of a “learn by reading” kind of person.
I’m pretty pumped to be back at Smashing Conf in San Francisco, May 23-26. Smashing puts on a super friendly and fun event and man am I looking forward to it.
I’ll be talking about Largest Contentful Paint and how to improve it with a huge focus on images in particular since they are by far and away the most common LCP element.
If you’re keen on joining, Smashing provided a 25% discount code you can use.
That’s the first issue in the books! I’m sure I’ll be playing with the format of these a bit as I go, so definitely let me know if you have any questions or feedback.
Take care,
Tim