I’m at Velocity in San Jose. Just got in last night, and I wish I could have been here for the whole thing. It’s no exaggeration to say that this is the biggest congregation of people who make the Internet work, in one place, for one subject. Jesse Robbins and Steve Souders, along with O’Reilly, get an amazing group of people together. Even the chat in the speaker room this morning was skimming the top of my forehead.
It actually feels like cloud computing and web monitoring are converging very quickly. It’s increasingly obvious that performance, user experience, and revenues are inextricably linked. Microsoft and Google covered this in a joint presentation yesterday, and by now, you’vep probably heard about the number of results Google shows. They tested the number of results that should be shown on the first results page, then tested them.
As Google’s VP of products Marissa Mayer points out, users wanted 30 results. But when they turned this on, they saw a 25% drop in searches on the site!
Being Google, they wanted to analyze the data. First result page searches were down 25% over six weeks. That would be a $2.5 Billion drop in revenues! Mayer did a blind regression across the 30 or so fields Google tracks for every query, and the biggest correlation was speed: It takes longer to get 30 results. It took about 0.4 seconds to get 10 results, and 0.9 seconds to get 30.
Because they hadn’t controlled for all variables, they then ran a different test: The only difference was speed. This was a brave move: They introduced latency, and saw a similar, but less significant, set of results. Even after turning off the latency, users continued to search less. That’s right: The perception of slowness had impacted the users’ attitudes about the usefulness of the site. (Incidentally, if you’re thinking about this analytically, that means Google was tracking by individual visitor — albeit anonymized — rather than by aggregates.)
Mayer then went through several pages:
They’ve been optimizing things like Google Reader, too. Mayer says (revealing a T-shirt with this on it), HTML wants to be square. If you try and round things, you’ll need to use .css and stuff. Rounded corners are slower; at its essence, HTML was designed to be square.
The Google News page is about 80K, and takes around 8 seconds to load. But it feels relatively fast. HTML tables are risky — they don’t render until the end of the table tag — what Mayer calls “Flash rendering” — so they chopped the page into smaller blocks of HTML. This has imperfections; for example, two parallel columns of different heights aren’t necessarily formatted cleanly. But you can interact with the uppermost table above the fold in under a second.
The Search page has other table tricks. They have ads on the top and the right — and they wanted to avoid using tables for this. Other search engines have ads atop and on the right. Given the revenue on the right hand side of the page, Mayer referred to this as the “billion dollar HTML tag.”
- The top of the page loads using chunked encoding — the Google logo, the result you typed, which doesn’t need anything to load from the result set because it’s known when you submit the query
- The stats on your result (such as the number of results found
- The Table align=right tag that’s independent, on the right, showing the ads.
- The Table align=left tag, that includes the search results themselves
By having two tables in HTML, one aligned right and one aligned left, instead of a single table with two columns, Google can show the ads before having to load the entire system.
Finally, Google Maps has 12% of users on slow connections. They started thinking about compression — you can compres a tile to half its size, and the satellite images to about a third of their size. The compression meant that usage went up. Users panned and zoomed more when the compression was implemented.
Mayer’s final lessons:
- HTML wants to be square.
- Small images cost $1.00, large ones cost $1.01, and designers hate this
- Tables are evil
- Compression is your friend
Google’s announced code.google.com/speed with a series of tech talks on performance.
(Mayer finished with some comments, including one to use “Safari, Chrome, or Firefox browsers” that emphasize performance.)
Also, I asked Mayer if she was open to browsers sharing performance data within the DOM so that it could be picked up in monitoring scripts — something we think is glaringly absent from browsers — and she seemed generally OK with the idea.