When you type a web address into your browser and hit enter, the page appears a few seconds later. It seems the most mundane thing in the world to do but in reality there's a hell of a lot happening behind the scenes before anything actually appears on your screen.
Once you know what that sequence is then it's a lot easier to work out why a page is slow or why a site will just won't load.
1. Browser reads the address
A URL is more than just a domain name. For instance:
https://example.com/products?category=books
The protocol is https, the hostname is example.com, the path is /products and category=books is a query parameter. The browser then takes those constituent bits and pieces and parses them in turn to work out exactly what you're asking for and what method it should use to get it.
It also takes into account the information it already has; if you've been to the site before then the cached data or the autocomplete will probably help to speed things up and it won't necessarily have to start from scratch on every visit.
2.DNS finds the server
Before the browser can get in touch with the website it needs to have the website's IP address. The DNS (Domain Name System) is what converts the human readable name (e.g. example.com) into that numeric address.
If the answer's already on your device or in your network then the lookup is effectively instantaneous. If it's not then the DNS resolver will go out and get the address and return it (it will of course normally cache that result for future use).
The site might well tell you it's not accessible even if it is in fact working perfectly as the browser simply can't work out where the site is.
3. Browser opens a connection
Once the browser has got the IP address it will then go on to talk to the server.
With HTTP/1.1 and HTTP/2 this is done via TCP (TCP initiating a handshake prior to any data actually being sent). With HTTP/3 there's another change in that it uses QUIC which runs over UDP.
It's important when things go wrong as a network issue could easily be impacting one type of connection rather than another and that has to be taken into account if a site is behaving in a rather odd way.
4.TLS makes the connection secure
The browser and server then go ahead and set up TLS. They negotiate the security parameters, they generate the keys and the browser then validates the server certificate to make sure it's valid for that domain and it's from a trusted source.
In most cases you'll get a security warning rather than the page itself when the situation is invalid. The most prevalent reasons for this are the cert having expired, the cert having been issued for a different domain, the cert chain being incomplete, the server being misconfigured and (very rarely) your machine having the wrong date/time.
The little padlock is there for a reason - it means that the information you send between you and the site can't be easily read or tampered with en route.
5. Browser asks for the page
Once the secure connection has been established the browser then asks for the page. In simple terms it's going to send something like:
GET /products HTTP/2
Host: example.com
Accept: text/html
The request can also include cookies and other information concerning what the browser will accept; the server then replies with a status code, some headers and usually the content of the page:
HTTP/2 200
Content-Type: text/html
A few status codes come up again and again:
The response code is 200 (which is a successful request).
301 response means the resource has permanently moved to a new location.
'403 Forbidden' message indicates that the server is denying access to the requested resource.
'404 Not Found' means nothing is found at the website or pages.
500 Internal Server Error means there was some sort of unexpected issue on the server.
6. Browser builds the page
When load the site, the HTML load first. The browser then parses that and builds up the DOM (Document Object Model), which is the structure of the page. Then it goes through the CSS to work out how everything should appear, works out the layout and shows the final output as content.
JavaScript can add content, modify elements, respond to clicks and make further requests. Meanwhile, the HTML itself also contains links to stylesheets, scripts, images, fonts and videos which the browser will retrieve as and when required.
So the main content is displayed before the image loads.
7. Why a page might load slowly or fail
When something breaks, Debugging can only then cease to be essentially about guessing and start to be about working out which step in the sequence was the wrong one once you know the order in which the events took place.
In your browser's dev tools, go to the Network tab; you'll see all the requests with their status, timing and any failures. The Console tab will show you any JS errors. You can do an nslookup or a dig via the command line to check the DNS. To get the response headers you just do a curl -I https://example.com.
Even if there's no single explanation that will account for all the possible ways in which the chain could break, if you know the points at which the chain could break you know where to look for the fault.
Main Idea
The page load process is a sequence of steps really. You've got to find the server, connect to it, set up the secure connection, do the exchange of the HTTP messages and then render the result. The thing to do when you've got a problem is to work out which of those steps in that sequence has failed first. That sequence (DNS, connection, TLS, HTTP and render) is the standard path that a browser takes to load a page.
When a website fails to load, which step do you usually investigate first: DNS, the server connection, TLS, or the HTTP response?
Let me know your thoughts to make this content more engaging and useful to right audiences.
Top comments (0)