Does asp:Image tag perform faster than normal HTML img tag?
I have 20 images to show on a web page (tiny images) and I have no idea which one to use.
On server-side
HTML elements in usual use (without setting runat="server" on them) are always faster compared to server-side counterparts, because they don't execute any additional server-side logic or consume other resources. They also don't add anything to page's view state.
On client-side
Simple server-side controls (those that translate to a single HTML element) are no different to normal HTML elements. But complex server-side controls (like calendar) are complex in terms of HTML element quantity thus require some additional browser resources. But making the same thing/functionality with usual HTML would create more or less similar results. So we can assume on the client-side speed is the same.
Verdict
Use server side controls only when you need to add some server-side processing to it. If not, rather use plain-old-HTML-controls. They will be processed faster on the server, will not add anything to view state and will work with the same speed on the client as their server-side counterparts.
This is true for any HTML element that has a server-side equivalent (like img that has asp:Image on the server side). When there's no client-side equivalent (like calendar) you have to of course use server side controls or use some client-side library that provides such functionality (jQuery has a date picker for instance). But you have to know Asp.net processing quite well to combine the two effectively.
use asp:image only if you have to manipulate it on the server side (dynamically setting the title, source, visible, etc).
since asp:image is "running" at the server side, it consumes a bit of memory and cpu usage.
Use an <img /> tag if you don't need to interact with it programmatically. That's less overhead (although the overhead of using asp:Image is minor).
No, there is no performance difference at all when it comes to loading the images. The asp:Image control produces an img tag, so the result that arrives to the browser is more or less identical.
The asp:Image control is convenient if you want to control it's attributes from the code behind.
The img tag will be faster for sure because no server side processing and not have ViewState (which can be disabled still).
Typically if you don't need to set properties dynamically don't use <asp:Image ... />
Remember you can always do something like:
<img src='<%= MyPathMethodInCodeBehind("some value") %>'
alt='<%= MyClass.SomeMethod(someParam) %>' />
However, the difference is really small and would argue it's not notable, yes, even for 20 images.
Related
Just a general question that I've been wondering about for a while. I write a lot of pages in ASP.NET, and so all of my controls have tags beginning <asp:, and include runat="server", meaning that they're server-side controls. What I'm wondering is whether there's any advantage to using client-side controls rather than server-side controls when they don't need to be server-side.
For example, rather than having:
<asp:Label ID="lbl" runat="server" Text="This is a label" CssClass="labelclass" />
Would it be advantageous in any way (e.g. performance-wise) to instead use:
<label class="labelclass">This is a label</label>
?
Only if there is no intent to modify or access label values on the server side. It will be slightly faster to use direct HTML as in this case ASP.NET won't have to spend time to parse server control to generate anything.
If they don't need to be server-side controls, use client side controls. This will make the rendering quicker as there is less code to convert.
I generally only use server-side controls if I'm going to be referencing the control in some way in my code behind file.
On a site note, its worth mentioning, an ASP.NET Label web control renders as a <span> element, and not a <label> unless AssociatedControlId property is used.
Definitely there is a performance boost if we use client control rather than server control as server controls are parsed by asp server and it generates html for it and so it is an overhead.
Its not about how much performance but there is definitely a performance difference.
Server controls should only be used if they have to get modified on server side.
In addition to the server having to render server side controls, they also require an associated ViewState in order to be ping ponged back and forth between client and server. This results in larger requests, heavier loads, and longer load times for your pages.
I'm supporting an application that uses runat="server" all over the place to show/hide table rows.
For example, in places where there are dependent DropDownLists, the row with the child ddl will be hidden until a value us chosen in the parent ddl.
Is that a bad practice? Is there a better way to do this?
I use runat="server" anytime I need it. So I think you can use it too. :-)
I think that's absolutely terrible practice. First of all you do not need to make the trip to the server to hide and show controls, unless you need new data.
Second, any decent javascript framework will allow you to hide show controls based on the control's id, class name, or whatever css selector. Moreover using a javascript post/get to a generic handler will give you the data that you need without the postback.
I'd suggest using JQuery, or some other alternative.
It depends on how much you care about performance. Anything that is marked with runat="server" goes through more processing than just client side tags.
Personally, I've used them before. Especially in the situation where a table cell or table row is relying on data from the server. You can use Javascript or JQuery with a hidden field but you still have to hit the server for the hidden field, so it doesn't buy much.
It's not bad to use runat="server" with standard HTML controls. Often you'll find the use of PlaceHolders to show and hide content on pages, or in ASP.NET MVC you might see the use of inline code blocks such as <% ... %> within the views. On it's own and not in consideration of other design aspects, it's neither good nor bad.
That's what I do to hide the row containing other server controls. The other options are to use a asp:panel or other container, but that will add more HTML without any gain.
I don't think it's necessarily bad practice. I've done the very same thing plenty of times. I think it's mainly personal preference.
Not at all. ASP.NET supports making any html tag run on the server side. Your alternative is to wrap the tag in a Panel, and hide or show that. If you're not looking for the extra functionality or want to control the output yourself, making an html tag run on the server isn't a problem.
Is there any reason use standart HTML controls (input type=text,input type=checkbox) instead of asp.net controls ( asp:TextBox, asp:CheckBox) to improve performance?
IMHO this would be a micro optimization. You will gain performance but it won't be noticeable. On the other hand you will loose much of the flexibility offered by the server controls.
You could try to reduce the size of the ViewState by disabling it for controls that don't need it. This will reduce the size of the generated pages and improve performance.
The ASP.NET user controls will all have ViewState associated with them unless you explicitly set
EnableViewState="False"
As such, you will bloat the size of the underlying page if you have a large number of controls. As a general rule, use what meets your needs and nothing more.
Do you need to access the user control in the code-behind?
Do you need the control to maintain value across post-backs etc?
In most cases, it won't make a difference, but it is good to keep your page clean if you don't need these features.
As always with performance optimizations: it depends on the situation. Test it in your project and see if it makes any difference.
Also with .net 4.0 another con of using server controls is gone, since you can set ClientIDMode to Static, which will give you full control over ID's on your controls. Previously using just a standard textbox or button (without viewstate) would still render crazy non-readable ID's because of the way Naming Containers work. Those days are over now though :)
Remember your three options are:
use regular html which can't be referenced on the server.
add runat="server" to your existing html-tags (ie. ) and you'll be able to access it as an HtmlControl.
use the asp.net tags (<asp:* runat="server" />)
The disadvantage of option 3 is that you don't always know what the rendered html-markup will be and you have less control over it. I personally only use option 3 for more advanced controls like , the button () and third party controls. For normal html-markup that I need to reference on the server I prefer option 2.
Regarding performance I would mainly look at the rendered output, how much extra bloat is rendered to the client and such. CPU-time on the server using one or the other approach I would say is secondary compared to the different caching techniques ASP.Net has already.
In web forms application, for server code, when use WebControls and when use HtmlControls? For example if I want write some text inside of span tag, should I use:
<span id="someid" runat="server"></span>
or
<asp:Label id="someid" runat="server"></asp:Label>
The main difference is that HtmlControls only provide a way of addressing a part of the page during the page cycle, whereas WebControls are stateful.
In your example, if you assign some value to the Label text, it will keep it across PostBacks.
In my experience is far better to use HtmlControls if you can, they are much more lightweight and they don't fill up your ViewState. Do use WebControls when you need them to be stateful.
For example, you might want to use a Label for a page title, because you can only assign the value once (typically in Page_OnLoad inside a if (!IsPostBack) block). You might want to use an HTML span to provide some status feedback (where the status is updated at each postback, for example).
I would use the span approach. Whatever server control you use it will finally render as an html control.
If your functionality can be done using an html control better use that..
For a server control like data grid you might have to code more to achieve those functionality by using an html table.
In that case you can use a server control.
one behaviour of asp:button is it always render as input type=submit
and asp:imagebutton always render as input type=image
I rely heavily on nested Master Pages in my web portal, this causes ASP.NET to generate huge ID tags for controls it creates, for example:
"ctl00_ctl00_MainBody_ctl00_lblDescription"
for a lblDescription Label i've created.
Is there any way to reduce this clutter?
Any other techniques(sorry for being general) to reduce page weight other than removing the viewstate?
Look at Yslow and do what it tells you (I would start here)
Turn off viewstate
Use jsmin to reduce the size of your JavaScript files
Reduce the size of your CSS (dead link)
Compress your response with standard gzip/deflate compression
Using ASP.NET MVC will give you smaller IDs
Whenever possible use HTML Controls. HTML Controls. They are lighter since don't have server-side objects unless you specify the runat="server" attribute.
I don't know how to remove the client id bloat but some general tips for making your pages smaller would be:
Minify and combine any .js/ .css into one file.
include css at the top of the page and js at the bottom (not really going to make it smaller but UI will load faster)
Enable IIS static/dynamic compression
Use caching for controls and pages
Ajax content loading - it's helps when you want to see main content faster than content with less priority
Terrapin has some great suggestions, but they are pretty idealistic. If you are looking for more applicable solutions to your current situation, check out control adapters.
The CSS Friendly adapters will do a lot of work for you to convert your ASP.NET controls from large ugly, long id named tables into more concise divs, with shorter names.
I have used them in a past and they can really make a huge difference. Other than that, turn the viewstate off on any control that doesn't need it. Conform to proper CSS/HTML and it will make another significant difference.
Best of luck!
To minimize the weight of your ASP.NET pages, you can also override the PageStatePersister property (of the Page class) with SessionPageStatePersister. See example here. That way, the Viewstate will be kept in the Session object on the server side, thus reducing the size of the html page on the client side.
Especially inside repeaters, ListViews and GridViews, name your controls something short.
This should be obvious by the Context (A list of Products)
If you have only one HyperLink inside a repeater, call it hl. You don't need to call these controls HyperLinkProduct.
<asp:Repeater id="rptProducts" runat="server">
<ItemTemplate>
<asp:HyperLink id="hl" runat="server" NavigateUrl='<%# Eval("URL") %>'>
<%# Eval("Name") %>
</asp:HyperLink>
<asp:Image id="img" runat="server" ImageUrl='<%# Eval("ImageUrl") %>' />
</ItemTemplate>
</asp:Repeater>
This will render something like:
<a id="ctl00_rptProducts_ctrl0_hl" href="/products.aspx?id=5">
Product Name
</a>
<img id="ctl00_rptProducts_ctrl0_img" src="images/5.png"/>
Multiply those ID names by a 100, and your IDs start to take up a lot more space if you use long descriptive names. Inside Repeaters, short IDs should be clear enough, if your Repeater is well-named.
Using CSS Sprites can speed up your page by reducing the number of requests. Here are a few articles I found.
In your case of using a label, make sure that you really need to use the label (which generates the text in a <span> tag. You could use a Literal instead.
Set EnableViewState="False" on controls that don't need it (or on the entire page/website)
If you're trying change the obscure ids generated by ASP.NET, there's not much you can do there.
Use html/css to style your pages, avoid tables for layout, when creating a label specify the id, shorter it is, the better.
Turning off the viewstate, as you mention, is good. Also I have noticed that the ASP.NET tree control generates a very large amount of HTML (if you have a fair number of nodes). I ended up writing my own tree control that generates 1/4 the HTML of the standard tree control. So you could look for controls like that, that are especially bad, and write your own control.
I guess if you were desperate to do this without retooling your pages (and none of the other sensible ideas worked ;) ), you could do this:
Write an http module that parses and extracts the ids with shorter, recognizable unique ids on the fly as the page is sent to the client, and store them in an application scope hash table. Then, on the return trip perform the reverse step for the incoming data.
At least, that's what I'd try. I'm not sure how nicely it would play with certain html and/or javascript constructs, but I think it could be done.
I suspect it would be a pain in the butt to do, especially if the shorter unique ids happened to conflict with any legitmate non-id values.
EDIT: Just remembered. You'd need to handle the ViewState too... (that would need to be decoded, fixed and re-encoded. Seems like a lot of trouble :) But then again, if you're going to go to that trouble, you can compress the viewstate a lot better by overriding the load/save viewstate methods...
I cut some huge pages (200K of html) down to about 30K using that method a couple of years back. In fact, using custom compression on the ViewState can often be enough to reduce a page size hugely.