How can table scrollbars affect scalability and performance?
(by Mark Qian on 9/6/2006)
When talking about issues affecting scalability and performance, people always speak "big" like
web framework and database. But do you realize that a very basic web component, table, may have a big
impact on the scalability and preformance? When you read a web page, have you ever pay any attention
to see if tables on the page have their own scrollbars (or frozen headers)? In other words, does the
table header frozen when you scroll down? You may say, "What does that matter?". That does really matter
if you care about the scalability, preformance and usability.
I will illustrate three types of tables to see how their behavior impact scalability and performance.
- Tables without their own scrollbars (frozen headers) - a "retail sale" style
A table without (its own) scrollbars means that you have to either make all the rows in the table
are visible or use the scrollbars provided by its containers like divs, iframes and frames. In both
ways, users have to do pagination frequently since the table size has to be small to keep
the usability at a Desired level - it is hard to scroll up and down to keep tracking which column
is which after horizontally scrolled. This means the level of chatness with your server will be much
higher and that will bring down the scalability and eventually lower the performance.
Let's take a look at two approaches I mentioned above:
a). Make all rows visible without scrollbar
To show every row in the table at once, you can not show too much at a time.
So pagination is the only mean to travel around.
Demo for table without scrollbar
b).Use scrollbar provided by its container, in this case - an iframe
Try the example below to see if you can tell which column is which
after scrolling down and then right/left: very poor usability. To see what is a number at the
bottom area, you need to scroll up to see what column it belong to. When you have a lot of rows,
it is easy to scroll up to find the header but it is hard to scroll back to the line you are
working on. So you can not load too many lines at a time for usability consideration. Similar to the
previous approach, you need to rely on the pagination to make calls to your servers frequently
(I only show one page in the example without pagination GUI).
Demo of a table without frozen headerShow details
- Tables with their own scrollbars (frozen headers) - a "whole sale" style
A table with its own scrollbars will at least have the header frozen when scrolling up and down
so that you can load a proper size of table for each "page" when paginating. This means that you
can tune the page size to minmize chatness while still have an acceptable page loading time.
Here is a demo for a table with frozen header: Scrollable table
- Tables with frozen headers and on-demand loading using Remote Scripting - a "retail sale" style
An on-demand scrollable table loads new rows "on demand" when users scroll down to a new area.
It may be a great choice for light-weight data. I think we still need pagination but at a much
For example, for a table without its own scrollbars (frozen header), you can only load probably 15
rows a page since it is too hard to scroll the page/container up and down on more rows. For a table
with its own scrollbars you can load more but the problem is users have to wait when the table is
loaded. So you can only load maximum, say 200 rows, since too many rows are loaded in to a table
at once will hurt the usability because of long initial loading.
With on-demand scrolling table, you can load much more on a table since there is no/little initial
loading time. In the case when users want to "jump", we can just paginate it.
Try it here: Running on-demand table
Cool!? Yes and no. It really depends on your goal. It minimize the initial loading time.
But have you found any problem? This a typical issue/problem of AJAX application:
the on-demand scrolling table actually generates more chatness since each user scroll down to
the new area will cause a request back to the server. So this is another "warning" to the
people over using AJAX.