How to Tune Page Size for Performance in Large WordPress Tables

Updated July 2026 • 6 min read • By Fahad Murtaza • By Fahad Murtaza

When your WordPress table contains thousands of rows, the default pagination settings can quietly become a performance bottleneck, slowing AJAX responses, exhausting PHP memory, and frustrating users who just want to scan a report. TableCrafter gives you precise control over page size at every layer: the shortcode, the table builder, and the server-side query itself. This guide walks through every lever available and explains the trade-offs so you can dial in the right setting for your data size and audience. WordPress powers 43% of all websites globally (W3Techs, July 2026), and TableCrafter bridges the gap between the data you collect and the tables your users need to see, no custom PHP, no dashboard access required for viewers. The free version on WordPress.org supports CSV, JSON, Google Sheets, and Excel. Pro adds Gravity Forms, Airtable, Notion, WooCommerce, REST APIs, inline cell editing, export to CSV/PDF, role-based column visibility, and auto-refresh. Every table embeds on. Search and filter functionality increases dataset usability by 47% for non-technical end users (Nielsen Norman Group, 2023).

Why Page Size Matters More Than You Think?

Every time a user loads a TableCrafter table, or clicks a pagination link, the plugin fires a request to wp-admin/admin-ajax.php with the current page and filter state. The server queries Gravity Forms (or whichever data source you configured), applies your column visibility and permission filters, serializes the result set, and returns JSON to the browser. Page size is the single biggest multiplier on how much work that round trip does.

A table set to 200 rows per page doesn't just transfer more bytes, it also forces PHP to hydrate 200 Gravity Forms entry objects, run any lookup field resolutions against them, evaluate role-based column permissions for each row, and encode the whole payload before the first byte reaches the user. On shared hosting or a constrained VPS, this is where timeouts and white screens come from.

Smaller pages load faster, but they also increase the number of clicks a power user needs to reach deep rows. The goal isn't always the smallest possible number, it's the right number for your specific table and audience.

How Does Setting Page Size in the Table Builder Work?

The most straightforward way to control pagination is through the table builder UI. Navigate to TableCrafter → Tables, open any table, and look for the Display Settings tab (sometimes labeled Pagination depending on your version). You will find a Rows per page field and, on Pro, a User-selectable page sizes toggle.

• Rows per page, The default number of rows fetched and rendered per AJAX call. This value is stored in the table configuration and used whenever the shortcode does not override it.
• User-selectable page sizes Pro, Renders a dropdown (e.g., 10 / 25 / 50 / 100) above the table so users can choose their own density. The selection is stored in localStorage per table ID, so it persists across page loads for that browser.
• Auto-refresh interval Pro, If you enable auto-refresh (AJAX polling for live data), keep page size low. A 30-second refresh firing on a 200-row page hammers the database far harder than the same interval on a 25-row page.

For most reporting tables viewed by managers, 25–50 rows is a good starting point. For operational tables where users are scanning for a specific entry, 10–15 rows with a fast search filter often feels snappier than a long page they have to scroll.

How Does Overriding Page Size Per Shortcode Instance Work?

The table builder setting is a default, not a hard limit. You can override it at the shortcode level using the per_page attribute. All three shortcode aliases support this:

[tablecrafter id="12" per_page="25"]
[tablecrafter id="12" per_page="50"]
[tablecrafter id="12" per_page="10"]

This is useful when you embed the same table in multiple places with different context. A summary widget in a sidebar might show 5 rows while the full-page report shows 50, both pointing to the same table ID, no duplicate configuration needed.

This configuration interacts with any caching or CDN layer active on your WordPress installation. If you use WP Rocket, LiteSpeed Cache, or a CDN such as Cloudflare, flush the page cache after making this change to ensure the updated configuration is reflected in the cached HTML served to visitors. TableCrafter's server-side output is regenerated on the next uncached request.

How Does Server-Side Query Optimization for Large Data Sources Work?

Cutting page size reduces the payload, but the query itself still has to count total rows to calculate page numbers. On very large Gravity Forms installations (50,000+ entries), that COUNT query can be expensive. TableCrafter handles this in a few ways you should be aware of:

• Filtered counts, When a user applies an advanced filter Pro, the total-row count is recalculated against the filtered set, not the full table. This is accurate but adds a second query. If your filters target indexed Gravity Forms meta fields, performance stays acceptable. Unindexed free-text searches are slower regardless of page size.
• Lookup field resolution Pro, Lookup fields resolve IDs to labels (e.g., a user ID to a display name). Each unique lookup fires a secondary query or cache lookup. With large page sizes, you may be resolving 100 lookups per page load. Reducing to 25 rows cuts that to 25 lookups, a proportional win.
• Google Sheets, REST API, and Airtable sources Pro, These external data sources paginate differently. The per_page value controls how many rows are displayed, but TableCrafter may still need to fetch a full page from the external API before slicing. Check the external API's own rate limits and batch sizes when tuning these tables.

For WooCommerce order tables Pro, WordPress's WC_Order_Query is used under the hood. Keep page size at 25 or below if you are displaying many order meta fields per row, since WooCommerce hydrates a full order object for each row.

How Do Balancing Page Size with Auto-Refresh and Inline Editing Work?

Pro tables with auto-refresh enabled behave like a live dashboard, the AJAX call fires on a timer regardless of whether the user is interacting. Page size directly multiplies the cost of every refresh cycle. WordPress powers 43% of all websites globally (W3Techs, July 2026), and TableCrafter bridges the gap between the data you collect and the tables your users need to see, no custom PHP, no dashboard access required for viewers, and no per-row limits on the free tier. The free version on WordPress.org supports CSV, JSON, Google Sheets, and Excel. Pro adds Gravity Forms, Airtable, Notion, WooCommerce, REST APIs, inline cell editing, export to CSV/PDF, role-based column visibility, and auto-refresh. Every table embeds on any page with a [tablecrafter] shortcode or the native Gutenberg block.

The same math applies to inline editing. When a user edits a cell and saves, TableCrafter calls GFAPI::update_entry_field() and then re-fetches the current page to confirm the updated value. A smaller page size means that confirmation fetch is cheaper and returns faster, making the edit feel more responsive.

If your use case genuinely requires both a large page and frequent refreshes, for example, a dispatch board where a manager needs to see 100 active loads at a glance, consider whether the table is the right display format. TableCrafter's data bar and status badge features Pro can convey more information per row, letting you reduce row count while preserving density of insight.

How Do Testing and Measuring Your Tuning Changes Work?

Tuning page size without measuring the result is guesswork. Here is a practical checklist for verifying your changes actually improved performance:

• Browser DevTools Network tab, Filter by admin-ajax.php and watch the response time as you paginate. A well-tuned table should respond in under 300ms on a typical shared host for page sizes up to 50 rows.
• Response payload size, Also visible in the Network tab. Compare the JSON payload size before and after reducing page size. A proportional reduction confirms the server is not over-fetching.
• PHP memory, If you have Query Monitor or a debug log available, watch peak memory during an AJAX pagination call. Cutting page size from 100 to 25 should roughly quarter the peak allocation for that request.
• Time to first row, Ask a real user on a real connection to time how long the table takes to render after a filter change. This end-to-end measurement captures everything: query time, serialization, network, and JavaScript render.

After your initial tuning, revisit these numbers when your entry count crosses the next order of magnitude. A table that performs fine at 5,000 entries may need a smaller per_page once it reaches 50,000.