Anatomy of a Website

Ever wonder what it takes to deliver a website to the world? There are quite a few components required, some of which overlap and even share names. It can make for some confusing discussions and lead to misunderstandings. In this post, I’ll explain how the pieces fit together.

The Language of Browsers

A website has to display in a browser (like Google Chrome or Mozilla Firefox) and that means that what comes to the browser has to be in words that the browser can interpret. That means, basically, HTML, CSS, and JavaScript. No matter how fancy the website or how complex the things may be on the back-end (the server end; see below), what comes to the browser is always a combination of those three languages.

The browser gets to a website through a URL (uniform resource locator) which is made up of words… like or Those words only mean something if they can be translated into an IP (internet protocol) address (like When you type a URL into your browser, a Domain Name Server looks up the URL and, if a valid IP address is returned, your browser’s request gets passed along to that IP address.

Webservers and Webservers

IP addresses normally point to servers, and most of those servers are computers (usually virtual these days) running the Linux operating systems. Sometimes these servers are called web servers because that’s their job. But these servers need to run another piece of software (which is also sometimes called “web server”) that listens for requests. The most popular products in this category are Apache and Nginx.

Quick recap: a server (a physical or virtual computer) running an operating system (usually Linux) has Apache or Nginx installed on it and configured to listen for web requests. That’s a web server.

Inside of the public folder of Apache or Nginx, you could put a simple HTML file and you’d have a website (a terribly boring and static website, but a website nonetheless). Take for instance this example from W3Schools:

<!DOCTYPE html>

<h1>My First Heading</h1>
<p>My first paragraph.</p>


That would work, and technically it would constitute a website. (I wouldn’t expect a lot of traffic, but who knows… anything can happen.) Back when I started making websites, that’s pretty much all there was! These days, however, we need a little more.


A “stack” is group of software products that facilitate the development and deployment of sites or applications. At KMDE, we work mostly with LAMP or LEMP. The “L” is for the aforementioned Linux, the “A” for Apache, and the “E” for Nginx (because it’s pronounced “engine x”).

The “P” is for PHP, a language that runs on servers and is generally used to produce HTML. About 80% of all websites run with PHP, and although it’s trendy for developers to hate, New Kids on the Block were once trendy too. PHP went through some ugly years, but these days it’s fast, stable, and the learning curve isn’t insane.

When the request that started with a URL in your browser makes it to a webserver running PHP, instead of a static HTML page (like the one shown above) getting returned, PHP executes and, based on the incoming request, dynamically produces the HTML that gets sent back to your browser. That’s a big part of how websites became interactive… you get a page sent to you, you put some information into it and send it back, and PHP reads what you sent and sends you something else.

(PHP isn’t the only thing that can do this; languages like Node.js and Go can do it too; PHP is just the most widely-used.)

This whole process gets even more powerful if the web server has a place to store (and subsequently retrieve) information. The “M” in our stack is MySQL (or MariaDB), a relational database engine. PHP stores information in MySQL/MariaDB and fetches it as needed.

So for example if you type a word into a search box on a web page and click “search,” that word gets received by the web server and picked up by PHP. PHP can use that word to search a database like MySQL/MariaDB and then build a new HTML page from the results, which it can then send back to your browser.

Interactivity 2.0

JavaScript was developed in the mid-nineties as a way to manipulate things on the screen after they’d made their way back to your browser. The browser has to understand JavaScript and interpret it (all browsers do these days) and the JavaScript has to be sent along with the HTML from the server to the browser. At first JavaScript was limited because it couldn’t talk to databases, but with the advent of AJAX (Asynchronous JavaScript and XML) that all began to change. That greatly increased the power of the web and browser-based applications.

Are we there yet?

Why yes, we are. At a very high-level, we’ve covered the pieces required for you to be able to type an address (or click a link) in a browser and end up with a response. From small sites like ours to Amazon or Facebook, the principle is the same.

As you can see, there are a lot of moving parts involved in getting a website delivered to a browser. Front-end development (such as with JavaScript), back-end development (server-side languages like PHP), database management, web server configuration and management, Linux server administration… all of these can be a person’s only job. You can imagine, then, that someone who calls him-/herself a full-stack developer either doesn’t know what it means, is exaggerating, or is a total tech bad-ass.

Hopefully this brings a bit of clarity to the big picture for those who may have been curious.

Leave a Reply

Your email address will not be published.

Join our Mailing list!

Get all latest news, exclusive deals and service updates.