For AJAX-based web applications, following is what I'd suggest in making things very zippy for the user:
1. Concatenate your JS and CSS files. Don't send out several files over the wire to the browser - the browser can only make 2 connections at a time. Be careful about JS dependencies - order is imp. in JS.
2. Minify and then compress the JS and CSS. Use Dojo's Shrinksafe or the YUI Compressor to do this. It will strip out whitespace, etc - make the code smaller in size (In JS, every byte counts) and compress.
3. Now gzip the above. (Paul's article talks only about gzipping - if you do the above 2 steps as well, you'd improve the performance a lot more).
Write an Ant script to automate all the above on code commit and you are done. Try other methods like loading other elements in the background or after a tab etc is clicked - important to show something to the user almost instantly. Did this for Alertle.com, which was a 100% AJAX web app (no page refresh at all), and the initial size of the code being sent to the browser went from 700k to about 20k using the steps above :)
4. Figure out browser caching - what to cache, how and for how long. Frequently changing code files - not a good idea to cache them for long, but images and other files, in most cases you only really need to download them once to the user's browser. Stuff to Google: etags and last-modified.
Improving site speed is a broad topic, and there would be other stuff on the server-side too where improvements can be made, like cached queries and using "prepared statements" to optimize the SQL.
While it's true that IE6 and IE7 can only handle 2 concurrent persistent connections per server, IE8 can handle 6.
Firefox 3 by default handles max 8 persistent connections per server, and max 15 connections per server in total (persistent and non-persistent).
This goes against RFC2616, but I guess the capacity of both servers and clients have increased enough the last 10 years to warrant such changes in default behavior across browsers.
The RFC2616 requirement was always a bad idea for users; for years I missed the Netscape feature that let you set this parameter to whatever you wanted; I left it at 20. (Was that up to 0.91N? I forget.) It helped out server software that made concurrent connections expensive, though.
Another good argument in favor of doing so is that establishing a connection has a non-zero time cost. Further, your server may not have the workers to spare (so that extra connection is going to sit until the server's queue isn't backed up.)
A RSS feed reader, pre-filled with top 1000 feeds covering various topics, from news to technology to gossip! I'd get the alien to spend the first half of his time reading these feeds, and the latter half I'd show him Google.com and ask him to find out what he doesn't even know he could have found out about! A trip to the urban jungle (Manhattan) and a trip to a natural area, and the being would be all set! :)
This is a great article. And thanks to jey for posting this. On a side note, reading it I found out that Sanjay is based in Toronto currently, which is where I am, so I just reached out to him and would be chatting with him a bit more about startups, immigration, etc soon. Small world, and thanks HN! :)
I loved the YC process. They asked the right questions on their application form - which helped us a lot in getting a clearer idea of the venture. The prospect of an interview also pushed us to develop a demo quicker than we would have (which we just finished - didn't submit before the deadline).
So thanks to the YC process itself, we NOW have a presentation deck ready and a demo and can charge full steam ahead regardless. YC for us would have been a nice-to-have, not essential. We have a fairly interesting idea and a background which included two of us having founded startups in the recent past (one of them being www.alertle.com - check it out for UI design), being speakers of Ruby on Rails and AJAX at conferences, and work experience at other startups and places like Merrill Lynch. And of course, a CS background. We didn't even get an interview.
I'm assuming the calibre of teams accepted would have been pretty extraordinary this year. Good luck to all! :)
I think you are right to some extent, but its fairly regular that when you are excited about something you are doing - time, sleep, etc take a backseat. You'll spend all your time thinking about it / building it. That is why it is important to be clear in your head - what do you love - the product or the business.
We loved the product we were building, so that kept us going. For geeks/hackers, the primary motivation is to build something they like, instead of $$. The money is incidental and its easy to get carried away with the 'product'. Some of us ended up working 7 days a week, 15 hrs a day on it. 4am everyday (and partly because some team members were in India). I think the frenetic pace, esp. is startups is natural and a good thing, but the key is to work smart - not just hard.
The experience has made me ask to myself almost every time I see a cool web app - 'ok, but how will it make money ?', and if it can't, then it would not be more than a short-lived dream for its founders and backers.
"The reason you failed is because not enough people want your product."
Never got to test that theory out, because even if enough people wanted the product, the business model around it is something which we haven't been able to figure out. We have the product's version 2.0 sitting ready (substantial updates from whats visible in ver1.0 demos) but we do not see a clear exit yet, so are hesitant to launch it. Being blogged about major tech blogs (from Lifehacker, Mashable, etc), some folks loving it around the world and writing reviews in ~ dozen languages - we already got that love. If we stayed out in the market more - we'd probably get more 'love'. But 'love' can only keep the servers humming for so long :)
1. Concatenate your JS and CSS files. Don't send out several files over the wire to the browser - the browser can only make 2 connections at a time. Be careful about JS dependencies - order is imp. in JS.
2. Minify and then compress the JS and CSS. Use Dojo's Shrinksafe or the YUI Compressor to do this. It will strip out whitespace, etc - make the code smaller in size (In JS, every byte counts) and compress.
3. Now gzip the above. (Paul's article talks only about gzipping - if you do the above 2 steps as well, you'd improve the performance a lot more).
Write an Ant script to automate all the above on code commit and you are done. Try other methods like loading other elements in the background or after a tab etc is clicked - important to show something to the user almost instantly. Did this for Alertle.com, which was a 100% AJAX web app (no page refresh at all), and the initial size of the code being sent to the browser went from 700k to about 20k using the steps above :)