Efficiency of various tag

[Beagle]

Does anyone know of any references where one can find the efficiency of rendering the various html tags? For example, is it faster or slower to render divs or spans and is that dependent on the display type?

I'm mainly interested in what it costs when a browser encounters <script> tags, so if anyone knows that off hand, what have you to say on it?

And before someone states that this is not noticeable enough to matter, I'm working on 300mhz machines with no graphics card. I need to squeeze speed everywhere I can.

[Bill Posters]

I'd say it's less an issue of the 'cost' of the script tags themselves and more a case of whether the machine has the welly to handle what the script is trying to do.

If you need a div, use a div. If it requires a span, use a span.
Use the right markup for the job and worry less about the impact of each individual tag.

I can view my own website* on my mobile phone, albeit it in a reduced form (though with the same markup as a full GUI browser gets), then a 300mhz PC with no graphics card isn't likely to break a sweat trying to handle a page of markup. (I'm assuming you're not building multi-MB markup documents that are likely to swamp the memory/cache.)

* XHTML document, external CSS file, external js file.

[ronaldb66]

I agree that the markup itself likely won't have a noticeable effect on rendering; it's more the heavy lifting of placing images, working out all the different dimensions, etc. that will. Complex, nested tables are notorious in this respect, and of course script execution may have an influence.

[Beagle]

Most hand-held devices actually have some kind of graphics processor on it. The machines I'm working on don't. If no one has ever analyzed it, that's fine. If I get the time to analyze it, I'll post my findings.

[ronaldb66]

with no graphics card. Eh, wait; missed that. How are pages presented, then? Do you mean pure text, sans any presentation a la Lynx?

[Bill Posters]

Most hand-held devices actually have some kind of graphics processor on it. The machines I'm working on don't.

I don't profess to know the ins and outs of hardware, but surely they have some kind of graphics processing, otherwise they'd presumably have no video capabilities at all - and you'd be using the OS and apps 'blind', so to speak, because you'd be staring at a blank monitor.

Surely there's enough grunt on there to handle the video/graphics requirement of at least a basic OS. I can't imagine web page markup would push that capability any harder or faster.

[Beagle]

It's frame buffered on the CPU. It's pretty slow. The systems serve very specific purposes so we can tweak them pretty heavily. But the limited disk space has become a problem for loading apps, so we're using a browser and developing web apps for several things. It allows us to deploy more functionality without eating much more disk space. We're using Opera on these systems since it blows away everyone else in its javascript execution time.

Depending on the length of the input form, we can have render times that take upwards of 10 seconds. I'm taking over client efficiency and we're moving towards XMLHTTPRequest to avoid multiple renders when possible, but on larger pages, the initial load of 10 seconds is still pretty terrible.

But I've never seen any information on making markup or css more efficient to render. Is this information available on the web. Google has thus far failed me. Anyone got any ideas.

And yes, come to think of it, you can play games on phones. There isn't a chance in hell you could do that on these systems. We custom build them in-house and they can't have fans due to the environment they're to be used in. Trust me when I say we need ALL the tweaks we can get.

[ronaldb66]

Hmmmm... those are some very, very specific circumstances you're talking about... You're making me mighty curious! ;)

Basically, I'd say keep the markup as simple as it can possibly be, with as little document levels (nesting) as possible; I'd be inclined to suggest making use of as few ids and classes as possible, too, but since default rendering by modern browsers is often based on style sheets as well, this may actually make very little difference.

Best course of action may well be to contact the folks at Opera and ask them if they can indicate specific heavy or lean rendering markup constructs.

[felgall]

Use the right tag for the job so that the stylesheet commands to get the effect you want can be minimized. That way the code will run as fast as possible. Any processing done by the browser will be a minor part of the total time taken to display the page compared to the time taken to download the page on a T3 connection (and an even less significant fraction of the total for slower connections).

[VIPStephan]

I might not be the right guy to give any advice on this subject but: Why not use XML? You can have custom tags for special purposes and would maybe save some space?

[fyo]

Don't use tables.

Seriously, don't use tables.

Really, I mean it. Tables are extremely inefficient, especially when nested.

I haven't investigated in detail since Opera 5 or so (same rendering engine as Opera 6), but they had a really sweet algorithm for rendering tables. It *never* required more than two passes. It also got some things wrong as a downside, since tables just aren't that simple to deal with.

If you have the need to use tables, make sure you're using the right "kind" of table. I'm referring specifically to the table-layout property in CSS. Basically, stick with "fixed" under almost all circumstances.

Lot's of things in a static page can cause elements to be refreshed (and inline content reflowed). In DHTML and DOM Ajax, this can rapidly become much, much worse.

The first and foremost thing to do is to THINK LIKE A BROWSER. Read your page one element at a time and consider if the browser has all the information it needs in order to render the element correctly - or will it need multiple passes.

[fyo]

Any processing done by the browser will be a minor part of the total time taken to display the page compared to the time taken to download the page on a T3 connection (and an even less significant fraction of the total for slower connections).

I remember pages of pure HTML+CSS that brought Firefox on my old 700MHz system to its knees, requiring MINUTES to render after finished download. Probably not the most efficient code, but just pointing out that it's not as simple as you seem to believe...

[Bill Posters]

I remember pages of pure HTML+CSS that brought Firefox on my old 700MHz system to its knees, requiring MINUTES to render after finished download. Probably not the most efficient code, but just pointing out that it's not as simple as you seem to believe...

I'd be willing to bet that it wasn't brought to its knees because of the 'cost' of any single element, but rather, as you say, the accumulative effect of flabby code and/or over-demanding scripting.


Fwiw, I'm still running an old 400MHz G4 and I'm able to browser the web day in and day out - including some very heavy pages - without FF or the machine keeling over.

[Beagle]

Considering that the files are being served locally, I don't think that the data transfer is TOO much of a problem. On top of that, we due make the best effort to minimize data going across the wire.

I'm interested in why it was said to use the "table-layout: fixed" style attribute on tables. What does that do for rendering time? What benefits / problems can it cause?

About avoiding reflow when using javascript to manipulate the DOM:

If I have a form, every time I change the value of a field, is the page reflowed? Is there something ELSE that occurs, like a re-render? I've noticed speed issues when setting field values in sequence.

Can I avoid reflow by setting an element's visibility to hidden, making changes, and then showing it again?

Can I avoid reflow by taking an element out of the dom, manipulating it, and then putting it back in?

Are there examples of these types of tests on the web somewhere? I still haven't been able to find much.

[djm0219]

I'm interested in why it was said to use the "table-layout: fixed" style attribute on tables. What does that do for rendering time? What benefits / problems can it cause?

Being specific with table dimensions saves the rendering engine from having to make multiple passes through the data as it tries to calculate how big each element of the table needs to be to hold its data. If you specify the table width and the width of the columns for the first row of data no futher calculations are required and the rendering engine simply has to plug in data.

The downside, afaik, is what might happen to how your data gets displayed if the contents of a cell are very different than the rest of the cells which may result in it being displayed a little "odd".

[jkd]

Here is some stuff straight from Mozilla on writing more efficient CSS:
http://developer.mozilla.org/en/docs/Writing_Efficient_CSS

I know you're working with Opera, but I'm sure these tips aren't Mozilla-only, since they make too much logical sense to be specific to any specific algorithm that other browsers don't implement.

[Beagle]

Hey thanks for that, that was a great find!

I wonder if we can find more of these, or if we get some accurate tests, we could create a sticky on HTML/CSS efficiency...