From Address Bar to Pixels
Between pressing Enter and seeing a page, a browser does a surprising amount of work. Most of it happens in well under a second, so it is easy to think of a page as something that simply appears. Knowing the steps explains nearly every "why did the page do that?" in the rest of this book: why a missing file breaks the look, why a slow script freezes the screen, why the page you edit in the browser's tools is not the file on the server.
A builder handed a floor plan is a useful picture. The builder reads the plan room by room, sends out for every material it lists, and then builds. If someone changes the plan halfway through, the builder redoes the parts that changed. A browser treats your HTML the same way.
How Does the Page Arrive?
The address you type names a server somewhere on the internet. The browser sends that server a request, a short message asking for the page, and the server sends back a response: a few lines of information about the answer, followed by the page itself, which is HTML text. That is the whole exchange in one paragraph. If you want the full picture of servers, addresses and requests, Computing Foundations from Zero explains them from the ground up and APIs for Beginners takes requests apart in detail. This page is about what the browser does next.
What Does the Browser Do with the HTML?
The browser reads the HTML from top to bottom and builds a model of the page in memory. Every heading, paragraph and link becomes an object, and the objects are arranged in a tree: the page contains a body, the body contains a heading and a list, the list contains its items. That tree has a name, the DOM, short for Document Object Model. You will meet it properly in Chapter 8; for now it is enough to know that what you see on screen is drawn from this tree, not directly from the file.
The browser is also forgiving while it reads. If a tag is left unclosed or something is out of place, it guesses what you meant and builds a tree anyway. That is kind to visitors, and it also means a mistake in your HTML may never show an error. Chapter 2 shows how to find those mistakes.
Why Is One Page So Many Requests?
An HTML file mentions other files: a stylesheet that says how the page looks, scripts that make it do things, images, fonts. Each of those is a separate request to a server, and each arrives on its own schedule. A typical page on the web is built from dozens of files, not one.
You can watch this happen. The browser's developer tools, which topic 6 of Chapter 2 introduces, have a Network panel that lists every file a page asked for, how big it was and how long it took. Open it on any news site and reload: the list scrolls for a while.
This is why a single missing file has such visible effects. If the stylesheet fails to arrive, the page still appears, but as plain black text on a white background, because the part that described its look never came.
How Does the Tree Become Pixels?
Once the browser has the tree and the styles, it works out which style rules apply to which parts. Then it does layout: it calculates the size and position of every box on the page for the current width of the window. Finally it paints, turning those boxes into the coloured pixels you see.
None of this happens only once. Make the window narrower, and layout runs again because every box now has less room. Hover over a link that changes colour, and the browser repaints that part. A lot of what makes a page feel fast or slow is how much of this work it forces the browser to repeat.
Where Does JavaScript Fit In?
Scripts join the sequence in two places. First, while the browser is reading the HTML, a script can make it stop and wait until the script has downloaded and run. That pause is why Chapter 6 teaches you to load scripts in a way that does not block the reading.
Second, after the page is built, a script can change the tree: add a paragraph, hide a panel, fill a list with new data. The browser then lays out and paints again. This is also why the page in front of you can differ from the file the server sent. The file is where the page started; the tree is what it is now.
So far: the server sends HTML, the browser builds a tree from it, fetches every other file it mentions, lays everything out and paints it, and scripts may change the tree at any point. Every chapter of this book works on one part of that sequence.
- "A web page is one file." A typical page is dozens of files, each fetched separately. If the stylesheet is missing, the page still appears, unstyled.
- "The browser just shows the file." It builds its own model of the page from the file, the DOM, and draws that. Scripts change the model, not the file.
- "Frontend code runs on the server." The server only sends the files. HTML, CSS and JavaScript all run in the visitor's browser, on the visitor's device.
- Almost every frontend problem is one step of this sequence going wrong, and knowing the steps tells you where to look.
- It explains why the visitor's device and connection, not your computer, decide how fast your page feels.
Knowledge Check
The browser receives an HTML file that mentions a stylesheet and two images. What happens to those three files?
- They arrive inside the HTML file itself, as part of it
- The browser requests each of them separately
- They load only after the visitor clicks on the page
- The server combines them into one before sending
What is the DOM?
- The HTML file exactly as it is stored on the server
- A list of every style rule that applies to the page
- The list of files shown in the Network panel
- The tree of the page's parts the browser builds
A page's stylesheet fails to load. What does the visitor most likely see?
- The content, as plain text on a plain background
- A completely blank page with nothing on it
- An error message instead of the page content
- The page styled the way it looked the last time
Why can the page you see differ from the HTML file the server sent?
- The browser downloads a newer file every few seconds
- Scripts can change the tree after it is built
- The browser saves its own edits back to the server
- Layout rewrites the HTML to fit the window width
You got correct