multiple use of an Access app can be a problem. An Access app using bound forms will hit problems around 10..20 users. Although an Access front end app can support many many users, Ive heard of multiple thousand users talking to a mainframe server db.
the first thing to do is to split the db into a "front end", containing the forms, reports, quries etc.) and "back end", containing the data.
ideally you should deploy the front end onto each workstation. that way round the user interface requires no network traffic to retrieve the forms & reports. you will still pull the data from the central back end.
optionally consider dumping local data, or data that hardly ever changes onto the front end. that may require a periodic update from the central back end.
do all temporary work or whatever on the local front end. If say you use temporary tables.
Thats all relatively easy to implement, the main design issue is making sure that the client workstations are using the correct (most recent front end).
There are other things that you can look at to improve performance. improving the 'quality' of your SQL can lead to big performance gains.. but its a black art. Generally you need to reduce the amount of data your queries use as soon as possible. make sure all the columns you do joins on are indexed, indexing columns that are often used in where clauses helps.
Bear in mind that Access is a file based db, not a server based db. each and every data interaction requires network IO, sucking across at least the indexes, and often the data before discarding any irrelevant data.. hence why indexing join & where clauses can be important
However getting the best often requires a rethink of how you use Access.. that means discarding bound forms and using unbound forms (being much more selective about how you retrieve data, update and other issues).. all of which is beyond the scope of forum like this.. Id suggest you consider getting a quality Access book such as the Developers Handbook by Getz and others.
Do you have a form that is using a Query or Table derived from the Back End Table. For instance a Main Menu boound to a Back End tables (just one record will do). Because this form is persistent, the Back End ldb file will always be open.