2

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?

Improve this question

4 Answers 4

Reset to default
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

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

Yes. Not just the size of the content itself, but also the server might be kept very busy generating the content. ASP.NET is not exactly the most resource-friendly system you can find.
I don't think I'd go that far. You can write bad code in any language on any platform. .NET does a pretty good job IMO.
Thank you for your help. Indeed, the element VIEWSTATE is quite long. Stackoverflow won't even let me paste it in a comment, as it is 1,627 characters long. Do you think that is problematically long? What does this value represent? Is there a way to "fix" it to mitigate performance issues? Thanks so much!
@n8wrl: you can indeed write bad code in any language. However, the OP is the person paying for that code, so he has a right to expect it to be reasonable quality, regardless of what language it's written in. Even from the few hints we have, it's fair to say that it's unlikely to be.
+1 on the maintenance aspect - that will be a nightmare to maintain
|
2

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.

Improve this answer

3 Comments

yes. [sigh]. I agree with your blunt assessment. Are there tools for running speed/efficiency tests on server-side code, or do I just need to get hold of the files and look at it line-by-line? Any recommendations on the profiling tools you referred to? Thank you!
in the browser: I'd suggest Chrome Developer Tools; it's probably the best, and it's built into Chrome. Firebug, which is an add-on for Firefox is a close second. (I actually tend to use Firebug in preference, but that's because I prefer the interface, Chrome is probably more powerful). On the server, you'd need to be using Visual Studio to debug/profile .Net code in any meaningful way. If you don't have a VS license, then you're stuck with just reading the code.
that said, the browser-side tools will give you plenty of info about which bits of the server-side code is running slowly, simply by looking at the page load speed.
0

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.

Improve this answer

Comments

0

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!

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.