Discover the best of the web!
Learn more about Digg by taking the tour.
How To Speed Up Your Web App
thinkvitamin.com — The next generation of web apps make heavy use of JavaScript and CSS. This article, by the lead developer of Flickr, shows you how to make those apps responsive and quick.
- 1145 diggs
- digg it
- pigdart, on 10/12/2007, -0/+20Flickr is one of the slowest initial page rendering/loading, Ive come across. They have so much javascript bloat reading this made me laugh.
- metziel, on 10/12/2007, -0/+12But think what it would be like WITHOUT those optimizations :p
- jvux, on 10/12/2007, -1/+5yep, it would be like one of those ***** pic sharing site without those optimizations
- travisk, on 10/12/2007, -0/+7That's the point... a Flickr user takes a big hit on the first page, but who goes to just one page on Flickr? Over the subsequent 100 page views, all javascript and css are cached, which results in a very responsive user experience.
- morganm, on 10/12/2007, -1/+2And that's great for people looking at their gallery of clever photos of themselves, but when they send you a link to show you one of them, oh man. I, like most of the world, am not a Flickr member, and I only occasionally look at a photo there. You'd think they could at least just display a photo quickly if they do all that conditional javascript to save time.
- mikeazorin, on 10/12/2007, -1/+2Flickr has such an awesome community, it's a shame it's so slow. I hope they get a huge redesign sometime, that puts these things into effect.
- rasterbator, on 10/12/2007, -10/+2Dude, check out your new site. You just got geek'd!
- rasterbator, on 10/12/2007, -10/+1Or, dude, scheck it out. We just pimp'd yo' site!
- mzkw, on 10/12/2007, -1/+11TV has ***** up your head in a way that you're never going to get it back.
- cakefart, on 10/12/2007, -0/+4I think the submitter did a poor job describing what the article was about. The article is quite good for novice web application developers and software architects, however- the 'speed up' techniques described have nothing to do with client side technologies.
As a followup, I'd look at the technologies mentioned (in the article) on the squid and Apache sites, as well as the IBM DeveloperWorks website.
http://squid.visolve.com/squid/reverseproxy.htm
http://httpd.apache.org/docs/2.0/mod/mod_deflate.html
http://www-128.ibm.com/developerworks/views/global/tutorials.jsp?topic_by=All+Topics&sort_order=desc&lcl_sort_order=desc&search_by=&show_abstract=true&start_no=1&zone_by=All+Zones&sort_by=Date&end_no=100&S_TACT=105AGX19&S_CMP=ZHP - jcmia1, on 10/12/2007, -0/+1i agree with cakefart - in addition, those .js files are not that small in size to begin with, so chances are the initial load of the pages are slow (subsequent loads may be faster because many of those .css, .gif, and .js are cached locally). All said, the best way to tune is still the back-end if your application is dynamic (i.e., loads content from some kinda of data store). I'd always start with tuning your OS first on the Web server, app server, and database server, if any. See here:
http://www.performancewiki.com/os-tuning-landing.html- insomniak29, on 10/12/2007, -4/+2I agree with cakefart...
- Cinder6, on 10/12/2007, -0/+1Hmm, it was my understanding that PHP's explode() is a lot slower than newer (identical) functions.
- Cinder6, on 10/12/2007, -0/+1Slow regarding I/O.
heh, sorry for the slow response. Digg ought to have a notification feature for whenever your comments get replied to.
- Cinder6, on 10/12/2007, -0/+1Slow regarding I/O.
- a1programmer, on 10/12/2007, -0/+3Using php to merge your js files? That's plain ridiculous.
- Bogtha, on 10/12/2007, -0/+2Woah, woah, woah. Some of this is *totally wrong*. It claims that Cache-Control: private disabled browser caching. It does nothing of the sort. It disables caching for proxies and *enables* caching for browsers. Read the spec for yourself:
> private
> Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache MAY cache the response.
-- http://www.ietf.org/rfc/rfc2616.txt
In cases where a resource would not normally be cached by a browser, specifying Cache-Control: private will actually instruct the browser to cache it. This could completely break some parts of a website depending on exactly where it is implemented.
The rest of the article seems mostly sensible, but you shouldn't implement any of this without reading the specs and understanding what it is you are doing. Better yet, hire somebody who really understands HTTP, because a lot of it is quite unintuitive. - mgadalsky, on 10/12/2007, -0/+0Amazing. I've never thought it is for real.
- TromaTix, on 11/18/2007, -0/+0Nice tips !
- yogastore, on 06/30/2008, -0/+0http://astore.amazon.com/calphalon.commercial-20
http://astore.amazon.com/calphalon.contemporary-20
http://astore.amazon.com/black.and.decker.lawn.hog ...
http://astore.amazon.com/black.and.decker.oven-20
http://astore.amazon.com/cast.iron.skillet-20
http://astore.amazon.com/12.electric.skillet-20
http://astore.amazon.com/6.quart.pressure.cooker-2 ...
http://astore.amazon.com/electric.pressure.cooker- ...
http://astore.amazon.com/8.inch.chefs.knife-20
http://astore.amazon.com/chefs.choice.knife-20 - neni001, on 07/20/2008, -0/+0http://astore.amazon.com/canon.powershot.s5.is-20
http://astore.amazon.com/canon.powershot.s5-20
http://astore.amazon.com/canon.powershot.and.sd100 ...
http://astore.amazon.com/canon.powershot.and.g9-20
http://astore.amazon.com/canon.powershot.and.camer ...
http://astore.amazon.com/bunn.coffee.makers-20
Digg is coming to a city (and computer) near you! Check out all the details on our