The Difference Between Static and Dynamic Websites

8 minute read

Websites come in a variety of flavours, all aspects of them can be tailor made to suit whatever purpose it is they’re intended to serve. Developing a website isn’t something you do in 5 minutes, it’s something that takes many hours, and is often something that constantly evolves. Projects that could potentially grow are worth putting a bit of extra initial effort into in order to save a lot of effort down the road. A rather big decision to make is whether a website should be static or dynamic - and the difference between the two is what I’m going to talk about here.

Whilst thinking about the direction I wanted to take this post, I decided to see what other people were saying, and I was rather surprised to see how many results there were…


96 MILLION? I knew it was a bit of a confusing topic, but wow. Arguably, if you add an “s” onto “website” it drops down to 7 million, just a casual 7 million. Anyway, point is, it’s evident that it’s not just me who wanted to know what the difference was. So here’s how I’ve learnt to define them.

Static vs Dynamic

Let’s start off with the basic definition of those two words, static being a lack of change, and dynamic being the opposite - continuous change. We’re not exactly breaking new ground here, the words themselves are straight forward. It’s when they’re used to describe two different types of website that it gets a little odd.

Back when I was at school, my maths teacher would tell me that mathematicians are lazy if I ever worked something out in needless complexity - and it’s one of those things that’s stuck with me. I mean, it’s obvious - there’s no point in spending needless effort on something. But what’s not so obvious is when it’s worth spending more effort on something at first to save effort down the road - and this is a key reason “static” and “dynamic” websites are defined.

Let’s use the good old for this example, now I apologise if you just clicked that link because you now have a massive photo of my face on your screen (sorry) - hold a piece of paper over it if you must, but bear with me because I’m making a point. That page is made up of (as we’ve already noticed) a photo, it’s also got some text which is part of the HTML code that makes up the structure of the page, then there’s some CSS (styling) which tells your browser what colour and size to make everything and where it should go. It’s just 3 files which are sent to your browser which parses the code and renders the page before leaving it on your screen ready to be etched into your retinas.

That’s a simple, single page website. Now, let’s look at this blog, there’s perhaps 50, maybe 60 pages on here currently. There’s a couple of different types of page, but there’s potentially a LOT of duplicated code - each post has the same styling and in fact, the same everything - other than the post’s content, of course. I could create a new file and copy and paste the code for the page into each. It’d work, I mean, it’d appear identical from the visitor’s point of view. The problem is, I’d suddenly have 50-60 files to manage. If I ever wanted to change something that wasn’t the content of an individual post, I’d have to go into each and every file to make the change. Fun? I think not.

So, what’s the solution? It’s simple! Rather than having the website be a collection of boring old files, we make it a collection of boring old files AND add some code and a way for the server to interpret it. Now, suddenly, we can have a template for the home page, one for the individual blog posts, and another for each distinctly styled page - we could break it down however we wanted to. We tell the server to say, query a database for the post’s content and title and insert it into the post template and send that off to the visitors. Just like that we’ve gone from an absolute nightmare to a rather elegant solution.

If we look at the words again, you could argue that they apply to different websites for different reasons. I think the main reason this topic can be confusing is because not many people define it in a clear cut, clear to understand way. is made up of static files that requires no server-side interpretation/execution, the web server just throws the raw files in the direction of anyone who asks for them and job’s a good’un. is a dynamic website, the server interprets scripts and generates the pages before throwing them at visitors. The difference is server-side programming.

Static websites can be served from the most basic of web server, the client says, “I want to view this page” and the server goes “That’s…. This file… Here you go”. Dynamic websites require any amount of code to need to be executed on the server before it’s “ready”. Client: “I want this page”, Server: “Sure, one second, it’s this file, looks like I need to add the date and some content, there you go, oh, I’ll also throw in the author’s name. Done. It’s all yours.”

So many explanations for this topic say stuff like “website scripting” - what in the world is that supposed to mean?! My websites are entirely made of “website scripting” - Is it some special, branded kind? No! The difference is server-side scripting/programming.

I’m sure there’s people out there who would argue differently for one reason or another - but whether it’s server side or not is the only thing that really matters. If you want to run code on the server, you need software on the server that can interpret and execute that code, clients will interpret the various types of code you’d use by default.

To summarise…

Dynamic sites include server-side execution of any quantity of script, it could be as simple as adding the year to the footer or as complicated as generating the entire page based off of the square root of a solar system. I really dislike how other people define it as “whether a database is used” or “website scripting”, or “if it’s running PHP”, “if JavaScript is used on the client side” - I mean, they’re not always “wrong”, but if they aren’t, they’re often not the full answer.

Static websites are better for the following scenarios:

  • They’re quicker to write (at first and for sites with just a couple of pages)
  • They’re easier to host as you’re literally just serving up files
  • They’re faster as there’s nothing that needs to be done to/with the files
  • They’re more secure as there’s less complexity to the server and thus less attack surface.

Dynamic websites are better for these reasons:

  • They allow you to automatically insert information into/modify a page for each request
  • They remove the need for duplicated code

The extent to which a site is “dynamic” can vary massively, you could simply have it pull in a template file for the header and footer and have the rest of the page be dynamically generated by a script. I do this on a couple of sites, it’s the only unique section of code, but it means that nothing is duplicated and thus I only ever have to make changes in one place - incredibly handy and time saving, especially when I need to add a page or change the navigation bar.

Where practical, I do prefer static sites because they are faster and a lot of CMSs (Content Management Systems - like WordPress) are incredibly bloated due to the fact they’re designed to be incredibly flexible. More code = more processing (aka slower) and more opportunity for vulnerabilities.

Short link: