A table plugin is fine until the table is real. Then the page is shipping the entire dataset to the browser so it can sort ten visible rows.
The default behaviour sends every row to the browser and does the sorting there, which works beautifully up to a few hundred rows.
Ten thousand rows rendered into the page is a multi-megabyte response before any styling. Paging and sorting happen server-side, so the response carries the rows being looked at.
Searching a large table should be a query, not a scan of a serialised blob. Table data is stored and indexed so filtering stays quick as rows accumulate.
Tables usually arrive as spreadsheets with thousands of rows. Imports run as batches so a large file completes rather than stopping at whatever the timeout allowed.
A wide table on a narrow screen is the most common real-world failure. Output is delivered so it scrolls within its own container rather than breaking the page.
Re-importing over a curated table is easy to do accidentally. Daily restore points make it recoverable.
Nothing is wrong at two hundred rows. At ten thousand the page weight, the browser sorting and the import limits all fail at once, and they look like three separate problems.
The measurement is the response size for a page showing twenty rows, because that is what the visitor asked for and often not what they receive.
Every row is about not sending data nobody is looking at.
| Setting | What we do | Why |
|---|---|---|
| Paging and sorting | Performed server-side rather than in the browser | Rendering every row so the browser can sort the visible ten produces a multi-megabyte response for a page showing a screenful. |
| Filter queries | Backed by an index rather than scanning stored data | Table content held as one serialised value cannot be queried, so every search reads and unpacks the entire table. |
| Import runs | Batched so large spreadsheets complete | Tables arrive as files with thousands of rows, and an import that stops part way leaves a table that looks populated and is not. |
| Narrow-screen output | Scrolled within its own container | A wide table is the most common cause of a page scrolling sideways on a phone, which breaks the layout around it rather than just the table. |
| Pre-import restore point | Taken before overwriting an existing table | Re-importing over a curated table is an easy mistake and an expensive one to reverse by hand. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Move the site across — migration is free, table data included.