One can also use Advanced HTML Optimizer from
www.aevita.com/web/htmlopt
I have personally used this utility and kind of liked it.
P.S. I am not advertising.
Discussion on:
View:
Show:
I need to optimizer a collection of Intranet applications built in ASP.NET. Does anyone know of good tools to accomplish this?
so you are recommending speeding up page times / reducing complete two way transmitions by using a constant [ high data transfer usage ] AJAX solution?
definately not a great solution option.
you wind up costing both the site owner and the client more data transfer, since you increased logarythmically the data transfer the site uses.
kill a connection completely let the client's browser cache serve to reload images and css, but don't suck data transfer with bloat like ajax.
definately not a great solution option.
you wind up costing both the site owner and the client more data transfer, since you increased logarythmically the data transfer the site uses.
kill a connection completely let the client's browser cache serve to reload images and css, but don't suck data transfer with bloat like ajax.
By the time you add in the cost of the the round trip including processing and rendering, you don't need to use it that much before the benfits go negative.
Done correctly, AJAX can greatly increase application responsiveness by reducing the amount of data sent back and forth and reducing the amount of page rendering done by the browser.
For example, consider a tabbed interface where clicking on the tab changes only the contents of the tab instead of re-sending and re-rendering the entire page (header, footer, other body, and the tab contents).
An excellent example of this is TechRepublic's new tabs. That is exactly how they work. On the Forums page, the Discussions, Questions, Posts from My Contacts, and Browse tabs use AJAX that way. And, in the right column, the Recommended, Contacts Online, and My Updates tabs use AJAX that way.
For example, consider a tabbed interface where clicking on the tab changes only the contents of the tab instead of re-sending and re-rendering the entire page (header, footer, other body, and the tab contents).
An excellent example of this is TechRepublic's new tabs. That is exactly how they work. On the Forums page, the Discussions, Questions, Posts from My Contacts, and Browse tabs use AJAX that way. And, in the right column, the Recommended, Contacts Online, and My Updates tabs use AJAX that way.
with CSS you can have the contents of each tab in the cache from loading the site, mouseover and it's visible.
why send a request and wait for the response, sucking data transfer up constantly, by using ajax?
with ajax being a persistent connection it is a data transfer EXPENSIVE technology.
it is not a reduce data transfer technology in the slightest.
why send a request and wait for the response, sucking data transfer up constantly, by using ajax?
with ajax being a persistent connection it is a data transfer EXPENSIVE technology.
it is not a reduce data transfer technology in the slightest.
.
"with CSS you can have the contents of each tab in the cache from loading the site, mouseover and it's visible."
Yes. Sometimes loading all the tabs at once is a better approach. But for tabs with dynamic content like on TR, AJAX is much better.
"why send a request and wait for the response, sucking data transfer up constantly, by using ajax?"
AJAX is not right for everything. You have to implement it appropriately, just like everything else you do. But, for dynamic tabs it is a good choice. Clicking on the tab gives you a quick update to just that tab without reloading the entire page or the other tabs.
"with ajax being a persistent connection it is a data transfer EXPENSIVE technology. it is not a reduce data transfer technology in the slightest."
AJAX is not a persistent connection. It communicates over HTTP just like other things the browser gets from a web server. JavaScript sends a request over HTTP and receives a response over HTTP. Each one looks much like a web page except the content of the "page" is XML with data or some other such.
Depending on the page, only receiving an update to a portion of the page can significantly reduce the amount of data sent across the wire. A good programmer can easily use AJAX to accomplish this. A poor one can abuse AJAX and produce a poor result (just like any other technique).
"with CSS you can have the contents of each tab in the cache from loading the site, mouseover and it's visible."
Yes. Sometimes loading all the tabs at once is a better approach. But for tabs with dynamic content like on TR, AJAX is much better.
"why send a request and wait for the response, sucking data transfer up constantly, by using ajax?"
AJAX is not right for everything. You have to implement it appropriately, just like everything else you do. But, for dynamic tabs it is a good choice. Clicking on the tab gives you a quick update to just that tab without reloading the entire page or the other tabs.
"with ajax being a persistent connection it is a data transfer EXPENSIVE technology. it is not a reduce data transfer technology in the slightest."
AJAX is not a persistent connection. It communicates over HTTP just like other things the browser gets from a web server. JavaScript sends a request over HTTP and receives a response over HTTP. Each one looks much like a web page except the content of the "page" is XML with data or some other such.
Depending on the page, only receiving an update to a portion of the page can significantly reduce the amount of data sent across the wire. A good programmer can easily use AJAX to accomplish this. A poor one can abuse AJAX and produce a poor result (just like any other technique).
Doesn't does it, increases them.
Done correctly the amount of data pulled in each cycle will be reduced, but more responsive in server side means more round trips.
If the overhead on a round trip is a sizable %age of a request response cycle, things will get worse not better, the more use you make of it.
This site is quite slow in some respects when things are busy.
Done correctly the amount of data pulled in each cycle will be reduced, but more responsive in server side means more round trips.
If the overhead on a round trip is a sizable %age of a request response cycle, things will get worse not better, the more use you make of it.
This site is quite slow in some respects when things are busy.
AJAX is not right for everything. But, it can be a good choice.
Employing AJAX does not typically reduce the number of round trips. And, it can be misused just like any other technique.
AJAX can reduce the size of the round trips. In the TR dynamic tabs example, it is an excellent choice because it avoids a full page reload. When the choice is a full page reload or a partial page reload, the partial page reload is preferable. It reduces load on the server, reduces load on the client, and reduces data transmission. Win, win, win.
TR was often slow and non-responsive before it had AJAX. I don't think the problem has anything to do with AJAX.
Employing AJAX does not typically reduce the number of round trips. And, it can be misused just like any other technique.
AJAX can reduce the size of the round trips. In the TR dynamic tabs example, it is an excellent choice because it avoids a full page reload. When the choice is a full page reload or a partial page reload, the partial page reload is preferable. It reduces load on the server, reduces load on the client, and reduces data transmission. Win, win, win.
TR was often slow and non-responsive before it had AJAX. I don't think the problem has anything to do with AJAX.
getting put up, by the same eejits that stick a 500k flash presentation on the home page.
You know the "It ran great on my workstation in the office" manoeuvre
These 48 update panels here give you a wonderful browsing experience except if you don't have 16 gig of ram and a gigabit lan connection to the server under your desk.
You know the "It ran great on my workstation in the office" manoeuvre
These 48 update panels here give you a wonderful browsing experience except if you don't have 16 gig of ram and a gigabit lan connection to the server under your desk.
Other discussions on TechRepublic point out that the use of frames can improve performance when only one frame out of several is refreshed with a new document. That is, navigation to a new page can be designed to only download the main content of the new page, not navigation, headers, and other decorations.
the firat hit to the site a frameset is a page per frame plus one extra page.
the problem is that most people didn't set frames up correctly, nor did they style the page to be a nice interface with them.
Frames are a decent tool, but were badly implemented on sites, and way over used, just like flash, table based layouts, animated images have all been over used and are driving site visitors away.
the problem is that most people didn't set frames up correctly, nor did they style the page to be a nice interface with them.
Frames are a decent tool, but were badly implemented on sites, and way over used, just like flash, table based layouts, animated images have all been over used and are driving site visitors away.
Look, typical webpages don't need to do complex tasks.
Menus -> CSS
Formating -> CSS
Dynamic Content -> depends...I prefer Perl
Client side scripting needs to die. It not only is typically very costly for both the client and server, but it's become redudantly redundant.
I can do about 99% of all web tasks with server side scripting, and I can do it more securely than with client side scripting (you never know what the client is going to send back...)
Menus -> CSS
Formating -> CSS
Dynamic Content -> depends...I prefer Perl
Client side scripting needs to die. It not only is typically very costly for both the client and server, but it's become redudantly redundant.
I can do about 99% of all web tasks with server side scripting, and I can do it more securely than with client side scripting (you never know what the client is going to send back...)
Guys, I think we are moving away from the topic at hand. The main goal is to optimize the pages. I don't think there is right or wrong here. If the benefits outweigh the negatives then use AJAX, otherwise do entire page postbacks... whatever works more efficiently for your particular task at hand...
As far as overusing JavaScript and other things, this is what we get for trying to make things more dinamic and trying to maintain state in a stateless protocol. In my opinion, we shouldn't have to do "workarounds" for deficiencies (so to speak) in an outdated protocol. They should really sit down and come up with a protocol that supports a stateful environment and allows us to maintain communication in an efficient manner. After all, connection speeds are increasing allowing for greater data transfers.
We are giving this model uses way beyond its original intended purpose, so what are we complainting about?
As far as overusing JavaScript and other things, this is what we get for trying to make things more dinamic and trying to maintain state in a stateless protocol. In my opinion, we shouldn't have to do "workarounds" for deficiencies (so to speak) in an outdated protocol. They should really sit down and come up with a protocol that supports a stateful environment and allows us to maintain communication in an efficient manner. After all, connection speeds are increasing allowing for greater data transfers.
We are giving this model uses way beyond its original intended purpose, so what are we complainting about?
stateful interaction, but we keeping trying to work round lack of state over http instead of using them.
My whinge was that ajax reduces round trips. It doesn't, it makes your page more dynamic by increasing the number of them.
Picky I know, but it's that sort of innaccuracy that helps keep us in teh situation you describe.
My whinge was that ajax reduces round trips. It doesn't, it makes your page more dynamic by increasing the number of them.
Picky I know, but it's that sort of innaccuracy that helps keep us in teh situation you describe.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
