Page load speed with E-Junkie Implemented v PayPal

[gardenseedsuk]

I run a small web based garden seed shop. The address is www.gardenseeds.co.uk. I currently use HTML Intergration PayPal, but have changed a copy of one of my pages so I can try the E-Junke solution (I want to add Google Checkout)



The original version of the page is at www.gardenseeds.co.uk/flowers01.html



and the version using E-Junkie code is



www.gardenseeds.co.uk/copy/flowers01.html



The page with your code on seems to load very much slowly than the PayPal version.



Any ideas?



Best wishes

[E-junkie_Guru]

It may help to understand the various connections at work when you are browsing your page:



Consider a Y-shaped diagram, where the stem is your connection to your ISP, one upper branch is the network route between your ISP and your main Web site server, and the other branch is the network route between your ISP and E-junkie's datacenter (or between your ISP and PayPal). Your page's overall responsiveness is only as fast as the slowest/longest of those three connections at any given moment, and the slowest link would be different for someone else on a different computer connected to a different ISP somewhere else in the world.



The route from your own ISP to your own site's server may be short and fairly direct, whereas the route to E-junkie's datacenter may be comparatively long and convoluted; if you replace the route to E-junkie with a route to PayPal instead, that link may well be quicker from your location, especially the further away your ISP is from Arizona. We don't notice much difference between your E-junkie page vs. your PayPal page from here, because our own datacenter is just across town, and PayPal is practically next door in California; from our vantage point here, your main Web site server in the UK is the "slow link" in our 3-way chain.



PayPal -- being a massive corporation (that's part of an even-more-massive corporation -- namely, eBay) with correspondingly massive, and multiple, backbone connections to handle the millions of transactions they process every day -- can simply provide better connectivity to your overseas ISP than we can even afford -- despite our own datacenter having multiply-redundant backbone connections of their own, it's a matter of scale and degree. Maybe someday if we get as massive as PayPal, we can afford the kind of massive connectivity (and the staff to support it!) that they currently enjoy.



You can minimize the wait from our branch by using your own cart button images, as described here:

http://www.e-junkie.com/ej/help.customization.php#button

[ryannagy]

Tyson -



Hosting the "add to cart" and "view cart" button on my servers would indeed help the page load faster and I am adding them right now. Thanks foe tip.



What can be done to help the cart itself load faster? Anything? My sense is a shorter load time would increase my conversion rate.



Any input appreciated.



- Ryan

http://ryannagy.com

[ryannagy]

I think I have answered my own question. On the shopping cart customization page, I can able to modify the cart and host both the paypal and google checkout images on my server, decreasing the load time:



http://www.e-junkie.com/ej/help.custom-cart.htm



I assume that would help, do you concur? Any other suggestions for decreasing the load time?



- Ryan

[E-junkie_Guru]

You could also try changing any instances of this:

https://www.e-junkie.com/...etc.

...in your button code to use this instead:

http://www.e-junkie.com/...etc.



There's really very few if any cases where merely adding/viewing items in the cart would actually need to be secure-encrypted -- and of course actual checkout where private and financial data is transmitted would always be secure regardless -- but we issue SSL-enabled button codes by default anyway.



We do that to prevent security warnings for merchants who may be using our code in their own, SSL-enabled storefront pages, and it satisfies merchants and buyers who may mistakenly believe or insist that everything to do with eCommerce must be secured with a padlock icon from end to end at every turn, even when no sensitive data is being transmitted.



In reality of course, our cart and button codes can all quite safely use regular http:// URLs to eliminate the performance hit of cryptography being used where it's not needed in trivial events where no personal, financial, or other sensitive data is being transmitted.

[ryannagy]

Tyson - This suggestion:



"You could also try changing any instances of this:

https://www.e-junkie.com/...etc.

...in your button code to use this instead:

http://www.e-junkie.com/...etc."



Made a huge difference. The cart loads in about 30% of the time that it did. Thanks.



And if anyone needs help implementing these suggestions, feel free to send me an email. I am super busy these days, but I do quite a bit of work with e-junkie and may be able help you if I have the time:



ryan AT ryannagy.com

801-598-7230

[personalityjunkie]

Now some 6 years later, is it still acceptable to change the ejunkie https urls to http? From what I can tell, doing so still seems to work and reduces load times. I wondered if it could potentially trigger Paypal captchas?

[E-junkie_Guru]

Our button codes still work fine with either http: or https: URLs, so take your pick.



That said, I just now set up test pages for each version, both with one set of Add to Cart code and one full set of View Cart code, and nothing else. Using the Timeline chart in Firebug's Net panel to analyze load times, force-reloading each page several times showed that neither version was consistently faster than the other, and the longest load durations were ~2-3 times the shortest durations for both versions (ranging from about 0.5s to 1.5s over my connection).



This help page covers some other tips you may find useful for improving page load performance with E-junkie Cart button codes:

http://www.e-junkie.com/ej/tips.buttons.cart.speed.htm