Development of a new version of lds.org has been available on new.lds.org for some time. As of 30 November 2010 that new version is now live on lds.org. I’d taken a few quick looks at the performance of the new version previously, but with it now live this seemed like a good time to take a closer look.
First up, the webpagetest.org results for lds.org. Some numbers for reference:
- Data transfered: 1,287 KB
- Number of HTTP requests: 66
- Fully loaded time: 2.3 seconds (taken with a grain of salt, this is just a single test)
The score for HTTP compression is an F, but that doesn’t really tell the whole story. Most of the resources on the page are loaded from lds.org and cdn.lds.org. Only cdn.lds.org (Apache web server) is responding with compressed results, lds.org (MarkLogic web server) never provides a compressed response. This results in an extra 118 KB sent over the wire. Given the initial large size of the data transfer for the site this is not a huge dent, but still big enough to make a difference. With HTTP compression enabled the total data count drops to 1,169 KB.
Something that would make a bigger dent is image optimization. The image compression analysis indicates another 478 KB in data savings that could be achieved. Combined with HTTP compression support this brings the page down to 691 KB. Addressing these two issues brings us down to 54% of the original page weight. No doubt this would reduce the time it takes to fully load the page. (Exactly how much you can reasonably compress a JPEG may vary, so take these numbers as a ball part estimate)
There are three external CSS files, minifying those would save another 17 KB, bringing our running total down to 674 KB. If you were to combine them as well you could cut out 2 HTTP requests entirely, which would help reduce the page load time.
Minifying the HTML output would cut out another 7 KB. This gets us down to 667 KB.
I thought this was going to be it for data reduction, but then I took a closer look at the Javascript files, some of them could still be reduced (which I tested with http://closure-compiler.appspot.com/home):
- https://cdn.lds.org/ml/platform/scripts/platform-utilities.js – original 8 KB, compiled 6 KB
- https://lds.org/resources/script/common/s_code_ldsall.js – original 12 KB, compiled 11 KB
- https://lds.org/resources/script/common/content.js – original 1.6 KB, compiled 1.2 KB
- https://lds.org/resources/script/pages/home.js – original 502 bytes, compiled 367 bytes
All of those numbers are the compressed versions of the files. They add up to an additional 3.5 KB of savings, which makes our new total 663.5 (664) KB.
All of those items together brings down the data transfer by nearly 50%. There are other things besides reducing the total data numbers that we can do to improve the performance of the site.
There are 46 parallelizable (is that a word?) requests to lds.org. Browsers have been increasing the number of concurrent connections they’ll support for a single host, but 46 seems well beyond that. Splitting that up across two or three host names would allow browsers to download more of the resources in parallel. Same is true for cdn.lds.org, but on a smaller scale for this particular page, which loads 12 items from there. Breaking that up across two or three host names would help.
I found the use of cdn.lds.org interesting. This is a good first step, common files used across various church sites can load resources from there and hopefully see increased cache hits. The ‘Expires’ header puts some of the resources out as far as 20 years. Others are as small as 4 hours, which should be increased. Another common reason for using a CDN is the lack of cookies needed for the request. Unfortunately using the same domain (lds.org and cdn.lds.org) means that requests to cdn.lds.org include the lds.org cookie.
I looked at this in more detail after I logged into the site, the cookie data added an extra 421 bytes to each request sent to cdn.lds.org, that goes completely unused. That comes out to some where around 5 KB of data sent to cdn.lds.org servers that is completely useless. To add insult to injury, the cookie data is also sent when the browser checks to see if the file has been updated ( If-Modified-Since and If-None-Match ). The solution would be to move the CDN to a separate domain name that is only used by the CDN and nothing else. You still get the distributed site caching and additional parallel download benefits and the browser will never have additional (useless) cookie data to send for each request.
While on the topic of caching, many of the resources loaded from lds.org have a very short Expires setting, just one hour. These could be cached for much longer, saving on bandwidth for subsequent page requests.
I already mentioned combining CSS files, the same could be done for some of the Javascript files as well. Reducing the total number of HTTP requests cuts out the over head involved with each request. Another option for reducing the number of requests is to combine some of the images into CSS sprites.
There are other things the site could do to improver performance (like moving more of the Javascript to the bottom of the page), but this list is a good start, with several options on how to improve the performance of the new lds.org site. Some are more involved than others, but in the end substantial reductions can be had in the amount of data transfered, the total number of resource requests on the page and the fully loaded time.