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
      bigger scale. 
      
      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.