Notes from performance.now()
Observations and lessons learned from the two-day conference on web performance
1. This was a great conference
Expectations were high because of the stellar speaker list — and expectations were met. A wide range of topics were covered, from internet protocols, to low level JavaScript hacks, to performance monitoring. Single track works well — it’s pretty chill to not have to worry about talks that happen at the same time, or rushing from one area to another just to get in. The hosting by Tim Kadlec and Steve Souders was thoroughly enjoyable. Pretty much all the talks were not just interesting, but also fun: Zach Leatherman’s talk about Webfont was a particular highlight. And the food was pretty great, too 😋. The only thing that was a bit off was that some of the talks had quite some overlaps, but all speakers gave their own spin to it. (and thanks to the organization for making some space for us at the last minute 😊)
2. JavaScript is the main culprit for slow web pages
JavaScript makes website slow. No news here, but this phrase was so often repeated during the two days at the Compagnietheater that it will be stuck there until next year’s event. Here’s the problem: we’re shipping more and more JavaScript to the browser, and low end devices (like cheap laptops, or anything that’s not an iPhone) cannot keep up compiling and parsing said JavaScript. For the 95th percentile of researched web sites, over 60% of time is spent parsing, compiling and executing JavaScript. For mobile websites, that means 10 seconds of JavaScript execution on start up. To keep users happy, especially those on low end devices and/or in emerging markets, we have to do better. How? Well, ship less JavaScript. What will also help: using preload headers, utilizing service workers and curtailing third party scripts.
3. Improving performance requires buy-in from all sides
After Tim Kadlec’s opening talk, Harry Roberts came out swinging against third party scripts and tag managers. Armed with a bunch of data and anecdotal experience, Harry pointed out that third party scripts (and their third party scripts) often make a website unbearably slow. Then, Harry switched to people: the only way to fix this issue is to talk to stakeholders that use the third party scripts. Are they really necessary? Can we solve this issue in a more user-friendly manner? Performance needs a holistic approach: engineers need to care about performance, and evangelize its importance — but stakeholders and management need to see its value too. Michelle Vu is an engineer on the performance team at Pinterest; she expanded on this by pointing that engineers sometimes need to be convinced, too: the performance team tries to give product engineers the data and the tools needed to detect and fix performance regressions.
4. Be data-informed.
I’ve never seen so many charts! Line charts, bar charts, pie charts, flame charts. Some curvy, some straight. Recurring advice: make sure you are measuring performance. Developers work on beefy devices, on lightning fast environments, whilst our users are stuck with the production website, riddled with marketing tags, on a low-end device. Ideally, we need two layers of data. Firstly, we need to capture data from real users on our production environments (Real User Monitoring). SpeedCurve is an example of RUM as a service. Secondly, to catch regressions before they get into production, we can use synthetic tests, with Lighthouse or WebPageTest. Michelle Vu and Katie Sylor-Miller both mentioned the difficulty and importance of A/B testing your performance improvements. And lastly, if you’re going to monitor metrics, make sure you pick a metric that makes sense for you. For some websites (like blogs), it will be First Meaningful Paint (or any of its siblings). For other, more interactive websites, something like First CPU Idle will make more sense.
5. Where was the React/Vue/Angular perspective?
Lots of performance evangelists point towards usage of modern frameworks (like React or Angular, and Vue to a lesser extent) as one of the reasons for performance degradation. The idea is that framework culture (anything that can be built with React, has to be built with React) leads to impossibly bloated JavaScript bundles. There’s no denying this as far as I’m concerned: for instance, our platform is built with React, and we’re pulling in around 1mb of uncompressed JavaScript per page, which seems way too much for a content-driven website.
Which makes it that much weirder that this part of the community was seemingly missing from performance.now(). It was only fleetingly mentioned in one or two talks as far as I can remember. It does feel like two separate worlds at this point — and I think everyone would benefit if those worlds can be brought closer together. Hopefully we’ll see that next year when we gear up for the second edition of a great conference.
