Technically it is the blue bar but it isn’t actually downloading content that whole time (the bandwidth utilization is 0). What is happening is that your site is sending out the bulk of it’s content quickly and the browser loads what it can but something near the very end is doing a VERY expensive operation on the server which is causing the very last part of the HTML to take 15 seconds before it is generated.
I’d start by looking at anything that comes before wedding-new.jpg in the site code (though it might also come after that and the buffers just don’t get flushed out). Odds are that it is going to be a back-end call out to some other service or to a database. It could even be something that isn’t user visible (like some back-end process that tracks stats).
If you can track it down and fix/remove the expensive operation it will also SIGNIFICANTLY improve your server capacity because that long operation is also tying up one of your server connections for the 15+seconds.
I used WPTs TCPDump feature, and there it is visible, that you receive two chunks, totalling in 2444 Bytes, rather immediately. And then, after some 15 seconds, you get the final 430 Bytes. Unfortunately the answer is gzipped, so you can’t see, what is in the last 430 Bytes (@Pat: How about a feature, that let’s you disable Accept-Encoding GZIP Headers? )
Looking at the decompressed response, the bottom area of the Page’s source right before the wedding image, and after the last quickly loaded image, looks like this:
Nice. Out of curiosity, how was .htaccess referencing the file? It just seems really strange for it to hit right in the middle of the response (though it could have been hitting at the end and the buffer just hadn’t flushed yet).