Web Development: What Happens Between a Tap and a Page

You tap a link on your phone and a page appears in about a second. In that second, your phone looked up a name in a global directory, opened a connection to a computer that may be on another continent, agreed on a secret key with it, asked for a document, received text, then received more files that the text pointed to, turned the text into a tree, worked out the size of every box on that tree, and painted them. Nothing about it feels like work. A person who has built websites sees the seams everywhere: why one site is instant and another stutters, why a layout breaks at a certain width, why a button works with a mouse but not the keyboard.

The web is also younger than it feels. Tim Berners-Lee wrote his proposal for it at CERN on 12 March 1989. On 6 August 1991 he posted a short summary of the project to a newsgroup and invited collaborators. On 30 April 1993 CERN announced that the web would be free for anyone to use and put its code into the public domain. Everything below grew out of three small inventions of his: an address format (the URL), a request protocol (HTTP) and a document format (HTML).

A URL starts a conversation of round trips

Take https://example.org/cats. Read it left to right. https says how to talk (HTTP, wrapped in encryption). example.org says to whom. /cats says what to ask for. Your browser does not know where example.org is, so the first step is a DNS lookup: a question to a nearby resolver that answers with a numeric address. Then come the handshakes, and here is the idea a graduate keeps: each handshake costs a round trip, and a round trip cannot be faster than light.

Light in optical fibre travels at about two thirds of its speed in a vacuum, roughly 200,000 km per second, or 200 km per millisecond. A round trip over a distance d therefore takes at least 2d / 200 milliseconds. For 10,000 km that is 100 ms, before a single byte of content, and real routes are never straight lines.

