Member Avatar for stilllearning

Hi,

I have some code which creates an extremely long table row, and I've been able to clean it up to a point where my performance is fairly decent. What I am trying to figure out is if its better in terms of speed to use divs as opposed to the really long table row. I didn't really find much on this topic online, so thought I'd ask out here.

Any ideas ?

Thanks !!

  • 3 Contributors
  • 2 Replies
  • 127 Views
  • 14 Hours Discussion Span
  • Latest Post Latest Post by scrappedcola

Dani AI

Generated

This is not a simple "tables vs divs" speed question — it depends on what the browser has to do and how the markup is built. asked about an extremely long table row; linked background reading and flagged layout/performance concerns. Below is a compact, practical checklist and a few concrete tactics to decide and measure which approach is better for a given case.

Start by choosing semantics and test early. If the content is tabular data use a real <table> for accessibility and correct semantics; use CSS Grid/Flexbox for non-tabular layout. Measure in the target browsers with realistic data and interactions instead of relying on assumptions — modern engines differ.

Concrete optimizations to try

  • Use table-layout: fixed plus explicit column widths or a colgroup to make table-layout predictable and cheaper. See MDN on table-layout for details.
  • Build large chunks off-DOM and append once (use DocumentFragment or construct an HTML string and set tbody.innerHTML) rather than repeated single inserts. See the MDN DocumentFragment docs.
  • Minimize per-cell work: avoid inline styles, avoid per-cell event handlers (use delegation), and keep cell DOM shallow.
  • Keep CSS simple for those elements (fewer complex selectors and expensive paint properties).
  • Profile with DevTools (Performance panel) and test with the actual number of cells you expect; cutting node count usually buys the biggest wins. web.dev has a useful guide on DOM size and page speed.

Quick microbench idea (compare strategies with the same data):

function timeBuild(buildFn, count){
  const t0 = performance.now();
  const container = document.createElement('div');
  container.style.visibility = 'hidden';
  document.body.appendChild(container);
  buildFn(container, count);
  const t1 = performance.now();
  document.body.removeChild(container);
  return t1 - t0;
}

Final note: pick the semantic structure first, then use the above tactics and measurement to guide changes. If a simple table-layout: fixed + batched DOM insertion solves it, that keeps the markup accessible and fast.

Recommended Answers

All 2 Replies

Member Avatar for scrappedcola

An interesting article on table layout is below. There are also a lot of really interesting blogs about other performance topics there too.

http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/

You also might consider a staggered rendering approach. You could render only the viewable portion (plus a little more) of the table at a time and then render the new content on scroll. Also you might see if pagination is a possibility.

Edited by scrappedcola because: n/a
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.