Web Compatibility and Performance Testing in a Multi-Browser World

Imad Mouline, CTO, Gomez (@imadmouline)

Buddy Brewer, Director of Engineering, Agent Technology, Gomez (@bbrewer)

Agenda

• The problem and the upside

• Functional validation across browsers

• Performance optimization across browsers

• Raw vs. perceived performance

• Key takeaways and Q&A

The Problem

• Building applications is more complex

• Developers now support an interrelated

mess of technologies that differ from

browser to browser

• Networking stack

• JS engine

• Rendering technologies (CSS, Canvas, SVG)

The Upside

• Browsers provide better performance, richer

functionality

• The rate of change is accelerating, with

competition between vendors leading to

massive gains in performance

How?

• We need to understand how our applications

perform in real browsers on the real network

• We need to know both what users encounter

and what they perceive

Asymmetric Advantages of Modern Browsers

• Dramatically faster JS engines

• Greater connection parallelism

• Client side storage

• Native CSS selectors

• 2D compositing (Canvas, SVG)

Testing Presentation

• Bespin determines browser Canvas support

at runtime

• Which browsers provide adequate support?

Yes: Firefox 3.5, Safari 4

No: Firefox 2, Safari 3, Any IE

Maybe: Chrome

Functional Validation

• As new versions ship, do the expected

browsers still work?

• As new browsers are released, do our

applications still work?

Revisiting Performance Optimization

• Are our old techniques still relevant as the

browsers we target evolve?

• Example: Domain sharding

• Legacy browsers allow 2 connections per hostname

• Domain sharding increases parallelism to boost

static object performance via pointing multiple

hostnames to the same host

Optimizing IE6 Behavior

• For older browsers, this could represent an

easy 50% load time savings

Optimizing IE6 Behavior

• What’s the catch?

De-optimizing IE8 Behavior

• In IE8 (and Firefox and Safari and Chrome) using

domain sharding leads to a glut of simultaneous

connection creation and a dramatic performance hit

Lessons

• Optimization techniques must evolve along

with the browsers

• So, performance testing should take into

account browser differences

• And to do that, we need to know what

browsers are visiting our site

▪ Difference between quickest and slowest browser load time equals 13.226 seconds

▪ Large sample of US end-users, on broadband connections, visiting a particular page on a web site over a 48 hour period

Performance Differences by Browser

▪ Load time for MS Internet Explorer higher than Firefox▪ Perceived render time for MS Internet Explorer lower than Firefox

▪ Perceived render time is the amount of time needed for the page layout to stabilize and for all content visible to the end-user above the fold to be completely rendered

Load Time vs. Perceived Render Time

Optimizing Perceived Render Time & User Experience

• Most prominent

image on site loads

almost last

• Changing load order

will not impact raw

page performance,

but will improve

perceived render

time and user

experience

What is the download order?

Factors that impact object download order

• Browser type / version

• Host latency, concurrency differences

• Geography

• Geography???

San Jose

Boston

Page Load TimeCache Level

Browser Cache Impact

Takeaways – Summary

• Know your end-users

• Identify where and how they use your application, how

they connect to the network, when they do it, where

they do it from, what browser they use, etc…

• Deliver on their expectations

• Know your entire application

• Build performance into your process

• Improve raw, workflow, and perceived performance

• Continuously evaluate your performance targets

• Measure what matters

• Measure from your end-users’ perspective

• Align your end-users’ web experience with your

requirements and ultimate business goals

Please complete an evaluation.

Questions?