Feeds:
Posts
Comments

Posts Tagged ‘browser caching’

As a user, one of the best ways to improve your online experience is to avoid downloading repetitive files. It’s a two way street though: If the site you’re visiting doesn’t put any effort into it – you’re (often) not going to be able to do much from the user perspective.

A great place to start is with the YSlow extension for Firefox.  I wouldn’t necessarily be concerned with the score that it churns out, but it will give you useful (and some not so useful) tuning pointers.

Gzip

Pretty simple concept that we’re all probably familiar with: Compact a file down to a smaller version – transmit – restore to it’s usable form.  We’ve got Apache serving up most of our content so we let mod_deflate do most of the work here.  Pretty simple, just make sure not to waste your time trying to compress things that are binary or already compressed.

ETags

These aren’t really for us.  Balancing requests over a set of multiple servers doesn’t necessarily mean ETags can’t work… but it does make it trickier to really get a benefit.  In the end, we just left them out.

Add an Expires Header

This is a little trickier than it may seem.  You never want people to download “the same file” if they can help it, but when you’ve changed that file — you need them to get the changed version immediately.

After playing with a wide variety of approaches, we settled on conditionally adding an expires header.  That’s been in our app for more than a year now and we’ve been pretty pleased with it.  The initial catch was symlinks being overwritten when we re-deployed.  It was a pretty simple addition to have our Capistrano scripts recreate it and we were quickly on track.

Here’s a sample YSlow shot of our savings.  It’s “pretty nice” to reduce what our users need to download on each request from their desk at work, but the savings for those using the site via a handheld device (or other slow connection) is pretty incredible.

Read Full Post »

Even seemingly simple web pages involve downloading several files behind-the-scenes before your browser can render something that looks and acts sharp for you.  To speed up that process our servers and your browser are constantly communicating about what files should be used to get you to the end result.

For example, when it comes time for our servers to render the login page on your first ever visit, we’re going to need to send you the login page itself + a file that details exactly how it should be displayed.  After you signin, we need to show you a page that allows you to search inside your case + that same file that lets your browser know how to display it.  If you’re thinking “seems a little wasteful to send that ‘how to display’ file again”, you’re absolutely right.

Part of the communication between our server and your browser is to let it know: “We already send you this file and the old copy hasn’t changed, so just re-use it instead of re-downloading”.  Where this breaks down is if you’ve already reached the “max cache size” for your browser.  At that point it stops saving files for re-use and just always downloads them.  If this is happening to you you’ll notice the connection status in your browser cycling through waiting / connecting / connected / transferring several times for just a single page.


If you suspect this is happening to you, you could be wasting a log of time.  The quickest and easiest fix is to clear the cache in your browser.  Alternatively (and temporarily), you could increase the amount of space your browser is allowed to use for caching this type of files which you can do in the “Preferences” pane of your browser.

Read Full Post »