wood burning stoves 2.0*
The moose likes HTML, CSS and JavaScript and the fly likes cache could speed-up IE rendering? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » HTML, CSS and JavaScript
Bookmark "cache could speed-up IE rendering? " Watch "cache could speed-up IE rendering? " New topic
Author

cache could speed-up IE rendering?

Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
My JSP page is very slow, there is a big html table. To optimize this page, could I cache the table head ? this cache could speed-up IE rendering? If yes, how to cache ?

Thanks.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60058
    
  65

Caching where? On the server? That won't help rendering times. On the client? You don't have control over that.

If your table is what is causing the problems, consider this: in addition to creating performance issues, is your huge table also creating usability issues? Are you feeding your users more data than they could possibly know what to do with?

My apps never show large amounts of data. Rather, they allow the user to pick and chose what data they want to see via filtering, and then any large data sets are presented using paging (where only part of the data is shown until the user asks for more).

You could possibly solve two problems by considering these techniques.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
I totally agree with you: use paging to improve performance. but user doesn't like this, they like huge table and huge data.

So we have to think about cache. I am confusing of the cache, the cache is in client side or server side ? Page static data is cached in user computer, like cookie or server side ? if it is server side, then no any help to IE rendering.

Thanks.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60058
    
  65

If it is your requirement to show the entire huge table then caching isn't going to help you with rendering times. Even if you were able to store the markup somewhere (a cookie with its limitations probably isn't going to cut it), IE is still going to need to parse and render the markup. I'm not sure if there are any IE-specific tricks that you might use, but I know of none.

One thing you can do is to simplify your markup. Do you have elements that are repeated for each table element that could be factored out? Do you have stylistic tags like <font> that should be handled by CSS? Are you including CSS styles in the markup? What about script? Could applying the precepts of Unobtrusive JavaScript help? Is your HTML well-formed? And so on...
[ January 17, 2008: Message edited by: Bear Bibeault ]
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29257
    
140

Originally posted by Edward Chen:
I totally agree with you: use paging to improve performance. but user doesn't like this, they like huge table and huge data.

