One of the strengths of D365F&O is it does not lack tweaks to make it fit your business needs. Needless to say there is plenty of stuff you can tweak to optimize performance, and the place to start (where you will get a lot of bang-for-the-buck) is the System administration > Setup > Client performance options. I have referred to these options before but for some reason they are often ignored or not well understood, so let's look at them.

Enable legacy navigation bar - Personally I like the legacy navigation bar, especial the breadcrumb so I can se the path to the form I'm in. The only drawback is that the search button is not centrally placed... but so what. From a performance perspective this is nothing, so just choose what you like best at your organization. The following images show the legacy and the new navigation bar respectively.

Feature callouts enabled - opinions vary on whether this is useful or irritating. From a performance perspective it's also nothing, but unless you really like disturbing users with notifications they don't even bother reading, turning them off reduces what the system has to do. Personally I find them annoying.

Factboxes enabled - exactly what it says. It can be useful to see related information in a form, but how much is it really used. When a user leaves a form, the system saves which factboxes were left open and automatically opens then when the form is opened again. This of course practical, but for each open factbox an extra connection and query is needed, and every time you change a record in a list page all the open factboxes need to by run (new queries). My first recommendation is educate your users to only open the factboxes when needed and to close them at least when leaving a form. Failing that you can make them aware of the importance (scare them) of doing as asked by turning them off. As a permanent thing it might however be a little radical.

Allow remote part execution - Form parts are a specific type of simpler forms normally used to extend other forms (there is publicly available info in the internet if you are not sure what they are). When a form part is called remotely there is no coupling between the caller form and the part (as it's executed in a separate session), so the part is not linked to the data sources and you don't have the element.caller() object of the part. As I cannot know if there is a base form lurking somewhere that needs to interact with a part that just happens to have the Run Mode property set to Remote (will cause an error), and I don't really see that a part running in a separate session has any significant negative impact on the overall performance (they are supposed to be simple and you are not going anywhere until you get the info in it anyway), I take the safe approach and don't allow remote part execution.