Before we begin, this is a slightly edited version of the same post from my personal blog, over at blog.gaprogman.com

First An Announcement

30 milliseconds

That's how little time that the home page for my new podcast takes to load. Like, from the initial request to the page being drawn in your browser.

What's Caching?

I don't really have a specific target audience for this blog, so I'm going to start with a little background information on what caching is - at least from a programming perspective. I've written a brief overview on what happens when you load a webpage in the past

on a different blog - here's a link

but the basic process is:

1. your browser figures out where the server which hosts the website is - this is called a DNS lookup
2. your browser asks the server for the web page that you've told it to load
3. the server responds with some HTML (the text content of the page and descriptions on where to put it)
4. your browser starts looking through the HTML for other things that it needs (images, CSS, JavaScript, videos, etc.) to show you the page
5. your browser asks the server for each of the extra files it needs (images, CSS, JavaScript, videos, etc.)
6. your browser starts downloading this files (it can do these in parallel, but limited to around 5-10 at a time)
7. while it's doing this, it starts to draw the web page for you
8. as each of the other files come back from the server, it starts to add them into the page

This process used to be quite slow, back in the days of dial up that is. With the advent of broadband, we suddenly had ten times the amount of bandwidth and found ourselves able to download stuff much faster. That's when web developers started including higher quality images, and they started looking into serving video. First there was RealVideo, QuickTime, Windows Media Video, DiVX and XviD, and a whole bunch of other formats; then there was YouTube. Then along came the ad networks and tracking scripts. Which slowed everything down again

not to mention that they made websites stupidly insecure, too

In order to reduce the amount of time that your browser needs to spend downloading files, it can temporarily store parts of each website that you visit in what's called a cache

this is similar to the super fetch, which I've written about before - here's a link

This means that when you go back to a website, if none of the images have changed (for instance), then your browser doesn't have to re-download them. This makes the page load quicker. That's caching in a nutshell.

Different Types of Caching

So far I've talked about "client side" caching, it's called this because it happens on the client side

your web browser is the client, whereas the machine which runs the website is the server

This is great, but can be rendered useless as soon as you clear your browser's history

clearly, you'd only do that because you've just ordered a super secret present for someone... right?

When you do this, it wipes out the browser cache. This means that the next time you visit your favourite website, your browser has to re-download all of the things that it had previously cached. Sometimes this needs to happen (when you start running low on hard drive space, for example), and sometimes it's by design (private browser windows clean up after themselves as soon as you close them).

Server Side Caching

Most websites that you visit these days will server you "dynamic content". Facebook is a prime example of this. Each time you load your feed (after logging in), there's a chance that the stuff on there will change. That's because the server which is running Facebook does some work before it returns your feed to you. Namely, it looks at all of the statuses

stati?

of your friends and figures out which ones you might be most interested to read. It then packages all of that data up and sends it back to you. When ever you request a dynamic page, there's a chance that the content will have changed. This means that the server always has to create the new content over again. This means that loading the page takes a long time, because the server is doing some heavy lifting

the amount of time this takes is sometimes called "Mean Time To First Byte" and means the amount of time it took for the server to send you the very first byte of information for the page

When a website consists of dynamic content, the web server will usually

but not always, because it's not relevant for a lot of sites

keep a copy of the page it just generated a server side cache. Then, when the same user asks for the same page, it will just send back the copy instead of having to recreate it.

A Metaphor

Imagine that you're working for a book shop. This book shop is a little weird because each book is typed and bound to order. You can go in and ask for a copy of Night Watch by Terry Pratchett

one of my favourite books

and they'll type it out and bind it for you. Imagine if you received 15 orders for the same book on the same day. You don't want to have to type out every page 15 times, so you use carbon paper and make 2 copies of each page, as you're typing it. This metaphor doesn't really fit, but it's enough for you to see the point in server side caching

hopefully

But what about static content?

Static and Dynamic Content

If you head over to the "naked domain"

ooh er!

for this my landing page (i.e. https://gaprogman.com) you'll see a static page. This page never changes, so it's not dynamically created when someone browses to it. In fact, if you view the source code of the page

go here to learn how

then the data that you'll see is exactly how it looks on the server.

Caching this on the server wouldn't make it load any faster because it never changes - in that it's static content. If there was ever a chance that the content could change based on who is browsing the page, then it would be known as a dynamic page.

Each time that you log into Amazon, eBay, or Netflix (for example), the pages that you see are dynamically generated for you. Most of the content you see will be the same that other users see, but there will be parts that custom to you. Before that site is able to send the HTML page back to your browser, it has to figure out which content to send over the wire. And this takes time.

To cut down on the time it takes to generate that content, a website or web application can store the generated content before it sends it out to you. The stored version is usually kept in a cache somewhere on the server. If you hit refresh as soon as the page has loaded, the server will simply get the pre-generated version of your page from the cache and send that over the wire. ... which all a very long winded way of saying that you can save time at the server by storing the generated content.

Conclusion

Hopefully, you have a much better understanding of some of the common techniques that can be used in order to speed up a website or web application. Just like website or web app security, knowing that these things exist is half of the battle. I'm going to be writing up how I used these caching techniques to make dotnetcore.show load incredibly speedily, very soon.