Live data from Hacker News

Paul Buchheit: Make your site faster and cheaper to operate in one easy step

paulbuchheit.blogspot.com

11–20 of 60 posts

Re: Paul Buchheit: Make your site faster and cheaper to operate in one easy step

#11

His speed estimates are wrong, as he should have tested gzipping many small files instead of gzipping one large file. There is a significant difference.

Why? If you're setting up your website right, you should be serving 1 HTML file + 1 JS file + 1 CSS file + 1 image for each request, and the latter 3 should all be cached indefinitely. (At least for static chrome - if you've got thumbnails, videos, or flash games you can't exactly sprite those.) His test file was 146K, which seems on the high side for HTML only, but I'd imagine serving 1 small file is faster than serving 1 large file.

Re: Paul Buchheit: Make your site faster and cheaper to operate in one easy step

#12
post #5

One scenario where using gzip might not be a good idea is when serving content less than 2-4 kB, like some thumbnails.

true about the image part. images shouldn't be gzipped, bad examples. It still stands for files less than 2-4 kB.

Re: Paul Buchheit: Make your site faster and cheaper to operate in one easy step

#13

His speed estimates are wrong, as he should have tested gzipping many small files instead of gzipping one large file. There is a significant difference.

Why? If you're setting up your website right, you should be serving 1 HTML file + 1 JS file + 1 CSS file + 1 image for each request, and the latter 3 should all be cached indefinitely. (At least for static chrome - if you've got thumbnails, videos, or flash games you can't exactly sprite those.) His test file was 146K, which seems on the high side for HTML only, but I'd imagine serving 1 small file is faster than ser…

1 image for each request? Are you putting all the images for each page into one image file, then cropping the needed region for each image on your page?

Re: Paul Buchheit: Make your site faster and cheaper to operate in one easy step

#14

Earlier quoted context omitted.

Why? If you're setting up your website right, you should be serving 1 HTML file + 1 JS file + 1 CSS file + 1 image for each request, and the latter 3 should all be cached indefinitely. (At least for static chrome - if you've got thumbnails, videos, or flash games you can't exactly sprite those.) His test file was 146K, which seems on the high side for HTML only, but I'd imagine serving 1 small file is faster than ser…

1 image for each request? Are you putting all the images for each page into one image file, then cropping the needed region for each image on your page?

That's the idea: http://www.alistapart.com/articles/sprites/

Re: Paul Buchheit: Make your site faster and cheaper to operate in one easy step

#15
post #9

That's only one of the needed steps. Adjust your headers so that static items are not reloaded frequently. Use versioned urls (e.g., /scripts/main.js?234) and update the versions only when you change the scripts or CSS. YSlow goes a long way in helping with that kind of stuff. The same applies for S3 uploads. You can pass cache headers in the upload request which will later be used on all downloads.

Do you know something that can modify django templates that contain CSS & JS imports so that the linked version gets updated with each checked in change to the files?

Re: Paul Buchheit: Make your site faster and cheaper to operate in one easy step

#17
post #4
post #2

Umm I am confused. Is this about compressing the web page itself? I think what takes most of the time to load on my website is the advertisers rather than the content itself. So perhaps this is about large websites like amazon which have large detabases?

I think what he means is just enabling transportation of compressed data from server to client, regardless what you are transporting. The size of your page does not affect the benefits you achieve with this method, which is always less data being transported.

GP is right about advertisers though :-(

Re: Paul Buchheit: Make your site faster and cheaper to operate in one easy step

#18
post #5

One scenario where using gzip might not be a good idea is when serving content less than 2-4 kB, like some thumbnails.

Gzipping images is generally not a good idea. PNG/GIF/JPEG are already highly compressed and will probably grow in size if you attempt to gzip them.

PNG is often not well compressed unless you've gone out of your way to do so with PNGCRUSH (http://pmt.sourceforge.net/pngcrush/) or something similar

Re: Paul Buchheit: Make your site faster and cheaper to operate in one easy step

#19
post #9

That's only one of the needed steps. Adjust your headers so that static items are not reloaded frequently. Use versioned urls (e.g., /scripts/main.js?234) and update the versions only when you change the scripts or CSS. YSlow goes a long way in helping with that kind of stuff. The same applies for S3 uploads. You can pass cache headers in the upload request which will later be used on all downloads.

Do you know something that can modify django templates that contain CSS & JS imports so that the linked version gets updated with each checked in change to the files?

django-compress does this very well (integrates with YUI Compressor, and several other compression filters). I use it on all my django sites.

Re: Paul Buchheit: Make your site faster and cheaper to operate in one easy step

#20
Mibbit uses a custom webserver... Instead of gzipping things on the fly, I decided to just look for a .gz version on the filesystem, and use that if it's there.

eg a request for 'index.html' looks for 'index.html' and 'index.html.gz'. If the gz is there it uses that and sets headers accordingly.

Works incredibly well, and the deploy scripts just gzip things when they're pushed out to production.

Post reply on HN