inline css performance issue

Question

There is a development company that's been hired by my company to make some complex software. It appears that they are using a .NET framework to write the code. I don't know if this is something strictly associated with .NET, but while looking at how the HTML is structured, I noticed a lot of in-line CSS. Just a lot of divs in the format <div style="position: absolute; top:177px; left:229px; width: 710px; height: 306px;" class="EventLabel Event_bg_red"></div>

There are also elements with long ids. id="ctl00_ctl00_ctl00_MainContent_MainContent_BodyContent_grid_DXDataRow0"

Do these long strings of text and long in-line style declarations impact the performance of the site? (I'm noticing some lagging issues, and do not know whether it is due to some script or complex HTML) Or perhaps .NET writes this HTML dynamically, thus the long time to compute all those position:absolute values. Or are strings of text like this negligible when it comes to a browser rendering a webpage?

Answer 1

Yes, inline CSS is slower than CSS from a separate CSS file. And no, I doubt that the long ID will be making any difference, performance-wise.

However, even if these things are an issue, they're unlikely to be the issue. Fixing the points you're looking at would be micro-optimisations. None of the main browsers would give you any noticeable performance issues with inline CSS. It's a standard element of web page code, even if there are usually better ways of doing it. And as for long strings... well, the browser's rendering engine is highly optimised for parsing long strings, so I don't think a few long IDs will cause it any problems.

If you've got general performance problem, I'd say it sounds like something deeper than that.

I'd suggest using a tool like Firebug or the Chrome developer tools to run some profiling on the site, and find out in more detail exactly where it is slow. The tools available for this kind of debugging are pretty advanced now, and with a bit of work you should be able to nail down pretty precisely where the problems are. Maybe it's the server-side code that's slow: you'll see long page loads for your HTML and Ajax. Or maybe some of the Javascript routines are slow: The profiling tools will show you exactly which calls are taking the most time.

My hunch would be that these things you've picked up are symptoms of a more fundamental underlying problem: to be blunt, it sounds to me the people you've hired to write the code don't sound like they're really very good at it. Try to get a look at the source code they've written, and get a feel for the code quality.

Answer 2

Those ids are auto-generated with the ASP.NET WebForm framework. To see if they are performance issues, you can use the page speed plugin, available for chrome or firefox. My guess at this point is that they are not, since browser usually store them in a hashmap and thus looking for them are very fast.

https://developers.google.com/speed/pagespeed/

As for the rendering time, use page inspector (built-in chrome/Safari) or firebug (plugin for Firefox). The network pane usually tell you how much time is spent on every resource.

My guess is that the lag is before any data is sent to the client. WebForm can get pretty heavy on resources usage when their are a lot of controls on the page, or when their is a lot of data to fetch from the database. Check for the ViewState usage too. (check it out on google if you don't know what it is) WebForm can shove hundred of kilobytes of data in your page if you're not careful and those data are sent back to the server every time you click a button.

Good hunting!

Answer 3

Inline CSS is never cached, much like HTML is never cached. External CSS files do get cached and reused by the user's browser -- so there's a performance hit there. (Same applies to Javascript inline vs external files.)

Inlined CSS is also hard to maintain, and makes the HTML file itself larger. I don't think the long ID's themselves are an issue.

Answer 4

I suspect it's a combination of things.

First, the funky-ID's are a .NET thing - it's an indication of the hierarchy of the elements in the site. It can be optimized and/or disabled, but it's usually harmless. Take a look at the source to the page and look for a form variable called VIEWSTATE - i suspect it is large (with all the ID's they're using that means lots of server-side controls contributing to ViewState) and that can be a problem.

Long/dynamically-generated ID's can also make it harder to write client-side code that interacts with elements on your page.

All the inline styling is probably from a WSYIWYG editor they're using to do the layout. Those tools often produce nasty HTML but 'get the job done.'

The only performance problem you might worry about is the size of the content delivered to the browser which will be larger with the long ID's and in-line styling. I doubt there'd be any once-it's-there performance problem.

It will likely make it more difficult to modify the site layout later on however.

Hope this helps