CAll Us: +1 888-999-8231 Submit Ticket
What Happens When A Link To Your WordPress Site Is Clicked?

What Happens When A Link To Your WordPress Site Is Clicked?

What Happens When A Link To Your WordPress Site Is Clicked?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
Host: blog.nexcess.net

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

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?

The Browser

The browser has the HTML document, but there is more to be done before it can render the page. A web page is made of more than just HTML. HTML controls the structure of the document and its textual content, but its appearance is determined by CSS. Many pages also include JavaScript for interactive or dynamic features.

CSS and JavaScript files are linked to in the <head> section of an HTML page. The browser sees those links, downloads the resources, and uses them to shape the final page. Once this initial data is downloaded, the JavaScript is executed, and it may want to download more resources from third-party servers. Each resource included in an HTML page kicks off a response-request cycle similar to the one we have already described: DNS, TCP connection setup, HTTP request, and so on. You can see why including lots of third-party resources makes for slow page-loads.

Once everything is fetched, the browser has what it needs to render the document and display it to the user.

Small Delays, Large Latencies

As you can see, a lot happens between a click and a rendered web page. Small delays at each stage add up to substantial latencies. The browser can’t do anything until the DNS server sends it the right IP address. If the web hosting server is slow to respond, the browser is left waiting. If WordPress doesn’t have the resources it needs to quickly execute PHP files and query the database, page rendering is delayed. Web pages that fire off a lot of additional requests and include multiple large JavaScript files introduce numerous delays. Geographic distance between the server and browser slows everything down.

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.

Posted in:
WordPress

Source link

About the Author

Leave a Reply