Ijeoma Balogun's bakery site in Leeds takes six seconds to show its opening hours on a phone. The server answers in 90 milliseconds. Every one of the remaining seconds is spent after the answer arrived, doing things the server has no say in, and that split is the first thing this topic is for.
The web is two machines and a contract between them. Almost every question filed here is really a question about which side of that contract a problem is on, and the answer is usually visible in a single panel that most people building sites have never opened.
What actually happens between the tap and the text
A phone asked for a page. It found the address, opened a connection, secured it, sent one line of request, and got back a file of markup. That file is not the page. It is a list of instructions naming everything else the page needs, and the browser makes one request for the HTML and one for every asset it names. Ijeoma's page names 34 of them: a stylesheet, two fonts, a script for the map, and thirty photographs of bread.
This is why the server timing and the page timing are different numbers with different owners. Time to First Byte is the server; Largest Contentful Paint is everything after. Ijeoma's Time to First Byte is 90 milliseconds and it is excellent. Her Largest Contentful Paint is 5.9 seconds, and no amount of work on the server will move it, because the server has already finished.
The one that stops the paint
Of those 34 requests, most can arrive whenever they like. Two cannot. Render blocking: a stylesheet in the head stops the page painting until it arrives. The browser will not draw text it might have to redraw in a different font and size, so it waits, and a stylesheet on a slow connection holds a blank white screen for as long as it takes. Ijeoma's stylesheet is one file of 180 kilobytes containing the styles for every page on the site, and the opening hours page uses about a tenth of it.
The fix is not a framework. It is putting the rules that style the first screen directly in the markup and letting the rest arrive late, which turns a blank six seconds into text at 400 milliseconds and photographs that fill in behind it. That trade, and the ones next to it, are what why a page feels slow, and what actually fixes it is made of.
Redirects, and the one that is remembered
Ijeoma's site had a second problem underneath the first. The old address for the page still existed and sent visitors on to the new one, and every phone that had ever been sent that way was making two round trips instead of one. The status code decides how long that costs. A 301 is permanent and a 302 is not, and browsers cache the 301. A 301 is paid once per browser and then disappears. A 302 is paid on every single visit, forever, because the browser has been told the arrangement is temporary and dutifully checks again.
Her old address was returning a 302 that somebody set in 2021 as a test. Changing one number in one line of server configuration removed a round trip from every returning visitor, which is the kind of repair that is invisible in the code and obvious in the numbers.
The same instinct covers the thirty photographs. A browser will keep a file it has already downloaded if the server tells it how long it may, and the header that says so is one line. Ijeoma's photographs carried no such line, so a customer checking the hours twice in one week downloaded the same loaves twice. This is why a site feels fast to the person who built it: their browser has everything already, and the measurement they should be reading is the first visit rather than their own.
The structure
What has to hold before the layer above it means anything
Read downward from the apex. Each layer rests on the one beneath, and a fault falls through to everything above it.
- The component frameworkWhere most people start, and the layer with the shortest memory
- The stylesLayout and appearance, and the largest subject on the topic
- The markupStructure, meaning, and whether a screen reader can read any of it
- The contract over the wireRequests, status codes and caching, which the three above all inherit
It says nothing about how much code each layer is. The bottom two are the smallest to write and the most expensive to get wrong, because everything above them assumes they were done.
The order to learn it in
The order that works is the order the browser itself uses, and it is the one place in programming, from the first variable to a deployed system where the machine's sequence and the syllabus agree. the structure under every page comes first, because everything else is attached to it and because a document that is structured correctly is already accessible, already indexable and already legible without a single style. Then how a page is laid out and how it looks, which is the largest single subject on this topic and the one most often skipped by people who go straight to components.
Taken backwards, the failure is specific and extremely common: somebody learns a component framework first, can build an interface, and cannot say what an element is or why the page has no headings. They are productive and they are building something a screen reader cannot read, and neither the framework nor the tutorial will mention it.
Where people stall
The stall on this topic is the back end, and it arrives about four months in. Everything up to that point has been files that a browser opens. Then a form has to remember something, and suddenly there is a server, a database, a session, a deployment and an environment variable, and none of those are the subject they thought they were learning. The half of this the visitor never sees, in the half of the web the visitor never sees, is a genuinely different discipline wearing the same job title, and treating it as more of the same is what makes the fourth month feel like failure.
What to open, in 2026
The Network panel in a browser's developer tools is the single most useful thing on this page. It lists every one of those 34 requests, in order, with what blocked what, and it replaced the practice of guessing which file was slow and deleting things until the page got faster. It is free and it is already installed.
Lighthouse, in the same panel, gives the numbers a name and a target, and it is the tool that turned page speed from an opinion into a measurement somebody can be held to. Its scores are a summary rather than a diagnosis: it tells Ijeoma her Largest Contentful Paint is 5.9 seconds and it does not tell her that the cause is one stylesheet.
What none of this covers is what happens when the two machines are not a browser and a server at all but two programs with no person waiting, which is a different contract with different rules and is the subject of programs talking to programs.