Last spring, I did a fun little exercise where I measured the load times of the campaign sites belonging to candidates in the Republican primary, and then plotted them on a graph to see how their speed correlated to their position in the polls. At the time, Romney was the front runner in the polls. He also had one of the fastest sites — though “fast” is a relative term here — at 9.3 seconds. Interestingly, Obama’s site was slower than all the GOP candidates’ sites, at 13.6 seconds.
A lot has happened since then. Articles have been written about mobile use among minority groups (who reportedly tend to vote Democrat), the candidates’ different mobile strategies (Romney’s mobile-specific site vs. Obama’s responsively site), and the role of social media in the election.
With election day around the corner, I thought it would be interesting to take a fresh look at the candidates’ pages on both desktop and mobile and see what comes up. As it turns out, there’s some good debate fodder in the results.
1. Desktop: Tested splash screens and home pages at barackobama.com and mittromney.com 10 times each on Internet Explorer 8 via WebPagetest’s servers in Dulles (VA), Asheville (NC), Miama (FL), Kansas City (MO), and Los Angeles (CA). Calculated median load times for each.
2. Mobile: Tested splash screens and home pages at barackobama.com and m.mittromney.com 5 times each on iPhone 4 over 3G and Wifi via stopwatch. Cleared cache and cookies between each set of tests. Calculated median load times for each.
Desktop results (load times, in seconds, on IE8)
|Location||barackobama.com – splash
||mittromney.com – splash|
|Kansas City, MO||5.315||9.300|
|Los Angeles, CA||5.290||9.483|
Above, we see Obama’s splash page come out ahead, 38% faster than Romney’s.
|Location||barackobama.com – home
||mittromney.com – home
|Kansas City, MO||16.372||11.415|
|Los Angeles, CA||15.291||11.371|
But Romney’s home page fully loads 20% faster than Obama’s.
Mobile results (load times, in seconds, using iPhone 4’s native Safari browser)
|Connection||barackobama.com – splash
||m.mittromney.com – splash
Romney’s m.site splash page loads in about half the time it takes for Obama’s RWD page to load over Wifi, but takes 46% longer over 3G.
|Connection||barackobama.com – home
||m.mittromney.com – home
Obama’s responsively designed home page just edges out Romney’s m.site over Wifi and 3G.
Finding 1: Both candidates’ pages are bulky, slow, and contain resources from many domains.
Not only are these pages big, they’re also grabbing resources from a lot of domains: 37 for Obama’s site and 31 for Romney’s. Each of these unique domains extracts a performance penalty, due to the fact that the user’s browser has to perform a DNS lookup for each one, kind of like how you use a phone book to find someone’s phone number using their first and last name. It typically takes 20-120 milliseconds for DNS to lookup the IP address for a given hostname. The browser can’t download anything from this hostname until the DNS lookup is completed. All those DNS lookups can add up, and that’s before you even factor in the transfer time for the actual file.
Grabbing the filmstrip view of each page load gives you a good idea of what huge payload combined with multiple domains do to performance.
First, check out Obama’s home page, which doesn’t substantially render until the 9-second mark:
Romney’s page loads the outer content first, leaving the banner call to action — ostensibly the most important content on the page, to load last, at around 12 seconds:
If you contrast this with the results in the table above, you’ll note that, while on paper Romney’s home page fully loads 20% faster than Obama’s, the Romney home page actually appears to take 3 seconds longer from a real user’s perspective. (This is a great reminder of the importance of getting down on the ground and watching how pages actually perform, and not just looking at numbers in a chart.)
Finding 2: Secure resources are a major performance roadblock at barackobama.com.
While Obama’s pages may load perceptually faster than Romney’s, they seem to be struggling against some performance impediments in the form of a heap of mostly unnecessary SSL resources.
Below is a waterfall chart for Obama’s splash page, with each row representing a unique page element. If you’re not familiar with waterfall charts, I recommend this layperson-friendly primer, but for our purposes today, it’s enough to know that the purple bars all represent SSL negotiation. The longer the purple bar, the more time it takes for this negotiation to take place.
The waterfall for Obama splash screen is filled with SSL resources:
Romney’s waterfall, not so much:
SSL can have a serious impact on load times. By my estimate, it’s adding about 2 seconds to Obama’s page, which is a major performance hit. And this is just the splash screen.
I’ve talked before about the impact of secure content on performance. If your pages absolutely require SSL resources, then you can be smart about it by re-using TCP connections and creating longer-lasting SSL connections. Alternatively, you can offload SSL processing to another device, such as a dedicated load balancer or firewall.
But the simpler fix is to avoid using SSL content on pages that don’t need it. It’s rare to find a good reason to mix SSL and non-SSL resources on a page. Looking at waterfalls for Obama’s pages, I’m seeing that a lot of the SSL resources are fonts and visual assets. There’s no good reason for this, as far as I can see.
(Why do SSL resources accidentally end up on pages where they don’t belong? Here’s how: Using unnecessarily secure tags is a simple enough mistake to make. Some third-party tags are secure by default. Site devs will include the default tag in page templates, so that it’s automatically used on every page of a site, even the non-SSL pages. There are non-SSL versions of these tags. Ideally, devs should use the SSL version on secure pages, and the non-SSL version on the rest of their pages.)
Finding 3: At a glance, responsive design doesn’t confer a significant mobile performance advantage on Obama’s pages. However…
This could (and probably is) due to the payload, domain, and security issues already discussed. From a usability perspective, it was interesting to note that, when I looked at both candidates’ sites on my phone, the images and buttons on barackobama.com were crisp and clear. In contrast, looking at the splash page for m.mittromney.com, the primary image is on the muddy side and the call-to-action button is extremely low-res. It looks like someone in Romney’s camp has taken a hardline approach to optimizing this page without worrying about the impact on image quality.
These findings raise more questions than they answer, but I think they’re interesting — and in the right circles, inflammatory — questions:
1. Does site speed actually matter in this scenario?
We know that even small differences in load time — as little as 250 milliseconds, according to Google — can be a competitive differentiator in ecommerce. We know that the speed of a site has a definite impact on customer satisfaction and brand perception. Does this hold true for politics as well? Can a swing voter be swung on web performance?
2. Can we extrapolate anything about the candidates’ stances on issues like site security and mobile design?
Depending on whom you ask, responsive web design is the saviour of mobile performance, and anyone who’s not jumping on the wagon is hopelessly out of touch. I can imagine how tempting it is for Obama supporters to use this as an analogy for Romney. What kinds of assumptions, if any, could you make about the crop of SSL content on Obama’s pages?
3. And the most important question: Who will win the election?
Based on the following logic (which seems as scientifically solid as many of the polls I see):
- Ohio will determine the election
- More independent voters use desktop than mobile
- The Asheville NC test results correlate roughly with performance in Ohio (Asheville is two miles closer to Columbus than Dulles is on Google maps)
- Obama is about 20% faster from this location
I predict an Obama win.*
*Margin of error 96% 1 time out of 25.