During the day, I’m the VP of Sales @NetDNA. That makes me spin up our Catchpoint and Keynote accounts to run performance tests on all kinds of websites. Below you’ll find some time-tested and very common performance tweaks that are 1) safe to use, 2) best-practices and 3) like gzip, actually help reducing bandwidth consumption (and your CDN bill) – items that we run into all the time when conducting performance tests.
1) Utilize hostname sharding
The HTTP/1.1 protocol specifies that browsers download two objects in parallel per host name. If you have ten total objects to download, the browser will break it down into five individual requests, in pair of two’s. Adding one or multiple additional hostnames is called domain sharding.
Instead of downloading all static objects via cdn.domain.com, a website utilizing hostname sharding will use cdn1.domain.com & cdn2.domain.com to increase the number or parallel downloads. If you’re not familiar with hostname sharding, Steve Souders posted a great article found here. For a more comprehensive overview, Googler Aaron Hopkins goes into quite some detail about browser preferences using HTTP/1.1 here.
Hint: Always use the same domain to avoid multiple DNS-lookups. For example, it is better to use cdn2.domain.com vs. cdn2.domain.net!
2) Forcing file compression on the CDN
Not using compression increases the initial load time for facebook.com by 414% on a broadband connection. This and more great data is available in a post Arvind Jain and Jason Glasgow here about the advantages of compression.
If a browser accepts compressed files or not, depends on many variables outside of a webmaster’s control, such as browser type, anti-virus software installed on the user machine, proxies, etc. However, most CDNs by default do not force compression and cache static asset directly from the origin server. You can ask your CDN to force compression on all files that are received from the origin server in an uncompressed format and store a compressed version in cache. The CDN will then send only compressed objects to all requests, unless compression is not supported – for instance if a user is using a proxy with IE6 on a request using HTTP/1.0.
3) Checking your cache-hit percentages
The cache-hit percentage is the best indicator of the effectiveness of your CDN. If an object is requested that is not yet cached on the CDN, it will request the object from the origin server and count it as a cache-miss. A good cache-hit ratio is above 95% where as an excellent ratio is being considered to be 99% and higher. This would mean that less than 1 in 100 requests are *not* served by the CDN and have to be requested from the origin.
Figure 1.1 shows a properly configured account. The first column identifies all hits that were cache-misses, the second column shows all successful cache-hits. A ratio above 99% is excellent.
If you see a cache-hit ratio below 80% on static files, your CDN is either poorly configured or not performing.
Hint: In case you see low cache-hit ratios, check your query strings settings first and see if your CDN is treating objects with query strings as separately cachable files!
@samir_said_that is VP of Sales at @NetDNA and loves everything about entrepreneurship, web speed, python/django. Samir is an avid performance tester with a passion for sales. Prior to NetDNA, Samir bootstrapped IXWebhosting.com together with his siblings, which provides shared hosting services to over 500,000 domains.