openskills.info

Browser Fundamentals

itWeb development

Browser Fundamentals

A browser turns a URL into an interactive document. It fetches resources, parses markup and styles, runs JavaScript, draws pixels, stores site data, and enforces boundaries between sites.

That short description hides a pipeline. Learning the pipeline gives you a reliable way to diagnose blank pages, stale data, slow interactions, blocked requests, and layout surprises.

The browser as a platform

A browser is more than a document viewer. It is a user agent that implements a collection of web standards. Those standards define shared behavior for URLs, HTTP requests, HTML documents, the Document Object Model, events, storage, and many other APIs.

You do not need to memorize every standard. You need a map of the major subsystems and the boundaries between them.

URL and navigation
       ↓
fetch request → HTTP response → bytes
       ↓
HTML parser → DOM tree
CSS parser  → CSSOM
       ↓
style → layout → paint → compositing
       ↕
JavaScript, events, and Web APIs
       ↕
storage, cache, and security policies

Each arrow is a useful debugging boundary. A page can fail before the response arrives, during parsing, while a script runs, or when the browser paints the result.

Navigation begins with a URL

A URL identifies a resource and tells the browser how to address it. A typical HTTPS URL contains a scheme, host, optional port, path, query, and fragment.

https://shop.example:443/items?id=7#reviews
└─scheme  └─host       └─path └query └fragment

The URL Standard defines how browsers parse and serialize URLs. The origin used by many security checks is based on the scheme, host, and port.

When you navigate, the browser creates or updates a session history entry. It fetches the target and creates a new Document for the response when navigation succeeds. Redirects can change the final URL before the document is created.

Fetch connects documents to resources

Fetch is the shared browser process for obtaining resources. Navigation, images, stylesheets, scripts, fonts, and the JavaScript fetch() API all depend on fetch behavior.

A request carries a method, URL, headers, mode, credentials policy, cache mode, and other settings. A response carries a status, headers, and an optional body. HTTP defines the meaning of these messages. Fetch defines how the browser applies web-platform policies around them.

The browser may satisfy a request from its HTTP cache. A cached response is not automatically wrong or old. Freshness rules and validation determine whether the browser can reuse it or must contact the server.

Parsing builds live models

The HTML parser turns incoming bytes into nodes in the Document Object Model, or DOM. The DOM is a tree and an API. JavaScript can inspect and change it after parsing.

CSS is parsed into a CSS Object Model, or CSSOM. The browser combines document structure with applicable style rules to determine what needs to appear.

Parsing and resource loading can overlap. The browser does not always wait for every byte before doing useful work. Script and stylesheet placement still matters because some resources can delay parsing or rendering.

Rendering turns models into pixels

Rendering is commonly explained as four connected stages:

  1. Style determines the computed styles that apply to elements.
  2. Layout calculates geometry, such as sizes and positions.
  3. Paint records how visible parts should be drawn.
  4. Compositing assembles painted layers for display.

This model is useful, but it is not a promise that every engine implements identical internal stages. Web standards define observable behavior. Browser engines remain free to optimize their internals.

A DOM change does not always cause every stage to run again. Changing text can affect layout and paint. Changing a transform may be handled later in the pipeline. Measure behavior in developer tools instead of assuming that one CSS property always has one fixed cost.

JavaScript shares time through an event loop

JavaScript execution is organized around agents and event loops. An event loop selects tasks, runs them, performs microtask checkpoints, and gives the browser opportunities to render.

An event listener does not run at the instant an input device changes. The browser dispatches an event, and registered callbacks run according to the event and event-loop rules. Promise reactions use the microtask queue and run before the event loop moves to a later task.

Long-running JavaScript delays other work on the same event loop. The page can appear frozen even while the code is computing correctly. Split expensive work, reduce it, or move suitable computation to a worker.

Storage is separate from the network cache

Browsers expose several storage mechanisms. Cookies participate in HTTP requests under their rules. Web Storage provides localStorage and sessionStorage. IndexedDB stores structured data. The Storage Standard defines shared storage infrastructure and quota concepts used by storage APIs.

The HTTP cache has a different purpose. It reuses network responses according to HTTP caching rules. Clearing one kind of stored data does not imply that every other kind is cleared.

Storage is subject to browser policy, user settings, origin boundaries, and quotas. Treat it as managed client state, not permanent disk space.

The origin is a security boundary

Browsers routinely load resources from several origins, but scripts do not receive unrestricted access to them. The same-origin policy restricts interactions between documents or scripts from different origins.

Cross-Origin Resource Sharing, or CORS, lets a server opt into sharing selected responses with another origin. CORS controls whether browser script can access a response. It is not an authentication system, and it does not stop a server from receiving a request.

Browser security also depends on secure transport, content restrictions, sandboxing, permissions, and careful application code. The origin model is the foundation, not the whole building.

Developer tools show the boundaries

Use browser developer tools to test the pipeline one boundary at a time:

  • Network: Was a request sent? Which URL, status, headers, and timing did it use?
  • Elements: Which DOM nodes and computed styles exist now?
  • Console: Which exceptions, warnings, and logged values occurred?
  • Sources: Which script ran, and where did execution pause?
  • Performance: Which tasks, style work, layout, and paint consumed time?
  • Storage or Application: Which client-side data and service workers exist?

Start from evidence. A red console message cannot explain a request that never started, and a successful status cannot prove that script was allowed to read the response.

Where this course stops

This course gives you the browser mental model. It does not teach HTML authoring, CSS layout, JavaScript syntax, HTTP administration, accessibility testing, performance optimization, or web security in depth. Those are separate skills.

Your next step is to choose one layer, inspect it in developer tools, and then study its standard or focused course.

Relevant careers