The ASP.Net app (not MVC) is slow, someone heard that Jquery can speed things up by offloading work to the client.
Due to security reasons Jquery/Client can't make Web Service calls so squirrely ways of having the code behind making Web Sevices calls and passing data back to the client are being done to Jquery popups, Jquery gidviews, Jquery (fill in blank of existing server side control).
We've got Jquery AJAX going on along with Microsoft AJAX Update panels, which I'm worried about.
Question is: Are we really going to get a performance boost (which my gut says No) or are we on our way to a slower, more painful app performance?
Don't mix and match frameworks. It can cause problems and will certainly degrade performance. Choose one and stick to it. UpdatePanels are easy but will never be as fast as jQuery and web services.
http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanels-are-dangerous/
I've never used the MS Ajax library but I have worked extensively with ASP.NET (webforms and MVC) and jQuery.
If this is an internal\intranet application or you don't need to worry about SEO, then using Ajax to pull content in will be fine. It will help your pages load and render in the browser quicker but your data still wont be available. You are really just breaking the hard work into several smaller components but the same amount of work is going to be done either way.
If you just care about getting a page rendered in the browser so that it doesn't feel (to the user) that its taking forever to load, then this is a great idea. If that isn't the ideal outcome, you might want to focus your efforts on figuring out why its taking so long to load data.
Related
When designing a ASP.net WebForm application what are some important steps to take (or hacks if you like to use the term) to ensure the best possible performance (in terms of speed, stability, and scalability)?
Avoid round trips to server
Wherever possible user AJAX calls.
Implement Caching.
Avoid using Viewstate wherever possible
For further more read these links.
Improve Web Application Performance
ASP.NET Web Site Performance Improvement
Since so many things can affect performance, it's difficult to provide such a list. We may make assumptions about your code that aren't correct, and may focus on the wrong areas while you suffer poor performance from something we would otherwise take for granted.
Having said that, in general you might keep an eye on:
Don't over-use ViewState. (I'd argue not to use it at all, but that's another issue entirely.)
Keep page resources small (minified text, good image encoding, etc.).
Ensure page resources are properly cached once downloaded.
Try to move most UX logic client-side. (Avoid post-backs for things you can otherwise do in JavaScript, fetch data asynchronously where possible in small chunks, etc.)
The list can go on and on, and that's just with the web tier of the application. You could easily encounter site performance problems resulting from slow server-side code or server-side resource dependencies (database, etc.) that can't be debugged in the browser.
So the main point is to learn your debugging tools. Through combinations of browser tools (FireBug, Chrome Developer tools, etc.), Visual Studio debugging (or whatever else you may use for your .NET code), good logging, and even profiling tools you can identify your bottlenecks and tweak your system accordingly.
Check your website in google page speed :click
It will give your problem . for unwanted style.images and etc.......
If you care so much for speed, stability and scalability you might first question whether ASP itself is a good compromise
when it comes to performance of the web application we need to consider many things this article will help you understand what performance is where to start.
In web application 80 percent of the time it is front end which requires performance optimization, what needed to be optimized is a big question and really hard to answer
this article i found will help you understand the web performance optimization
Web Performance Optimization
Hopefully this question is not to confusing, but I can help clear it up and there is a definitive answer: Yes or No (and why of course). I develop a lot of internal intranet applications using ASP.NET Webforms targeted for the Windows Environment and IE. This allows things like Windows Authentication and the drag-and-drop ASP.NET server controls work extreamly well and the focus is typically on the function rather than the pazzaz or the look of the site; I'm not selling products here to the masses.
However some users are starting to use Macs, and as we know the default browser is Safari. Unfortunantly Safari does not support Windows Authentication. To add on, a lot of the out-of-the box ASP.NET server controls don't render properly as they do in IE. Plus I have to take into account all the differences I need in my .js as well.
Now looking at this from an internal busniess perspective, having a single enterprise platform is not uncommon, so assuming the users are on IE is not a problem. However as more Macs get introduced, bridging the gap to make these intranet web apps browser agnostic can be quite a difference in development time.
I was wondering if ASP.NET MVC has a leg up on this issue. I know it does not solve the Windows Authentican issue (chime in on this as well for solutions), but I was wondering since server controls were not being used like with web forms, if using MVC was the advantageous choice when trying to make web applications cross browser compatible? I don't mind doing MVC as opposed to webforms, and if there is documented or gained knowledge on why MVC works better for cross browser use, then speak to it. If experience shows the way that MVC renders its controls as opposed to server controls from webforms is better across different browsers, this is mainly what I am trying to detmine.
Does anyone know about this? Thanks!
ASP.NET MVC gives you more control about how HTML, CSS, and JavaScript is rendered because you don't have all of the built-in controls that render this for you. Since you have full control over these elements, you are more enabled for developing in a cross-browser manner. This puts more burden on developers. It's a classic power vs. responsibility trade off.
MVC does do away with the mangled html of server controls, the huge footprint of viewstate, and generally makes the rendered html much cleaner and more efficient. So to answer your question, Yes, MVC will make it easier for you to have clean html that stays just the way you wrote it, without having asp.net's rendering mangle everything.
Windows authentication is supported in Safari. If you are facing issues can you give some specifics.
The web form controls (with newer version of asp.net) usually work across browsers fine. The problem is when it doesn't, it is hard to track them down. I have also had issues where they didn't work well with IE6, tracking them and fixing them is little hard in Web Forms. But that is trade off if you want drag and drop controls.
With MVC, there is no concept of controls similar to web forms. You control everything that is delivered to the client, the HTML, CSS and Javascript files. You do have HTML helpers to render your models to corresponding HTML controls. The amount of extra code you will be writing will depend on the task you are trying to accomplish. Since you control all the assets delivered to the client it makes it easier to track bizarre one off browser specific issues.
Using MVC doesn't mean you won't run into cross browser issues, you will. It may be easier to fix but then if you are experienced in web forms you should be able to achieve the same results.
I have seen that ASP .Net Code Behind files are really slow. I have used local web services which I call from jquery ajax function and they are fast. But I am still confused? Should i display dynamic data from code behind or web services?
I let my web service return a JSON Object and I assign relevant elements from that JSON object to different html elements like (image, div etc.)
You need to weigh several things..
If you are dealing with a low-traffic, internal web application, perhaps server-side postbacks are the way to go. Often you'll find that there's less code you'll have to write in this case.
If you are working on an external, public, high-traffic web application, perhaps AJAX is the way to go. That way you avoid posting back entire ViewState and running through the full page lifecycle. This may result in more front-end code, but is less load on the web server.
Keep in mind that client-side data binding is a very viable solution these days, with the help of such things as jQuery Templates. So that helps bind data returned from AJAX calls to tables and other elements.
As far as web services go, they are great for when you're sharing data/functionality between different systems. If you don't foresee doing that for this particular application, then perhaps there's no need to over-engineer it - keep it simple with either MVC and Action methods that support AJAX calls out of the box, or get familiar with PageMethods.
I'm sure there are other pros/cons I haven't mentioned, but this is the first thing that came to mind.
ASP.NET classic life cycle and postback is the base of Microsoft Click&Go philosophy. It is not designed to be fast even if it suits in most cases.
AJAX plus Web Services architecture is good way to improve server performances and dynamicity. It may not improve client performances, may increase the network load if bad designed and complicate a website architecture.
Another possible orientation is ASP.NET MVC, where old life cycle and postback is ancient history.
Like Kon said, mixity is probably the best way at the moment : MVC+AJAX or ASP.NET+AJAX where classic client<->server requests are used for common functionnalities and AJAX requests brings dynamicity with small requests for friendly functionnalities.
Note that most users on the planet are using Internet Explorer who have the worst javascript engine on the planet ;)
I had 1/2 web application prepared. I had seen that the performance getting very slow when using the ajax control compare with using javascript but only when that is deployed on the server.
Why is this problem problem arriving when ajax controls used in application, performance sleeps & not opens the pages quickly.
What is the solution for this to improve performance when ajax control use & it deploy on the server.
Regards,
Girish
Yes.
Well, the reason it's slower when you deploy to the server is because the ajax requests now have to go over the entire internet. This is different compared to running locally, when the requests do not go over the internet.
How to speed it up?
Make less calls.
Return more things per call so you can make less in general
Return as little as possible, in a condensed format if possible
Consider enabling gzip on your server
other such things
Take a look at the improvements made for stackoverflow: https://blog.stackoverflow.com/2009/08/a-few-speed-improvements/
The other answers are good for general optimization, but I'm thinking there's an inherent problem with your understanding of the request flow in your application. For all intents and purposes, "ajax" is javascript.
The first and most important thing you can do is get Firefox and use firebug.
This will allow you to see what requests are made to the server, how long they take, and much, much more. This will give you a better understanding about the performance of the two different versions of your app.
You need to better understand your problem before we can really help you.
Consider using the ToolkitScriptManager instead of ScriptManager, it will merge all the requests for AJAX controls in a single request. This will increase the performance since there are less requests. Also, make sure that you have set the in the WebConfig when moving to the production server. When debug is set to true, the performance slows down dramatically.
I'm planning a ASP.NET project for which I'm going to use AJAX. I'm researching all the available technologies for doing so in the .NET world.
I need a solution that is well documented and stable.
The current solutions I've found are:
1. ASP.NET AJAX UpdatePanel
2. ASP.NET AJAX with Web Services + JQuery
3. JQuery + Http Handlers
In the second and third solutions the backend would only send JSON or XML messages to the client.
In my experience the best way to go is JQuery with WCF with JSON webservices.
The reason is:
ASP.NET ajax is gives you alot for free in terms of coding but is bloated from the start and needs to be stipted and slimed. On the other hand you have JQuery that you needs more development but is light weight. JQuery has a great plugin library as well.
XML is to slow, JSON is fast.
Thats how I would do it today.
All will work but I've had most performance and stability with using JQuery and a script service.
An update panel will work but as its designed to work in the general case it can be a little bloated if you aren't careful. One reason being is that it posts the viewstate back with each update.
I recommend you check out the site: encosia.com as it has a number of posts on how to use script services and page methods. Then you can make a more informed decision. I would say that I've not used page methods and probably won't but that's entirely for personal reasons.
One other thing to consider will be any mvc you may end up doing. The general consensus is that it's a whole lot easier with JQuery. Added to that Microsoft have officially adopted it and also provide intellisense in VS2008.
All compelling reasons to include at least some of it in your project. In mine I only use the built in ScriptManager when I absolutely have to.
HTH!
S