Just tripped over a nifty article 'Optimizing Page Load Time' that suggests that thinking about HTTP makes a great deal of sense when thinking about performance.
As an example, here's one of the cookies on the site that I work on:
SMIDENTITY=0gzinsuUJJp+/tRSC5ZaV0WudjvPIRSZc06S2wfBFp39qMk3IbwLjlr1yo
C1MhhFxqBPclz6XDo4tClYYnoQR7ZUh5s5z8doG63QTqetXr/pFIRyEKY7wWHtZhcKj4S
Ck43mU7JuRvPhiSuVaEZC2Cfk4N01qZE47y+nfAFD/ZAwXRBraUfKzUYHl9d+uADHFcz8
pGEHPCch1+6g0LtuRuGxO+IdELXiduWUJfs6kozvBvPGqUltBYTHv2XiLwj6AN9xDdY1K
UHQ5/DX5g0OQuud8NuBGLvF7BQyfNtHqGduOGGXgkLs3+GsD2D5ro83w/WuHt/B6DMbK8
M6FEE8t7q419KMPWxngxFA5d6rP7qxAxUXQDf4blC3POGWTGMMkV/YJvd4mqayiSEPZpH
PceeZs1WZ0GAibVtm2q4f/aYyFbv4iHvYabePsU7GP4FFpUAKoavF2GqJOTa2bUc17rtO
bQcxUrdMAV3YaHA+FodiEpVWXymdj94r95deNKjYgrC64AkGyQTTcUJpsZ3cG+9x1/j2g
mK+0Dx2XI507Azr6aFcz31X2aQ+TdtMvoCnvw664BGgs4lVT7HT9ATMKkJNTNaruM8hqF
zu0Jz0lASUlguCp9NfJQDt6ar/BUMDS/516dHZgQyXh9HTBDKzi5q8LP975mPU;
Now multiply that times the 44 http requests it takes to load one our most popular pages! That's 30K worth of cookies! sweet!
Monday, October 30, 2006
Tuesday, October 24, 2006
YUI Graded Browser Support
The YUI article on graded browser support is a nice overview of the nuts and bolts of browser support in a world where different browsers provide different levels of support for web content. It links to a chart that shows how different browsers are currently supported.
Browser support is a nice example of a class of strategic issues that are surprisingly prevalent on web projects. This is small 's' strategy: web developers don't need to understand your business model or care about financial engineering, we just need to know which users we _must_ support, a business/technical question that will determine which browsers we need to support well, which browsers we should support on at least a rudimentary level, and which browsers we shouldn't worry about.
The standard scenario is the business owner (aka stakeholder) of a project asks for tricky functionality (and this could be something as simple as fly-down menus or precise layout of text and images on a page) and, when asked about browser support, asserts that 'all browsers' or 'all major browsers' should be supported. This is usually about ten minutes before the business owner expects to head out of the office on vacation for two weeks, and before she goes she wants a firm commitment that the project will be completed or at least well underway when she gets back.
My job is often to try to figure out how to share the unwelcome news that there are some basic business questions that need to be thought about fairly carefully in order to make sure expectations are met when the site is completed. They involve thinking about people who turn of javascript (no fly-downs), accessibility (how should keyboard navigation work? Where do we need alternate content), maybe even localization (You can bet that somewhere on the carefully laid out page, localized text just won't fit without blowing something out or wrapping in a surprising way).
And of course there's the unwelcome news that we don't plan to test on IE 5 and a number of other browsers, and that people using these are likely to have difficulty with the page in proportion to the complexity of the page.
This problem is about to get worse, not better: with IE 7, Firefox 2, Ajax, and Web 2.0 we've got a new generation of browsers, some wonderfully tricky client-side technology, and rising expectations from stakeholders as to the kind of experience we can deliver.
This means a lot more conversations ahead about which browsers we need to support and which browsers we will disregard to some extent.
Browser support is a nice example of a class of strategic issues that are surprisingly prevalent on web projects. This is small 's' strategy: web developers don't need to understand your business model or care about financial engineering, we just need to know which users we _must_ support, a business/technical question that will determine which browsers we need to support well, which browsers we should support on at least a rudimentary level, and which browsers we shouldn't worry about.
The standard scenario is the business owner (aka stakeholder) of a project asks for tricky functionality (and this could be something as simple as fly-down menus or precise layout of text and images on a page) and, when asked about browser support, asserts that 'all browsers' or 'all major browsers' should be supported. This is usually about ten minutes before the business owner expects to head out of the office on vacation for two weeks, and before she goes she wants a firm commitment that the project will be completed or at least well underway when she gets back.
My job is often to try to figure out how to share the unwelcome news that there are some basic business questions that need to be thought about fairly carefully in order to make sure expectations are met when the site is completed. They involve thinking about people who turn of javascript (no fly-downs), accessibility (how should keyboard navigation work? Where do we need alternate content), maybe even localization (You can bet that somewhere on the carefully laid out page, localized text just won't fit without blowing something out or wrapping in a surprising way).
And of course there's the unwelcome news that we don't plan to test on IE 5 and a number of other browsers, and that people using these are likely to have difficulty with the page in proportion to the complexity of the page.
This problem is about to get worse, not better: with IE 7, Firefox 2, Ajax, and Web 2.0 we've got a new generation of browsers, some wonderfully tricky client-side technology, and rising expectations from stakeholders as to the kind of experience we can deliver.
This means a lot more conversations ahead about which browsers we need to support and which browsers we will disregard to some extent.
Thursday, October 19, 2006
Quick Tabs are nifty
Hey look, IE7 has something called quick tabs that lets me see thumbnails of all my open windows.
OK, so I'll probably only use as often as the powerpoint slide sorter (which I did use once), but it's nifty. How many years has it been since anyone has been able to looke at IE and notice anything nifty? Hint: you were still building web sites to support Netscape 4.7.
Moving files from ibook to macbook is sooo easy!
I can't believe how easy it was.
OK, so the part where the ibook stopped booting sucked. And getting the hard drive out was bizarely hard (50 screws? 10 pieces to remove first? something like that).
But once that was done, I booted up the new macbook, connected the drive using a USB enclosure I picked up at fries a while back, and an hour later all of my wife's files and applications were migrated over. iTunes. Email. Word & Mozilla. Palm desktop. user accounts and passwords. The ssid & key for our wep network. Probably other stuff I can't think of right now.
OK, so the part where the ibook stopped booting sucked. And getting the hard drive out was bizarely hard (50 screws? 10 pieces to remove first? something like that).
But once that was done, I booted up the new macbook, connected the drive using a USB enclosure I picked up at fries a while back, and an hour later all of my wife's files and applications were migrated over. iTunes. Email. Word & Mozilla. Palm desktop. user accounts and passwords. The ssid & key for our wep network. Probably other stuff I can't think of right now.
Monday, October 16, 2006
Collaboration is tricky
Bruce Schneier's article about opposition to Facebook news feeds tells the story of how Face book introduced a new feature to automatically log changes in feeds -- and the masses were not happy.
It's one thing to know intellectually that the kind of privacy folks could enjoy in the twentieth century is pretty much gone if you want to participate in 21st century society. It's another to realize that what a wrenching transition it will be as various technological forces inexorably chip away at the masks we present to the world. Increasingly, strangers and co-workers will be able to google our secrets.
It's one thing to know intellectually that the kind of privacy folks could enjoy in the twentieth century is pretty much gone if you want to participate in 21st century society. It's another to realize that what a wrenching transition it will be as various technological forces inexorably chip away at the masks we present to the world. Increasingly, strangers and co-workers will be able to google our secrets.
Tuesday, October 10, 2006
Head Shot
I've decided to put my picture in my profile. So have uploaded one as part of this post. The process is marvelously user-unfriendly:
- Load a photo using the upload widget, which is cryptic, but not so bad
- Find the url of your photo in the code:
<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"
href="http://photos1.blogger.com/blogger/3099/3814/1600/elijah_lovejoy.jpg"
><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;"
src="http://photos1.blogger.com/blogger/3099/3814/400/elijah_lovejoy.jpg"
border="0" alt="" /></a>
- Then take the photo url (http://photos1.blogger.com/blogger/3099/3814/400/elijah_lovejoy.jpg) and paste it into the proper field on the profile page.
Why can't there just be an upload button on the profile? Why are computers so gosh-darned hard to use?
Sunday, October 01, 2006
6 months without perl
My memory is that I reimaged somtime around march, and I haven't installed activeperl until now. Scary thought.
Anyhow, as usual, I'd completely forgotten how to setup perl cgi on Apache (which for whatever reason did not take 6 months to install, so maybe I can still call myself a web developer...), but a quick google diggs up a page on a site called the site wizard that provides much of the information that I need, with apache error logs providing the rest.
Folks who wrote the error handling code for apache deserve major good karma, and probably more credit than they get for the success of this application. Amazing how often you can find the information you need in the error log.
So the steps I took, so I can look here next time I do it:
Voila. apache is up and running. Now to see if I can remember why I installed perl in the first place.
Anyhow, as usual, I'd completely forgotten how to setup perl cgi on Apache (which for whatever reason did not take 6 months to install, so maybe I can still call myself a web developer...), but a quick google diggs up a page on a site called the site wizard that provides much of the information that I need, with apache error logs providing the rest.
Folks who wrote the error handling code for apache deserve major good karma, and probably more credit than they get for the success of this application. Amazing how often you can find the information you need in the error log.
So the steps I took, so I can look here next time I do it:
- create super simple CGI.pm script
use CGI qw/:standard/;
print header,
start_html('A Simple Example'),
h1('A Simple Example'); - Add Handler directive so apache knows that .pl means cgi script
AddHandler cgi-script .pl - set +ExecCGI permission on the relevant directory (I turn off apache when I'm out in the wild).
<Directory "C:/htdocs">
Options Indexes FollowSymLinks +ExecCGI
AllowOverride None
Order allow,deny
Allow from all
</Directory> - Tell apache where to find perl, so my script now looks like this
#! /Perl/bin/perl
use CGI qw/:standard/;
print header,
start_html('A Simple Example'),
h1('A Simple Example');
Voila. apache is up and running. Now to see if I can remember why I installed perl in the first place.
Subscribe to:
Posts (Atom)