I have an asp.net project, and I load a base aspx page to display to the user. Then I ajax in the results of an ascx component and inject it via innerHTML in javascript.
I have noticed that the ascx component loads slowly on the first page load, but instantly thereafter. This is really cool, but I do not understand how this can be cached, as the contents are generated by making several db calls.
Does the server send some kind of hash to compare the contents to, to see if it changed on the server or not? Is this a browser thing or an asp.net thing?
What you are experiencing is most likely just in time compiling and has very little to do with the user control itself.
Watch the performance monitor counters for .net. This will tell you a lot about what's going on.
Can you use Firebug/IE developer console/etc. to determine the response code? If you can check the headers, you should be able to see a date that indicates either a cache time or a last modified date. I poked through the MS ASP.NET Ajax documentation, but couldn't find any references to default caching times or cache modification.
However, jQuery's ajax function uses an ifModified property which (according to the documentation) checks the Last-Modified header to determine whether or not it should retrieve the results. I'd imagine that the ASP.NET Ajax calls work in a similar fashion. It may not be prudent for your current project, but jQuery makes it very easy to set caching options.
Related
I want to create a quick page load response in ASP.NET MVC .
If I use [outputCache] then it saves the whole page with the dynamic parts and then a new client will see previous client information.
What is the Best Practice to Do It?
I saw that there is a Cache Tag Helper but will it be faster?
Because I still have to go into the Action and and rendering the page except for the section of the Cache Tag Helper.
Many thanks to those who have an optimal and fast solution.
In the docs for response caching, Microsoft has a prominent warning:
Disable caching for content that contains information for
authenticated clients. Caching should only be enabled for content that
doesn't change based on a user's identity or whether a user is signed
in.
As you indicate, your scenario involves dynamic authenticated content. Thus you should avoid caching the rendered output as a whole, and maybe consider caching specific data or elements within a page only if you're very careful and performance requires it. Otherwise, safer to leave defaults. ASP.NET Core is very fast -- it's unlikely the rendering is the bottleneck in most cases.
To be more specific... When someone clicks a link on my web application, can that user be redirected immediately after the click and then wait for the page (user controls) to load. (Can the user controls load one by one with a priority or something?)
Right know, there is a delay after the user clicks on a link and then gets redirected.
Things you can do:
Check how you're using the ViewState if you're not careful it gets
quite big. But some parts of your app might be depending on it so
it's kind of situational.
Caching of pages or just controls
AJAX - while it doesn't feel as natural as in the MVC, it's still an option
for Web Forms
Script & Css bundling and minification - less requests
for more data are always faster then more requests for less data
These are things I'd start with. From my experience excesive ViewState is the place where you can gain the most but a usually it takes quite some effort to get rid of it since just turning it off might make some of your controls not working properly on postback.
This is just a start but going deeper would require much deeper knowladge of the application.
You could use AJAX technology to create the required responsiveness of your application.
In fact, you only need one page. You could load all actions performed (and the updated HTML/JS) using AJAX.
I would advise to read into that subject. You could use jQuery or similar frameworks to do the communication with the web server.
Required reading: ASP.NET AJAX.
My advice is to try to redo your application with AJAX approach:
here is a smart article about it http://www.asp.net/mvc/overview/older-versions-1/nerddinner/use-ajax-to-deliver-dynamic-updates
Take a look to AJAX technique: http://en.wikipedia.org/wiki/Ajax_(programming)
From what I understand, you are using classic Asp.NET and therefore, webforms.
One way to speed things would be to switch to the Razor platform, which eases things a bit (by preventing unnecessary postbacks).
Alternatively, if you don't want to remake the whole application, you could use a simple html link instead of an asp:hyperlink.
we are creating a custom content management and out portal page is bit bulky it is about 60Kb without images.
and during loading the page in some browser we can see some parts of site load faster than the other parts of the site where as we want to indicate (or instruct the web server) to load some of the areas first then load rest of the page.
is there any particulat setting in IIS for is there any particular method in classic asp for doing that?
also I have the same question in asp.net.
best regards.
I don't believe there is a built in way to describe which parts of a page load first in either ASP or ASP.Net. It really isn't a server decision - depends on how your browser parses the page and then requests the additional resources (or renders the existing ones).
You could potentially use AJAX and build in the order each section loads either as a state engine or by chaining. Seems to be pretty complicated for the benefit.
If you just don't want the user to see anything until the entire page loads you can control that from code using buffering. In classic ASP you use Response.Buffer and Response.Flush so the server doesn't start returning HTML until the whole page is ready - it will keep parts of the page from loading (the server won't stream results). I assume ASP.Net has a similar/identical method for buffering. Note that you can't pick sections of code with buffering but you can send only portions (top down) at a time.
For maintainability reasons, I want to database drive my javascript, in that I only want to send the javascript which is needed based on the users options.
So, is it faster/less resource heavy to have links in the database pointing to javascript files, then using response.writefile to embed those files into the clientside page, or is it faster/less resource heavy to stick the javascript script straight into the database, and response.write it onto the screen as and when needed?
So, is it faster/less resource heavy to have links in the database pointing to javascript files
Usually yes.
External Javascript files can be cached by the browser, and will be loaded only once. Javascript code injected into the HTML page needs to be loaded every time, which increases bandwidth and loading times.
Also, having JavaScript code in a static file (instead of a dynamic one that fetches the code from the database on every request) is bound to be the fastest and least resource-intensive solution.
Don't use Response.Write.
Be aware that if you send the entire JS file once, the client will / should cache it so it doesn't have to be sent again.
DB lookups for every page just to get the relevant JS will be slow.
By only sending the links to the javascript to the client a seperate HTTP request will have to be created in order to go and get each file.
If you embed only the required javascript directly into the page when needed this prevents this. Look at jQuery, thats got a load of javascript available to the client that isn't being used.
Less HTTP requests generally results in a faster website so I would go with embedding the code directly.
Edit:
I disagree with the caching answers above. If you ensure only the smallest amount of javascript that is required is embedded then my answer should be faster. This page will be cached too!
I'm working on a site at the moment that loads all of its browser popups by using page methods. This approach works but it's starting to get messy. I also view page methods as ways to perform small tasks, username availability comes to mind.
What other options are there besides page methods and the update panel?
You should look at the JQuery ajax functionality. http://api.jquery.com/category/ajax/
You can point the url of the AJAX request to an aspx page or an html page or pretty much any web resource that you like, as long as the request is handled on the server by some kind of HttpHandler. And as long as your callback handler is able to handle and display the returned resource
PageMethods sounding fine to me (which are essentially Webservices).
You could pull more data per request and use cache more. You could build a better JavaScript wrapper which satisfies the need for more tidiness.
You could choose another library: How to call a web service from jQuery