This may seem a bit ‘back to basics’, but it’s a topic of discussions I’ve been having recently.
When presenting performance metrics, folks sometimes use mean, sometimes median, sometimes both, sometimes they include standard deviation, percentiles, etc. I’ve been looking for some concrete guidance on what metrics to use, and in what contexts.
There has been a good deal of work around defining guidelines, best practices, etc. for improving Web page performance (i.e. delivery speed). As Web page publishers have worked to implement these best practices, they inevitably reach a point where they can go no further to improve their own content. The long poles in the tent are outside their control, often in third-party content - in many cases, ads.
Someone recently asked me what Instant Messaging client I use on my BlackBerry.
Last fall I was looking for an AOL IM (a.k.a. AIM) client for my BlackBerry 8800. After much searching and evaluation, I settled on JiveTalk. It connects to virtually all IM networks (via gateways), and is a true IM client application - not a wrapper around SMS, like some products.
It’s not free, but the cost is minimal, and it’s truly one of the best products I’ve found. Highly recommended.
Nicely done …
Ensuring the static objects from your Web site are cacheable is one of the best things you can do to improve performance.
I stumbled across this site the other day, with a tutorial on caching, and a tool to assess the cacheability of a site. Very nice.
AOL has released an open-source tool for measuring Web page performance called PageTest. It shares some similarities with Yahoo!’s YSlow, but works with Internet Explorer (6 and 7).
You can run PageTest as a browser plug-in, or use a hosted version at webpagetest.org (this is still being built out, so please be patient).
We’ve been using (what has evolved into) PageTest at AOL for years. Give it a try.
What keeps users coming back to your Web site? Compelling content? Fast Performance? Cool site design? The answer is “yes”.
Yahoo! released version 0.9 of YSlow recently. The release notes offer the highlights, but this blog entry by one of the developers provides more details.
I haven’t had a chance to spend much time with the new release, but it promises to address what I saw as the biggest shortcoming of prior releases - that it only crawled the DOM and didn’t capture network traffic. The new version promises to do both, providing a much more complete picture.
I was a bit disappointed to see that a bug I had reported in prior versions still remains - YSlow falsely identifies redirects. For example, today on www.aol.com there are 3 redirects, but YSlow identified 20 - the other 17 are listed as “redirects to <blank>” .
Nevertheless, a great tool.
The state of the Mobile Web has bothered me for some time. So, I’m putting my money where my mouth is, and learning more about the attempts at standards, like W3C’s Mobile Web Initiative, and the challenges.
I’ve been using a BlackBerry 8800 for a few months now. Mainly for access to my company’s e-mail and calendar, but also for IM and Web access. This is the first BlackBerry, or Smartphone for that matter, I’ve used, and I must say that I’m sold.
Having a mobile Web browser with me all the time, I find myself trying to look up movie reviews while I’m browsing videos at Blockbuster. Or trying to do a price comparison for something I see at a local retail store. Or trying to find (and reserve) a book at my local library, that someone just recommended in a conversation. I don’t want to wait until I get back to a computer to do these things, I want to do them in real-time, from where I am.
Notice I said “trying” in each case above. Nearly every time I try something like this, I come away frustrated and disappointed because the Web sites are barely usable (and sometimes not at all) on a mobile device.
