Wednesday, July 25, 2007

Liveblogging JavaScript Performance / Yahoo Performance Sessions From OSCON 07

500K = practical upper limit of JavaScript

Write less code
- Profile
- Minimize

Load it as late as you can
- Bundle

Work hard now to be lazy later

Draw UI as late as possible
Never pre-draw hidden UI
- Including loading relevant JavaScript

CSS very top of your page
JavaScript very bottom of your page

Load your app in stages

Always want to show a quick response acknowledgement
- UI should RESPOND quickly even if it can't RESPOND quickly

onmousedown feels a lot faster

All data requests should go to data-manager code which knows whether or not a network request is actually necessary.

Use range caches; only fill in missing pieces.

Balance local updates vs. re-fetching from APIs

Perf optimization as much about APPEARING fast as being fast

Be pragmatic: do the wrong thing if it has a better result

Cheat when it works for you
- Slow app theoretically more extensible in future not actually useful

Firebug == Tivo

Bottlenecks abound and are usually not obvious

Browsers bog down - restart for consistent benchmarks
Firebug Profiler

Don't be clever
- Consider when it is and isn't worthwhile

Browser more like mobile phone than desktop

Small, quick-loading pages with Ajax interactions is best

Eat your own dog food
- (Getting Real: build apps you actually want and need)



//////////////Yahoo Web Performance Session


14 Rules

Exceptional Performance Team

5% of "loadtime" is HTML - 95% is everything else (CSS, images, JavaScript, etc.)

80%-90% of end-user response time is spent on the front end. Start there.

Far-future expires header on Web server.

25-50% improvements

1. Make fewer HTTP requests
2. Use a CDN (Content Delivery Network)
3. Add an Expires header
4. Gzip components
5. Put stylesheets at the top
6. Move scripts to the bottom
7. Avoid CSS expressions
8. Make JS and CSS external
9. Reduce DNS lookups
10. Minify JS
11. Avoid redirects
12. Remove duplicate scripts
13. Configure ETags
14. Make Ajax cacheable

(Roughly in order of priority.)

Get a clear idea of how users use your site and specific pages

images "sprites" ?

Book coming from O'Reilly with whippet or greyhound or something

YUI blog
YDN blog

YSlow will be open source

Response time and page weight very strongly correlated
YSlow doesn't track response time, but YSlow grade and response time strongly correlated

IBM Page Detailer

1 comment:

  1. Here's some more on image sprites:
    http://paulstamatiou.com/2007/07/25/how-to-optimize-your-site-with-image-sprites/

    ReplyDelete

Note: Only a member of this blog may post a comment.