A Proposed Front-end Performance Policy

I’ve been using this when working with clients to come up with an agreement on how we handle older and slower browsers. I’m eager to hear your thoughts on it.

There are two major truths when it comes to in-browser experience:

1. Both we and the client want the most responsive experience possible.
2. Everything added to the page slows it down.

So with these two facts of life, what steps do we need to take so everyone is happy? Onward!

Create success metrics with the client

These should be customized to your client and project and done before the wireframing phase. These goals should be reasonable from a technical POV, as well as testable.

Some goals that would be appropriate:

1. The slowest browser supported must go from an empty cache to fully loaded and initialized within 10 seconds.
2. Hover states (and other ‘instant’ changes) should respond within 300ms.
3. Animations should appear smooth, with jumpiness occurring < 15% of the time (across all browsers).

For load-time based goals, it’s important to define who’s computer and connection this must be done on (e.g. the clients). Additionally, the goal may be defined for multiple pages, for example: the two most popular landing pages (e.g. homepage and support).

If the client has more wants more aggressive goals than are reasonable with the intended design, expectations need to be set with visual and interactive design to keep things more minimal.

Communicating the performance impact during design phase

Internally

During IA, IxD, and visual design, it is the interface developer’s role to communicate the performance impact of interactive features or certain visual techniques on the target browsers. Give the designers constraints: “If we’re using Cufon, we cannot have more than 10 elements of custom font per page.”

Externally

Expectations need to be set that all browsers will not have the same experience. They won’t perform as well as eachother, nor may it make sense to have feature parity.

It may be sensible to drop a few features from the IE6 and IE7 experience. Features that could be considered to be dropped are: shadows, transitions, rounded corners, opacity, gradients.

When communicating the impact of something:

• Clarify the impact with as much detail as possible: “it will hurt page load” vs “it will add 2 seconds to page load in IE”
• Provide a quick POC (proof of concept) if it’s reasonable: “This similar-looking page without siFR loads in 4 seconds, with siFR it loads in 8 and has a delay to show during scrolling”

Develop according to best practices

Choose libraries and plugins that are performance optimized. Make wise architecture decisions based on performance goals. Also minimize DOM manipulation when possible, and write styles to avoid visual changes to the page as it loads and initializes.

Measure performance during QA

QA teams should also prioritize performance related tickets alongside visual, functional, and usability issues. Developers and QA should determine how that priority will be assigned.

During QA, the success metrics should be tested regularly.

Tools to test with:

• YSlow, Page Speed, Hammerhead, MSFast, PageTest

When performance goals aren’t met, there are three options:

1. Redevelop the code – profile, discover bottlenecks, refactor code, optimize to target faster execution in the browser
2. Drop the feature – turn it off for slower browsers only
3. Redesign approach of the UI – perhaps the design could use a tweak which would bypass the issue entirely

With this approach, I think all parties have  a better chance of having aligned expectations heading in as well as a more sensible workflow in dealing with performance challenges.

What do ya’ll think? Realistic?