Rendering a web page – step by step
Have you ever thought about what happens when you surf the web? It’s not as simple as it seems:
- You type an URL into address bar in your preferred browser.
- The browser parses the URL to find the protocol, host, port, and path.
- It forms a HTTP request (that was most likely the protocol)
- To reach the host, it first needs to translate the human readable host into an IP number, and it does this by doing a DNS lookup on the host
- Then a socket needs to be opened from the user’s computer to that IP number, on the port specified (most often port 80)
- When a connection is open, the HTTP request is sent to the host
- The host forwards the request to the server software (most often Apache) configured to listen on the specified port
- The server inspects the request (most often only the path), and launches the server plugin needed to handle the request (corresponding to the server language you use, PHP, Java, .NET, Python?)
- The plugin gets access to the full request, and starts to prepare a HTTP response.
- To construct the response a database is (most likely) accessed. A database search is made, based on parameters in the path (or data) of the request
- Data from the database, together with other information the plugin decides to add, is combined into a long string of text (probably HTML).
- The plugin combines that data with some meta data (in the form of HTTP headers), and sends the HTTP response back to the browser.
- The browser receives the response, and parses the HTML (which with 95% probability is broken) in the response
- A DOM tree is built out of the broken HTML
- New requests are made to the server for each new resource that is found in the HTML source (typically images, style sheets, and JavaScript files). Go back to step 3 and repeat for each resource.
- Stylesheets are parsed, and the rendering information in each gets attached to the matching node in the DOM tree
- Javascript is parsed and executed, and DOM nodes are moved and style information is updated accordingly
- The browser renders the page on the screen according to the DOM tree and the style information for each node
- You see the page on the screen
- You get annoyed the whole process was too slow.
I, too, get annoyed when the above steps take longer than one tenth of a second. But now at least I have some documentation to look at, while waiting the remaining fractions of a second before the page renders.
Spoiled we are, all of us.
(Feel free to add more steps, through the comments…)

madr ( 11 Jan 2010 )
13), sad but true …
Further frustration:
Stylesheets are parsed as they turns up, and can create a flash of white screen when not placed in .
The same goes for scripts: it doesn’t wait until all other stuffs have been downloaded.
Scripts blocks pararell downloads (step 3-15) for all resources until it’s happy. That’s because people still use document.write these days.
Lovely!
Roland Bouman ( 11 Jan 2010 )
Nice writeup! But I feel you did leave out a rather important point: browser cache lookup. And one step further: webserver proxies and their cache lookups.
Craig Buchek ( 11 Jan 2010 )
Pretty good, although I’d consider this to be a bit simplified. For example, step 5 requires 3 packets to be exchanged (the 3-way TCP handshake). Also, a lot of web sites have load balancers (or even multiple tiers of load balancers) or more server tiers. And there’s a good chance that the client is behind a proxy server as well. And don’t forget all the routers, switches, and firewalls also involved.
Loon ( 14 Jan 2010 )
Was going to add steps, but this page was so slow… probably due to me looking at it from a proxy, routed from England and back. Proxy steps perhaps?
Cody ( 15 Jan 2010 )
Dang I didn’t realize there were so many steps to render a webpage. Even if I stopped and thought about it, I wouldn’t have know about all of these different steps it has to go through. I guess we are spoiled, because most of the time it takes seconds to complete.
Kristopher ( 19 Jan 2010 )
From a networking and transit perspective, there’s easily 10 sub steps under #6.
Robin ( 25 Jan 2010 )
This is bookmarked and printed for reference! Thanks for a great one :) !
Pariloto ( 5 Feb 2010 )
I think that this is also a good guide for understanding how you can speed up a web site, by controling and optimizing some of the above steps.
I think that a “correct” html combined with a good browser will get you happy as all the steps above will be made under the tenth of a second that you talked about.
Case pariuri ( 11 Feb 2010 )
So true! And as a happy-end and pain-beginning, this is just the beginning – steps for arriving at you – after that it’s the process of loading it! I guess there can be millions of processes loaded around this action!
Markus ( 22 Feb 2010 )
Interesting stuff, I never thought about how many steps it goes through.
Mac ( 26 Mar 2010 )
Some of these steps could have been combined and the last one is not really a ‘step’.
Gkanell ( 13 Apr 2010 )
Very nice article…thnx for sharing…
Guillermo ( 23 Apr 2010 )
Wow! Try to figure all this stuff in the old (no so good) days of the /360 or VAX-11…
By the way, sometimes here in Montevideo, with mobile ADSL it seems that we are still in that era. That’s why I prefer information over spectacularity: ¡avoid heavy pages!
Great article, very helpful, ¡Gracias!
Guillermo.
Siegfried ( 26 Apr 2010 )
Nice, but not always true.
1. Not all web pages are built out of a database. So you may skip this steps for all socalled static web pages. I think constructing static pages dynamically is nonsense.
2. The page is rendered earlier. At least in modern browsers. As soon as the html is loaded and parsed, the page is rendered (while loading other resources like stylesheets). After loading the stylesheets the page is rendered again. And after loading each image the page is rendered again. And after loading and parsing the javascript the page is rendered again.
R2J WebWorld ( 26 Apr 2010 )
Wow, this is such a super, long step taken for a split-second process! @ Mac, I think the last 2 weren’t a step at all.
jeffatrackaid ( 1 Jun 2010 )
When you break down a HTTP request like this you can begin to see why a site may take a long time to load. Consider a graphics laden site with dozens of images. This process has to repeat for every request. Many browsers restrict the number of simultaneous downloads to a server, so even if the server and network is fast, the page may load slowly as it handles dozens of request. Tools like YSlow and Page Speed (FireFox add-ons) can help you pinpoint problems in your site. I see a lot of companies waste money on hardware upgrades when tweaking a page design to limit HTTP requests would have provided much greater bang for the buck.
Rodrigo Alves Vieira ( 3 Jul 2010 )
Thanks for the writing!
washburn ( 1 Sep 2010 )
Thank for slowing thing down for us. we surf the net every day not thinking about what is taking place in the background.
we have come a far way
moocr ( 2 Nov 2010 )
This is a very clear steps list from type a url to show a web page.
I just develop a very simple blowser using java, it can not display any image or picture, it just show the links, hehe, I study the steps by this way!
Hasan Sheikh ( 21 Jan 2011 )
good one!