The request path

You search Leboncoin for a second-hand bike in Lyon and copy the link to send to a friend. It looks something like https://www.leboncoin.fr/recherche?text=velo&locations=Lyon, and every part has a job.

https is the scheme: it tells the browser to use an encrypted connection. www.leboncoin.fr is the domain, the site's name. /recherche is the path, the page on that site. Everything after the ? is the query, your search, which the server reads to build the results. Links from newsletters often add utm_ parameters to the query, to tell the marketing team where you came from. Some links also end with a fragment after a #, which points to a spot on the page. The browser keeps the fragment to itself and never sends it to the server.

The domain is the one part the browser can't use as it is. Computers on the internet find each other with numeric addresses, called IP addresses, so the first step is to turn the name into one.

First, the browser asks DNS, the internet's directory, for the IP address that goes with leboncoin.fr. Your internet provider usually answers and remembers the answer for a while. DNS only gives directions: the site itself lives on servers somewhere else.

Next, the browser contacts the server at that address and sets up an encrypted connection. That's the padlock, HTTPS. It scrambles what travels, so nobody on the café Wi-Fi can read it, and the site's certificate proves you're really talking to Leboncoin. The browser asks for the page, and the server sends back an HTML document: the page's structure and its text.

That document lists everything else the page needs: style sheets for the look, scripts for the behaviour, images and fonts. The browser fetches each one, often from other servers. Finally, the scripts ask the servers for live data, such as the latest listings, and the page fills in.

At no point does your browser open Leboncoin's database. It only talks to servers, and the servers decide what to send.

Each of those files is one exchange. The browser sends a request: a method (usually GET to read something, or POST to send a form) and the path it wants. The server sends a response in three parts. The status is a three-digit code saying how it went. The headers are labels about the answer: what kind of file it is, how long the browser may keep it, a cookie to store. The body is the file itself.

The first digit of the status tells you whose problem it is. 200 means it worked. 301 is a redirect: type http://lemonde.fr and the server answers "go to the HTTPS address instead". 404 means the page doesn't exist. 500 means the server itself failed. So when a page loads but one part stays empty, the status of that part's request already tells you which side to look at.

You can watch all of this in the browser's developer tools. The Network panel lists every request with its status and size, and a news site's home page often makes more than a hundred.

The server that answers is often not the company's own. Look up www.lemonde.fr in DNS and the answer points to Fastly, a CDN (content delivery network): a company with servers in many cities, which keep copies of a site's files and send them from somewhere close to each visitor. The British government's site uses the same company. A CDN makes pages arrive faster, survives the traffic spike on election night, and absorbs attacks that try to flood a site with requests. Most of the time, Le Monde's own servers never even see your request.

Your browser keeps copies as well, in its cache. On a first visit it downloads everything. On the next one it reuses the logo, the fonts, the style sheets and many scripts it already has, so the page appears much faster.

Remember this when someone shows you a site running smoothly. The person who built it has everything in their cache. A new customer arriving from a search starts with nothing.

Each step of the path can slow down, and the pattern of a complaint tells you which one. Say a shop's site opens instantly on the office fibre but takes ages on a phone in a TGV. The same server sends the same page in both cases, so a slow server would be slow in both. The difference has to come from what changed: the network, the device, or what the browser had in its cache.

On a weak mobile connection, each request waits much longer for its answer, and a page that needs eighty files pays that wait eighty times. Large images, videos, ads and trackers from other companies all add files and weight. On an older or cheaper phone, the processor is the limit: a page full of JavaScript can take several times longer to run. A bigger server fixes none of this, because the page is what's heavy.

You can check before spending anything. The developer tools can simulate a slow connection, and Lighthouse, a free test built into Chrome, scores a page's speed and lists what slows it down. Fix images first, then scripts, then outside tools.

When a site is slow or down, you rarely open the code yourself. You ask the people who can, and the right questions save days.

Before agreeing to a bigger server or a rebuild, ask where the time goes: is the site slow on every connection, only on mobile data, or only on older phones? Ask for the page's weight in MB and its number of requests on a phone over 4G, and compare them with a lean site such as GOV.UK. Ask which outside scripts the page loads (ads, analytics, chat, the consent banner), what each one is for, and who decided to add it. Ask whether the files come through a CDN.

Finally, ask who tested the site on the kind of phone your customers really carry, on the network they really use. Most of them have a mid-range phone on mobile data, not a new laptop on the office Wi-Fi.