I just changed my CSS image sprites to run from local to CloudFront and there's now a noticeable lag, even across pages and page reloads. Any ideas as to why this might be happening?
+1
A:
Moving images from localhost to a server (in this case CloudFront) will always incur a speed penalty (relative to localhost, certainly). This is because even with a great hosting service the browser has to send an http request via the internet to that server, to find out whether the document's been modified since it was previously cached, or not (not modified: HTTP response 304).
Assuming that the document doesn't need to be downloaded again/re-cached that should be the end of the image-requests for the CSS (particularly if you're using css-sprites).
If the image-sprites have to be re-downloaded because the cache has expired, or the document's changed, then obviously the browser has to download the file again, via the internet and network. And this incurs a cost due to contention on your own network/intranet, between your house and your neighbours between home and cabinet and then whatever speed your ISP provides to you.
Whereas localhost is the same machine, and (likely) has a response measured in the milliseconds. In contrast, accessing Amazon's CloudFront might only take a second or two, but that's still an order of magnitude (or more) greater.
David Thomas
2010-10-08 04:48:11
Thanks! For some reason the Cache-Control headers aren't updating correctly, and I'm having a bizarre issue with the S3 browser (as in, I can't get it to load). So the browser's not doing any caching whatsoever, and I'm left unable to set any expires headers whatsoever.
Josh Smith
2010-10-08 04:58:51
And now S3 browser is back up. Must have been an outage. After setting the caching headers, the issue doesn't arise for me. But the high-level overview was definitely appreciated.
Josh Smith
2010-10-08 05:05:09
Keep in mind that CloudFront caches the S3 objects for 24 hours or something. So if you set Cache-Control headers on S3, but CloudFront has already cached your object before you did that, then you won't see the version of the object that has the headers set for a while.
tfe
2010-10-10 00:32:35
@tfe, thanks! I guess that I *could* use their new functionality to make it expire early, but impatience is a dumb reason to do so.
Josh Smith
2010-10-10 23:23:50
Whenever you're uploading assets to a CDN configured with far-future expires headers, you should never overwrite existing assets; instead, always use a new name. Otherwise clients who have cached the original version of your assets will never find out that you updated them. This is common practice for CDNs (appending a timestamp or version number to all uploaded files).
tfe
2010-10-11 02:23:46