We're building a web application that has a page where the user sees a large table of editable items. This table has controls on each row to move the row up/down and the option to delete the row. Each row also has two select elements.
This table could consist of around 200 rows in extreme circumstances, it is when we have lots of rows that we run into severe performance problems. The page is incredibly slow to scroll up and down and we see "checker-boxing" on the screen, also deleting a row takes around 30 seconds, sometimes more! Moving up and down takes a similar amount of time, and the page is generally unusable.
We've been trying to narrow down exactly what the problem is and we're pretty sure it is to do with the select elements in the table - if we remove these from the rows; scrolling is perfect, moving up and down is ~1 second and deleting a row ~7 seconds.
If we delete a row from the bottom of the 200 row table, it is near instant.
It seems like the problem is to do with the CSS on the page, when we run the profiler it is the re-calculating of styles that is taking around 3 seconds.
The page performs fine in other browsers, any help/knowledge would be great.
Thanks
We have several tables in our Web App for iOS 6, some of which contains several hundreds of rows as read-only with just text, but some contains SELECT elements as well.
Setting the table-layout to fixed had a tremendous impact on the performance. Some of the larger tables had major rendering problems with the default dynamic table width calculation, which we didnt overcome so far. This was especially the case when a row contained checkboxes.
Some tables didnt render the last line for example, or the table was cut off anywhere near the bottom, and so on.
We use a special stylesheet for the portrait mode, which changes the width of the TABLE and TD elements and which completely removes some of the columns as well.
This works really fine and had caused no side effects or problems so far.
For scrolling, we use a special DIV element surrounding the table which has a defined height and is using "-webkit-overflow-scrolling: touch". Even the largest table with around 850 entries scrolls without any loss of performance or flickering.
When do you render the table? During the page rendering/ ready/ load Event?
Do you use an "innerHTML" assignment or do you create the DOM tree in the logic?
Setting table-layout:fixed; as a style property on the table (in your stylesheet) might make it more respond faster. The browser has to do less calculations, downside is you have to specify column widths yourself.
Related
I have created a report , which do what it is supposed to do (or almost)
One thing that still bugs me is the following
On some pages , I have 4 boxes (see below)
On other pages, I have 5 boxes (see below).
The number of boxes can change depending on unknown variables/factors.
I would like to have 5 boxes in every page. I'm not sure how to do that. I checked on google and all that came up was some trick to have a fixed number of rows, which is not what I'm looking for
http://www.sqlchick.com/entries/2010/9/11/displaying-fixed-number-of-rows-per-ssrs-report-page.html
Thanks for any insights you will be able to provide me , with.
The fixed number of rows solution that you linked to in your question is actually partially what you want. Your "boxes" are presumably repeating based on rows in a dataset, what you are asking to do is ensure that exactly five rows appear on each page. The linked solution uses an extra parent RowGroup to force a page break after n rows, which will ensure there are not more than n rows per page.
However the issue you are seeing is that sometimes there are four rows per page and this will be because the combined content of the rows ("boxes") is larger than a single page and therefore when the report is rendered the rendering engine is forced to split it onto a new page. The only way to avoid this is to either ensure that five rows of content is never larger than a page (e.g. by shrinking fonts or changing layout and/or setting the CanGrow property to False on relevant report items), or by mandating a lower number of rows per page (e.g. 4 or 3) when setting up the parent row group that forces the page breaks.
While making a webpage I've noticed a huge decrease in performance(client side) when I've added more rows to a table. Each row in my table consists of the same 4-5 different 32x32 icons (links to actions) and about 100 characters. When there were 10 rows, the webpage run fluently - scrolling and jQuery animations were smooth. Now that my table has 100+ rows (pagination is not an option), the animations are really slow and rough.
Is there a way to optimize not the images themselves, but the code, to raise performance?
Right now I have images in tags. Will it make any difference if I will change them to with background-image? Will the browser be less loaded?
If images are the problem, it is likely because the client is trying to re-download the images for each row, which is very inefficient even though the images are small. You can test if this is true with a tool such as Fiddler by checking if you get a whole bunch of the same requests every time you reload the page.
If this is the problem, look into CSS sprites. With this method, you can deliver 1 image to the client, and this one image will be used to render all of your icons on all your rows.
A practice I commonly use when manipulating content on websites is to absolutely position elements with a left (or sometimes top) value of around -2000px, so as to ensure it won't be seen on screen.
Now, I know I could use display: none to make my objects disappear, but some elements don't play nice when not displayed, and sometimes I need to make a reference to some property like its width, for example, which can't be accessed when the display property is set to none. So often I will position the element so it is hidden ofscreen.
My assumption, then, is this:
Since the object is not rendered on the screen there should be no difference in the performance of the website* when I use left: 2000px as opposed to left: 200000000px.
So I assume that if the following code is used, there would be no difference in the performance of the two pages:
Page one:
<div style="height:100px; width:100px; left:-2000px"></div>
Page two:
<div style="height:100px; width:100px; left:-200000000px"></div>
Are my assumptions correct? If that element were the only difference between two given pages, would there be any difference (however small), in performance?
*That is to say load time, page size, responsiveness, or any other measure of performance
=================================
Update
I have profiled the pages as suggested by Michael and found the following: Spark was correct in saying that the load time would be affected by the file size. There was a difference of four bytes in the file size which corresponded to a difference of about 4ms in load time.
Secondly, my incredibly large left value was interpreted correctly by IE and Firefox, but not by Chrome. Chrome doesn't seem to recognise values greater than around 135 million pixels. However, given the performance difference seems to be minimal, I can't speculate as to why they would have decided to limit it to such an arbitrary amount.
You can attempt to profile the page load time with Firebug (or Chrome/Safari Developer tools), but I would be extremely surprised if there was any difference at all. The browser cares about the x,y,z coords of an element. It doesn't matter if those are on or off the screen; they are still just three discrete data points.
When you say performance do you mean load time?
Load time of the CSS could be effected if you could measure the difference in bytes left:-2000px vs left:-2000000px then yes, it would take longer to load the latter, but this has nothing to do with it being "off screen" just the CSS size.
So the long answer is not putting it off screen makes no difference you still have to load it, however the bigger the value, the longer it takes to load. Tho in this case it's so small it not really an issue.
For example load times...
left:-2000px = Input: 0.021KB, Output: 0.019KB
left:-2000000px = Input: 0.025KB, Output: 0.024KB
im making a memberlist for my website, we got 500+ members and want them on 1 page. we used tables before but this makes many dom elements and firefox says it gets slow.
is there a way to make a list with 3/4 colums with css to avoid the nr. of dom elementst?
greets. stefan
In cases like this, the best way to display 500 elements is with Javascript. Having 500 records as JSON is not that big of a memory hog, totally acceptable. You'd have to make a dynamically updating table that takes the records from memory and displays only 40 rows at a time. You could also implement search etc in JS to make it more user friendly.
I've recently been developing an application using tables with a large number (hundreds) of rows. The rows contain tabular data and each row contains two drop down lists as well as link which displays hidden table rows directly below it.
I am currently experiencing lengthy delays when attempting to select a value from the drop down, and when displaying the hidden table rows.
Is the table the source of my problem here?
From what I gather, HTML tables can be appear to be slow to render if widths are not explicitly stated. If they aren't, the browser has to finish loading the contents of the cells before it can calculate the correct widths.
MSDN has some information here on their "Building High Performance HTML Pages" article that may help; they suggest the following (regarding tables specifically):
Set the table-layout CSS attribute to fixed on the table.
Explicitly define col objects for each column.
Set the WIDTH attribute on each col.
The problem is more than likely the rendering of the controls (100 select boxes) rather than the table layout. How many items are there in the drop down list? Does it perform the same way in all browsers on different operating systems?
Sorry to be so vague but generally tables aren't slow to render, but are looked down upon because of their lack of accessibility (although of course much of the idealism is the fact screen readers don't like them).
I can state from experience that it's almost certainly the dropdown lists that are causing the slowness. Tables with hundreds of rows can render almost instantaneously if they only contain text, but add a dropdown list to each row with just a few dozen options, and now even 50 rows will take a noticeable amount of time.
Try to design around the need for dropdowns in the table rows - if this is a form (and why else would you have dropdowns?), have the user select the row they wish to edit, and then put the editable controls only in that row, either via AJAX if you're into that sort of thing, or a more traditional "detail view" approach.
I've not noticed any slowdowns when displaying static tables with a few thousand entries, but adding effects like sorting or dynamic zebra-striping can quickly bog down even a modern browser on a fast computer. Make sure you're not running any JavaScript iterations across the entire table.
Whatever you come up with, test the approach in a couple of browsers on a couple of platforms, with some slower machines. I once had an app that was speedy everywhere except in Safari for Macintosh. It turned out to be something about the way it rendered the dropdowns. There's just no substitute for experimentation. Uhm, I meant testing.
If you know how wide each column should be, try specifying table-layout: fixed in the CSS for the table and see if that makes any difference (it should stop the browser trying to re-render the whole table just because you've toggled visibility on a few rows.)
IE does not handle very large DOMs manipulations well at all.
If you have two selects in each of the rows and a link, and let's assume each select has 5 options that's (((5options + 1select) * 2) + 1 link + 3tds + 1tr) at least 17 DOM items per row. Plus, if I'm not mistaken, ie treats each text item as it's own DOM node. So add another 10 DOM nodes for the drop down text and 1 for the link, that's 28 DOM items per row.
I agree with the others that it's not only your table that is causing the slow loading but the population of the dropdown list as well.
If it helps you can try paginating your table. You can use JavaScript frameworks such as jQuery or extjs for pagination and AJAX.