On Aug 27, 2007, at 9:32 AM, Pekka Jääskeläinen wrote:
It revealed a problem with cache headers (I've discussed this on IRC withnick 'visit0r'): So, it seems the static contents in 'public' do not have cache headersby default set like they should. This is with Pylons 0.9.6rc3 (upgradedrc-by-rc from 0.9.5).
That shouldn't actually be a problem as they use ETag's instead. The Yahoo tool is not perfect, and does have a few inconsistencies on some things.
Next issue: These components are not gzipped: *displays the css* hereHow do I use the gzipper of paster? What should I add to the Pylons conf?
That will definitely make an impact on speed to an extent. I'd suggest having your front-end app handle gzipping. I use Apache in front of Paster, which gzip's the images when I add the following (Apache 2):
<LocationMatch /(style|scripts|trac/js|trac/css).*>
# Insert filter
SetOutputFilter DEFLATE
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
</LocationMatch>
Otherwise, it seemed the bottleneck was the .js files, like I suspected.Thanks again for pointing this useful tool out. I might collect these optimizationtips to a receipe wiki at some point.
The most substantial speed boost I got on the PylonsHQ site, was from reducing the CSS from 3 stylesheets to 1 because each CSS load goes one at a time, blocking parallel downloads and anything else until the CSS is done. Moving the JS to the bottom also resulted in noticeable improvement since it loaded just once at the end instead of blocking parallel page component loading.
Cheers, Ben
smime.p7s
Description: S/MIME cryptographic signature
