How Long to Cache?
The more we cache, the more is stored on the client machine, and that means fewer hits on the server.
Static pages and components should always be cached. If they’re not going to change, store them on the client machine so they only have to make the trip once. However, caching them forever creates its own problem: The browser will never expire them. If we change them sometime down the road, the browser will not pick up the changed component because the cached component has not yet expired. [The workaround is simple enough, though. When changing a component, just change its name (some people append the version number or release date to the name of the component). The old component, with the old name, will cease being used and will be purged by the client according to an LRU (least recently used) algorithm.]
Dynamic pages and components should not be cached unless we can predict when they will be changed next. If we can, we can set them to expire at that time and allow caching until then.
In general, an expiry date should be as far into the future as possible, but not later than the date of the next change to the component. If we set a component to expire daily, we will inconvenience our end-users once a day. If we set a component to expire monthly, we will inconvenience our end-users once a month. How often are we willing to inconvenience our end-users?
Creating Peak Load Unintentionally
If we set an expiry date with the expires header line, every browser in the world will expire the component at the same time. If the component is used on many browsers world-wide, this can cause a sudden, perhaps crippling, peak on our server. To avoid this sudden peak, use cache-control: max age to set a duration instead of using expires to set a date. [However, if we know our component will change on a certain date, we can use expires instead to make sure all browsers pick up the change at the right time.]
Viewing Component Load Times
Paid Monitor’ Free Page Load Testing shows us what components were loaded, how long they took to load, and what they waited for prior to loading. It provides the same information that is available through Paid Monitor’ Transaction Monitoring, but we can see the results immediately. Paid Monitor’ Transaction Monitoring is for continual monitoring; the page load testing tool is for one-time use.
Page load testing and transaction monitoring provide information about page loads from Monitis’ computers worldwide, but they do not show the results from our end-user’s computer. If the end-user gets different results, the causes are more localized.
Separate Static Content from Dynamic Content
Some Technical Gotchas
Here are some special situations to watch for:
- HTTPS is not cacheable.
- If we are using .htaccess, Apache’s ExpiresActivedirective must be on.
- Some browsers will consider the page uncacheable if the last-modifiedheader line is missing.
- Cookies can interfere with caching.
- PHP is non-cacheable by default, so make sure to use the headerfunction to set an appropriate expiry.
- If appropriate, use GET rather than POST.
Caching on client machines is a good idea, but it does nothing to help first-time visitors to a web page. Client caching is only useful on subsequent visits.
As a request journeys from the server to the client, it hops from one machine to another until it reaches its destination. Some of those in-between machines are willing to cache our content if we ask them. First time visitors may not have to retrieve the content all the way from the server. It may be available on a closer machine.
This is simple enough to implement. Just make sure the server includes the cache-control: public and vary: accept-encoding headers in the response. [The latter is required to get around a problem with some software that serves compressed content when it should be serving uncompressed content.]
Caching Tutorial for Web Authors and Webmasters by Mark Nottingham. Published 2010.06.29 by Mark Nottingham at www.mnot.net/cache_docs. Accessed 2011.12.14.
Paid Monitor Free Page Load Testing Tool. Published by Paid Monitor at pageload.monitor.us. Accessed 2011.12.20.
Paid Monitor Transaction Monitoring. Published by Paid Monitor at portal.monitor.us/index.php/products/transactions-monitoring. Accessed 2011.12.05.
Optimize Caching. Published by Google at code.google.com/speed/page-speed/docs/caching.html. Accessed 2011.12.14. This is a detailed explanation of HTTP caching and a how-to tutorial.
Website Performance: Taxonomy of Tips by Warren Gaebel. Published 2011.12.29 by Paid Monitor at blog.monitor.us/2011/12/website-performance-taxonomy-of-tips. Accessed 2012.01.02
YSlow Ruleset Matrix. Published by Yahoo at developer.yahoo.com/yslow/matrix. Accessed 2011.11.30. Yahoo’s implicit rankings can be inferred from the second column of the table (weight). The bigger the number, the more important Yahoo considers the tip to be.
Try Paid Monitor For Free. A 15-day free trial. Your opportunity to see how easy it is to use the Paid Monitor cloud-based monitoring system. Credit card not required.
The Paid Monitor Exchange at GitHub. This is the official repository for scripts, plugins, and SDKs that make it a breeze to use the Paid Monitor system to its full potential.