Now count round trips. Opening a TCP connection takes one (SYN, then SYN-ACK; the client's reply carries on to the next step). Encryption with TLS 1.2 takes two more. TLS 1.3, standardised in 2018 (RFC 8446), takes one. Only then can the HTTP request go out, and its answer takes one more round trip plus the time the server spends thinking. HTTP/3, standardised in 2022 (RFC 9114), runs over QUIC (RFC 9000, 2021), which merges the connection and the encryption into a single round trip. Same page, fewer conversations.

Without JavaScript: at 10,000 km (a 100 ms round trip), 50 ms server time and no DNS cache, the first byte arrives after 480 ms with TCP and TLS 1.2, 380 ms with TCP and TLS 1.3, and 280 ms with QUIC.

This is why distance matters more than people expect, why content delivery networks put copies of your files near the user, and why "reuse the connection" is a first rule of performance. It is also why a chatty page that makes twenty separate trips feels worse than one big file.

HTML is a tree, not a page

The server's reply is text. The browser parses that text into a tree of elements called the DOM (Document Object Model): a ul contains li elements, a body contains a ul. Everything else the browser does, styling, layout, painting, clicking, reading aloud, works on that tree, not on the text. HTML and the DOM are now maintained by the WHATWG as "living standards", an arrangement the W3C agreed to in 2019.

The idea that stays is that tags carry meaning, not looks. A button is not just something that looks pressable. The browser gives it keyboard focus, lets you press it with Space or Enter, and tells a screen reader it is a button. A div styled to look the same gets none of that. Headings (h1, h2) let a blind user jump around a page the way a sighted user scans it. The cheapest accessibility a developer ever gets is to pick the right element.

Without JavaScript: in the starting tree, the "Save" element is a real button and "Cancel" is a div styled to look like one. Both look clickable; the browser lets Tab reach only the first.

Try deleting the "Save" button and adding a button instead of the div. The readout changes because the browser's own answer changes: tabIndex is 0 for a button and -1 for a plain div. You can repair a div with extra attributes and scripts, which is what many sites do, but the standard element already did the work.

CSS: every element is a box, and layout is negotiation

CSS was first proposed by Håkon Wium Lie on 10 October 1994, and the first level became a W3C recommendation in December 1996. Its central picture has not changed: every element is a rectangular box with four layers. From inside out: the content, the padding around it, the border, and the margin that keeps neighbours away.

The part that trips up every beginner is what "width: 160px" means. By default (box-sizing: content-box) it sizes the content only, and the padding and border are added outside it. With box-sizing: border-box the width includes them. Most modern stylesheets switch everything to border-box, because it matches how people think about a box.

Without JavaScript: with width 160, padding 20 and border 6, a content-box element is 212 px wide (160 + 40 + 12) and a border-box element is 160 px wide with a 108 px content area.

Boxes are then arranged by layout, and modern layout is a negotiation between the children and the container. In flexbox (one dimension) the container hands out spare space or takes it back by shrinking items. In grid (two dimensions) you describe tracks and the browser places items in them. Grid shipped in the major browsers in March 2017 (Chrome 57 on 9 March), and one line, repeat(auto-fit, minmax(70px, 1fr)), gives you "as many columns of at least 70 px as fit". That one rule is the core of responsive design: you do not know the width of the screen, so you describe the rules and let the browser decide.

Without JavaScript: in a 260 px container with an 8 px gap, a wrapping layout of 70 px items fits 3 per row, because 3 × 70 + 2 × 8 = 226 fits and 4 × 70 + 3 × 8 = 304 does not. A non-wrapping flex row of 6 items squeezes each to about 37 px.

JavaScript: one thread, one queue, and the order things run

JavaScript was written by Brendan Eich at Netscape and released in December 1995; its standardised form, ECMAScript, appeared in June 1997. It is the part of the page that can change the DOM after the page has loaded: react to a tap, fetch new data, redraw a list.

The idea a graduate keeps is the event loop. The browser runs your JavaScript on one main thread, the same thread that handles taps, scrolling and painting. Nothing runs "at the same time" as your code on that thread. Instead there are queues. Code runs to the end of its current job. Then the browser runs all waiting promise callbacks (microtasks). Only then does it take the next waiting timer or event (a task), and then it may paint. A timer set for 0 ms does not mean "now": it means "after the current code and the promises are finished".

Without JavaScript: the three puzzles print A B C; A B C D; and 1, 2, promise, timer 0 ms, timer 10 ms.

The consequence is practical. A function that takes 120 ms keeps the page from responding or painting for 120 ms, because there is only one thread. Phone screens refresh 60 or 120 times a second, so the browser has about 16.7 ms or 8.3 ms to do all its work per frame.

Without JavaScript: a 120 ms task at 60 Hz (a 16.7 ms frame) blocks about 7 frames; at 120 Hz (8.3 ms) about 14.

That is why you fetch data without waiting (asynchronously), split heavy work, and move it off the main thread to a worker. It is also why "the page froze" is almost always one long task, not a slow network.

APIs and JSON: the front end asks, the back end answers

The front end is what runs in the user's browser: HTML, CSS, JavaScript. The back end runs on a server you control: it holds the data, checks who is allowed to do what, and talks to the database. They meet at an API, usually a set of addresses plus verbs. The browser sends GET /tasks and the server answers with a status code and a body, most often JSON, a plain-text format of objects, arrays, strings, numbers and booleans.

The vocabulary is small and worth knowing cold, because it is the same on every site. Verbs say what you want (GET reads, POST creates, DELETE removes). Status codes say what happened, in families: 2xx worked, 3xx look elsewhere, 4xx your request was wrong, 5xx the server failed. The meanings are set out in RFC 9110 (2022): 200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized (really "not logged in"), 404 Not Found, 422 Unprocessable Content.

Without JavaScript: GET /tasks returns 200 with a list; GET /tasks/99 returns 404; POST with a valid title returns 201; POST with invalid JSON returns 400; DELETE without a token returns 401.

JSON is strict, and that strictness is a feature: double quotes only, no trailing commas, no comments. A parser that accepts anything would hide bugs until later. Notice also who decides what: the front end can ask for anything, but the back end must check every request, because anyone can send a request by hand. That is the seed of Computer Security (34/33).

Fast and for everyone: speed, accessibility and shipping

Two qualities separate a site people like from one they leave. The first is speed. Google's Core Web Vitals, published at web.dev, give targets for the 75th percentile of real page loads: the largest piece of content painted within 2.5 seconds (LCP), responses to taps within 200 milliseconds (INP), and a layout shift score of 0.1 or less (CLS). Most of the cost is the same two things you have already seen: round trips and bytes.

Without JavaScript: on a 20 Mbps link with a 50 ms round trip, a 2,000 KB page with three dependent steps takes about 0.3 s of waiting for round trips and 0.8 s downloading, about 1.1 s in this model.

The second quality is accessibility: the page works for people using screen readers, keyboards, switches, magnification or just a phone in sunlight. The standard is the W3C's Web Content Accessibility Guidelines (WCAG 2.2). The WebAIM Million survey, which scans the home pages of the top million sites with an automated tool, found in February 2026 that 95.9% had at least one detectable WCAG failure, up from 94.8% the year before, with about 56 errors per page. The most common was low-contrast text, on 83.9% of pages. Automated tools catch only some problems, so the real number is higher. The next piece, UI & UX Design (36/75), computes contrast live.

Finally, shipping. A site can be a folder of files copied to a content delivery network (static hosting), or a program running on a server that builds each page on demand. In both cases the modern routine is the same: commit to version control, an automated build and test, then publish. That pipeline is the subject of Shipping Software (36/76).

What a graduate just sees

• Every new connection costs round trips, and distance puts a floor under each one. Fewer trips beat faster servers.
• The page is a tree. Choose the element for what it is (button, heading, list), and keyboard and screen-reader support come with it.
• Every element is a box: content, padding, border, margin. Know which one your width counts.
• You do not control the screen. Write rules ("at least 70 px each, as many as fit"), not pixel positions.
• JavaScript has one main thread and a queue. Promises run before timers, and a long task freezes everything.
• Status codes are a shared language: 2xx worked, 4xx you erred, 5xx we erred.
• Never trust the front end. Anything the browser sends can be forged, so the server checks everything.
• Speed and accessibility are not polish added at the end. Both are mostly decided by structure and by how much you send.

Where it shows up next

• Shipping Software: Testing, DevOps & the Cloud (36/76): the pipeline that builds, tests and publishes the site, and the monitoring that tells you when it breaks.
• UI & UX Design (36/75): the layout rules, hierarchy and contrast that decide whether the boxes you just placed are usable.
• Databases (34/28) and Computer Security (34/33): behind every API is a data store and a list of ways to attack it.
• In the world: the checkout flow of any shop, a bank's web app, a government form that has to work on a ten-year-old phone, a documentation site that is only static files.

If you want to go deeper

• 📘 Textbooks. David Flanagan, JavaScript: The Definitive Guide (O'Reilly, 7th edition, 2020), the long standard reference for the language; and Ilya Grigorik, High Performance Browser Networking (O'Reilly, 2013), free online at hpbn.co, which goes deep on the round trips and protocols in the first section.
• 📘 Gentler. Marijn Haverbeke, Eloquent JavaScript, free online at eloquentjavascript.net, and the MDN Learn web development pathway, which is the reference most working developers keep open.
• 🌐 Free courses. CS50's Web Programming with Python and JavaScript (Harvard, free to audit), and Full Stack Open from the University of Helsinki, a free course that builds a complete app.