So I'm at the stage in web programming where I'm past the "Look, Ma, I can put data in a grid and it shows up on the page." I'm now at the, wow, this site is not as snappy as I want it to be. So, I enabled the "Net" tab in Firebug, closed my eyes, crossed my fingers, and went spelunking.
The first thing I noticed is that all of my .aspx pages are being "GET"ed at least three times. Is this normal? If not, what is "normal"? What affects the "GET"ing of the .aspx pages? I'm assuming that includes the time it takes to hit the database and render all the controls on the page. Is that true?
Perhaps what would really benefit me is a place I can look to get some "best practices" for these kinds of speed related issues.
Things to consider:
Using IIS 6.0 via HTTPS
We're using Masterpages
We're using Telerik controls
A RadMenu
A RadScriptManager
I'm certainly more of a thick client guy than a web guy
EDIT
Answers to questions below:
The response code is 200
EDIT
Screen shot added:
FirebugScreenshot http://img187.imageshack.us/img187/5873/firebughelp.jpg
EDIT Added Additional Screenshot to include Request Headers
EDIT
Added links
page source
My Master file as txt
My WebConfig (without connection strings, obviously)
EDIT: Here is the source of your two extra page loads:
<script type="text/javascript"
src='<%# ResolveUrl("~/Common/jQuery/jquery-1.3.2.min.js") %>'>
</script>
<script type="text/javascript"
src='<%# ResolveUrl("~/Common/jQuery/jquery-ui-1.7.1.custom.min.js") %>'>
</script>
As you can see in the rendered version the src attribute is empty, causing it to load the page two extra times.
<script type="text/javascript" src=''></script>
<script type="text/javascript" src=''></script>
You can probably fix this by using the runat server tag and having it resolve the urls automatically.
<script type="text/javascript"
src="~/Common/jQuery/jquery-1.3.2.min.js"
runat="server"
ID="jQuery"> </script>
<script type="text/javascript"
src="~/Common/jQuery/jquery-ui-1.7.1.custom.min.js"
runat="server"
ID="jQueryUI"> </script>
(or change <%# %> to <%= %> -- since you need to have the version that outputs a string instead of the binding syntax).
Original answer removed since it was not related to the actual problem.
It's unlikely that those are AJAX requests, as the response length is the same on each request.
I'm also ruling out the bug with empty src attribute of img elements, as this only causes one reload of the page, not two.
There is a know bug with Telerik RadEditor that might cause such condition, but you don't mention it in the list of used controls. Here are more details about it:
http://www.telerik.com/community/forums/aspnet-ajax/editor/radeditor-forces-page-load-twice.aspx
You might also want to comment out the Telerik controls on the page to see if that helps.
The browser should normally hit the server just once, and all the time it takes to query the database and whatnot should be confined within that request. If you're playing around with ajax controls, they're likely to query the server more times for new data. You can use firebug to inspect the requests and responses, and see what they contain.
A common cause for the aspx being requested several times is having IMG tags rendered without any SRC attribute. This will default to querying the same page for the image source. If this is the case for you, then you could check the request headers in firebug, to see if it expects an image.
You could also go to the console and type document.images to get a list of all the images. The ones that aren't visible on the page will be shown slightly faded. Inspect those for blank SRC's.
This normally happen if you are in the Development Environment and "Enable browser link" in VS 2015/2013 .
To avoid the Multiple GET Requests Shown in Firebug, uncheck "Enable browser link" from the tool bar.
If you view the page source, you find script tag added to the page when you check "Enable Browser Link". This causes Get/Post Actions to the iis server. For more details: http://www.asp.net/visual-studio/overview/2013/using-browser-link
The browser makes a GET request for each resource included in the Page, including js files, images, css files...
It could be lots of things - the important part of the request is what it's GETing.
Generally you're going to see more than one request for an ASPX page as it loads the javascript libraries to perform validation and postbacks. Controls can also have javascript embedded as resources, which in turn create other GET requests, usually for WebResource.axd and ScriptResource.axd.
If you have security enabled, that could be the challenge and response requests - first a 401 then a 200. What are the response codes that you are getting?
Related
I'm attempting to speed up my website by combining and minifying my [web|script]resource.axd files.
Something based off of and similar to this.
http://www.koders.com/csharp/fid2061F9773188F0AB36F0DC42BC6073E3A935F71F.aspx?s=cdef%3Ajquery (modified to work with ie6)
The telerik controls in my pages render a lot of resouce.axd script tags. They also appear in update panel ajax postbacks in the pipes format.
Left by themselves the script files are run once. However after I combine the files in the regular page post and an update panel update fires. The code gets run a 2nd time due to the script reference in the update panel ajax response.
This results in a bunch of Telerik "Namespace is already registered." errors.
(I think this is because it is a seperate script file with a different name however I still get an error when I have the same file name, Telerik.Web.UI.Orientation is already registered)
I've been thinking that I can just remove the script references from the update panel postback altogether as the scripts are already on the page and there should never be any new controls added to the page requiring new scripts.
I've implemented this and I don't see any issues so far. Could there be something forboding that I am forgetting about?
Or is this a valid assumption?
Examples:
Normal Telerik Post
<html>
...
<script src="webresource.axd?d=asdfasdfasdfasdfasdfasdfasdf1" />
<script src="webresource.axd?d=asdfasdfasdfasdfasdfasdfasdf2" />
<script src="scriptresource.axd?d=asdfasdfasdfasdfasdfasdfasdf3" />
<script src="scriptresource.axd?d=asdfasdfasdfasdfasdfasdfasdf4" />
...
</html>
Normal Telerik UpdatePanel Response, no issues when requested from non combined page, throws <namespace> is already registered error when requested from page with combined scripts.
1|...|...|...|
123|scriptBlock|ScriptPath|/ScriptResource.axd?d=asdfasdfasdfasdfasdfasdfasdf3|
456|scriptBlock|ScriptPath|/WebResource.axd?d=asdfasdfasdfasdfasdfasdfasdf2|
Combined Scripts
<html>
...
<script src="js.axd?path=gdfg78sdfgsd70fghsrg89dg0sdfh0sfh9sfgh" />
</html>
What you said makes sense and as long as its working I don't foresee any issues. But I haven't run into this issue myself and I use a lot of telerik controls in update panels. It does have me a little curious. I assume you are, but wanted to double check, that you're using the RadScriptManager, which will automatically combine those script files for you. And since you mentioned you're aiming to improve performance as much as possible, I'd also suggest looking at their StyleSheetManager and Compression.
http://www.telerik.com/products/aspnet-ajax/stylesheetmanager.aspx
http://www.telerik.com/products/aspnet-ajax/compression.aspx
http://www.telerik.com/products/aspnet-ajax/scriptmanager.aspx
Also, have you considered using their RadAjaxManager instead of UpdatePanels? It should be more lightweight.
I was able to setup some ASP.NET Image controls to render images from a database by using an HttpHandler.
// Notice the ImageHandler.ashx
<asp:Image ID="imgSrvcGrp" runat="server" ImageUrl='<%# DataBinder.Eval(Container.DataItem, "ServiceGroupID", "~/ImageHandler.ashx?id={0}") %>' />
It works great and was surprisingly easy to setup. My question follows...
I noticed that the HttpHandler (ImageHandler.ashx) gets hit at certain times when I don't expect it to. For example, I have a break point at the Page_Load event of the page that contains the Image tags consuming the HttpHandler and another break point in the handler itself, and I found that even though there is no postback (ie - the Page_Load break point is not hit) the handler sometimes gets hit (ie - the break point in the handler is hit).
Oddly, I found this occurs when I close a jQuery dialog on the page. I have a jQuery dialog popup on the page, and I found that when I close the jQuery popup (by clicking on the X) the image handler is hit for every image on the page that consumes it and yet no postback occurs.
The only other detail that I can think to add is my webpage is using Telerik's RadTabStrip, and it is possible that it is somehow having an effect upon this matter.
I realize that my explanation was rather long-winded, so to be more succinct with my question: Why does my image handler get hit so often even though there are no postbacks occurring?
Because loading a page resource and posting a form are different actions.
Don't think of it from an ASP.NET perspective with postbacks and Page_Load handlers and whatnot. Think of it from the perspective of the actual HTML in the browser. A "postback" is nothing more than a form being posted to a page. If you're not doing anything to trigger a form post, the page won't post back.
However, the page is hitting the server when it requests other resources. CSS files, JavaScript files, images, and so on. The resources referenced within the HTML which the page needs to load. So when a page is loaded, it doesn't just hit the server once. It hits the server to get the HTML document (this is where Page_Load for the page gets triggered), and while it renders that HTML it hits the server again and again for every resource referenced in the HTML document.
If the page is hiding/showing resources with dynamic style tweaks, then it shouldn't need to re-load those resources each time it shows them. However, if the page is doing something which causes it to have to re-render the loaded content (and that content isn't cached in the browser), then it will hit the server. This would be what causes that ASHX handler to get hit.
One suggestion for you would be to load up the page with some debugging tools (FireBug in Firefox continues to be my personal choice), and watch the actual traffic coming and going on the page (the "Net" tab in FireBug, possibly something similar in other tools.) This can help you determine exactly what is being requested and possibly what is requesting it. For example, if that RadTabStrip is for whatever reason removing img elements from the page and re-adding them, it'll request the image from the server each time.
I’m trying to use a third-party ActiveX control on our intranet ASP.NET site, and I’ve run into a problem I can’t figure out.
Expected behavior: The control expects to see a specific variable in the URL (“msg”). If you provide it, it works. If you don’t provide it, it complains that the value is missing.
If I put the control in an HTML page, it works fine. But if I then change the page’s type to aspx, the control acts as if the variable isn’t there. The control still loads and runs; I’m not getting any permission or safety messages. But it complains that “msg” wasn’t provided on the URL.
In other words, if I try these URLs, the first one works fine; the second one gives me the "you didn't provide the msg parameter" complaint:
(works fine)
http://mysite.mydomain.com/controltest/test.html?msg=123
(complains)
http://mysite.mydomain.com/controltest/test.aspx?msg=123
I know the aspx version is being processed by the server before being sent to the client, but there aren’t any server-side commands or tags (it’s the same file, just copied and renamed). As far as I can tell, the resulting page that is sent to the client is exactly the same.
Is there something about aspx vs html that would cause the control to not be able to get that variable? I can see it fine from javascript that I add myself.
Here's the content of the page. Not much to it. If I get this working I intend to add some aspx tags and code, but there's no point yet.
<html>
<head>
<title>
ActiveX Control Test
</title>
</head>
<body>
<OBJECT ID="control1" CLASSID="..." CODEBASE="..." >
</body>
</html>
Turns out Eugene was correct, the third party control was doing a string search on the URL and was only looking for .html or .htm.
I have a nested master page. A parent master page, a child master page and a content page whose master page is the child master page. I have a reference to jQuery in the parent master page in the head section.<script type="text/javascript" src='<%#ResolveUrl("~/includes/jquery-1.4.2.min.js") %>' ></script> & Page.Header.DataBind(); in the OnLoad event.
I am using jQuery in all the pages including the master pages. However I am getting "Error: $().ready is not a function" in the content page. If I include jQuery reference in the content page it works.
Question: If the reference to jQuery is in the master page head section, why aren't the content pages able to use jQuery? When I do view source, the script tag with jQuery is there and it works.
The master pages and content page are merged during rendering and sent to the browser as a single html page so I am not sure when master pages are used, jQuery references break.
UPDATE:
When I changed '$.ready(function()' to 'jQuery(document).ready(function($)' it worked! I am not loading any other javascript libraries and I am not using MS Ajax.
First, and I didn't notice this before, but is your original call to $.ready(function() {}), which didn't work, but jQuery(document).ready(function() {}) did work? Does your call work if you use $(document).ready(function () {} )? Just wanted to make sure it's not a typo. The jQuery docs say the $.ready(function() {}) is valid, but it's not recommended.
OK, assuming it's not a typo, it definitely sounds like you have a conflict with the '$' variable. If you're using third-party controls or ASP.NET AJAX, you may run into conflicts (even though you may not be including the JS file explicitly).
If you could post what gets output by the browser after your page loads, that would help.
Also, if you run Fiddler (or some other traffic request tool), you can see if any JS references are being downloaded. Look not only for .JS files, but also .AXD files (some third-party tools name these files ScriptResource.axd or WebResource.axd, and they may redefine the '$' variable).
You may want to check out this link on the jQuery API page about the noConflict function. This helps when you have a conflict with the $ variable.
Without seeing the output, it's tough to diagnose. But hopefully this helps.
i also have the same issue, it sounds like a jQuery conflict
i fixed my issue :
<script type="text/javascript" >
$(document).ready(function () {
$.noConflict();
});
</script>
in the <head> section
Is there a reliable method for viewing the size of the viewstate on any given postback?
I would recommend using FireFox addon called "Viewstate Size". Quick, simple and convenient.
https://addons.mozilla.org/en-US/firefox/addon/5956/
Enable Trace in the web.config.
Browse the application http:////Trace.axd
In the "Control Tree" Section , sum up the ViewState Size and Control state Size of the controls.
To view it in the page at the bottom of each request you can enable page level tracing like:
<%# Page Trace="true" %>
You can read more about this technique here:
http://msdn.microsoft.com/en-us/library/94c55d08.aspx
Trace could be overkill sometimes. You can add this javascript to the page see quickly see how the ViewState grows as you click around.
<script type="text/javascript">
alert('Viewstate is now ' + $('#__VIEWSTATE').val().length + ' bytes.');
</script>
In Google Chrome you can use Chrome Viewstate or Viewstate indicator modules
You have a few options:
Using Trace
Using a browser plugin
Adding code to your project for extracting the viewstate size
I found this article quite useful "Determining an ASP.NET Page's View State Footprint" and it covers the options mentioned above.
However what I ended up doing when I needed to look at the viewstate size etc. of a application I was brought in to work on, was to use a tool called "ASP.NET ViewState Helper".
What I liked about that tool was that I could run it as a standalone executable, no installation of plugins required and no changing of the code required.
The drawback is that it only works for IE but in my case that was fine.