Member Avatar for Member #905211

Chrome has that allows you to profile the rendering of the DOM elements on the page (at least I believe that to be the case) https://developers.google.com/web-toolkit/speedtracer/

I need a way to do the same thing in IE. This is currently not possible from the web developer toolbar (you can only profile network trafic and JavaScript)

Does anyone know of a tool that allows for the profiling of the DOM to see how long it take to render each element on to the page (as well as how long it take to calculate the widths of elements and rendering them)

On top of this, a CSS profiler would be cool.

Free tools would obviously be prefered, however I am willing to pay for this tool as well.

  • 1 Contributor
  • 1 Reply
  • 106 Views
  • 5 Hours Discussion Span
  • Latest Post Latest Post by Member #905211

Dani AI

Generated

As noted, third‑party APMs exist, but Internet Explorer itself (IE10/11) already provides useful rendering metrics via the F12 developer tools’ timeline/UI‑responsiveness view. That timeline reports grouped events such as style recalculation, layout and paint so slow frames can be tied back to the JS or DOM change that triggered them. For older IE builds that lack a timeline, manual instrumentation is the practical fallback.

A short workflow to reproduce and inspect a slow render: open the F12 tools, record a session while performing the problematic interaction, then inspect the timeline for long “Recalculate style” / “Layout” / “Paint” entries and expand those entries for stacks and timestamps. Correlate those with the DOM Explorer’s computed styles to see which elements required width/height recomputation. If a per‑element number is needed, isolate that element (hide others) and re‑record so its cost isn’t masked by the rest of the page.

When timeline data isn’t available, measure using the high‑resolution timer and force layout to detect reflow costs:

var t0 = performance.now();
// do DOM writes that may trigger layout
document.body.offsetHeight; // force layout
var t1 = performance.now();
console.log('reflow ms:', t1 - t0);

See the Performance API for precision timers and the concept of reflow/layout for background on why reads after writes force recalculation (performance.now() (MDN), Reflow (MDN)).

For deeper system-level tracing (GPU/GDI, thread scheduling) use Windows Performance Recorder / Analyzer or Visual Studio’s profilers; these expose native stacks and can show whether IE’s rendering pipeline, not page code, is the bottleneck. Practical fixes that reduce layout time: batch DOM writes, separate reads from writes, prefer transforms for animation, and reduce DOM depth/complexity. Instrumentation adds overhead—treat measured times as directional rather than absolute.

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.