Large libraries and performance Free & Pro

FileDeck renders a library into the page and then searches, sorts, filters, and paginates it in the visitor’s browser — no round-trips to your server for any of that. That keeps normal libraries fast and cache-friendly. For very large collections the thing to manage is how many documents render into a single page, which you control with per_page and by scoping libraries by category.

How instant search scales

• Up to about 500 documents: FileDeck inlines a compact search index into the page, so search-as-you-type happens entirely in the browser with zero requests back to your server — results are instant even on slow connections.
• More than about 500 documents in one library: the inlined index is skipped so it doesn’t bloat the page, so search-as-you-type isn’t available in that single library. The right move for a collection that big is to split it into smaller, category-scoped libraries (below) — or, on Pro, add full-text search, which queries your server and works at any size. Sorting, filtering, and pagination still work in every library.

There are no performance modes to choose or indexes to rebuild — behaviour follows library size on its own.

Split big libraries by category scope

One giant library page is rarely the best experience, and it’s the single most effective thing you can do for a large collection. Because every block and shortcode accepts category scoping, you can give each audience a smaller, faster, fully searchable page:

[filedeck category="hr-policies" per_page="20"]

Put scoped libraries on separate pages — one per department, product, or topic. Each page renders less, keeps instant search (each stays under the ~500 mark), caches better, and visitors find documents faster. The Gutenberg block offers the same category scoping in its settings panel.

Choose a sensible per_page

Rendering thousands of rows into one page helps nobody — it slows first paint and overwhelms visitors. Set a moderate page size on the block or shortcode:

[filedeck layout="table" per_page="25"]

Values between 10 and 50 keep pages light while search and filters still operate across the whole library, not just the visible page. Both classic pagination and load-more are available; see pagination for the trade-offs.

Page caching works fine — with one exclusion

Library pages are server-rendered and cache well, so keep your page cache and CDN on. Two rules:

1. Exclude the download endpoint. Add /fdk-download/ to your caching plugin’s exclusion list (and any CDN page rules). If the endpoint gets cached, visitors can receive stale files and download counts stop incrementing.
2. Purge after bulk changes. The inlined search index lives in the page, so purge the page cache after big edits or a CSV import so visitors see the new state.

Images and thumbnails at scale

The image column loads a thumbnail for every visible row, which is fine at normal page sizes but adds up if you push per_page high or use the image-heavy grid layout for a huge library.

• For very large tables, consider omitting the image column — title, size, type, and date usually carry the information.
• If you keep images, make sure documents have appropriately sized featured images rather than full-resolution originals; WordPress generates thumbnails automatically when images are uploaded normally.

Hosting notes for very large libraries

FileDeck itself needs no special infrastructure, but at thousands of documents the usual WordPress fundamentals matter more:

• PHP version: run a current PHP release (FileDeck supports PHP 7.4 through 8.4); newer PHP is meaningfully faster.
• Disk space: the files live on your own server, so budget storage for the library itself, not just the database.
• Protected downloads (Pro): protected files are streamed through PHP rather than served directly by the web server, so many simultaneous large downloads benefit from a host with reasonable PHP worker capacity.

FAQ

Is there a hard limit on how many documents FileDeck can handle?

No hard limit. A single library renders all its documents into the page, so the practical ceiling is your hosting and page weight rather than the plugin. For large collections, scope libraries by category so each page stays light and fully searchable.

What changes when a library passes ~500 documents?

Only one thing: the inlined instant-search index is skipped for that library, so search-as-you-type isn’t available there. Split the collection into category-scoped libraries to keep instant search, or use Pro full-text search. There’s nothing to configure or rebuild.

Will page caching break search or downloads?

Caching library pages is fine and recommended. Just exclude the /fdk-download/ endpoint from caching and purge the cache after bulk edits.