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.
Related
lets say i have 20 similar formatted tables with 30x30 cells on my homepage.
Would it be faster/better performing to have all 20 tables written in html and show/hide them when needed or have only one table where the content is changed via javascript?
I‘m really unsure because the DOM will be way larger with seperate tables so accessing elements should be slower in total.
But otherwise repopulating the table or redrawing will also habe a significant impact I guess.
I think rendering won‘t make a big difference as in both cases only ine table should be in the render tree
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 searched the internet for these new features of angular 7, but didn't fully understand it.
I went through drag and drop and virtual scrolling
Could someone please shed some light on these?
now consider a case where you are to display huge chunk of data, now either you will do pagination which will include an api call per page (if data changes frequently) or if you load everything at once which will slow down or kill UI process.
Virtual Scroll is about loading huge chunk of data in DOM without hampering the performance.
it's key features are:
data is displayed as per size of viewport i.e. if you container div is 500 px it will show around 10-15 rows at a time.
Ad you scroll these rows are changed but number of elements in the DOM will remain consistent.
This is handy when you have to show huge chunk of data without implementing pagination.
Thus it improves the UI performance.
I implemented Virtual list displaying multiple column and array length was 1 million which is a huge amount of data to display at a time.
Virtual list is implemented over virtual scroll and it supports multiple columns.
check out detailed explanation and code here:
https://www.codeproject.com/Articles/5260356/Virtual-List-in-Angular
please have a look in the image:
This question already has answers here:
Angular many rows grid performance in Chrome browser
(2 answers)
Closed 4 years ago.
I have a problem with Angular 6 performance issue. In the page there is a large table which has 100 rows and each row has 100 columns. Then this page is kind of laggy when I trying to use libraries like ng-select or ng-bootstrap datepicker, etc. Even if those libraries has no data exchange with the table. Which means even if the ng-select is just embedded in the HTML and has no data filled, the open and close of the ng-select drop down is laggy, takes about 0.5 sec to load. Same with other libraries. When I reduce the table to 10 rows, the lagging issue is improved significantly. Why does this happen?
Another observation is that when I use native tags of the HTML such as select option, it is not laggy at all, it react instantly. How to improve the performance in my situation? Thanks!
Code is basically something like this.
app-component:
<ng-select></ng-select>
<row-component *ngFor="let basket of baskets"></row-component>
row-component:
<div *ngFor="let apple of apples">
blah blah blah
</div>
It could also just be an issue of how many DOM elements that are being created and displayed on the page. You could try and use row virtualization which only renders rows that are displayed on the screen.
The fact that using ng-select makes the website more laggy than native html tags makes me think that the additional event listeners from the angular components have also decreased the performance of your webpage.
Ag-Grid has a great article about how they optimized displaying entries in a table. https://www.ag-grid.com/ag-grid-performance-hacks/
Do you use any library for the table like Angular Material?
One possible (and very common) solution is virtual scrolling:
https://material.angular.io/cdk/scrolling/overview#virtual-scrolling
There are a couple of things you may want to consider:
First, do you need to display all 100 columns at once? Is it possible for you to break up the columns into more manageable chunks, and maybe use a tabbed interface (Something like the Angular Bootstrap Tabset https://ng-bootstrap.github.io/#/components/tabset/examples) and group related columns into tabs to reduce the amount of columns you have to display on one page.
Second, there will be a performance issue when you get over a certain number of rows, which is where paging the data would be a good option (again, maybe look at Bootstrap paging https://ng-bootstrap.github.io/#/components/pagination/examples). You can set a hard limit - maybe 40 rows per page, or set the row limit dynamically by getting the browser window size, subtracting the amount of space you need for menus etc., and dividing the rest by the row height to determine how many rows will fit in the space you have available, and use that as your page size. This way you'll always only have to display a subset of the columns, and only as many rows as will fit on the screen without scrolling, and you should find your performance improves dramatically.
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.