I saw no problems loading your page from this end, so it may be a simple matter of geography and Internet routing across the pond to the UK. I notice you're using your own button images, so the only thing your page is loading from our Tucson datacenter would be our box.js script, which operates the overlay-style cart "inside" your page.



If you want to test, find this line in your page:



<script src='1http://www.e-junkie.com/ecom/box.js1' type='text/javascript'></script>



...and disable it by "commenting it out" in HTML, like so:



<!-- script src='1http://www.e-junkie.com/ecom/box.js1' type='text/javascript'></script -->



Then clear your browser cache and reload the page (use Ctrl-Refresh or Ctrl-F5) to see if that improves your page loads. If so, then that is indeed the drag, at least for buyers near your location (I didn't experience the problem because I'm loading box.js from our datacenter just across town, not across an entire ocean and continent :^). Other UK buyers in a region with more robust Internet connectivity (say, around London) may not even notice much of a drag at all.



In that case, you may want to consider giving up the overlay-style cart (which requires loading that box.js file from our server) and just use the non-JavaScript version of our button codes, which opens the cart in a new window/tab. You don't really even need to replace your button codes, as simply removing box.js will make your existing JS buttons work in "fallback mode" using the new window/tab anyway.



We do not recommend saving a local copy of box.js to load from your own server, as that would miss any bugfixes or other enhancements to the cart we roll out from time to time, and we haven't really designed box.js to work as a local copy nor tested it that way, so we can't be certain it would work properly.

It's a strange coincidence, but I actually stopped by to ask about the same point. I am also in the UK and have one version of my sales page for ClickBank that loads pretty much instantly and the other using the e-junkie cart that loads the top half of the page right up to the cart button, but then waits for about two seconds before the second half starts to load and I was wondering what may be causing this. I have a relatively fast connection so others may well be experiencing more exaggerated slow downs.



For the sake of comparison I visited Tom's site and it seemed to load far quicker than mine.

I've just checked out my site on different browsers and seen greatly varying results. I.E and FireFox are loading the whole page in about a second. Chrome is slower with some pause and Safari seems to hit a real block for a couple of seconds before the rest of the page loads after the cart. This is particularly strange because Safari and Chrome are normally the two quickest browsers, but something is tripping them up in this case.

The interesting thing about Safari and Chrome is that they're both based on the same basic page-rendering engine, WebKit, so there may be something idiosyncratic about the way WebKit is behaving that doesn't affect other browsers like IE, Firefox or Opera which each use their own rendering engines.



As I was alluding to above, page load performance will depend on each user's general geographic location and the robustness of their ISP connection.



When your browser loads the page, it loads the page source itself and any of its images and other files (JS/CSS/etc.) from the same server where you host your Web site, but it loads the parts relating to our cart (our button images and the box.js cart script) from our Tucson datacenter.



Greater distance from Tucson will tend to correspond with decreasing responsiveness, and a really robust connection (say, using an ISP with a lot of high-capacity backbone redundancy and surplus capacity) will tend to perform better than a marginal one (ISP using only one fat backbone uplink or a few smallish ones, or running close to full capacity).

It may be technically possible, but we really don't recommend it, as your local copy would miss the bugfixes, feature upgrades and other improvements we roll out from time to time. Also, we really only build and test our script to work just as we provide it, so we can't be certain it would work properly as a local copy, nor can we predict or help fix whatever problems you might encounter with that. If you want to do this anyway, that would be entirely up to you to accomplish and, if necessary, troubleshoot on your own.