Testing for performance is only half the battle. At some point, you must actually implement performance optimizations and compare results to make sure your site is getting faster. Sometimes you want to test out an optimization, such as using a different CDN or loading assets from a different system. Other times you want to understand if a specific piece of third party content is a single point of failure. In this post we’ll discuss two methods for testing optimizations without making major changes to your site’s source code:
- Using DNS Overrides to test how requests from different domains would affect performance
- Creating simulated failed requests to see how Single Points of Failure (SPOFs) would affect performance
Testing with DNS Overrides
DNS Overrides allow you to change a request to a specific domain to instead go to a different IP address or hostname. This is helpful because you can test specific types of requests without modifying the HTML source.
For example, let’s imagine that we want to test the media website CNN.com to see what performance issues would be resolved using a different content delivery network (CDN) provider. Right now, CNN is using a CDN at
i2.cdn.turner.com. If you look in the HTML source, you will see links to that host. If you wanted to test a new CDN, you could go through and modify the CNN’s backend to change all those links to use a different CDN, such as CloudFront. Unfortunately, this is a ton of work, and it requires the ability to modify source code on CNN.com, which you may or may not have. This is where we can use DNS overriding.
You can configure performance tools such as Rigor Optimization to scan CNN.com and use DNS overrides so that all requests to
i2.cdn.turner.com will instead be sent to
d37gvrvc0wt4s1.cloudfront.net instead. You can see this in the screen shot below:
During the scan, when Rigor Optimization sees a URL to
i2.cdn.turner.com, like this image, it will instead make a connection to
d37gvrvc0wt4s1.cloudfront.net. Rigor then makes the same request to
d37gvrvc0wt4s1.cloudfront.net that it would have made to
i2.cdn.turner.com, complete with a
Host header. In the screenshot below we can see this example:
We can see Rigor Optimization is auditing this URL. However, it makes a connection to
d37gvrvc0wt4s1.cloudfront.net and sends that request. Rigor Optimization includes a special
X-DNS-Override-To: header so you can see what location Rigor Optimization actually sent this request to.
With DNS overriding, you can test whether one CDN is better than another for your site without all of the complexity of changing your backend. This makes DNS overriding an excellent way to forecast the impact of optimizations.
Testing for Single Points of Failure
This page loads in about 19 seconds, as you can see the waterfall here:
We can see that the request to Optimizely is right now the top. Now let’s see what happens to IBM’s performance if Optimizely’s systems went down. We can use DNS Overrides to simulate a failure of Optimizely by sending requests to
blackhole.webpagetest.org. This is a special domain that never responds to any requests or connection attempts, and it perfectly replicates an unresponsive server.
Here is the Waterfall when we create a SPOF with
Rigor Optimization now supports DNS overriding. For our customers, you can find the DNS override setting in the “Advanced” tab, under “Browser Configuration.” WebPageTest is another popular, open source tool that supports DNS overriding. You can use WebPageTest’s
setDNSName scripting functions or use the “SPOF” tab when starting a test to automatically override DNS to point to
Interested in super specific performance optimizations like SPOF testing and DNS Overrides? Then you will love Rigor’s performance monitoring and optimization platform. Our continuous monitoring provides 24/7 performance visibility of your website’s performance and availability and can identify hundreds of performance defects that are slowing it down.