Get Free Trial
Get Free Trial

Performance Optimization for Flexmonster Pivot Table with Custom API

posted on May 22nd, 2026

Answered
taehong asked on May 22, 2026

Hello,

We are currently using Flexmonster Pivot Table with a custom API implementation, and we are trying to improve performance. While reviewing the current behavior, we found a few points we would like to confirm:

  1. Sequential API calls

    • Flexmonster is currently calling endpoints such as /select and /members sequentially rather than in parallel.
    • Is there any way to make these requests run in parallel?

  2. Gzip-compressed JSON response

    • Our server returns data in JSON format.
    • If we send the response as gzip-compressed data, can Flexmonster automatically decompress it and use it normally?

  3. Pagination support

    • At the moment, it seems that the entire dataset is loaded at once and then rendered on the screen.
    • Is there any way to support pagination or partial/lazy loading instead of loading the full dataset at once?

If these features are not currently supported, could you please let us know whether there are any plans to support them in a future release?

Thank you.

1 answer

Public
Maksym Diachenko Maksym Diachenko ⋅ Flexmonster ⋅ May 22, 2026

Hello,

Thank you for writing to us.

Sequential API calls

Regarding sequential API calls, this cannot be changed in Flexmonster. The /select and /members requests serve different purposes: /select retrieves the actual dataset, while /members is used to populate filter pop-ups.

The only practical optimization on this side is to disable the member filter and /members requests by configuring field mapping and turning off filter members population using the filters.members option. With this option, only conditional filters will remain available: https://jsfiddle.net/flexmonster/qojme3tc/

Gzip-compressed JSON response

Flexmonster supports working with Gzip-compressed responses. If the server supports gzip compression, the client automatically handles decompression as part of standard HTTP processing in the browser, so no additional configuration is required on the Flexmonster side.

Pagination support

Currently, Flexmonster does not support pagination or lazy loading. With the custom API, the data required for visualization is still loaded in a single request, but the key point is that it is already aggregated on the server side rather than being a full raw dataset. This means Flexmonster does not perform heavy client-side aggregations and does not need to load fields that are not part of an active view, or records that are filtered out.

Thus said, we understand that the volume of aggregated data can still take a long time to load at once. We plan to address this in our upcoming major update - Flexmonster 3.0. It introduces a new communication protocol based on WebSockets that supports lazy loading. Only the visible portion of the grid will be loaded initially, with the rest of the data loaded in the background or on scroll, reducing loading time for users. It will also introduce a redesigned search-based member filter for fields with a large number of members. Instead of always fetching all members upfront, they will be retrieved on demand via search queries, removing the long-running queries for all members.

The abovementioned features are already available, and you can explore them on our prerelease website, or download the latest builds to experiment with local data: https://prerelease.flexmonster.com/

Please let us know if our answer helped you.

Best regards,
Maksym

Please sign in or register to submit your answer