Divs vs. The table debate is whether to use div or table elements mainly to control the layout of an HTML page.
In one corner we elitist primary css, who preach the goodness of all things, div. Div advocates smaller file sizes, faster loading & rendering times, and increasing the ease of maintenance of its technology, with increased accessibility to less visible firms.
In the other corner we have the old school of designers who justify their choice of frames largely on the basis of easy development. and the relative lack of cross-browser compatibility issues.
After much examination of the columns on both sides of the question, it was gravely evident that there was a general lack of opinion on substance, especially in regard to burdens & paying respect
This article attempts to address this failure by introducing some much-needed issues into the debate. home page I transposed it in 3 different ways: one using divs, another using tables, another by specifying tables table-layout: fixed . Then I set myself the task of finding out how quickly the pages would download and display. I also noted 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 write things to explore the pages loaded both from the web server and from the cache of the browser.
This article does not attempt to evaluate claims about ease of development, ease of maintenance, or accessibility for a less established firm.
Testimonial Pages
- I chose my company’s home pregnancy page as an example of testing pages because it represents the real
world group It uses 8 tables with 2 levels of nesting. - All 3 pages in the W3C root pass for XHTML 1.0 Transitional, and used .css files.
pass W3C validation as CSS 2.1 - All 3 pages use the CSS Reset style sheet which removes the browser’s default style.
- I use Microsoft .Net to render web pages on the desktop. But it runs very little code in the code behind the file. That little bit tells the browser to load the page in an hour. It also sends a telling time tag so I could see whether the page was retrieved from the server or the browser. cache.
Place Time
I have included scripts at the head of each test page. The first line of the script block assigned a new Javascript object (dtStartLoadTime) variable. The calculateLoadTime() function fires on the load body of each page set. In this function another variable (dtEndLoadTime) is loaded with a new object. Since the dtStartLoadTime assignment seems to be one of the first things the browser does when loading a page, and the physical load event occurs after the page has loaded, subtracting the dtStartLoad time from the dtEndLoadTime is a useful way to calculate the page load time.
Network Round Trip Time
Although page load time methods provide useful information, it is still only 1 puzzle. Those extra bytes used in table-based calculations could still impose a performance penalty both on the server and in rendering times, and net transmission times from the server to the client browser. In order to calculate the round-trip network calculation times for each page, I decided to test the page layout, which uses an iframe. The page has a password for each test page, which 1. assigns the object variable (dtRequestTime) to the Javascript object, and 2. refreshes the iframe with the URL displaying the page name in the header of the tag. The round trip network time is calculated by subtracting the dtRequestTime from the dtStartLoad time on the page. The test harness page also includes a Javascript function that outputs the test results to a dynamically generated HTML table.
Browsers
I have browsers 5 installed on 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 in my experiment. I also wanted to use Opera, but for some reason the javascript to refresh the iframe wasn’t working in Opera the second it was invoked after the page was displayed. I don’t like the fact that the article aims to try to solve this. .
Test method
For each feed:
1. Clear the cache
2. Click the Div button (take the page from the server) (Note the time stamp on the page)
3. Click the Div button (grab the page from the cache) (Make sure the time stamp is the same as the previous step)
4. [Ctrl-a], [Ctrl-c] to select all and copy the results to the buffer
5. Click on Paste spreadsheet, [Ctrl-v] to paste the results to the spreadsheet.
6. Clear the cache
7. Click the File button (grab the page from the server) (Note the Time stamp on the page)
8. Click the Table button (get the page from the cache) (Make sure the time stamp is the same as the previous step)
9. [Ctrl-a], [Ctrl-c] to select all and copy the results to a buffer
10. Next in the spreadsheet, click [Ctrl-v] to paste the results into the spreadsheet.
11. Clear the cache
12. Click the Fix Table button (capture the page from the server) (Note the Time stamp on the page)
13. Click the Fix tab button (grab the page from the cache) (Make sure the time stamp is the same as the previous step)
14. [Ctrl-a], [Ctrl-c] to select all and copy the results to a buffer
15. Click on the Excel spreadsheet, [Ctrl-v] to paste the results to extend the spreadsheet.
I repeated the test twice, once against a web server running on localhost, and once against an Impact Informatics production web server.
Results of the test
Results for 12 pages of each page (6 from server, 6 from browser cache) in milliseconds:
Over
Div – 64610
Table – 64730
Fixed table – 65388
Network About Times
Div – 26648
Table – 25914
Fixed table – 26306
Page Read 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 by the next fastest method, Tab. At last the fixed table came,
658 milliseconds slower than the table or an average of 54,833 milliseconds. I think I should have been more careful about the types of column widths on my website, probably using a faster fixed algorithm that browsers are supposed to use. The slower times for the fixed page layout could be explained by the larger size of the note.
Size of the event file (bytes
Div Total – 316576
Table Total – 318861
Fixed Table Total – 319113
Conclusions
1. There is no significant benefit to using a div over a table technique. 10 milliseconds is insensitive.
2. Contrary to what many technical posters seem to believe, CSS techniques apply equally to tables and divs.
3. Contrary to the opinions of many posters on the technical side, entire pages can be created by your browser whether they contain frames, divs, or any combination thereof.
4. The advantage is that the file is a small size based on the art. How significant it is for you depends on the number of times your page is requested. Since my website gets about 800 views per month, the 2285 byte difference between the Div and Table page would save me only 1.74 MB of . data transfer per month, which does not have much impact on the allowance of 1000 GB. Implementing this change will save me nothing on my hosting bill! However, if you look at a site like Yahoo’s home page which receives over 4 billion page views per month from the US alone, this change would save 8512 gigabytes in bandwidth regardless of the fact that the page is sometimes served from the browser’s cell. At roughly $1.00 per gigabyte per month, this adds up to some neat savings, especially if users have migrated to other sites.
Pages are still being tested!
If you have any problems with my test files, or are curious about the code I used to run the tests, I’ve left the Iframe test harness and test pages on my site. This link attempts to harness an Iframe.
Report:
- Iframe test harness.
