Today's tip comes from Chris Wallace. In his post on The last browser testing advice you'll ever need he talks about his coding and testing process, lays out the a-grade list of browsers (from the Yahoo! UI Library), and if you take the time to read the comments you'll see several tips from readers of the site (including this link to the multiple IE installer).

Worth the time, read it if you can.

Today's tip comes from High Performance Web Sites by Steve Souders. Before the author jumps into web tuning tips, he provides a very brief introduction to some of the features of the HTTP GET headers, including:

• compression for requests which the Accept-Encoding and Content-Encoding headers to reduce the size of the response using common compression techniques


• conditional requests which uses the If-Modified-Since, ETag, or If-None-Match headers to send the last modified date back to the server - if the server returns a 304 status it skips sending the body of the response


• expiring requests which use the Expires header to save the expiration date with the component in it's cache


• persistent connections which use the Keep-Alive header to keep the same TCP connection open to the same server (reducing the overhead of opening and closing multiple socket connections)

If you're a regular performance tester, there's no news there... but I though it was a nice summary for those who might be just breaking in.

I'm a couple chapters into the book and like it quite a bit. The format reminds me of the "How to Break Software" series of books, only instead of attacks the book provides rules. I'm not willing to sumarize any of the rules without contacting the author, but I recommend the book. It's well written and covers some great fundamentals of front-end performance optimization.

I was talking a look at Google product search and wanted to think of the simplest test I could that might reveal a lot of information. After the page loads, if you simply hit the refresh button in your browser repeatedly, you'll be able to notice the following behaviors:

• query response times change each time


• some sponsors change each time, while others don't


• column width (between product description and price) changes based on sponsor size

This gives me several ideas for testing and learning about the product. First, I feel like I could quickly program a script to track sponsor results and performance over time time. If I varied the search criteria for similar products, this could quickly be used to start to verify the accuracy of  adds and the rules for displaying them. This could also become a good no-load baseline for the performance of whatever environment you're testing in.

Understanding the relationship between sponsor text (number of characters) and column widths would be worth looking into. Might be an issue, might not (likely not and issue). But it's also something that can be verified quickly and repeatedly with the script that's pulled together.

For some common web elements (like dropdowns, flyouts, or ads) there is a timing component to your testing. Often they are available for a short period of time after you move off of them. This allows people who might have shaky hands to still use those controls. But how long is long enough? Or too long? When you think about your testing for these seemingly simple elements, think about the timing and make sure you're calibrated correctly for your target audience.

There are a number of tools out there for various browsers that provide similar features, but when I'm working in FireFox I use Firebug. Firebug integrates with Firefox and provides a number of tools for editing, debugging, and monitoring CSS, HTML, and JavaScript. Tools like this are particularly helpful when doing website scripting, basic web testing, or security testing.