I have a big HTML table (~10K rows, 4 columns, text only) dumped from a database. I'm experiencing poor performance when opening it in Chrome/Firefox.
I do not have direct access to database, so it is impossible to load page by page. All data is static HTML.
Does pagination with some jQuery plugin help improve performance in this case? Any other suggestions?
When applicable, setting table-layout: fixed helps in reducing rendering time a lot. The slowness is mostly caused by the fact that in the default table layout method, the browser has to parse and process the entire table, calculating width requirements for all cells, before it can render any part of the table.
Fixed layout tells the browser to set column widths according to the first row (paying attention to any CSS that may apply to it). This may, of course, result in a mess, if the widths are not suitable for other rows. For a data table where rows are generally very similar, the widths can probably be set suitably.
This does not change the issue that very few people, if any, are going to read all the 10,000 rows. People will probably be looking for some specific data there. It might be better to set up a search form that lets the user get just what he wants.
I had a similar problem and made a jQuery plugin:
https://github.com/lperrin/infinitable
To use it, you can load all your data with Ajax call, turn it into a huge array, and pass it to the plugin.
It basically hides cells that are not visibles, while making it easy to sort or filter cells. There are other solutions to achieve that, but this one has no dependencies besides jQuery.
The project contains a demo with a table containing 100,000 elements.
Pagination would most certainly solve this problem. You could also try initially setting the table style to display: none. Although the pagination should likely take effect before the browser attempts to render the table.
You could also store the table in a separate html file, do an ajax call to the document, and implement live scrolling. Although, this depends on how you expect the user to explore the data. If jumping to a particular rage like 100-199 is useful, a paginated table would be ideal.
Related
Suppose we have two tables, one is Paginated and other is Scrollable. Both have them allow sorting of records by clicking on any column header.
Let's suppose the table has 5000 records of 6 columns. When the user clicks on any of the column to sort, my understanding is that the whole 5000 records will get sorted and my table state will get updated.
In case of Pagination, since I am only rendering 10 records/ page, the rendering will be fast.
In case of Scrollable table, since I am rendering the whole 5000 records, the rendering will be slow.
I have a project to make ahead and it may involve a huge records of data and column sorting is a mandatory feature. I want to validate whether my understanding of rendering speed for this use case is right or not?
What kind of optimizations are available in either cases for me to know?
Follow up:-
Do I actually need react-window or react-virtualized if I am anyway going for Pagination of table?
You are correct in thinking that Paginated table will be faster with rendering than an enitre table rendered with 5000rows. Also an table with 5000rows is likely to cause your browser to slow down due to a large set of elements in the UI
However there is very little performance difference if you use concepts like virtualization or windowing wherin you render only that amount of data as is coming in a view. This is much faster and optimized.
Now if you come to UX point of view. A user is likely to find a paginated table with column sorting much efficient as compared to a scrollable table.
There are three main reasons because of which I would go with a paginated table with sorting on columns
Its easier for users to jump pages when they want to visit an old data instead of scrolling all the way down to it. This is one of the most strong reason for me
When you use Pagination and the user decides to change the sorting order, it might get trickier to maintain scroll if you decide too. However pagination goes along smoothly with it. Either you stay on the same page or you move the first one. In either case it easy to implement
If your data grows, keeping all the data on client side may become an overhead. In such cases its better to depend on a API to get the data. Now virtualization with fetching data on the go can sometimes become tricky and need lot of special attention and details on prefetching
In short its better to go with Pagination both because of UX and Implementation reason for a large table
I think the optimization here here is not a problem, both of the ways could be done with equal performance.
You mentioned react-virtualized - it's common to use it as a solution for scrollable tables with good performance, it gives you ability to render only these fields that are actually required.
I have a table with thousands upon thousands of rows with 4 cells in each.
https://streamable.com/pywk9
You can see above my table is very big (no idea if its showing very well the laggy scrolling).
I understand this is because the browser has to actually render everything and with large datasets it could take time.
Is there a way WITHOUT pagination to make it more bearable?
Perhaps some way to render content ONLY shown in browsers view like a certain angularJS component (without needing angularjs)
A table that size is useful to nobody, you say you don't want to paginate but why? Pagination is a usability feature for a reason. Just implement pagination and searching. A grid with more than a few thousand rows is not going to be useful to anyone.
If you really need to have the table that big and scrollable then the technique used is to remove the item that are not in view out of the DOM. As you scroll you create DOM objects for the items as they come into view and remove them as they move out of view. This way there are not thousands of DOM objects the browser has to deal with.
My site has these interactive tables that are inert until activated by an instructor when they are testing students. The backend is controlled by a vendor and I am the lowly web developer who cleans up their mess on the frontend so things look presentable. I've managed to change several tables indirectly through CSS and JS, but I can't apply anything to the HTML directly to the table since it's generated when the page loads. This particular table is perplexing,it will not shrink down to 720px. I tried everything from adddClass, nth-child, fixed sizes, etc. My last attempt was to write a function that set attributes to td's. It worked and it'll show on the developer tools but the actual table didn't shrink at all. I've been up 24+ hours so I might just be tired and not aware of simple mistakes. Anyways here's my demo. Thank you very much any help is very appreciated.
I just found this: Why is my table cell width wrong in Chrome?
Tables have a property called table-layout which is by default set to auto. It allows the table to be flexible and gives it the ability to distribute column widths on the fly. Setting my rogue table this way:
table-layout: fixed; width: 100%
made it behave and honor the widths I had assigned to it. Here's more details on table-layout
Demo
EDIT: I forgot to mention that this only happens in Chrome, but in Firefox and to a certain extent IE (it's a little off, but that's what you'd expect from a half-baked piece of work), are ok.
I am porting quite a huge piece of software to an ExtJS Grid. Lots of data (and I mean lots of data) is loaded on-demand into spans that are placed inside grid's cells.
Imagine grid cells having <span id="foo_bar'></span> as content, and special ajax handlers are polling the backend for updated information and once available the spans are filled with it.
Now, in case I collapse some part of the grid and then re-exand them again I loose all automatically filled cell content, and am left with empty spans (which I started from in the first place).
I know the correct way is to setup a store and push all data into the store. But as I've mentioned above: I am porting quite a huge piece of legacy software to ExtJS, and I do not really have much choice here.
Is there a way to automagically push grid cell values to the store?
Update:
A grid is loaded with, suppose, 2000 cells (this can vary tremendously). Every cell contains various grades of HTML, mostly this is , but this can be pretty much anything (including several spans or divs in one cell). In the background there is a comet process pushing new data to the HTML page almost in real time. This data is populated to the corresponding SPANS and DIVs either based on their IDs or class or both.
What I want to achieve is that either:
a) the model for the grid is atomagically updated with the new html content of the cells (how can I achieve this)?
b) when collapsing/expanding tree's nodes the model data is NOT reloaded afresh.
Is either a or b possible? if so — how?
Just update your store when the 'special ajax handlers' successfully return values. In staid of manually messing with the dom.
so in the success callback do something like -> loadData()
Edit:
Seems like you are working with very bad legacy code :) If adding a simple line of code to the ajax handler is a tremendous effort.. You can however attach dom listeners, but it's very bad practice. Here are some events to listen to
Edit:
Here is an example of the use of how you could listen to dom events, it's rather a pure js solution but, meh.. it works..
I'm writing a Javascript based table widget that I hope to be capable of handling basically a limitless amount of data. To do this, the table will make Ajax requests for data only as it is needed (when scrolled into view). I have the basic idea working, but one issue I'm struggling with is the resizing of table columns.
Since only a section of all the rows is actually rendered at any time, the table tends to reflow as the max width of the columns changes.
I thought about iterating the table cells each time the table is rendered, and remembering the "max width" of each column. There would still be some reflowing, but once you've seen the widest td, it should stop. The issue is that this seems to be a kind of clunky solution, and I find myself writing more code than I'd like to handle it.
Has anyone run into this before, or have any simpler ideas on how to handle it?
For consistency, I would lock the column width to what it is on the first view of the table. That way, there's no shifting at all.
You should also give the developer a way to specify a static column width for the columns so that they can size them appropriate to their data once they know the widths.