Since I never got a copy of this document after the emergency 4am wakeup call and deletion (LOL – that will make a good story over beers later) – I’m just going to take a wile guess at what might be the cause based solely on “large document” and “primarily a problem on retina display”.
One problem I’ve seen a lot is that people have many retina resolution images on the page in image-warehousing type stacks. Since warehoused images are online, each of these large images must be downloaded each time the page is rendered – they will be cached, but only a few – if you have many images and many pages the cache quickly gets used up.
Downloading large images over the internet is slow. That’s all there is to it. There is no way of speeding this up short of calling your internet provider and sending them lots of extra $$$.
A couple recent documents I’ve seen where warehousing dozens of images – (at several resolutions for responsive behavior) – and needed to download all of them to render the edit mode display. This takes a really really long time (tech detail: WebKit only renders on the main thread – so the UI is hung while it does its work – this means if the render takes more than a couple seconds the Mac shows the beachball).
The solution is a tradeoff: stop warehousing images on pages like this. This will mean the document will open more slowly (since it will contain those images), but the upside is that those images will be on your local machine while you’re working and stacks can load them direct from memory, which vastly more efficient and much faster.
If you are warehousing images on this page, then I think trying out local images on a test document might be worth the time it takes to experiment. If it yields no substantial results we can look elsewhere.