You have a pretty good handle on how your application works. You’ve talked the design through with your development team and maybe even sat in on some standalone tests or watched a demo performed under lab conditions. Everything looked good until it came time to test your application with all of the third party calls integrated. Now page load times have gone through the roof.

Third party calls can add seconds to your page load time, can bog down your application’s ability to respond and can compromise your website’s security with fourth-party calls to unknown, and possibly unsafe, content.

Load testing may tell you a lot about how your website is running, but it can’t diagnose why third-party calls take so long to complete. It could be an overloaded DNS resolver, it could be a slow third or fourth party server, it could even be that the content has to flow through a congested internet link. All the tests are showing is a waterfall chart with a huge space between ‘Start Render’ and ‘Document Complete’.

So how do those third party calls affect your load test? Simply stated, they slow down your processes with their prolonged wait times. That means that each process waiting for a response is occupying one of the limited number of threads that a CPU can handle. You can use up your thread pool while, at the same time, not be able to exercise your code to its fullest because of extended wait times.

So how can load testing help you sort out your problems?  To start with, you will have the chance to see exactly which third party calls are causing your slowdown. You can then work with your third-party partner to find out how to speed up exchanges, or you can negotiate with a new partner whose response times are better. You can also work with your third-party partner to find out what kind of fourth-party calls are being included in the transaction and figure out how to optimize those exchanges.

Your testing may show that the website is laid out poorly, with third-party calls happening early in the page render. This information could then be relayed back to the web developers for a rewrite of the page to put those third-party calls later in the rendering sequence.

The bottom line is that testing won’t fix your problems, it will only tell you where they are so you can get your coders working on them.  However, without testing you’ll be left to troubleshoot your website in production, where your customers will be your unhappy test team.