[5.1.5] How web pages are retrieved

How a Web Page Is Located, Retrieved and Displayed

From typing a URL to seeing a page

When you type a web address into a browser and press Enter, a lot happens very quickly. Your web browser must find the correct IP address for the server using DNS (Domain Name System), connect to that server across the internet, request the page from the web server using HTTP or HTTPS, download HTML along with any images, style sheets and scripts, and then render everything on your screen. Understanding each stage helps you explain errors, improve performance and stay safe online.

This page explains the key steps and offers realistic scenarios so you can compare what happens in different cases, such as cached DNS vs fresh lookup, successful fetch vs redirect or error, and fast, simple pages vs complex ones that rely on many resources.

Step 1: Interpreting the URL

What the browser reads from the address

A URL (Uniform Resource Locator) tells the browser how to fetch something (scheme like http or https), where to fetch it from (host name like www.example.org), and what to fetch (path like /index.html, plus optional query and fragment). The browser first checks whether the URL makes sense and whether you have permission to access it (for example, a school filter may block certain domains).

https://www.example.org/ uses the HTTPS scheme (secure HTTP), the host www.example.org, and the root path /. The default port for HTTPS (443) is assumed and does not need to be written.

https://shop.example.org/search?category=books&sort=price#top includes a path /search, a query string with key–value pairs (category, sort) used by the server, and a fragment #top which the browser uses to jump to a section after the page loads.

http://intranet.school.local:8080/news/today specifies HTTP (not encrypted), a local host name and a custom port (8080). Schools and organisations sometimes use non-default ports for internal tools.

Step 2: DNS lookup to find the IP address

Turning a domain name into a network location

Computers communicate using numeric IP addresses. DNS translates a human-friendly name (like www.example.org) into an IP address (for example 93.184.216.34 or an IPv6 address). Your device asks a DNS resolver (often provided by your school or internet provider) to look up the address. DNS results are cached for a short time to reduce delay and internet traffic.

Your device or local resolver already knows the IP address because it was looked up recently. The browser proceeds immediately to connect. This reduces page load time.

The resolver contacts authoritative DNS servers step by step to obtain the answer and then returns the IP address to your device. The result is stored in cache for future requests for a limited time (the TTL – time to live).

If DNS cannot find a valid record or there is a network issue, the browser cannot reach the server. You might see messages like “Server not found.” Checking spelling, network connectivity and DNS settings usually resolves this.

Step 3: Connecting and requesting the page (HTTP/HTTPS)

From TCP connection to server response

With the IP address known, the browser opens a connection to the web server. For HTTPS, the browser and server perform a TLS handshake to create an encrypted channel. The browser then sends an HTTP request (often a GET) for the path in the URL. The server responds with a status code and the requested content, plus headers that provide extra information such as content type and cache rules.

The server returns 200 OK with the main HTML document. Response headers might include Content-Type: text/html and caching instructions. The browser begins parsing the HTML immediately.

The server replies with 301 Moved Permanently or 302 Found and a new URL in the Location header (for example, redirecting from http to https). The browser automatically follows the redirect to fetch the final page.

404 Not Found means the resource does not exist at that path. 500 Internal Server Error indicates a problem on the web server. These codes help you decide whether the issue is your request or the site itself.

Step 4: Downloading additional resources

HTML is just the start

The HTML page often references other files: CSS style sheets, JavaScript scripts, images, fonts and videos. As the browser parses HTML, it discovers these references and issues more HTTP/HTTPS requests for each one, sometimes to different hosts (for example, a content delivery network). To improve speed, the browser downloads several resources in parallel when allowed.

On a repeat visit, the browser may already have images and scripts stored locally due to caching. It checks whether the cached copies are still valid using headers like ETag or Last-Modified. Valid cache entries save time and bandwidth.

On the first visit everything must be downloaded. Servers often compress text assets using gzip or brotli to reduce size. This speeds up delivery over slower connections.

A Content Delivery Network (CDN) stores copies of files in multiple locations worldwide. The browser is directed to a nearby server, reducing latency and improving reliability if one location has problems.

Step 5: Rendering the page

From HTML to pixels

The browser builds a DOM (Document Object Model) from the HTML and a CSSOM from the style sheets. It combines these to calculate layout, then paints elements to the screen. Some scripts can block rendering until they load or run, so developers often defer non-essential scripts to improve performance.

A page with basic HTML and one small style sheet renders very quickly: the browser parses, computes layout and paints with minimal delay.

If a page includes many large scripts, the browser may pause rendering while the files download and execute. Developers use techniques such as defer or async loading to avoid blocking the first paint.

When an HTTPS page tries to load an HTTP resource, the browser may block it as mixed content to protect security. This can leave missing images or features until the site is fixed to use HTTPS everywhere.

Putting it together: end-to-end flow

Browser reads the URL and checks for cached DNS and cached content.
If needed, DNS resolves the host name to an IP address.
Browser opens a connection to the IP and performs a TLS handshake for HTTPS.
Browser sends an HTTP request; server replies with a status code and content.
Browser parses HTML, discovers linked resources, and requests them (using cache where possible).
Browser builds the DOM and CSSOM, runs scripts as required, lays out the page and paints it to the screen.
Further user actions (clicks, scrolling, form submissions) may trigger new requests or dynamic updates.

Summary of key terminology

Term	Short definition
Browser	Client application that requests, renders and secures web content.
URL	Address that specifies the scheme, host, path and optional data to locate a resource.
DNS	System that translates domain names into IP addresses.
IP address	Numeric address used to route data to the correct device on a network.
Web server	Software/service that listens for HTTP/HTTPS requests and responds with resources.
HTTP/HTTPS	Protocols for transferring web data; HTTPS adds encryption and authentication via TLS.
HTML	Markup language that defines the structure and content of web pages.
Cache	Stored copies of resources used to speed up future requests.
CDN	Network of servers that deliver content from locations closer to users.
DOM/CSSOM	In-memory representations of page structure and styles used for layout and rendering.

Key Takeaways

URLs tell the browser how, where and what to request; DNS translates names into IP addresses so the server can be reached.
Web servers respond using HTTP/HTTPS with status codes and headers; HTTPS adds encryption and authentication.
Browsers parse HTML, fetch linked resources, build the DOM/CSSOM and render the page to the screen.
Caching, compression and CDNs reduce load times by avoiding unnecessary downloads and shortening network distance.
Errors like 404 and 500 indicate whether the problem is with the requested path or the server; DNS failures prevent reaching the server at all.