Hi everyone,
Here's a summary of what I planned to go over in the talk today - I managed
to cover only a fraction.
- Reference + further study:
- Read Steve Souders's books:
- High Performance Web
Sites<http://www.amazon.com/gp/product/0596529309?ie=UTF8&tag=orpesbl-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0596529309>
- Even Faster Web
Sites<http://www.amazon.com/gp/product/0596522304?ie=UTF8&tag=orpesbl-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0596522304>
- Watch Steve's talks online:
- High Performance Web
Sites<http://video.yahoo.com/watch/1040890/3880720> at
Yahoo
- Even Faster Web
Sites<http://www.youtube.com/watch?v=aJGC0JSlpPE>at Google I/O 2009
- Read more excellent, and short, advice:
- Yahoo's Best Practices for Speeding Up Your Web
Site<http://developer.yahoo.com/performance/rules.html>
- Google's Web Performance Best
Practices<http://code.google.com/speed/page-speed/docs/rules_intro.html>
- If you're hooked:
- Steve's blog <http://www.stevesouders.com/blog/>, with cool links
- Hammerhead <http://stevesouders.com/hammerhead/>, Steve's firebug
plugin to time your page loads many times, with both an empty
and a primed
cache. Firefox only.
- The YUI Blog's performance
category<http://yuiblog.com/blog/category/performance>
- Steve's UA Profiler <http://stevesouders.com/ua/> - differences
in performance characteristics between browsers
- Issues like those we discussed, not JS benchmarking
- Tools:
- Install & use plugins for Firebug to analyze your site
- YSlow <http://developer.yahoo.com/yslow/> from Yahoo! (very solid)
- Page Speed <http://code.google.com/speed/page-speed/> from Google
(new, cool, and a little flaky)
- Use an HTTP debugging proxy:
- Fiddler <http://www.fiddler2.com/fiddler2/>, free, Windows only
- Charles <http://www.charlesproxy.com/>, $50, Windows+Linux+OS/X,
my favorite (does bandwith and latency throttling)
- Firebug's "Net" panel (very convenient but Firefox only)
- Chrome's "Resources" view (Ctrl-Shift-J, choose "Resources",
Chrome only)
- Google Page Speed's "Activity"
panel<http://code.google.com/speed/page-speed/docs/using.html#activities>(incredibly
detailed, Firefox only, currently unstable)
- Reply to this message if you know of more good tools (that you've
actually used)
- Practices:
- Measure measure measure:
- Check your site's actual performance
- Check with the browsers your users are using
- Simulate connection parameters similar to your users' (e.g.
bandwith, latency)
- Try to measure your user's actual times
- We use a modified version of
Jiffy<http://code.google.com/p/jiffy-web/>,
easy to write your own
- Minimize HTTP requests
- Combine JS, CSS. Implementation suggestions:
- part of the build script
- script/manual process done offline
- online, like the minify <http://code.google.com/p/minify/> PHP
project
- Maybe
django-assetpackager<http://www.matinfo.ch/blog/archive/2008/05/17/django-assetpackager-installation.html>helps
implement this?
- Combine images
- The technique is called CSS
sprites<http://www.alistapart.com/articles/sprites>
- Good online
service<http://spritegen.website-performance.org/>for generating CSS
sprites, code is open
source <https://launchpad.net/css-sprite-generator>
- Check for duplicates (they happen)
- Load non-critical content (e.g. analytics) after page load with
JS
- Enable caching
- Set "Expires" or "max-age" HTTP header
- With Apache:
ExpiresDefault "access plus 1 year"
- Prefer far-future expiration where possible
- Change resource URLs to avoid stale content
- rename URLS + files in build script
- rename URLS & use URL rewriting to point to originals
- can rename in build script or on the fly
- can use hash, timestamp, etc. (or even svn revision)
- Avoid query parameter technique - some browsers and proxies
refuse to cache it
- Cache dynamic data & AJAX if possible
- Need unique URLs (e.g. gmail's JSON mail content - see with
Firebug)
- Reduce content sent
- Enable GZIP for static + dynamic content
- No scalability hit for static content, compressed responses
are cached
- Compressing dynamic content may burden your servers, but try
it first
- Minify JS + CSS
- The YUI
Compressor<http://developer.yahoo.com/yui/compressor/> gives
the best reductions
- PHP's minify <http://code.google.com/p/minify/> and probably
django-assetpackager<http://www.matinfo.ch/blog/archive/2008/05/17/django-assetpackager-installation.html>
do
this on the fly
- Optimize images
- Serious savings (occasionally %60 or more)
- Convert to PNG (yes, even 8-bit gifs) and use
PNGOUT<http://advsys.net/ken/util/pngout.htm>(Windows, best
optimization),
OptiPNG <http://optipng.sourceforge.net/> (all platforms)
- Smushit (included in YSlow) - will offer you links for
optimized images after you analyze your site
- Put CSS stylesheets at the top
- This is about the user experience - allowing the page to be
usable as early as possible
- In Firefox, if a stylesheet placed lower in the page changes the
appearance of the page, users will see a "flash of unstyled
content" (FOUC)
- In IE, if a stylesheet is placed lower in the page the browser
will try to avoid the FOUC by not rendering *anything* until the
stylesheet finishes loading.
- This causes the "blank white page" syndrome
- Avoid CSS's @import, use <link rel=... /> instead
- IE treats it the same as putting CSS at the bottom of the page
- Put external JS at the bottom
- JS downloads block parallel downloads (especially in older
browsers, including Chrome 1.0, Firefox 3.0, IE < 8)
- This isn't possible with JS that uses document.write
- If it's your own JS, convert it to use DOM manipulation
- If it's a vendor's JS, try contacting them and asking about
alternatives, or faking it yourself (by observing their code)
- Tips for static resources:
- Use proper combining, caching, gzip'ing, and minifying as stated
above
- Prefetch / preload resources
- Perfect if you have well-established entry points (e.g. a
login page everyone has to go through)
- Low-hanging fruit, minutes to implement and no effect on user
experience (if done after page load)
- How to preload with
jQuery<http://orip.org/2009/03/prefetching-javascript-or-anything-with.html>,
for example
- Use a CDN
- Better performance across the board for static resources, sort
of equivalent to buying a faster server for your app
- It's what saved ynet in the analysis, otherwise it would
have been a gazillion seconds, not 12 seconds
- Free CDNs with popular JS / CSS frameworks (e.g.
Google's<http://code.google.com/apis/ajaxlibs/>,
Yahoo's <http://developer.yahoo.com/yui/articles/hosting/>)
- Regular CDNs (if you can afford them)
- CDNs that are appropriate for smaller budgets, e.g. Amazon's
CloudFront <http://aws.amazon.com/cloudfront/>
- Avoid sending unnecessary cookies
- Everytime an HTTP request is made to mydomain.com, all cookies
are sent with it
- This is irrelevant for static resources
- Solution: host them on a separate domain with no cookies
- e.g., YouTube uses ytimg.com
- Increase parallel downloads (more
info<http://yuiblog.com/blog/2007/04/11/performance-research-part-4/>
)
- Host resources on different hostnames - the browser will open
up to X connections per hostname
- e.g., YouTube uses i1.ytimg.com - i4.ytimg.com
- Balance needed: the more hostnames, the more DNS lookups
(round-trips to the DNS servers)
- 2 - 4 hostnames were found good during tests, more hostnames
slowed the pages
- keep filename -> hostname mapping stable, to allow caching
- Start resource downloads earlier
- Flush response before it's complete, the browser can start
downloading resources mentioned so far
- This
message<http://www.mail-archive.com/[email protected]/msg34587.html>suggest
how to do this with Django
That's it for now, maybe I'll post this in the blog as well.
orip
On Wed, Jun 17, 2009 at 5:02 PM, Ori Peleg <[email protected]> wrote:
> 2 load graphs, one for http://yahoo.com and one for http://ynet.co.il
> In case you want a softcopy during the talk
>
> --
> Check out my blog: http://orip.org
>
--
Check out my blog: http://orip.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"PyWeb-IL" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/pyweb-il?hl=en
-~----------~----~----~----~------~----~------~--~---
_______________________________________________
Python-il mailing list
[email protected]
http://hamakor.org.il/cgi-bin/mailman/listinfo/python-il
