Please wait...

Server-side processing (Lazy Loading) in wpDataTables

Server-side processing (Lazy Loading) explainedFull information on the Server Side processing feature

“Server-side processing” stands for the type of tables when all the data interaction operations (searching, filtering, switching pages, sorting) aren’t done by your site visitor’s browser (with JS), but by MySQL server on your site instead.

One of the main benefits of MySQL DB engine is fast data processing, which means that when you need to sort whole table by one of the columns, or filter by some value, it will be done fast even when it contains several hundreds, or thousands or even millions of records. What is the key difference between “usual” wpDataTables and wpDataTables with server-side processing turned on? When should the first and the second option be used?

  • “Usual” wpDataTables (the ones that do not have server-side processing feature enabled) fetch all the rows and output whole table to the front-end at once, then split it to pages, using Javascript; all data processing (page switching, sorting, filtering) is done on client’s computer by Javascript. This works great for relatively small tables: once the table gets bigger, the page also gets larger, which means that the page generation and load time will also increase; also each sorting, filtering or page switching will take more time. So, for larger data sets (more then 2000-3000 rows and in some installations even more then 500 rows) “usual” wpDataTables will work slow, and for really large ones (10 000 rows and more) it can crash the page completely.
  • wpDataTables with server-side processing enabled fetch only the amount of rows needed on the page at this exact moment. By default it equals to the number of rows that administrator defines for the table in the “Display length” setting, then the front-user can change it. E.g. if the table is configured to show 10 rows by default, only 10 rows would be queried from MySQL; and when the user switches to the next page, sorts the table by some column, filters by some column, an AJAX-request is sent to the server, query is processed by MySQL, and 10 rows are returned again. This may slow down smaller tables, but for larger tables this may be the only option.

There’s no “official” rule for the size of the tables from different input sources, since it very much depends on the hosting, bandwidth, and the device of the front-end user, but I’d say, in general, file-based (Excel, CSV, XML, JSON) tables could be freely used for tables that don’t have more then 2000-3000 cells (columns * rows), MySQL table type can be used for any limits; but server-side processing feature is mandatory for data sets larger then 3000-4000 rows.

If your MySQL-query based wpDataTable doesn’t work correctly with server-side processing, probably this is happening because wpDataTables server has problems with parsing of the query and building new queries dynamically (happens rarely, but does sometimes). To avoid this please prepare a MySQL view (a stored query), which will return the data that you need, call it e.g. “view1” and then build a wpDataTabled based on a simple query like “SELECT * FROM view1”.

Please note some this when working with the server-side processing feature:

  • Row grouping feature can cause trouble when combined with server-side processing.
  • Please do not use “ORDER BY” in the SELECT statement. wpDataTables has its own sorting engine so it makes no sense to use MySQL’s sorting, since it will be overridden. Also server-side processing feature adds this part of statement automatically when users triggers the sorting on the front-end, and having it in initial statement may cause the table to crash.

Never miss new features!

Join 2000+ newsletter subscribers

Never miss notifications about new cool features, promotions, giveaways or freebies - subscribe to our newsletter! We send about one mail per month, and do our best to keep our announcements interesting.

We never spam or disclose your address to anyone.