Much thanks to the attendees, and especially thanks to the great organizers of this year’s dev up Conference. I’ve embedded the slides after the jump and included some of my notes about the topics I discussed during the talk. If anyone has any questions, I’m happy to start up conversations on twitter.
When I talk about caching, I don’t mean Geocaching and it’s what some people think of when they hear the word. Caching in the modern web world can mean web browser, Content Delivery Networks (CDNs), other methods. It is simple to see when you inspect things like DNS entries and web page source, much of the modern web and large scale sites run on the backs of CDNs and many layers of caching servers.
In the traditional database, application, web technology stack, things like load balancing and scaling are considerations when you do not take advantage of methods to improve performance outside of coding and configuration tuning. And caring about web page speed is probably the most important thing teams can do to keep customers and conversions going.
Improving the behavior of your sites with these technologies can prove to be a stop-gap, but buying time with a CDN or Varnish do something else. It can give teams what is needed to search for and resolve underlying issues with code, configuration, systems, servers, or whatever else is the problem developers and operations may be facing.
First you have to decide what’s most important. Are Key Performance Indicators (KPI’s) such as conversions or average time on site or bounce rate the one key metric or metric that matters what you want to measure? The goal is to have a top couple of items that are most important to your business and try and determine what performance enhancements or changes will assist there. If user metrics are important, make sure you have a measure of those, but you will likely have to break it down into some pure numbers to measure including things like bounce rate, average session time, first click, or page weight.
It is important to maintain some scientific rigor such as planning with A3, Plan-Do-Check-Act (PDCA), or Observe-Orient-Decide-Act (OODA). Don’t slap it on top of existing hardware or servers. And remember that caching doesn’t solve all your problems, your brain does. Know your data, files, and headers really well and don’t over-engineer your solution. And as part of the above methods, always Continuously Improve. That means changing and testing one thing at a time.
Understanding that request headers are often the key to a good caching strategy can shape the direction of your choices. If using Browser side caching, JavaScript, CSS, other static images can be cached for extended periods of time as long as you are using unique naming on the files and having a smaller Time to Live (TTL) set on the HTML files referencing those static items.
CDNs use DNS to direct production domain names with a CNAME to the CDN network. The traffic is routed through the network to retrieve files from a server that has low latency and delivery it to the end user. They use your servers/systems as an “origin” for pulling data to cache. Origin may need to be offloaded due to licensing of servers, systems. Often times the costs of horizontal scaling in a hosting environment exceeds the costs of using the CDN to offload certain processing.
The biggest key to caching strategies is understanding the caching is to be built on top of existing systems. What do I mean by additive? Bring order to chaos of the internal. Presenting an even interface to your end users. They don’t care that you’re using the other kinds of bricks or stones underneath, they want a flat table to set their plate on.
Next is dealing with the processes around caching. Populating caches and invalidating them are the two tasks that most of the time will be spent on.
Pull based systems usually do not require any additional automated steps or procedures to populate the caches. The configuration of the CDN, server, or cache technology builds in the methodology used to populate the cache. The big gotcha on pull based systems is making sure that links, content are not hardcoded with origin in order to prevent your code bypassing the CDN, so relative URLs.
The opposite is the big gotcha on pushed based methods it’s required to properly address CDN URL’s for your static assets. Push based includes things like S3 buckets in Amazon and the like which means a manual or automated method in which to push content to the external system. This requires keeping in sync with cached items or else it can lead to 404’s with missing images or other assets without a careful process.
We spend the most time on our large clients dealing with cache invalidation, cache busting, and cache troubleshooting issues. This can be helped by automating often processed tasks like using an API to purge the whole cache after a code deploy or creating a job that will clear one item upon content updates.