Notes from a front-end web performance conference

Stacey Tay

Follow

Apr 5, 2019 · 5 min read

This week I had the privilege of attending #PerfMatters, a conference focused on front-end web performance. I’ve never been to a conference before, but I was thrilled to be attending because it promised an amazing lineup of speakers and topics.

I started delving into web performance about over a year ago, and so thought this would be a great chance to deepen my knowledge and meet other people in the community.

This post consists of three parts:

(1) my experience attending the conference,

(2) some of the things I learnt at the conference, and

(3) parting thoughts.

Thoughts on the conference experience

Everyone is so friendly and approachable

I went alone and it was a fairly intimidating experience, since I’m generally a shy person and can take awhile to warm up. But, I made a rule to not sit alone during lunch and to try to talk to at least 2 people each day. I’m glad I did because everyone I met was nice and fun to talk to.

I ended up meeting a lot of people, talking about things ranging from the PRPL pattern, experimenting with Cloudflare workers to better serve users in Australia (from servers in the US), functional programming’s increasing prevalence in front-end web development, and how to get started with snowboarding (not performance related, in case you’re wondering).

The talks were absolutely amazing

All the speakers had something related to web performance in one form or another to talk about, and it was obvious that they put in a lot of effort into their presentations. Jenna Zeigen’s talk covered a long list of performance tricks and each of her points had a song lyric to go along with them, which was so entertainingly informative. She told me that it took her about 15 minutes for each song and there’s like over 30 in there 🤯

Videos of the talks should be announced on @perfmattersconf soon, but a number of the slides have already been published with #perfmattersconf.

The talks cover the many facets of working on web performance

Improving a web page’s performance isn’t just a one-off audit, fixing the problems that makes that page slow, and then moving on. It takes a concerted effort from all stakeholders—business, design, engineering, marketing, product—in an organisation to get and stay fast.

The talks weren’t all just about how we could improve TTIs or load times, which are important. But, they also covered the other important parts of making the web accessible and usable for as many people as possible. From how people perceive performance to empowering a performance culture, and from how privilege defines performance to the intersection of performance and accessibility.

A non-exhaustive list of performance tips and tricks learnt

Some, if not all, of these might be common knowledge, but many were new to me.

Performance Culture

• Empower developers with tools to enable better performance. Also, make performance part of the development process.
• Compare your site with your competitors’ to get executive buy-in on driving performance. Use WebPagetest’s side-by-side video comparison of your webpage against a competitor’s loading journey to succinctly drive your point across.
• Measure the potential annual revenue gains from increasing site speed with Google’s Test My Site tool.

Performance on the Web

• Latency has an outsized impact over bandwidth on network requests.
• SVG animations are great for animating loaders because of their (relatively) smaller sizes.
• Squeeze your page into 14KB if possible, to avoid multiple round trips because of TCP slow-start.
• Not all CDNs are doing HTTP/2 prioritisation as expected.
• If you have to use web fonts, Zach Leatherman wrote a great guide on how to load them well.
• Perceived performance is influenced by duration (actual duration that a process takes, referred to as “performance”), responsiveness, fluency (perceived smoothness of a process), and tolerance (how long does the user expect a process to take). Slides from Gemma Petrie and Heather McGaw’s talk on Measuring Perceived Performance to Prioritize Product Work.

Some Neat Tools

• Chrome’s code coverage tool is useful for determining where and when to code-split stuff out. Interact with the page a little to see how the numbers change, and according to Tim Kaldec, about 45% unused code is normal and it’ll be diminishing marginal gains to optimise over that.
• Chrome’s override network resource feature allows developers to return a locally saved file, which is useful for debugging something on the fly.
• Google Docs Spreadsheet to do bulk WebPagetest audits.
• Online JavaScript AST explorer (alright, this one isn’t exactly related to web performance, but I found out about it during the conference and can’t stop playing with it).
• Request Map creates a network graph from a web page and is useful for visualising third party requests.

Parting Thoughts

If there’s one overarching theme I got from the conference, it’s that to be good at web performance, it’s crucial to understand how the browser works (things like how rendering happens and the critical rendering path). But, performance doesn’t just stop at technical gains.

Getting buy-in from all stakeholders, not just engineering, is crucial to improving and maintaining performance because web performance goes beyond loading a page as fast as possible.

There’s also perceived performance to consider, and then determining whether further improvements in performance creates additional significant business or user improvements. It’s important to keep in mind that performance is just one part of the user experience.

I didn’t take too many photos during the conference (note to self to definitely take more photos the next time), but I did manage to snap this one.

If you’re interested in web performance or just web development in general, this is an amazing conference to check out and it’s scheduled to happen next year too! There’s also a scholarship program for those unable to attend without financial assistance. Looking forward to seeing you there next year!

Thanks to Hui Yi, Jingwen Chen, and Yao Hui Chua for reading an earlier draft and sharing their feedback.