shennyL shennyL - 3 months ago 7
jQuery Question

jQuery DataTables - Slow initiation, "Normal" html table shown in the beginning

I'm using jQuery DataTable plugin, but I got a concern where the scripts loading seems to take some time, so my web page is always displaying the ordinary html table first, and after all script done, the table will then become DataTable.
I don't think this kind of appearance is acceptable, so I hope can get some advices here. whether I can make the scripts faster, or don't display the plain table ahead?
Btw, I am calling my script from a _Scripts partial view at my _Layout.cshtml head tag

@Html.Partial("_Scripts")


(UPDATE)
I tried to hide the table, and show it after the datatable initialize, however, I get a datatable without the table header. Any idea why this is happening?

$('#stocktable').hide();
// Initialize data table
var myTable = $('#stocktable').dataTable({

// Try styling
"sScrollX": "100%",
"sScrollXInner": "100%",
"bScrollCollapse": true,

// To use themeroller theme
"bJQueryUI": true,
// To use TableTool plugin
"sDom": 'T<"clear">lfrtip',
// Allow single row to be selected
"oTableTools": {
"sRowSelect": "single"
},
"fnInitComplete": function () {
$('#stocktable').show();
}

Answer

My caveat is that I am not familiar with _Scripts partial views, so the advice below is what I would give someone just including and calling JavaScript in the 'normal' ways:

  1. Style the plain HTML table so that it shares the same appearance as the final. If you have jQuery UI enabled (bJQueryUI: true), this means having the jQuery UI classes in the 'plain' table rather than waiting for DT to add them.

  2. Use various FOUC (flash of unstyled content) techniques to hide the table until it is ready to render. DataTables API has useful callbacks that you can use for the "show it now" part of things, such as fnInitCallback. The most basic (but accessibility-damaging) technique is to style the table with display:none, and in the callback, use $('#myTable').show() or some variation. Searching on the internet should provide some great solutions that preserve accessibility.

Other than that, it's really just a question of (as you say!) tolerance for "acceptable". We use server-side processing (returning far fewer records), a script loader for faster script loading time (we're experimenting with head.js but there are others!), and the minimized versions of the scripts. Even with this, we sometimes see the plain table for a moment before it becomes a DT, but since internet users are accustomed to seeing pages being 'built' before their eyes as elements are loaded, it was an acceptable tradeoff. For you, it might not be.

Good luck!

Comments