It looks like there’s a JS call to include a script and the path is not resolving. Maybe a typo in the name of the file or may be that the file didn’t get uploaded on the last publish for some reason.
In any case, I’d fix that first. Depending on the platform you can see a long pause when the browser is waiting to try to resolve that – or give up.
To move along further – you really have to measure what is taking the time in order to know how to optimize. Old developer adage: never optimize before you measure.
Fortunately Safari and Chrome come with some good tools. I’ll use the Safari ones here – just because they’re prettier. 
Both work great.
If we look at the graph we can see that the primary page renders around 2.1 seconds. This will vary A LOT depending on connection speed, device type, screen resolution, retina, etc. So the numbers will always just be relative measures. That said, my details are: 1080p retina display on a very fast mac with a 1Gb/s connection. So load times tend to be a bit faster than average. So if there are long loads in these graphs we know they’re a problem.
Next we can look at what is taking up those 2.1 seconds by expanding the graph. There’s a lot to see. A bunch of JS and CSS files are downloading. But a large chunk of time is taken up loading a lot of thumbnail images. You can see when the last thumbnail loads, the page renders almost immediately afterwards.
The primary thing you’d like to show the user ASAP is pretty simple, namely: one very large photo and some basic menus and things.
The low hanging fruit are all those thumbnails: we’re not even looking at them. Why wait for all those thumbnails when the users won’t see them until they click. Just render the page after the one big image loads. Then download all those thumbnails in the background.
So, I’d try to restructure the page a bit so that the thumbnails use a JS to cache in the background. I don’t know if the script/stack/whatever will allow that – but I think that’s what will need to happen to improve things in any significant way.
If you’re using some other tool to generate the scripts/slideshows/thumbnails then I’d contact the developer directly and show them those timeline graphs. I suspect they just don’t realize that those thumbnails are in the critical path of the page-load. Or maybe they even know of a simple way to work around this.
If you’re doing this on your own, then go find yourself a background image caching script. Google and you’ll find a ton.
I don’t generally like to disagree with other posters – but in this case I’d recommend against the other suggestion. I would NOT cut down your images. Your site is all about images – scaling them down or cutting quality is only going to shave a few percent – and the cost to those meager savings will be reducing the very thing that you’re trying to show off.
Or, at least get that low hanging fruit first. Once there’s nothing else to cut or load later, then you can optimize the images a bit more.
Good luck with the page. It looks great.
Isaiah
(/uploads/realmacsoftware1/original/2X/0/027c67490e1c5faaff73f481d369b5ab5c5b3123.png)
