Tony Toews's Access Performance FAQ is the best place to start, in my opinion.
That said, the problems you describe sound like they fall into two classes:
A. slow opening forms.
B. slow performing forms.
There are two common causes for A:
creation of the LDB file/contention for it with existing users. This problem is usually resolved with some form of the solution from Tony's LDB Locking article. You can tell if this is the cause of the problem if opening the first form is slow, and opening successive forms are not slow if you leave the initial one open. FWIW, I don't use that method, but use a persistent database variable that accomplishes the same thing (not the most recent time I've posted the code on SO, but perhaps the one with the best context is here: http://stackoverflow.com/questions/1833746/ms-access-is-there-a-significant-overhead-when-using-currentdb-as-opposed-to-dbe/1837922#1837922).
out-of-date metadata in linked tables. This can happen if, for instance, you work on the front end on your test server, move it to the production environment and update the connect strings to point to the production back end. Updating the connect string doesn't refresh all the metadata stored in the linked table definitions, and there's no way to actually fully refresh them. So, you have to delete and recreate the linked tables in the production environment. The symptom of this one is that in the test environment forms open immediately or in only a second or two, and in the production environment take a minute or more to open. After opening, they generally work just fine. FWIW, I haven't really seen this problem except in the earliest days of Access 2000 when it was a significant and terrible problem that almost cost me a job (my first A2000 project).
Slow-performing forms is more complicated to fix, but the cause is usually pretty uncomplicated: the forms are loading too much data at once. Forms with lots of subforms (usually on a tab control) and lots of large combo boxes are the usual culprit. The solution is to not load the subforms/combo boxes until they are actually displayed. In a tab control that means loading the subform for each tab in the tab control's OnChange event. For combo boxes, you'd load them when they are displayed, or if they have too many records in them (over 1000, I'd say), don't load a rowsource until after the user has typed 1 or 2 characters (using the OnChange event of the combo box).
The problem with that is that you're trading one major slowdown (loading all that stuff when the form is first opened) for a number of much smaller slowdowns (loading each subform/rowsource as its needed). It's a trade-off and you have to decide where you want your pain.
There are lots of other things to do, and one thing to examine early on in troubleshooting performance problems is the Recordsource of each main form. Left joins can get really expensive performance-wise and it's a good idea to eliminate any of them that aren't absolutely required. I just recently vastly speeded up a form that had a left join to the parent table from the child table. It was impossible for the child to exist without a parentID in the PK field in the child table, so that left join was completely unnecessary. Removing it really speeded up navigation from record to record.