Yeah there's a few requirements in that though that most web designers don't understand
(and most pools don't understand either)
I'll list them here so if anyone else is interested in doing anything, they'll know the requirements.
1) Requests (as few as possible)
When you access a page on our web site, it returns one blob of text, and the only other request your browser makes is to get the tiny images in the top left (usually just the eye)
Though, the index page (that's not much use except the first time you visit the site) includes the background image.
Most web sites break everything up into multiple files that the browser caches, but the browser has to check each one with multiple requests across the internet.
...
4) 'Flashy'
Well, if it involves anything like flash or other scripting languages to produce animated images, then that's completely out.
The bottom line is that the site contains more than the necessary information, it's fast to load, and it's secure.
... and a bit of information about the current web server - it's Load Average is usually around 0.00 to 0.01 - and it handles about 150-200K requests a day at the moment.
I am assuming that your web server is separate from the miner processing and with the low loads, you may have some room for a little bit of flashy. I have only been here for a few months and I am very used to the familiar look of the site. I suspect a fair number of people are reading the home page for info about block changes (as I do). If it were me, I would have the home page be a static .html page that gets updated once a minute for those using it for processing. The browser would cache that page in most cases, and if not, it loads directly. Inside of that, I would add a couple lines of javascript to load a json encoded set of values for the few dynamic fields from your server including how many seconds to delay for the next "ping". That would be 100 bytes or less, so not a lot of traffic, but yes, it is a hit. Once loaded, update those fields and set it up to do it again in however many seconds your server determines was safe (and random to distribute the load). You could even do something like the page count on bottom left of strandvision dot com where the javascript has a starting value, starting time and increment value per 1/10th second and have the shares actively count up as an estimate till the next update. On the server side, I would cache the dynamic fields once per second (memory or disk) to reduce database queries for all these repeat queries.
Also, with the importance of fees, I would also consider adding a current block value to the home page stats to help miners understand how frequently the transactions change and get a feel for where the mempool is (and user urgency) at the moment.
If you are using a LAMP setup, I would be willing to do this for you for free. I also think that some enhancements to your API may help grow the site. I have a pretty flexible API library that can optionally do tracking, limiting, checksum verification with a secret for some calls, security groups of access levels - all can be individually configured per key. The actual code for the api call is a php script object that can utilize any of your existing code to build a php array. That array is sent back to the API library which formats to the user's preference of json or xml. I would be willing to offer that to your for free and if you like, willing to put in the couple hours to get it incorporated into your site. If you feel comfortable with my work, I would also be willing to help with other API pieces including the payment reporting for each miner.
If you would like my help, I could probably complete these in 2 to 3 weeks (have a full time job to keep up with too).
I am also building up minergain dot com which will eventually do a fair bit of this as well - although delayed by a minute in most cases. That is free for anyone interested although obviously not as far along as Kano's site.