This is not really the space for this question, but I will give a couple of quick pointers...
Usually the thing that kills apps most is having too much granularity in fields. If you can round numbers so there are fewer possible values in a column, or drop the time from date/time fields, this can really help.
Similarly, drop any whole columns that you don't need. Every bit of data that is in-memory is taking resource and will slow things down a bit. If it's not in use don't load it.
Check for inefficient expressions. Big nested expressions can slow things down, anything with an IF in there could potentially be re-written with Set Analysis. Try creating a new app with the data model but no visualisations on it. What happens as you add (copy/paste) each visualisation back in. Is there one which is worse than others?
Sometimes it's just something silly and unexpected that can break an app. Referencing the now() function in a variable is an example - because this refreshes every second, every selection that could be affected by that variable is recalculated every second. Never use now() in the front end.
Calculation conditions can really help. If you have any tables which could have more rows than a user is likely to comprehend put a calculation condition on it, based on a simple expression. For instance, if you have a RowCounter field (which contains 1 on every row) you can have a calculation condition of sum(RowCounter) <= 10000, and this would only draw the table if there are 10,000 or less rows in it.
Check the data model. Ensure all tables are joined only on the fields you expect. Synthetic keys can kill performance (and give unexpected results). Make sure that there are no data islands (tables that don't join to other tables) as Cartesian products are possible - and these are very bad news.
Try breaking stuff down a bit. What happens if you only load one month? Does that help? At what point is performance hit? Can your users make do with less history?
Chucking more RAM and CPU (especially RAM) at a problem will often help ease it - though it is seldom a silver bullet.
You probably won't find your answer in the above, as it is all a bit general, but it may give you some jumping off points for things to Google and dig a bit deeper on.
You may also find some of my blog posts handy:
https://www.quickintelligence.co.uk/perfect-your-qlikview-data-model/
https://www.quickintelligence.co.uk/qlikview-data-structures/
Hope that these thoughts help point you in the right direction.
Cheers,
Steve
