Browser Fundamentals
Browser fundamentals covers how web browsers turn URLs into rendered pages: DNS resolution, HTTP requests, HTML parsing, the DOM, CSS layout, JavaScript execution, and the rendering pipeline that produces pixels on screen. Understanding this chain explains why pages load and behave the way they do.
itWeb development | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Browser Fundamentals
A browser is the machinery that turns a URL into an interactive document. It is not a polite pipe that carries a page from a server to a screen. It negotiates a request, remembers some things, runs code, applies rules, and manufactures pixels. This explains why one blank rectangle can have an impressively large family tree.
The first anchor is fetch. A navigation and a resource request begin with a URL and request rules. The response might arrive from the network, after redirects, or from the HTTP cache when freshness rules permit reuse. A reload therefore changes the story less reliably than folklore would like. Record the final URL and response before accusing the page of anything dramatic.
The second anchor is the pair of live models: the DOM, which represents document structure, and the CSSOM, which represents style rules. Together they feed style, layout, paint, and compositing. A node can be present in the DOM yet absent from the screen because its computed style or geometry defeated its ambitions. This is not the browser being mysterious. It is the browser being several departments with limited lunch breaks.
The third anchor is the event loop. JavaScript callbacks, browser tasks, Promise microtasks, and rendering opportunities share time. A long callback can leave correct code staring heroically at an unresponsive page. The useful question is not did JavaScript run, but what work occupied the path before the next input or paint?
Client state adds another drawer to the cabinet. Cookies, Web Storage, IndexedDB, service workers, and the HTTP cache do different jobs and obey different boundaries. Clearing one drawer does not empty the others. An origin, made from scheme, host, and port, also draws a security boundary; CORS decides whether a response may be exposed to a script, not whether the server received the request.
Read the intro when the pipeline needs a full map. Use the slides for subsystem relationships, then keep the cheatsheet beside developer tools while tracing a real failure. The practice reference gives the evidence order, and the exercise makes a request failure and a rendering failure look distinctly different on purpose. Field Notes covers the habits that prevent a debugging trace from becoming an accidental security incident or a performance fairy tale.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://html.spec.whatwg.org/multipage/
Supports
- HTML defines document structure, loading web pages, web application APIs, event loops, Web Storage, syntax, and rendering
- Navigation fetches a resource and can create a new Document associated with session history
- Event loops coordinate tasks, microtask checkpoints, and rendering opportunities
- Promise reactions are queued as microtasks
- Web Storage exposes localStorage and sessionStorage
- Origin uses scheme, host, and port concepts as a security boundary
- https://dom.spec.whatwg.org/
Supports
- DOM defines node trees and programming interfaces
- EventTarget objects register listeners and receive dispatched events
- Event target and currentTarget identify the dispatch target and the listener invocation target
- Event dispatch can use capture, target, and bubble phases
- https://fetch.spec.whatwg.org/
Supports
- Fetch defines requests, responses, redirects, cache modes, credentials modes, and the JavaScript fetch API
- A response has a status, headers, an optional body, and a URL list
- Fetch can use an HTTP cache or make a network request according to cache mode and response state
- CORS is an HTTP-header protocol that lets responses opt into cross-origin sharing
- A successful HTTP status does not by itself make a cross-origin response available to script
- https://url.spec.whatwg.org/
Supports
- The URL Standard defines URL parsing and serialization
- URLs include components such as scheme, host, port, path, query, and fragment
- Browser URL APIs use the standard parsing model
- https://storage.spec.whatwg.org/
Supports
- The Storage Standard defines shared infrastructure used by browser storage APIs
- Storage is organized by storage keys and buckets
- Browser storage is subject to quota and persistence policy
- https://www.rfc-editor.org/rfc/rfc9110.html
Supports
- HTTP uses request and response messages
- Requests include methods and target resources
- Responses include status codes, fields, and representations
- HTTP semantics are shared between clients, servers, and intermediaries
- https://www.rfc-editor.org/rfc/rfc9111.html
Supports
- HTTP caches store responses for reuse
- Freshness determines whether a stored response can be reused without validation
- Stale responses can be validated with the origin server when applicable
- https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/How_browsers_work
Supports
- Browsers parse received HTML and CSS into the DOM and CSSOM
- The critical rendering path includes style, layout, paint, and compositing work
- Parsing and resource retrieval can overlap
- JavaScript can block parsing and rendering work
- https://web-platform-tests.org/
Supports
- Web Platform Tests is a cross-browser test suite for the web platform
- The project provides documentation for running tests and contributing compatibility tests
- https://home.web.cern.ch/science/computing/birth-web/short-history-web
Supports
- The first Web server and browser operated at CERN by the end of 1990
- WWW software including the line-mode browser was released in 1991
- CERN released WorldWideWeb source code on a royalty-free basis on April 30, 1993
- NCSA released the first Mosaic browser version in early 1993
- Tim Berners-Lee founded W3C at MIT in 1994
- https://www.w3.org/Style/CSS20/history.html
Supports
- CSS 1 became a W3C Recommendation in 1996
- https://www.mozilla.org/en-GB/about/history/
Supports
- The Mozilla project began with the 1998 release of Netscape browser-suite source code
- Firefox 1.0 was released in 2004
- https://www.apple.com/newsroom/2003/01/07Apple-Unveils-Safari/
Supports
- Apple unveiled the Safari public beta on January 7, 2003
- https://blogs.windows.com/msedgedev/2015/04/29/introducing-microsoft-edge-the-browser-built-for-windows-10/
Supports
- Microsoft announced Project Spartan's Microsoft Edge name in April 2015
- https://blogs.windows.com/windowsexperience/2020/01/15/new-year-new-browser-the-new-microsoft-edge-is-out-of-preview-and-now-available-for-download/
Supports
- The Chromium-based Microsoft Edge became available for download in January 2020
- https://developer.chrome.com/docs/devtools
Supports
- Chrome DevTools documents browser inspection and debugging tools
- https://learn.microsoft.com/en-us/microsoft-edge/devtools/overview
Supports
- Microsoft Edge DevTools provides tools for inspecting and debugging web experiences
- https://firefox-source-docs.mozilla.org/devtools-user/
Supports
- Firefox documents its developer tools for inspecting and debugging web content
- https://developer.apple.com/safari/tools/
Supports
- Apple documents Safari developer tools for testing and inspecting web experiences
- https://brave.com/
Supports
- Brave presents browser privacy controls including Shields
- https://engineering.fb.com/2016/08/31/web/browserlab-automated-regression-detection-for-the-web/
Supports
- Browser performance measurements vary with cache, browser state, environment, data, and code nondeterminism
- BrowserLab launched a fresh browser instance per trial to keep cache, configuration, and cookies consistent
- BrowserLab used repeated trials and traces to isolate and identify browser performance regressions
- https://engineering.fb.com/2017/01/26/web/this-browser-tweak-saved-60-of-requests-to-facebook/
Supports
- Cache freshness and validators govern reuse and revalidation of browser responses
- Content-addressed asset URLs allow long freshness lifetimes because their contents do not change
- A deployment that changes a cached resource must either accept stale content for its freshness lifetime or change the URL
- https://blog.cloudflare.com/introducing-har-sanitizer-secure-har-sharing/
Supports
- HAR files capture browser request and response details including headers, cookies, payloads, and timings
- Session cookies and tokens in a HAR can expose authenticated sessions when shared
- Sanitizing session-related information before sharing a HAR reduces that exposure
- https://slack.engineering/chrome-tracing-for-fun-and-profit/
Supports
- Chrome tracing can capture browser performance data beyond ordinary JavaScript profiling
- Performance reports vary with hardware, operating system, browser, network, and other running software
