gui design - Should we kill the features that users are not using frequently, to improve performance?

According to the heat map that we generated for our app (an ad server), users rarely sort the items in the lists, they usually use the search to find the items they wanted to find. Developers said it will highly improve the performance of the app if we remove the sorting feature.

I am very skeptic about this change as it's a best practice to be able to sort the data in the long lists ( our lists can reach to 100 items) but in the same time the performance (loading time) of the app is very important for the company.

Any suggestions?

Notes :

Thanks to kettch for these questions :

Do your users know that the columns are sortable? - Yes in the user tests almost all users noticed the sortable header

What is the average size of the data set? - Usually, you get 50 lines per page, but a standard campaign manager (our targets) only need 4 - 5 items per page for now

Why are the users who do sort using the feature? - I don't have a clear answer for that, I would say they try to find underperforming campaigns by sorting them by pacing or CTR

Is the data grid so painfully slow that the users never user it? - No it is fast actually, but – apparently – the sorting feature is causing problems in the database and creating discrepancy in the data

Developer's notes for the issue :

• Issue getting the data in postgresql because of the amount of calls needed to update this data, just so that we can sort it, if less than 5% of our users are actually using this to sort.


• Won't scale forever the way it is now

Also what we would be winning by doing this the way we are planning :

• Realtime. Like, really real-time. Every time you refresh the page you would see the latest performance (and not 2 minutes after or whatever)


• Better performance not only for the list, but for the whole product. Less "freeze" in part of the apps


• Cost optimisation, because we wouldn't need to compute it every 2 minutes, although no one would actually see the data (during night or whatever). We would compute it only when necessary

Answer

Beside what was said in the other good answers here, you have a much more basic problem. You are misreading your data.

A heatmap generally sums up all clicks on a pixel, regardless of who made them. And you (and the other answers) seem to be interpreting this heatmap as the proportion of users who ever click on that pixel, which is an entirely different cup of tea.

Imagine that you have an online shop. A standard heatmap will display a ton of clicks on features related to browsing around, looking at comments, etc., and only very few clicks on the "Checkout" button. This does not mean that nobody uses that button, it means that people click a ton of other things during a visit, and then only place the order once. And this is exactly how you want them to act! In your case, it is entirely possible that every single one of your users is using the sorting, but only need to do it once per visit - and still view it as extremely helpful for their task. (I am not saying that this must be what is happening - but with your data, you cannot rule it out).

To get the information you want, you would have to generate a completely different information display, which relates clicks to the user who made them, and only counts a click on a given element once per user. This will tell you how many of your users don't use the function.

Once you have gotten that information, you can start considering whether a function used by few visitors should be removed or not. (If you find out that only 10% of the users ever checkout in your webshop, would you remove the "Checkout" button?)