Joomla
YSlow
Yahoo! released YSlow, a Firefox extension that integrates with the popular Firebug tool. YSlow was originally developed as an internal tool at Yahoo! with the help of Steve Souders, Chief Performance at Yahoo! and author of O'Reilly's High Performance Websites book.
YSlow analyzes the front-end performance of your website and tells you why it might be slow. For each component of a page (images, scripts, stylesheets) it checks its size, whether it was gzipped, the Expires-header, the ETag-header, etc. YSlow takes all this information into account and computes a performance grade for the page you are analyzing.
The current YSlow score for the drupal.org front page is 74 (C). YSlow suggests that we reduce the number of CSS background images using CSS sprites, that we use a Content Delivery Network (CDN) like Akamai for delivering static files, and identifies an Apache configuration issue that affects the Entity Tags or ETags of static files. The problem is that, by default, Apache constructs ETags using attributes that make them unique to a specific server. A stock Apache embeds inode numbers in the ETag which dramatically reduces the odds of the validity test succeeding on web sites with multiple servers; the ETags won't match when a browser gets the original component from server A and later tries to validate that component on server B.
Here are some other YSlow scores (higher is better):
- http://wordpress.org: 78 (C)
- http:/drupal.org: 74 (C)
- http://plone.org: 64 (D)
- http://postnuke.com: 63 (D)
- http://typo3.org: 56 (F)
- http://mamboserver.com: 56 (F)
- http://joomla.org: 53 (F)
From what I have seen, Apache configuration issues, and not CMS implementation issues, are the main source of low YSlow scores. Be careful not to draw incorrect conclusions from these numbers; they are often not representative for the CMS software itself.
And it doesn't change the fact that drupal.org is currently a lot slower than most of these other sites. That is explained by drupal.org's poor back-end performance, and not by the front-end performance as measured by YSlow. (We're working on adding a second database server to drupal.org.)
CMS code base comparison
Drupal
Source: Drupal statistics at Ohloh.
Joomla!
Source: Joomla! statistics at Ohloh.
Wordpress
Source: Wordpress statistics at Ohloh.
Plone
Source: Plone statistics at Ohloh.
(These graphs depict statistics for the core of each project, and do not include contributed modules, extensions or third-party plugins.)
Conclusions
- All projects have been growing in size. No exceptions.
- Drupal has, by far, the smallest code base. It's lean and mean. Joomla!'s code base is about 8 times bigger than Drupal's. Even Wordpress's code base is larger than Drupal's.
- Of all tools, the Wordpress code has the fewest code comments. Drupal and Joomla!, on the other hand, have the best documented code.
Drupal vs Joomla: popularity
Google trends is a tool that analyzes Google web searches and that can visualize search trends over time using so called "search-volume graphs". These graphs usually provide a good mechanism to compare the popularity of two or more products.
Here is the search-volume graph that compares Drupal and Joomla:
It is worth pointing out that Joomla has been around a lot longer than the graph suggests. In 2005, the bulk of Mambo's core developers left Mambo and started Joomla after a dispute with Miro Corporation, the company that founded Mambo. Keep this in mind when interpreting the graph. (I tried adding Mambo to the graph but the term Mambo isn't unique to Mambo, the content management system.)
That said, you can see that Joomla is more popular than Drupal, and that Joomla has been growing a lot faster. Why? The general consensus is that Joomla has a more appealing balance between functionality, flexibility, performance, quality of code, ease of use, documentation, user interface design, support and product marketing.
I want to add that Drupal is not trying to compete with Joomla. We are actually pretty good at ignoring the competition, and just do what we think is best to do. Regardless, there is significant overlap in functionality and many of our users ask questions about the differences between both ...
Drupal vs Joomla: hosting costs
Sun's new Fire T1000 and T2000 servers are much touted for their low power consumption. According to the Sun Fire T2000 power calculator, an idle Sun Fire T2000 with 4 cores and 8GB of memory consumes 203 watts, and a busy one consumes 251 watts, resulting in a difference of 48 watts.
Now, hosting companies pay something like one dollar per month in power and cooling costs for every 6 watts of power used. Thus, a Sun Fire T2000 costs 33.83 USD per month (203 watts divided by 6.00 watts/USD/month), and a busy one costs 41.83 USD per month (251 watts divided by 6.00 watts/USD/month).
Imagine that you have one such machine for your Drupal website and one such machine for your Joomla website. Now, say that the Drupal website is on average 100 times more efficient than the Joomla website (a theoretical example) and that the Drupal machine's workload is 0.8%, while the Joomla machine's workload is 80%. That means that the monthly cost to power and cool your server is 33.90 USD per month (203 / 6 + (0.008 * 48 / 6)) for Drupal and 40.23 USD per month (203 / 6 + (0.8 * 48 / 6)) for Joomla.
In this simplified and hypothetical example, you save 6.33 USD per month by choosing Drupal over Joomla, or 75.96 USD per year! Three years will save 227.88 USD. ;-)
That, and Greenpeace will love you! (Greenpeace UK, by the way, has chosen Drupal as their platform of choice.)
Drupal vs Joomla: performance
Which content management system is faster? Drupal or Joomla?
Experimental setup
I used the "Apache, mod_php, PHP4, APC" configuration from previous benchmark experiments to compare the performance of Drupal and Joomla on a 3 year old Pentium IV 3Ghz with 2 GB of RAM running Gentoo Linux. I used the following software: Apache 2.0.55, PHP 4.4.2, MySQL 4.1.4, Drupal 4.7.3 and Joomla 1.0.10.
I simply downloaded and installed the latest stable release of both Drupal and Joomla, and tried my best to make them act and look the same. To do so, I enabled the login form and the "Who's online" block. I also setup two links and a search widget in the top menu, enabled the hit counters for posts, and setup identical footers. Next, I created one author, one category and one post as shown in the images below.
Apache's ab2 was used to compute how many requests per second both systems are capable of serving. The page was requested 1000 times with a concurrency of 5 (i.e. ab2 -n 1000 -c 5). To test the impact of gzip-compressing pages we specified whether ab2 can accept gzip-compressed pages (i.e. ab2 -n 1000 -c 5 -H "Accept-Encoding: gzip;"). Note that ab2 did not request any images or CSS files; only the dynamically generated HTML document was retrieved.
Requests per second
When caching is disabled Joomla can serve 19 pages per second, while Drupal can serve 13 pages per second. Hence, Joomla is 44% faster than Drupal.
However, when caching is enabled Joomla can serve 21 pages per second, while Drupal can serve 67 pages per second. Here, Drupal is 319% faster than Joomla.
In other words, Joomla's cache system improves performance by 12%, while Drupal's cache system improves performance by 508%.
It is important to note that Drupal can only serve cached pages to anonymous visitors (users that have not logged on). Once users have logged on, caching is disabled for them since the pages are personalized in various ways. Hence, in practice, Drupal might not be 319% faster than Joomla; it depends on the ratio of anonymous visitors versus authenticated visitors, how often your site's page cache is flushed, and the hit-rate of your Drupal page cache.
Lastly, when serving gzip-compressed pages Drupal becomes slightly faster compared to having to serve non-compressed pages. Joomla, on the other hand, becomes a little bit slower. The reason is that Drupal's page cache stores its content directly in a compressed state; it has to uncompress the page when the client does not support gzip-compression, but can serve a page directly from the page cache when the client does support gzip-compression.
Document length
The first figure shows that the cost of compressing or uncompressing pages is neglible. The second picture shows that it can, however, have significant impact on the document length, and hence, on bandwidth usage.
Drupal always attempts to send compressed pages. Joomla, on the other hand, doesn't compress pages unless this option is explicitly turned on.