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.
6 replies on “Performance Analysis: lds.org”
Nice review.
I am not a member of the lds.org team, but I do work at the church, and am kind of the resident performance guru/pesterer (unoficially). Pretty much everything on your list has been on the radar for quite a while, they are just taking time to implement.
Getting the site up and running, and porting over the tons of content has understandably been the priority. But we do get the occasional performance victory as well.
Two of the biggest wins so far have been to:
1) get the carousel content loaded at the very bottom of the page. Yes those large banner images could be optimized (trying to get that built into the process), but all but the first one are loaded via ajax when the jQuery ondomload fires, so they at least are not really influencing the render time of the page. This is naturally a huge win from loading a few hundred K worth of images at the top of the page, that weren’t even going to be seen for a while.
2) get the cdn.lds.org up and running. This has been a long time coming, and we still have room to grow. The .lds.org cookies being applied to the subdomain somehow slipped past my defenses and I recognized that as soon as the CDN started being used. Gonna have to look into getting that separate domain. The CDN only got into production a week or two ago, so it was late to the game for the lds.org update. That they have any files pointing to it is awesome, and we hope to increase that number as things progress.
Files that we know will not change, and that we can put a version number on (jQuery), get the 20 year cache. Files that are more site specific, and that will be updated fairly regularly get the 4 hour cache, which is at least up from the 1 hr they used to have.
We had to find a happy medium between a long cache on files that would have a unique name versus common names that could NOT be cached forever else things might break when we updated. With a site as large as lds.org it is very difficult to introduce a version number into the name as not all parts of the site are built at once. So 4 hours is the happy medium we came up with. If you have other insight into how to get around this we’d love to hear it.
Per the “46 parallelizable” requests, the biggest thing I am pushing for here is to create some sprites to reduce the number. 20-30 or so could easily be moved into a few sprites to drop that connection count dramatically. Again, getting the site out the door being the priority I didn’t pester too much on this. But now that it IS out the door, I can be a little more annoying 😉
Whenever I hear about a site coming on line (newsroom, store.lds.org, mormon.org, etc) I do a review very similar to yours and put it directly in the hands of the teams responsible. Similar to the above, getting the site out the door is priority, but teams are becoming more and more performance conscious.
There is a long climb ahead, but I am optimistic for the future. Things will steadily continue to get better.
Thanks again for your review. As many voices preaching the same “gospel” can only help the cause 🙂
Hi Aaron, thanks for taking a look at this.
There is one very simple, very easy thing that will help improve things – enable HTTP compression. As you know, this requires zero changes to the site, it is strictly a server level issue. I know a few people in the IT department, but so far have had little luck actually getting that changed. At this point I’m beginning to wonder if MarkLogic doesn’t support HTTP compression, if that is the case they should pack it up and send it back to 1999.
On versioning resources, there are plenty of smart folks there, I’m sure they can manage that 🙂 We do it for WordPress.com, which I believe is a much larger site than lds.org.
Good to hear that more of the teams are looking at performance. It isn’t just the design and code teams though, the server and network people need to be involved as well. I’m going to continue to push for doing at least the basics, which not only improve performance, but can save the church money.
I’m happy to chat more about this, drop me a note if you want to meet for lunch sometime.
compression… yeah, tell me about it. I keep saying “all it is is flipping a switch”. Not sure where in the chain it is getting hung up. Definitely one I will be pounding on.
versioning – it’s not as much the size of the site as I am sure wordpress is much bigger. It’s the different projects. calendar, directory, content, scriptures, etc are all different projects running at different speeds. I don’t want to talk out of place too much, just to say that I have brought this up many times and been told an emphatic “no.” So we work with what we can 🙂
I’ve been asking for better HTTP compression from different folks there for a couple of years, hopefully it will eventually get to the right person 🙂
Unfortunate on the versioning since that has such a negative impact on caching. Also if you ever move to a separate commercial CDN you may run into invalidation issues.
I sent your post over to my buddy there. It appears that, as of this morning, gzip compression is on for all but one element on the page.
Thanks Mike!
I specifically forwarded this to a few people I know as well. I’m not sure who or how, but the latest test I ran – http://www.webpagetest.org/result/101202_1F7E/ – does show all appropriate requests getting a compressed response. One down, several more million sites to go 😉