The data displayed in your chartJS is returned from a microflow.  This means you can put some branches in your microflow to return the data you want.

Create a helper entity (might be non-persistent) containing the attributes you wish to filter on, then amend your source microflow to pass the helper entity, and branch the microflow based on the attribute values to amend your retrieval query.  Place on change actions on the filter attributes to refresh the helper entity which will re-run the source microflow to return the correct data set whenever a value is changed.

Then to display your chart, you first retrieve of create a record in your helper entity and display it, set any default values to the filter attributes.  Add the chartJS in the view of the helper entity.

HTH

Edit: How many objects are your queries returning?  I suspect the long duration is with the chartJS rendering, rather than the database queries.  One way to reduce the number of times that the chart is refreshed is to change what I said above, and not add the on change microflow.  Instead add a button to run a microflow to refresh.  In this way you can adjust multiple filter attributes, and update the query once instead of every time you change an individual attribute.

I would also investigate whether you are able to pre-aggregate some of your data so that your chart displays fewer records.  For example, in one of my applications I use scheduled events to calculate metrics on number of support tickets created, closed, still open, ticket age, average resolution times etc.  These aggregated metrics are stored in a metrics entity which is then used as the basis of the charts.  I also allow the definitions of the data to be aggregated to be defined in a report template, so you can decide what period to aggregate over (weekly, monthly etc.), of whether to aggregate by location, support team etc.