There are alternatives to creating bloat in an accdb. I'm also going to take the optimistic route and assume you do, indeed, plan to deploy a properly split relational database application by placing a shared back end, with only the tables, in a network location, and giving each user their very own copy of the front end, with all of the forms, reports, queries and VBA. However, if that's not already your plan, I urge you to stop now, read up on properly split relational database applications in Access, and proceed appropriately.
Bloat is usually the result of doing a lot of work inside the accdb which involves things like appending data in bulk using insert queries or deleting records using delete queries and importing external data and so on. Access does not initiate deletion of objects and records used in temporary operations. They're marked internal as "deleted" but physically remain, taking up space, i.e. "bloat". Removing that bloat is the "Compact" part of "Compact & Repair".
In addition to the advice already given, you may want to look into creating a temporary "side end" accdb in which all of that data mongering goes on externally to the production front end accdb. That allows the temporary accdb to house the temporary tables and records. And that means you simply delete the auxiliary, or "side end" accdb when you are done with it. And that reduces bloat in the production accdbs.