Yeah, most of your issues are are from the .js files you have spread through the site. Your home page alone has 19 .js files, all spread throughout the page code so that they break parallel object requests.
I'd highly recommend getting someone to combine, minimize the .js files and then serve them via gzip encoding from a single request at the bottom of your webpages. Then, create two or more sub domains and spread the serving of some of your other resources using those. And, an advanced technique you can do as well is css spriting, which will combine your individual images into a larger single image. Those things alone will cut the loading time in half. And for repeat viewings, a simple addition to your .htaccess file (assuming linux), will make your site load in under 1 second. You may also want to get rid of the request for that 404 object (...webfont.svg) and you have a page being requested that returns a 500 error (internal server error, aka "not good").

Though, i am sorry to say that i am too busy myself to help you. But i wish you luck in your search.

You have to know what you are doing before you make that change though because you could break the ability to update your site. As long as you change the file names when you change the files (css and js are usually the ones to be concerned with) then it's a quick and easy win. I usually just add a version number to the end of the files as a query param so I don't have to change the actual file but I can still bust the browser cache - i.e. my.css?v=2

Yes, that was the code I was talking about, I gave a higher level explanation as Inbal said he was hiring out, and they'd know what I was referring to.
Though, I'd almost argue that you can do a non-far future expiration, and still leverage the browser cache well. Some types of sites may get repeat visits within a short period of time and only that short period of time, and so you can set the cache time for less. Even a cache time of 30 days is a major improvement over no cache settings. This also allows you to not have to change the file name all the time if the data you're altering is not critical, in which case you can allow the natural expiration to take place. We do this on our site, all product thumbnails are set to expire in 30 days (same with the cdn edge server cache). The images are updated all the time, but we don't necessarily worry about these images and let them expire/refresh naturally (unless it's a critical error, like image of the wrong product). I'd also look into different cache settings for different files. CSS and JS files for example will get most of their use from page to page viewings within the same browsing session, and thus even a cache period of 1 day (though i'd recommend going higher) would be sufficient to allow a large amount of cache hits for most of your visitors.
Though, with that said, appending version numbers to certain files, or changing the file name, is still a good idea if the changes are critical ones (like layout changes with .css).
And to clarify, when i say the repeat viewings will load in less than 1 second, that is assuming you can cache the majority, if not all of your static content. Thus, all that is left for page load is the loading of the main page code doc (dns lookup, connection time, time to first byte, and doc content download). Unless you have a ton of backend overhead or are testing from a location across the globe, this time should be under 1 second on average. This is of course best used with chunked encoding to allow the browser to start processing the data before the entire code doc is downloaded. Though chunked encoding, with flushing early (with your css at the top) will in general reduce your start render time.