The compression stats only look at the HTML document. It certainly is important to compress the HTML document, but it’s important, perhaps even *more* important, to compress scripts and stylesheets. I submitted this URL, “http://stevesouders.com/hpws/gzip-html.html”, to the Compression Check form and it didn’t notice that there was 120K of uncompressed JavaScript and CSS. It would be awesome if Port80 could extend their test framework to check these additional resources. As mentioned in the next paragraph their framework is capable of detecting these additional resources in the page.

The cache control analysis reports the presence of cache control headers, but it does *not* indicate if those headers make the resources cacheable by the browser. I submitted this URL, “http://stevesouders.com/hpws/expiresoff.php”, to their “Cache Check” form and it gave all the resources a green check that cache expiration information was present, but unfortunately the information made the resources *not* cacheable. (This is an example of how *not* to do caching.) Checking that the expiration information is in the future would be a great enhancement to this test.

Screen paint time is clearly important to measure as John points out but such thinking is not limited to just JavaScript evaluation, flash playing and even JPEG decompression is obvious and noticeable if you are too aggressive regardless of delivery time. You can of course just play a bunch of media files or run lots of tasks at once and your page will run slow in the browser window…surprise surprise multitasking OSes at play. :-)