Can you offer the large dataset as a download (Excel or even big HTML page if that's really what they want) ? This allows a preview to return quickly. It also sets expectations. People are willing to wait longer for a download than for a web page (where 8 seconds is a lot)


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60058
    
  65

Great idea, Jeanne! PDF downloads for large data are becoming common too.
Bryce Martin
Ranch Hand

Joined: Nov 19, 2007
Posts: 269
I have the same issue right now with my web app. They want me to return the search results without paging. We gave them the option. We said to them, "look, if we do this it could take a minute or two for the page to load if your search returns alot of information, if we use paging it would be quicker." But they didn't want it, so we gave them what they asked for. If they use it and decide they want the paging, then we'll add it later on. But it will have to go through the project cycle and may take a little bit of time before its implemented. We let the user make the choice and now they have to live with it. There needs to be some accountability or else they won't ever learn to trust your suggestions.

Load the table up. There isn't anything you can do to render it any quicker. I fought with efficiency issues for a couple weeks and found that because the way the browser renders tables there is nothing you can do. They have to render the whole thing before it displays it. For large tables that's the price you pay.

I hope this helps. My $.035, stinking inflation.
Bryce Martin
Ranch Hand

Joined: Nov 19, 2007
Posts: 269
I just had a thought when I took a potty break...

You could try this...haha, i'm so psyched I thought of it...

Create your table in your markup. Just leave it empty. Then use the jQuery $(document).ready() to do an AJAX call to a servlet that returns your data via JSON. But you can do it in a virtual paging sense. Do it as if the user was clicking a next button. Pass over the index just like paging and return like 50 results at a time. And when jQuery is done doing its .append() inside the table it calls the ajax call again but with the index incremented by 50. This would load the table straight away with very little wait. Then the table would just keep growing until all results were finished loading.

See where I'm going with this?
I would call it virtual paging. Basically automatically running paging code except you append to the table instead of replacing it

I REALLY hope this helps.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60058
    
  65

That is exactly the tactic that Google maps uses. As you pan around the map, it calls back to the server to fetch the needed map tiles.

Though I would think that clients who would diss paging, would also balk at having to press a "next button".

It might be acceptable however to show the first part of the table, and while the customer is looking it over, automatically go back to the server to fetch the rest and fill it in gradually.

I've used this tactic for few similar things successfully.
Bryce Martin
Ranch Hand

Joined: Nov 19, 2007
Posts: 269
So I'm not the first one to think of it, but I know in all that i've looked around I haven't seen this technique mentioned. But yeah, going back to the server after some initial page load an loading the rest is exactly what this would be doing. I'm going to be working on implementing this in my web app right now it will be a nice enhancement that the users will think is just a speed improvement. Ohh us tricky programmers
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60058
    
  65

It's a great idea, and kudos for thinking of it, but no, you are not the first. But the fact that your clients will benefit from it is all that matters.
Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
Simple question,
In a 30*57 table, what is reasonable expectation of IE rendering ? How long it should take ?

Thanks.
Bryce Martin
Ranch Hand

Joined: Nov 19, 2007
Posts: 269
I did a 8 X 4000+ and it takes 2.5 to 3 minutes. Depending on what I'm running on my machine and how big I have the cache set up for IE. I would suspect that your table only takes 10-15 seconds at most. And in some cases I wouldn't expect it to even take that long. Its only 1700 cells. As opposed to my 32,000 or more. How long is it actually taking you?
Eric Pascarello
author
Rancher

Joined: Nov 08, 2001
Posts: 15376
    
    6
It all depends one what te computer is doing [do they have 50 applications running?], what their CPU/RAM/OS is, and so on. There is no real numbers.

A9.com has lazy loading with its requests. Give it a try.

Eric
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Before trying to find the fix, you should spend some time finding the bottleneck.

With a real big table like that, a good place to start is the network.
Are the users accessing the server on a fast subnet, DSL, Dialup?
If they're on a slow network then gzipping the data could cut down the size of the data transfer significantly.

If they are on a fast network, you might want to find out how long the database is taking to return your results. Maybe a stored procedure or a view that has a lot of the query plan prepared already (or simply tuning the query) will speed things up.

You really can't say how to fix something until you know what, exactly, the problem is.

I often wonder if customers really want a page that large or if they just don't understand the available alternatives.
[ January 18, 2008: Message edited by: Ben Souther ]

Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
Bryce Martin
Ranch Hand

Joined: Nov 19, 2007
Posts: 269
I've done all that you have suggested. I've run through the web app from top to bottom testing for bottlenecks. The fact of the matter is that I can return a 4000+ resultset from our server and pump it into a list of beans in a second or two. But when the page builds it just takes a long time for the browser to render that much info into a table. I'm using Servlets, JSP, and JSTL to build this stuff on the fly and its really a browser problem. I'm running windows xp pro, 2.4 ghz, 1gig ram and I have Lotus Notes, WDSC, and a browser up. Maybe a client access session. And when I run it off my localhost web server it takes about 2.5 minutes. When its up on the production box it will take maybe a minute or around there. Like I said, I spent about a week and a half or two weeks making sure I didn't miss something. Large table renders are just killer on a browser.

As far as letting the users know their options...I couldn't explain it any more to them. They wanted what they wanted, so they'll have to live with it. And that is what they have been told.

But, I can't help but still try to find a way to make it better for them even in their seemingly bad decision.
Eric Pascarello
author
Rancher

Joined: Nov 08, 2001
Posts: 15376
    
    6
Have you also validated your code to make sure that there are no errors that can cause issues?

Type in "W3C validator" into a search engine

Eric
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Originally posted by Bryce Martin:
I've done all that you have suggested. I've run through the web app from top to bottom testing for bottlenecks. The fact of the matter is that I can return a 4000+ resultset from our server and pump it into a list of beans in a second or two. But when the page builds it just takes a long time for the browser to render that much info into a table. I'm using Servlets, JSP, and JSTL to build this stuff on the fly and its really a browser problem. I'm running windows xp pro, 2.4 ghz, 1gig ram and I have Lotus Notes, WDSC, and a browser up. Maybe a client access session. And when I run it off my localhost web server it takes about 2.5 minutes. When its up on the production box it will take maybe a minute or around there. Like I said, I spent about a week and a half or two weeks making sure I didn't miss something. Large table renders are just killer on a browser.

As far as letting the users know their options...I couldn't explain it any more to them. They wanted what they wanted, so they'll have to live with it. And that is what they have been told.

But, I can't help but still try to find a way to make it better for them even in their seemingly bad decision.


What about the network?
Are you on a subnet or are you accessing this over the internet.
If the latter, does your container have the ability to gzip the response?
If so, have you tried turning it on?

Large text files and streams compress nicely and doing so could cut down on the size of the transmission by more than 2/3.
Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
Originally posted by Bryce Martin:
I did a 8 X 4000+ and it takes 2.5 to 3 minutes. Depending on what I'm running on my machine and how big I have the cache set up for IE. I would suspect that your table only takes 10-15 seconds at most. And in some cases I wouldn't expect it to even take that long. Its only 1700 cells. As opposed to my 32,000 or more. How long is it actually taking you?

I am taking 8 seconds end-to-end. Reasonable ? I am trying to get 4 seconds...
Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
Originally posted by Ben Souther:
Before trying to find the fix, you should spend some time finding the bottleneck.

With a real big table like that, a good place to start is the network.
Are the users accessing the server on a fast subnet, DSL, Dialup?
If they're on a slow network then gzipping the data could cut down the size of the data transfer significantly.

If they are on a fast network, you might want to find out how long the database is taking to return your results. Maybe a stored procedure or a view that has a lot of the query plan prepared already (or simply tuning the query) will speed things up.

You really can't say how to fix something until you know what, exactly, the problem is.

I often wonder if customers really want a page that large or if they just don't understand the available alternatives.

[ January 18, 2008: Message edited by: Ben Souther ]

I am testing with my local server, so network is not a problem. Sever side is using 2 seconds, 6 seconds is used for page rendering. My table is 30*57.

Thanks
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12682
    
    5
Does it really have to be one logical HTML table?

Since the browser won't try to render a table till all the parts are resident, how about using multiple tables formatted to look like one continuous table?

If the first screen-full comes up quickly that gives them something to look at while the remaining parts are being loaded.

Bill


Java Resources at www.wbrogden.com
Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
Originally posted by William Brogden:
Does it really have to be one logical HTML table?

Since the browser won't try to render a table till all the parts are resident, how about using multiple tables formatted to look like one continuous table?

unfortunately, it is ONE table. it uses table as page layout structure. Looks like it is a bad design. what is your page layout ?


If the first screen-full comes up quickly that gives them something to look at while the remaining parts are being loaded.

Bill

Good idea. Do you know how could I know the sequence of IE rendering, like IE rendering log ?

Thanks
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60058
    
  65

it uses table as page layout structure

Oh.

Lessons earned. Is this something you can fix, or something you got stuck with?
Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
Originally posted by Bear Bibeault:

Oh.

Lessons earned. Is this something you can fix, or something you got stuck with?

I can't change this. too many job. If not use table, how do you structure page layout ?

Thanks
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60058
    
  65

Originally posted by Edward Chen:
If not use table, how do you structure page layout ?
CSS.
Bryce Martin
Ranch Hand

Joined: Nov 19, 2007
Posts: 269
You are getting the times that I would suspect for your table size. Try using <div> tags and CSS to style your page.

I'm on the intranet here. Connection speeds are not an issue. An 8 column by 4000 row table is just plain massive for a browser to render. I've timed it by commenting out my jstl table generation and it returns in less than 2 seconds. But when I put the table generation in it takes a nice long time. I want to implement an ajax build of the table so that the page loads and they have something to look at while the table continues to load. All in good time though...as some of you know I have some other bugs I'm working on
Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
Originally posted by Bryce Martin:
You are getting the times that I would suspect for your table size.

The html file size is 189293 bytes.

Ajax is nice, but I think it is bug prone and costs too much to make this change.

Most doable things are, to use CSS div to structure layout and to implement user preference of showing/hiding some columns.

Thanks.
Bryce Martin
Ranch Hand

Joined: Nov 19, 2007
Posts: 269
Bug prone? Costs to high to change over? How so? If you use a javascript library like jQuery it does everything for you. Its cross browser compatible and extremely stable. I have yet to have a bug using it, and I'm a beginner (I know how to break things like this).

Good news though, at the end of the day yesterday I got the go ahead from my boss to implement a table with paging. No more messing with these stupid long loading time issues. I'm so pumped it get it moving today

AJAX is fast, stable, and proven. There are a few different libraries out there now that make it extremely easy to implement. Look into jQuery, and if you don't like that then look at Prototype. The learning curve is less than if you spend your days sitting around here posting about not doing it

Best of luck
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60058
    
  65

Ajax is nice, but I think it is bug prone

As Bryce pointed out, Ajax is quite stable. People can write bug-prone code using Ajax -- but they can do that with any feature. Do you have information that backs up your assertion?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: cache could speed-up IE rendering?
 
Similar Threads
How can IE not cache page
f:ajax does not render in IE 8
How to preload a signed applet without user being asked security question?
body onload() alternative
Page Number on JSP