Basically, you want it to build the cache first before using the layout. I don't think looping through will help unless as it loops through, it is refreshing or doing some calculation on fields you want cached. It may be as simple as sorting the calculation field that needs a cache built, but then again, you may have multiple fields that need cached. Also, while looping through won't work, down page downs through it probably will, but only in 11 and not in 12.
FileMaker doesn't work like that. What you're describing is a consequence of how FileMaker refreshes and loads records. There are two primary things going on here. One has to do with the loading of the records themselves; the other has to do with the refreshing of unstored calculations.
I'll ask this question: Is this database being hosted by FileMaker Server over a network? Because if it's not, then the record loading issue doesn't make any difference, and we can skip it entirely. Otherwise, we can look at it.
When you say, "... calculations in related tables", I'm going to assume you mean unstored calculations (because if they were stored calculations, you likely wouldn't see what you're seeing). Unstored calculations only refresh their values when they're needed - for example, when they're being displayed to the user. (Other times include when they have to be evaluated as part of a relationship - on the parent side - or in order to evaluate another calculated expression.) They're not stored in the database, but only in the cache - and they require updating whenever the conditions that drive their values change (not that they are necessarily updated then; they just require updating).
So, freezing the window - or even looping through the records - will likely not help much, especially in a multi-user environment (you haven't indicated whether this is true or not, but it's a consideration). What we probably need to look at instead is either (a) making your calculations more efficient (so they update faster), or (b) finding a way of storing their results (so they don't have to be updated on the fly). The latter option is counseled by some developers, but others are ... enthusiastic opponents for a variety of reasons.
So, short version: Perhaps if you posted some sample calculations, or a copy of the database, we might be able to help you look at them for optimizing purposes.
If your users only need to see the data, and not manipulate them, if they don't need to interact with them, no buton, then you can render everything in html in a webwiever, and that's super fast to scroll.
It could be isues with the interface design. Duplicate the layout and strip it right back: remove script triggers, conditional formatting, graphics, everything. Test for speed now. If it's better then work out what's causing the bottleneck.