• When we spread performance across bins of 500 milliseconds, we saw that the highest frequencies were just below the median, and those after the median were spread across a long, even rundown.  

• It seems that the 4.5 second threshold is hard to break. Less than 600 sites fall into the “”4000 – 4500″” bin, while about 1000 fall into the “”4500 – 1000″” bin.  That’s the largest gap between two sequential bins.  
• A prevailing idea in WPO is that a 2 second load time is a benchmark of fantastic performance. The above data shows a pitiful number of sites are even in the ballpark: only 2.2% of the sites studied clocked in at less than 3 seconds. 

Histograms by CMS (WordPress and Drupal)

Our last post generated a lot of questions about WordPress — not surprising since it’s the most popular platform by far, as well as the worst performer.  For the chart above, we did another histogram of TTI, but this time compared data from Drupal and WordPress. (We chose Drupal for this comparison because its median performance was closest to the overall median of 7 seconds).

We see that Drupal’s performance distribution looks similar to the overall Time to Interact distribution from the first chart, with highest frequencies around 5 to 6 seconds, and smooth, steady drop off in frequency as performance gets worse. Conversely, WordPress sites see steady frequencies from 6 to 10 seconds, and show more sites per bin than Drupal as performance gets worse (plus a good amount “”more”” than 20 seconds).

WordPress vs JavaScript
The more interesting question is WHY those WordPress sites show worse performance.  Our hypothesis (which was shared by some of our readers) is that some WordPress sites are disproportionately loaded with plugins and JavaScript widgets.  The WordPress dashboard makes these assets very easy to implement, and many WordPress sites we’ve analyzed in the past fit that heuristic.  Here, we look at the total “”weight”” of JavaScript per page for Drupal and WordPress, in kb.

This histogram looks directionally similar to the one of Time to Interact.  Even though more WordPress sites have less than 50 kb of JavaScript (a tiny amount) — the rest of the bins show a trend where more WordPress sites have more JS.  This certainly doesn’t represent causality, but possibly reflects a wider correlation.

Does JavaScript Correlate with Time to Interact?

Does it mean anything that WordPress shows trends of higher TTI and more JavaScript?  We can’t prove it, but we can look at the correlation of JavaScript weight and TTI across all of the CMS data.

JS weight was not the highest-correlating factor with Time to Interact — overall asset count, asset weight, number of domains, and number of images had higher coefficients.  But when it’s graphed, it’s clear that there is a demonstrable link.

Why WordPress is Slow
WordPress sites generally have more bytes of JavaScript, and increasing bytes of JavaScript correlates with increasing average Time to Interact.  Does this mean there aren’t fast WordPress sites, or that WordPress sites are inherently limited in some way? No. But user tendencies have led to WordPress sites to be significantly slower as a group.  

If nothing else, this data drives home a key tenet of modern WPO: that while “”Web 2.0″” has introduced compelling functionalities that are easy to implement with JavaScript, it’s also caused widespread slowness on the web.  Widgets and plugins are intended to improve user experience on websites, but developers and site owners shouldn’t lose site of the fact that performance is key to user experience, and there will always be tradeoffs with adding more functionality.