You’re reading this article, which means you clicked a link, a string of characters that uniquely identifies this document, one of the billions on the web. You might have clicked a link on the Hostdedi blog’s index page, or a page of Google search results, or a Facebook page. But wherever you came from, you got here in the same way, and that process is what we’re going to talk about.
The Domain Name System
When you click a link in a hypertext document, you ask the browser to download and display the associated content. Before the browser can download anything, it needs to know which of the millions of servers on the web has that page. The human-readable web address (URL) doesn’t encode that information in a way that is useful to machines. The web address must be translated into an IP address that can be used to route information around the web. That’s the job of the Domain Name System (DNS).
There are two types of DNS server: recursive and authoritative. Recursive DNS servers are responsible for finding out the IP address associated with a URL. They’re usually managed by the ISP that provides the internet connection a browser is using, although not always. An authoritative DNS server knows the IP addresses for a chunk of the web. Recursive servers ask authoritative servers for the relevant IP address.
Recursive DNS servers are like librarians: they know a lot, but not everything. Often they need to consult authoritative external resources to answer a question, and in the DNS system, that’s the authoritative DNS server.
The browser sends a request to the recursive DNS server. If it knows the IP address of the site, it sends it to the browser immediately. If it doesn’t, it has to ask authoritative DNS servers. Authoritative DNS servers are organized in a hierarchy, an upside-down tree. At the top are root servers that know which authoritative DNS servers are responsible for .com, .net, and so on.
If the host’s web address is blog.nexcess.net, the authoritative DNS server that knows about .net addresses is asked which server knows about nexcess.net addresses. Then the DNS server that knows about nexcess.net is asked about blog.nexcess.net.
Our authoritative DNS servers know which IP is associated with blog.nexcess.net, so it tells the recursive DNS server the browser queried, which then tells the browser. At this point, the browser has the information it needs to send a request to the server hosting our blog.
A Note On Simplification
In this article, we’re focusing on DNS, HTTP, and TCP. These protocols and systems are the top of a deep stack of technologies, so our description is partial — we’re missing a lot out because it’s not relevant to most WordPress clients.
The HTTP Request
The browser knows the IP address of the server hosting our blog, so it sends the server a message announcing that it would like to open a connection. There is a bit of back and forth chatter between the browser and the server, following which a TCP connection is established between the two. TCP/IP is the network protocol one layer down from HTTP, the protocol of the web.
The server and the browser are talking to each other, so it’s time for the browser to get to the point. It sends the server a message that looks something like this:
GET /a-blog-article HTTP/1.1
This asks the server to retrieve the resource /a-blog-article on the server at blog.nexcess.net. Assuming that such a resource exists, the server sends a response, which includes headers with details about what is being sent and a response body — the HTML of the article itself.
Now the browser has the HTML, but before we talk about the rendering process, let’s loop back to look at what happened on the server before the HTML was sent.
WordPress doesn’t send the browser pre-made HTML. When the browser sends a request for a page on a WordPress site, the HTML is built on-the-fly in the milliseconds between request and response. WordPress is composed of dozens of files in the PHP programming language and its these files that build the page. When they run, the PHP files combine data from the database with templates to create a complete page of HTML.
It is this ability to generate HTML dynamically that makes WordPress so flexible and powerful. Each request can be answered with different content, providing a unique experience to each user. HTTP itself is stateless: it remembers nothing between requests, which would make a complex session-based web application impossible. But with session cookies and dynamic page generation, WordPress can provide an app-like experience from the server.
If you want to know more about how WordPress generates pages, take a look at What Is The WordPress Loop?
Once everything is fetched, the browser has what it needs to render the document and display it to the user.
Small Delays, Large Latencies
Responsibility for optimizing each of these steps is split between the web hosting provider and the site owner. We take care of DNS performance, network optimization, server resources, and more, ensuring that we can deliver data as quickly as possible. But as a site owner, you are responsible for optimizing page sizes and the number of external resources each page loads.
Together, our performance-optimized hosting and a well-optimized front-end experience make for a fast and responsive user experience.