Hi David,

1. In regards to the initial question, in terms of slow load issues, it could depend on different factors.
   It depends on how many charts you plan to have per each Page;
   
   How many tables would be on the same WP Page;
   
   How many rows in total would be combined.
   
   So, for example if you only set up one table on the page which has 1 thousand rows - that should be handled very easily.
   
   For tables up to 2 thousand rows - you should not even have to use our Cache feature, so I can't say for sure what might have been slowing down that specific/initial table you tried.
   
   I will advise in general on the slow load topic :
   
   
   

   The loading speed depends on a lot of factors - your hosting plan, server's performance, amount of other data on the page, internet speed, etc. 

   For example, you can take a look at the table on our documentation, which contains around 2.600.000 rows, and see how it loads. The more data the table has, the more chance that it will impact the loading time.

   Please note that Table is an SQL Query Based Table, it uses our Server-Side Processing feature, which dramatically improves loading speeds by using AJAX to only load one Table page at a time,

   compared to non-server-side Tables which always load all rows on the HTML of the Page regardless of Table Pagination.

   -

    

   If you use non-server side Tables, like linked from Google Spreadsheet/CSV/Excel , we advise trying our cache and Auto Update Cache feature.

   With our caching option, the load time is significantly lowered, but we still recommend keeping the data in these files down to around 5.000 rows.

   If any of your Table linked from source file goes above that size - then the best is to switch to SQL based Tables, to import the data from CSV/Google Sheet or Excel.

    

    If you import the file, the plugin reads the source file and creates a manual table. 

   Once the table is created, it is no longer linked to the source file, so changing data in the table will not show up in Excel or Google Spreadsheet, and vice-versa. 

   To modify this table, you can either switch to the Excel-like view, 

   and then select and copy the range of cells you want to paste from the source file, and paste it in the Excel-like view, 

   or you can import a new/edited CSV to update the table, as well, in the following ways :

   • Update manual tables: Replace data within an existing table.
   • Update manual tables: Add data to an existing table.
   •  Update manual tables: Replace the entire table with new data.

   -

    

   You can also check, in this table's filter settings for columns, how many unique filtering values there are.

   If you have, for example - a string column that you set as a selectbox/multiselectbox, 

   and if it has more than 50 possible filtering values,

   you can go into that column setting, and check what is set for "Number of possible values to load" – 

   Here you can define how many possible values per page will be loaded in selectbox filter and editor inputs. It is recommended not to be set for All if you have more than 50 possible values for this column.

   

   

   So, check if that might be the case, try to lower the value to 50 and see if it helps the speed.

   -

    

   Also, it is possible for other plugins to affect the loading speed.

   We had a couple of cases with users who have an "optimization plugin" with specific settings, 

   such as  'SiteGround Optimizer', for example.

   These plugins have certain settings that can negatively affect the performance of our tables.

   If there is any JS minification going on,  there can be other settings, I can't say exactly,

   but something to be aware of.

   If you wish to do troubleshoot testing to check if an optimization/caching plugin might be slowing down tables,

   you can try to disable all plugins and just leave wpDataTables active - then clear all cache and reload the page, see if it loads faster.

    

   Then, if any optimization plugin Is used, try to revert all its settings to default, and if you use server-side tables ( such as SQL or Manual tables) ,  then exclude the pages where you have tables from caching.

    

   -

   Another thing to consider is how many 'Default rows per page' are set in the Display settings.

   

   Try setting this as low as possible and test if that improves performance for that table.

   I recommend it is best to use our new 'Custom rows per page', so if you allow front-end users to be able to use the dropdown for Rows per page on front-end, this will limit their options, to avoid loading 'All rows' and if you wish to get as much performance as possible, you can even remove the 100 and 50 options, or even 25 if that helps. 

   

    

   -

   Check if you have the "auto-refresh" enabled on the Tables.

   

    

   If you have a large number of tables and enabled this at a high frequency, such as every 5 or 10 seconds, then the Hosting Server will often make Admin-Ajax calls from the Hosting Server to the SQL Database to pull the data, which can increase the server's load.

   You can try disabling it and see if that helps.

   -

   Lastly, if you use an external Database connection ( not the default WordPress database), in some cases it can help the performance if you can move those SQL tables to pull them directly from the same DB where WordPress is on the Hosting server, so you can try that as well.

   -

   That is about all the advice i can give about this, but of course, let us know if you have additional questions.
   
   
   

2.  

   In regards to using an SQL Query based table via server-side processing :
   Yes, our server-side processing can help, for very large tables - When the SQL based table has more than 2 thousand rows.
   
   
   But, for example, in cases where a user has, let's say a lot of tables on the Site which are SQL-based.
   And if you have server-side enabled on all of them - and if you have the "Auto refresh" option on them in high frequency;
   Check if you notice any high CPU load on your Hosting server for WordPress.
   
   If you notice any high CPU load for the server - It is better to disable server-side processing for smaller tables ( less than 1K rows), to reduce the number of Admin-Ajax calls to the Hosting server.
   
    So we advise to keep the server-side processing active only on larger tables, but as you can see, it depends on a specific use-case, what could be the best way to configure everything.
   
   
   

3.  In regards to including multiple values for one "VAR1" Placeholder :
   Sorry, but that is currently not possible.
   
   If you need to call multiple values through variable placeholders - You can try to use multiple VAR placeholders, such as VAR1, VAR2, VAR3 and so on.
   
   
   Could you please create a new ticket for this individual point - and if you can show us more details, about this use case, what are you trying to achieve with the multiple values on the variable placeholder, how the table looks etc, and we can advise?
   
   

    

   When you have multiple questions or issues which are for different subjects/topics,

    please open a new ticket for each subject, and we will help/advise more effectively. 

   In that way, issues and questions that are related to different subjects will be in separate tickets so other users or our support agents can find them easily. 

   Our policy is to have one issue or question per ticket for the reasons described already.

   Thank you for understanding.

   
   
   Thank you.