From snapping photos with a cellphone to streaming music through a browser, much of the tech trickery we take for granted in 2017 looks simple on the surface but involves a complex series of computations and calculations behind the scenes to make the magic happen. As an example, take Google.com.
You not might think much of visiting the most well-known search engine in your browser, but there’s a lot of heavy lifting going on to serve up the page, and, as noted by The Next Web, Mozilla developer Alex Gaynor has written a detailed guide to what’s actually going on in the background.
It’s close to 5,000 words and growing, so if you don’t want to sift through the entire document we’ve picked out some edited highlights here of precisely what happens when you navigate to a web page.
First of all your computer has to interpret the signals coming through from your keyboard—each key press closes a specific electrical circuit that tells your computer the letters and symbols you’re hitting. The computer polls for new inputs every 10 milliseconds or so.
As soon as you click inside your browser’s address bar and press the “g” key all kinds of code whirs into action—your browser checks whether or not you’re in incognito mode, and if you aren’t, scours your bookmarks and history for potential matches. It’s also going to be looking for popular search terms on the web, and of course updating the URL and search suggestions as you add each successive letter.
Chances are, you’ll see “google.com” appear before you finish typing it, thanks to the smart algorithms built into your browser and whatever its default search engine is set to. This is confirmed with a tap on the Enter key, sending the Enter key code to the computer’s Human Interface Device (HID) keyboard driver, which passes it on to the operating system.
The next step is to parse what you’ve typed into the address bar—is it a URL? Is it a search term? Is it some gibberish your cat has typed out on your keyboard? If the browser can spot a valid protocol (like HTTP) or domain name (like Google.com) it can open the page, otherwise it passes the query on to your default search engine, often with a code that indicates the referring browser.
In this case we’re headed to a website, so the browser then checks its HTTP Strict Transport Security (HSTS) list, a preloaded table of sites that would prefer to connect via the more secure HTTPS protocol. If it spots a match, it sends the first connection attempt via HTTPS, otherwise it uses HTTP.
Next, the browser performs a DNS lookup, which is like looking up someone’s home address—though in this case we’re trying to find where a website lives on the internet. The browser might have this information already stored if you’ve visited the site recently, so it checks its cache first; otherwise, it checks the online address book stored in your OS, and then a reputable one stored on the web, to try and find the site you want.
Once the DNS lookup occurs there’s another layer of checking and counter-checking, known as an Address Resolution Protocol (ARP) process. This actually works inside the DNS lookup to figure out whether you’re connecting to a machine on your own network or a site out on the wilds of the web. Finally, with the address and location of the website established, your browser can open up a socket: a connection between your computer and the site that allows for a two-way flow of information back and forth.
The next stage is a series of virtual introductions and pleasantries between your computer and the website you’ve requested (in this case Google.com). These involve establishing a common language so the displayed website actually makes sense, and going through some ID checks for the sake of security. Key to this is the Transport Layer Security (TLS) handshake, the setup of secret keys to prove you’re on the right website.
Once everyone’s on good terms, the actual data transfer can start—browsers can make all kinds of requests to sites and vice versa, but here we just want the HTML and other code that makes up the Google.com home page. In the space of a few fractions of a second, the familiar search engine interface is showing up in your browser.
It’s the browser’s rendering engine that does the bulk of this work, and the different browser developers have all deployed their own engines (which is why the layout of webpages sometimes varies between browsers): Chrome uses Blink, which is based on the WebKit engine that Safari uses, while Firefox has Gecko. Having used Trident in Internet Explorer, Microsoft now has EdgeHTML for its Edge browser, which is based on Trident—if you ever find an older website that asks you to switch back to Internet Explorer, its because it uses older technologies that only Trident supports.
The browser calls in the help of the CPU and the GPU on your computer as it interprets the code it’s getting and turns it into a webpage—in this case a search box with the Google logo (or maybe a Google doodle) above it. Unless your browser, your internet connection, or the Google homepage is broken, you’re ready to start searching.
All of that calculating and parsing and data transferring, and you’ve not even started searching yet—how your queries are interpreted and organized by Google is a whole other story. We’ve simplified some parts of the process for the sake of space, so again you can check the full document for more details, but you should now have a better sense of what goes into even the simplest of operations inside your browser.