Design+Performance @ Bigcommerce San Francisco

This week we had the honor of hosting the creator of YSlow and HTTP Archive, former Head Performance Engineer at Google, and overall performance Boss - Steve Souders to speak on Design + Performance.

He opened by talking about the gap that commonly exists today in how web apps are built, between designers and developers with regard to performance. The relationship can be adversarial and contentious, but it doesn’t have to be and it can’t be that way to build engaging successful web applications. It can and should be a complementary relationship, like the Yin and the Yang.

The challenge is finding the intersection of design and performance. There’s a lack of awareness of how a design can impact performance that would benefit by bringing groups together early in the product development process.

A summary of where are we now

• Often times Designers and Developers work in silos
• Sometimes the designs created are hard to implement in a way that creates a fast and engaging experience
• Fast is important for both business metrics and user satisfaction (studies from Bing search results and Obama’s campaign website)

Where do we start?

At the beginning of a project, create a small interdisciplinary team (comprised of all the parts of the development process - Development, Design, Product, Marketing, Sales, Ops, etc ) that will stay together for the life of the project.

Establish communication channels and if possible, co-locate them. Bringing people in halfway thru is a much harder hill to climb.  

As a team, define guiding principles for the project. Ask yourselves “What are the most important things?”

Prototype early with designers and developers and have everyone on the team engage.

Start measuring performance from the beginning. You don’t have to optimize from the beginning, but you’ll get an idea of the challenges you have ahead. Establish a performance budget - limits on load time, render time, css and js payload sizes.

Measuring performance

We need to move away from `window.onload()` as it doesn’t reflect the user experience for today’s websites. As an example with Gmail, onload fires at 3.9s, but there’s no content for the user to see or use. With Amazon, onload fires at 9.7s, but above the fold (ATF) rendering happens at 2s.

There are two metrics that reflect what the user is experiencing on your website:

• Start Render Time - the time it takes for the browser to begin painting your page (after content is downloaded, blocking js executed, fonts and css downloaded)
• Speed Index - the time until the median ATF pixel gets painted in the browser

 WebPageTest also displays filmstrips of the timeline of what’s painted in a browser for a given page

Custom metrics

The standard metrics aren’t the only way to judge performance. You can create custom metrics based on what you deem to be the most important things on your page/site:

• Identify the most important design element(s) on your page. Twitter defined theirs as the ‘time to first tweet’ - how long does it take to see the first tweet at the top of your timeline.
• Determine the best way to measure when that element is displayed. The method may not be obvious, like trying to determine when an image is fully rendered.
• Use the User Timing spec to mark the time.  Tools like Google Analytics, WebPageTest, Speed Curve will surface those marks.

Tying it all together

This brings us full circle, back to the beginning of the project. Sit down early with the entire team - designers, developers, and other decision makers, and decide on what it means for your website to produce an enjoyable, engaging experience.  

Thank you to Steve for taking his time to talk to us!  

 You can find Steve’s presentation on his site and can watch his talk below.