Today’s header image was created by George Brynzan at Unsplash
Before we begin, this post will end up being web development heavy. But that’s because I want to talk about ways to speed up your website.
Also, I was going to originally going to call this post: Caching All The Things!
First An Announcement
Before I get on to the topic of this blog post, I wanted to talk about a new project of mine
what? Another one?
Essentially, I’ve started a podcast on .NET Core. I’ve called it “The .NET Core Podcast”
what an original title, I hear you cry
and if you’re at all interested in .NET Core, then you can find out more about it over at https://dotnetcore.show/
The reason I bring it up is because I’m going to use the website for the podcast to illustrate how you can improve the page load speed of your websites.
That’s how little time it takes to load the home page for my new podcast.
Like, from the initial request to the page being drawn in your browser.
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:
- your browser figures out where the server which hosts the website is – this is called a DNS lookup
- your browser asks the server for the web page that you’ve told it to load
- the server responds with some HTML (the text content of the page and descriptions on where to put it)
- your browser starts downloading this files (it can do these in parallel, but limited to around 5-10 at a time)
- while it’s doing this, it starts to draw the web page for you
- 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
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.
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
But what about static content?
Static and Dynamic Content
If you head over to the “naked domain”
for this site (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.
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.