Divs Vs. Tables: Performance Benchmarks

Divs vs. tables is a debate on whether to use mainly div or table elements to control the layout of an HTML page.

In one corner we have avant-garde css elitists who proclaim the goodness of all things div. Div advocates claim smaller file sizes, faster loading & rendering times, and increased ease of maintenance for their techniques, along with increased accessibility for the visually impaired.

In the other corner we have old school web designers who justify their choice of tables largely based on ease of development and a relative lack of cross-browser compatibility issues.

After an extensive survey of posts on both sides of the question, it became painfully obvious that there is a general failure to substantiate opinions particularly with regard to loading & rendering performance.

This article attempts to address this shortcoming by injecting some much needed facts into the debate. I coded virtually identical versions of my company home page 3 different ways: one utilizing divs, another using tables, and another using tables specifying table-layout: fixed. I then set myself the task of discovering how quickly the pages would download and display. I also recorded the number of bytes of each page, along with the byte size of each page’s associated Javascript, css, and image resources. I decided to set things up to test pages loaded both from the web server and the browser’s cache.

This article doesn’t attempt to evaluate claims regarding ease of development, ease of maintenance or accessibility for the visually impaired.

Test Pages

• I chose my company home page as the template for pages to test because it represents a real
  world example. It does use 8 tables with 2 levels of nesting.
• All 3 pages pass W3C validation for XHTML 1.0 Transitional, and the .css files employed
  pass W3C validation as CSS 2.1
• All 3 pages utilize a CSS Reset style sheet which removes browser specific default styles.
• I chose Microsoft’s .Net as the development platform to render the pages on the server. However, there is very little code running in the code behind file. What little there is instructs the browser to cache the page for an hour. It also emits a time stamp so I could tell at a glance whether the page was drawn from the server or the browser’s cache.

Page Load Time
I included a script block in the head of each test page. The first line of the script block assigned a variable (dtStartLoadTime) to a Javascript new Date object. A function calculateLoadTime() was set up to fire on the onload event of the body of each page. In this function another variable (dtEndLoadTime) was loaded up with a new date object. Since assignment of dtStartLoadTime seems to be one of the first things the browser does when loading a page, and the load event of the body happens after the page is loaded, subtracting dtStartLoad time from dtEndLoadTime is a useful way of calculating page load time.

Network Round Trip Time
Although my page load time methods provide useful information they still are only 1 piece of the puzzle. Those extra bytes utilized by table-based methods could still exact a performance penalty both on server-side rendering times, and network transmission times from the server to the client browser. In order to calculate network round trip times for each page, I decided to create a test harness page which utilizes an iframe. The page has a button for each test page, which when clicked 1. assigns a variable (dtRequestTime) to a Javascript new Date object, and 2. refreshes the iframe with the URL pointing to the page noted in the button’s caption. The network round trip time is derived from subtracting dtRequestTime from the dtStartLoad time on the test page. The test harness page also includes a Javascript function for recording test results to a dynamically drawn HTML table.

Browsers
I have 5 browsers installed on my Windows XP laptop: Firefox 3.6.23, Internet Explorer 7.0.5730.11, Google Chrome 14.0.835.202 m,Safari 4 Public Beta 528.16, and Opera 9.24. I used the first 4 for my testing. I wanted to use Opera as well but for some reason the Javascript to refresh the iframe didn’t work on Opera the second time it was invoked after a page displayed. I didn’t feel like it was worth it for the purposes of the article to try to solve this problem.

Test Methodology
For each browser:
1. Clear cache
2. Click Div button (grab page from server) (Note Time stamp on page)
3. Click Div button (grab page from cache) (Ensure Time stamp is the same as prior step)
4. [Ctrl-a], [Ctrl-c] to select all and copy results to the buffer
5. Click on Excel spreadsheet, [Ctrl-v] to paste the results to spreadsheet.
6. Clear cache
7. Click Table button (grab page from server) (Note Time stamp on page)
8. Click Table button (grab page from cache) (Ensure Time stamp is the same as prior step)
9. [Ctrl-a], [Ctrl-c] to select all and copy results to the buffer
10. Click on Excel spreadsheet, [Ctrl-v] to paste the results to spreadsheet.
11. Clear cache
12. Click Fixed Table button (grab page from server) (Note Time stamp on page)
13. Click Fixed Table button (grab page from cache) (Ensure Time stamp is the same as prior step)
14. [Ctrl-a], [Ctrl-c] to select all and copy results to the buffer
15. Click on Excel spreadsheet, [Ctrl-v] to paste the results to spreadsheet.

I repeated the test twice, once against the web server running on localhost, and once against the Impact Informatics production web server.

Test Results
Results for 12 pulls of each page (6 from the server, 6 from the browser cache) in milliseconds:
Overall
Div – 64610
Table – 64730
Fixed Table – 65388
Network Round Trip Times
Div – 26648
Table – 25914
Fixed Table – 26306
Page Load Times
Div – 37962
Table – 38816
Fixed Table – 39082

Div was the fastest technique by 120 milliseconds overall or an average of 10 milliseconds faster
each time the page was displayed over the next fastest method, Table. Fixed Table came in last,
658 milliseconds slower then table or an average of 54.833 milliseconds. I think that since I was careful about specifying column widths in my Table test page, it probably took advantage of the faster fixed layout algorithm that browsers are supposed to employ. The slower times of the fixed layout page could be explained by the greater amount of markup.

File Size Results(bytes)
Div Total – 316576
Table Total – 318861
Fixed Table Total – 319113

Conclusions
1. There is no significant performance advantage to using div over table based techniques. 10 milliseconds is imperceptible.
2. Contrary to what many posters at technical forums seem to believe, CSS techniques apply equally to tables and divs.
3. Contrary to the beliefs of many posters at technical forums, entire pages can be cached by your browser whether they contain tables, divs or any combination thereof.
4. There is an advantage to the smaller file sizes of the div based technique. How significant it is for you depends on the number of times your page is requested. Considering my home page gets about 800 views per month the 2285 byte difference between the Div and the Table page would save me only 1.74 MB of data transfer per month, which is not much of a dent in my 1000 GB allowance. Implementing this change will save me nothing on my hosting bill! However, if you look at a page like Yahoo’s home page which gets over 4 billion page views per month from the US alone this change would net 8512 gb in bandwidth savings disregarding the fact that sometimes the page would be served out of the browser cache. At roughly $1.00 per gigabyte per month this adds up to some nice savings especially if the techniques are migrated to other pages.

The test pages are still up!
If you have any problem with my test results, or you’re curious about the javascript code used to perform the tests, I left the Iframe test harness and the test pages up on my site. Here’s the link to the Iframe test harness.

Reference:

• Iframe test harness .