Unfortunately, given how Flickr’s API returns collections, this is always going to be slow. Let me try to explain.
The collections API has one public method – flickr.collections.getTree, but this returns very little information. True, it returns the name of a collection, its thumbnails and included sets, but there is no information about the sets apart from the id, title and description. Specifically, there is no information about the thumbnails for the set, how many photos are in it etc. To get this second level of information, I pretty much have to iterate through each of the sets, and each is an individual API call. So, if you have 5 collections and underneath them you have a total of 50 albums, you will be really hitting the server very hard.
Can the page be shown while the collections are being fetched? Not the way it is currently built. All the fetching and processing activities for collections (and pretty much everything else) happens in the back-end. There are many reasons for this including keeping down JavaScript bloat and ensuring proper indexing of pages by search engines. But as a by-product, until the post content is fully generated, it will not come to the front-end. There is no way to selectively show the content early, because it is not that the images are taking a long time to load; the problem is that the server itself is taking long to generate the content (i.e. the text + images). The lazy display of photos is already built in: the text shows up first, while the JS engine tries to figure out how to lay out the pictures, and the images come up when ready.
I could consider a solution wherein collections are processed via the front-end but everything else is in the front-end, but I cannot commit to a timeline for it, since it is going to be quite a big change.
As an alternative to speed things up, why not consider separate pages for each collection? The plugin is noticeably faster if you are displaying a single collection.