Why do you think you need to shrink your FE file? Is it growing on you, and are you aware of the Compact & Repair operation in that context?
Usually, data is the biggest part of any database. Shrinking a front-end involves removing functionality because the queries, forms, reports, and macros take up very little space when the DB is NOT open. Their structures expand only at run-time. To shrink the FE means to take out something that was working for you.
For instance, a table with a thousand records of 100 bytes each is 100K bytes plus indexes, tabledefs, and fielddefs. A query in its quiescent form (i.e. not open) might be from 100 to 250 bytes. NOT Kbytes... BYTES. Closed queries are dirt-cheap.
As long as you don't have images embedded in the DB, forms and reports are relatively small, but do depend on the complexity of the form. Unfortunately, the "powers that be" at Microsoft have not published internals of the data structures so it would be a huge guess to tell you the sizes of forms and reports as structures in a FE file. However, based on the properties visible in property sheets, I would guess that forms overall would have no more than 400 bytes for the form itself plus probably a couple of hundred bytes for each section and on the average between 200 and 400 bytes per control, varying. This is based on looking at the property sheets for the those objects, counting properties, and making wild-arsed guesses at the data structure sizes. This is NOT based on any actual article that tells us actual sizes.
If you could be more specific as to your needs, we might be able to either give you a solution or a workaround, or explain why you really DON'T want to do that to your FE file. Answering a question like yours without knowing the end game is kind of difficult.