Every website you’ve built in this series has been displayed by a browser — but what actually happens inside it, between receiving HTML and showing a finished page? This guide covers the rendering pipeline, step by step.
Our guide on how websites work covered the request/response cycle. This guide picks up where that left off — what the browser actually does with the HTML, CSS, and JavaScript it receives.
What a Rendering Engine Does
According to MDN’s glossary entry, a rendering engine (also called a layout or browser engine) is the part of a browser that transforms HTML, CSS, and other resources into a visual representation on screen. Different browsers use different engines: Blink (Chrome, Edge), WebKit (Safari), and Gecko (Firefox).
Step One: Building the DOM
According to web.dev’s explanation of how browsers work, the rendering engine starts parsing the HTML document and converting elements into DOM nodes — a tree structure representing the page’s content, the same DOM you’ve been manipulating with JavaScript throughout this series.
Step Two: Building the CSSOM
While parsing HTML, the browser also parses any CSS — from external stylesheets or style elements — building a parallel tree called the CSSOM (CSS Object Model), which describes how each element should be styled.
Step Three: Combining Into a Render Tree
The DOM and CSSOM are combined into a render tree, containing only the visible content along with its computed styles. Elements hidden with display: none exist in the DOM but are excluded from the render tree entirely, since they don’t need to be drawn.
Step Four: Layout and Paint
The browser calculates the exact position and size of every element (layout), then draws pixels to the screen based on those calculations (paint). According to MDN’s performance guide to how browsers work, rendering steps include style, layout, paint, and in some cases compositing — and browsers try to display content as soon as possible, rendering progressively rather than waiting for the entire page to finish downloading.
Where JavaScript Fits In
While CSS is being parsed, JavaScript files download in parallel. Once JavaScript runs, it can modify the DOM directly — adding, removing, or changing elements — which triggers the browser to redo parts of the layout and paint process. This is exactly why every interactive behavior covered in our JavaScript guides ultimately routes back through this same rendering pipeline.
Why This Matters for Performance
Understanding this pipeline explains a genuinely practical fact: JavaScript that repeatedly changes the DOM in a tight loop can force the browser to recalculate layout and repaint over and over, which is why heavy, frequent DOM manipulation can make a page feel sluggish. As a beginner, you don’t need to optimize for this immediately, but it’s useful context for why “why is my page slow” questions often trace back to excessive DOM changes.
Browsers Are Single-Threaded (Mostly)
Browsers are largely single-threaded, meaning they execute one task at a time on the main thread before moving to the next. This is why a JavaScript function that takes too long to run can freeze an entire page — scrolling stops, buttons stop responding — since the same thread handling your script is also responsible for rendering and reacting to user input. Modern browsers offer web workers to run JavaScript on a separate thread for genuinely heavy computations, but for typical beginner projects, keeping functions fast and avoiding long-running loops on the main thread is enough to keep pages feeling responsive.
Beyond the Rendering Engine: What Else a Browser Does
The rendering engine is only one piece of a browser’s architecture. A separate networking component handles HTTP requests (the same request/response cycle covered in our HTTP and HTTPS guide), a JavaScript engine parses and executes scripts, and a data storage layer manages cookies and other locally saved data like localStorage. The browser engine itself acts as the bridge connecting the user interface — tabs, address bar, back button — to all of these underlying components.
Progressive Rendering: Why Pages Appear Gradually
Rather than waiting for an entire page to fully download and parse before showing anything, browsers render progressively — displaying content as soon as enough of it is available, then continuing to add more as additional resources arrive. This is why a slow-loading page often shows text before images, or shows a basic layout before full styling kicks in; the browser is deliberately prioritizing showing something useful as early as possible, rather than leaving a blank screen until every single resource has finished loading.
Reflow: Why Changing Layout Is Expensive
When JavaScript changes something that affects an element’s size or position — like altering its width or adding a new sibling element — the browser has to recalculate layout for potentially many other elements, a process sometimes called reflow. This is more computationally expensive than simply repainting colors, which is part of why frequent layout-triggering changes (especially inside loops) can visibly slow a page down, while changes that only affect appearance (like color) are comparatively cheap.
Common Questions
Why do different browsers sometimes render the same page slightly differently? Each browser uses its own rendering engine with its own implementation details, so subtle differences in spacing, fonts, or edge-case CSS behavior can occur — part of why cross-browser testing matters for professional projects.
Does the browser wait for all CSS before showing anything? Generally yes for the CSSOM specifically, since CSS can affect layout in ways that would cause visible content to jump around if applied incrementally — this is part of why render-blocking CSS is a real performance consideration for larger, more complex pages.
Why do browser developer tools have a “Performance” or “Rendering” tab? These tools let developers watch the exact steps covered in this guide happen in real time — parsing, layout, paint — which is genuinely useful for diagnosing why a specific page feels slow, well beyond what a beginner typically needs but worth knowing exists as your projects grow more complex.
Why Modern Browsers Run Each Tab Separately
Modern browsers like Chrome run each tab in its own separate process, rather than one shared process for the entire browser. This has a genuinely practical benefit: if one tab crashes — because of a runaway script or a memory issue — it typically doesn’t take down every other open tab with it. This process isolation also improves security, since it’s harder for content in one tab to interfere with another tab’s data or behavior. As a beginner, you won’t configure this directly, but it explains why closing one misbehaving tab is usually enough to recover, rather than needing to restart the entire browser.
Quick-Reference Guide
- Rendering engine — the browser component that turns HTML/CSS into a visible page.
- DOM — tree representation of HTML content.
- CSSOM — tree representation of computed styles.
- Render tree — DOM + CSSOM combined, visible elements only.
- Layout and paint — calculating positions, then drawing pixels to screen.
Conclusion
Every page you’ve built throughout this series passes through this same pipeline — DOM, CSSOM, render tree, layout, paint — happening in a fraction of a second every time a page loads or updates. Understanding it connects HTML, CSS, and JavaScript into one coherent picture of what a browser is actually doing behind the scenes.
In the next guide in this series, we’ll cover web hosting and domains, completing the picture of how a project goes from your computer to a live, publicly accessible website.
Explore More Web Development Guides →
When not writing, Alex is probably debugging someone else’s code.