Developer Resources FeedTake Advantage Of EditLive! 6.5's Cache Improvements
The engineering team have recently completed some major improvements to the way that EditLive! caches resources like images, style sheets and your configuration file. While to end users these changes are all "under the hood", site administrators can take advantage of them to get more control and better performance out of EditLive! As an extra benefit, the changes you make to make EditLive! faster also make your website faster for visitors.
If you want to try it out, grab a copy of the latest 6.5 build. Don't forget to let us know your thoughts.
What's New?
Previously, when EditLive! downloaded resources it would cache them in memory for the length of the browser session. This meant that EditLive! didn't notice any changes to those resources until you restarted your browser. If you've ever tried to tweak your configuration file and try it out you will probably have encountered this and had to restart your browser to see the changes. Now EditLive! obeys the HTTP cache control headers specified by your server and by default caches only for the lifetime of that applet instance; refreshing the page will cause EditLive! to check for updates to all of it's resources.
It also meant that when you did restart your browser, EditLive! had to download the entire configuration file, style sheets and images all over again. On a fast connection this doesn't have much impact but on a slower connection it can be quite noticeable. With the new caching support, EditLive! will now cache items on disk so that they can be reused even after the browser has been restarted. EditLive! simply asks the server, using standard HTTP, if there are any updates and uses the local cache if there aren't.
Finally, by caching on disk, it means that EditLive! can make better use of RAM by dropping items out of it's memory cache more frequently because they'll be available to quickly load back in from local disk. Most people won't notice this but if you work with a number of large images you should find EditLive! handles it a lot better.
What Does That Mean For Me?
Apart from just enjoying the benefits, you now get more control over how long things are cached by specifying HTTP headers. For example, once you've tweaked your configuration file and are going into production, it most likely won't change again for quite some time so there's no point in having EditLive! ask the server about updates every time it loads as that just slows down the start up of the applet. Similarly, any style sheets and images that don't change often can be given longer cache times.
How Does This Make My Site Faster?
We haven't just invented a new caching system, we've implemented the same system that browsers use for your content. So any changes you make to allow EditLive! to cache resources longer will also allow your site visitor's browsers to cache them longer as well. So when the user visits multiple pages on your site or returns to your site multiple times, it's more likely that they will be able to use a local version of your style sheets and images instead of having to download them again. Visitors get a faster browsing experience and you save on bandwidth - what's not to like?
What's The Catch?
There is one big catch to caching - if you do make changes to resources that have long cache times, those changes may not be noticed by EditLive! or visitors to your site until that cache time expires. Usually that doesn't cause problems but it is worth keeping in mind.
Fortunately, there is a simple way to force EditLive! and browsers to download a fresh copy of a resource, even before it's cache time expires - simply change the URL to it. The items in the cache are always based on their URL, so any change to that URL represents a new resource and it has to be downloaded fresh. If you combine this with reasonable cache lengths, and very short or no caching allowed for frequently changed items you can achieve a good balance of speed and freshness.
Controlling Cache Lengths
How you adjust caching times depends on the server you're using. To get started, first look at this introductory article on HTTP caching which goes into some detail about how it works and the trade offs involved. There's some links to the relevant configuration options for commonly used servers at the end of the article, but you can also find information in the documentation for your server.