The Evolution of the Velocity Conference and Performance Metrics

This year Velocity celebrated its 10th anniversary. A lot has changed in the past 10 years. Velocity has gone from a conference being held once a year to three yearly events, including international locations. Velocity was THE conference to attend to network and learn about web performance. It covered performance from both the back end and front end perspective, which I have always believed is critical to understand the overall performance of an application. This year O’Reilly decided to switch the focus of the conference and Velocity no longer included sessions on web performance, those moved to Fluent.

The conferences were co-located, which in theory meant you would be able to attend sessions for both conferences, with a joint pass. In actuality, even if you purchased a joint pass it was very difficult to attend sessions at both due to scheduling. Sessions did not start at the same time, which meant you could only catch the first or second half if you wanted to attend sessions from both tracks. As a result I wasn’t able to see nearly as many keynotes and sessions as I would have liked. But luckily, I have a trial subscription to Safari thanks to the conferences and can catch up on the sessions and keynotes I missed.

Since this was the 10th anniversary, it wasn’t surprising to hear a lot of talks on how the web has evolved over time. Some discussed changes for the better and some highlighted where improvements are still needed. One of my favorite talks fell into this category, although it wasn’t described in that way. Shubhie Panicker from Google, and Nic Jansma from SOASTA presented a session on “Reliabily Measuring Responsiveness in the Wild.” This talk introduced the concept of “time to interactive” and using long tasks in the browser to help identify when a page is interactive.

Like the web itself, the metrics we use to understand performance have evolved and grown over the last 10 years. The web performance community has moved away from metrics like page load time and has tried to find ones that more accurately reflect the users perception of when a page has loaded. Some measurements like “above the fold” time have come and gone while others have remained such as render time, time to first paint, and speed index.

Performance is about more than when items load on a page. As a user, seeing content is good, but if I’m trying to scroll or click and can’t that can be as frustrating as not seeing content. The important thing to note is users will remember the worst performing interaction on the web site. They don’t remember all the times the page loaded quickly and with no jank, but they do remember the one time there was. Time to interactive is an attempt to measure the point between the page painting and all objects fully loading, at which the site interactive. Chrome has introduced a long tasks API to provide a way to measure when there is no main thread contention and a user can interact with the page.

Finding new methods to measure applications in a way that matters to the end user and ultimately the business will help organizations ensure they meet customer’s expectations. New ways to measure performance will continue to emerge. Investigate the metrics, and experiment with them. But keep in mind, every site is different. Identify the core metrics that work for your application and organization.