WordPress Release Stats

Before we get to test results, first thing is to see how this 4 version compare when it comes to size, number of files, hooks, requirements and few other things. Latest version is the version we used to test here.

Test Environment

For tests I have used WordPress 3.0.4, WordPress 3.1.4, WordPress 3.2.1 and WordPress 3.3. Test machine is CentOS powered VPS server with PHP 5.3.3 and mySQL 5.5.14, with PHP memory limit set to 256MB. PHP runs with eAccelerator enabled. All WP installations used only GD Press Tools 4.3.1 Pro plugin, and all had exactly the same content. GD Press Tools Pro had all its security related features activated, and they add about 3 SQL queries per page, and these queries are counted in the results below. Since I run GD Press Tools Pro as a part of all my WordPress installations, I think of it as logical and essential expansion of WordPress.

Each test for each WP version is repeated 10 times, highest and lowest results are removed, and the average is calculated from the rest of the measured values. Same method is used for server and client (browser) side. For client side measurements I have used Firefox 8.0, and before each measurement, all cached data was emptied. I use my faithful Lenovo IdeaPad Y560 with Intel Core i5 and 8GB RAM. Testing is done on 4 most used pages in WordPress: dashboard, posts list, post editor and comments list. Other pages are similar to these 4, and they will not show much difference in overall results.

If you compare results in this benchmark with previous one comparing 3.0 vs 3.1 vs 3.2, you will see that results for these 3 versions are now different. Difference comes from using latest versions of each WordPress, using differently configured server, and new browser. It is interesting to see how much faster is Firefox 8.0 over 5.0 used for old benchmark.

Server Side Execution

For client side I have measured 4 elements: used PHP memory to generate the page, number of SQL queries executed, time server needed to generate the page and number of hooks (both actions and filters) registered for execution. As with any version of WordPress, each new version uses more memory than previous one. But, while first 3 tested versions had number of executed SQL queries in decline, new WordPress 3.3 uses 4 to 9 queries per page more. Number of queries in the test includes 3-4 SQL queries executed by GD Press Tools Pro for security purposes, and it is the same for all 4 tested versions.

With all this, execution time on server-side for WordPress 3.3 is about 10%-15% higher than in earlier version. Number of hooks is expected to rise, just like the used memory. But again, there is a big jump with new WordPress. You can see all data on the charts below.

Server Side: Used PHP Memory

Server Side: Number of SQL Queries

Server Side: Execution Time

Server Side: Attached Hooks

What this mean? In terms of server performance WordPress 3.3 is a big step backward from WordPress 3.2. I am not going into analysis why this happened, or if it was really needed, but the fact is that new WordPress doesn’t add any feature that warrants such change on the server-side.

Client Side Execution

Pages generated by new WordPress are only a bit larger than before, and the same goes for JavaScript used. Interesting thing is that on post edit page new WordPress adds less JavaScript, all thanks to new editor and quick tags code. Hopefully, we will see more JavaScript improvements like this in next versions. But, execution time is another story, and overall, this new version is slower even than WordPress 3.1 in some cases. Similar results are with cached execution, and new WordPress on average is slowest in the 3.x line.

As before, Firefox even with latest stable version 8.0 is still slower than Opera 11.6 or Chrome 16/17. It is not as drastic difference as before, but with Opera or Chrome, pages are loading some 20%-30% faster.

Client Side: Page Size

Client Side: JavaScript Size

Client Side: Execution Time

Client Side: Execution Time - Cached

What these results mean for end-user page loading? The difference is not big, we are talking about half a second slower execution. That is hardly noticeable, but it proves the conclusion from the server-side benchmark: new WordPress is slower than previous one, while in the same time you will not see why that is needed, what new features are so important to justify this performance drop.

Overall performance index

Last chart shows two interesting, overall comparison indexes. First one is for server-side performance, and other for client side. They take into account individual results for each test and each page. WordPress 3.0.6 is referent version for this test and results for it are normalized to 1.0 for all pages and tests. Lower value is better.

Server Side: Speed Index

Client Side: Speed Index

As you can see, speed index for each of the pages shows that WordPress 3.2.1 remains superior to new WordPress 3.3 in terms of performance. If we want to compare overall for client and server-side, look at the last chart bellow. Overall, WordPress 3.3.0 managed to cling to second place thanks to some of the improvements, like WP Editor API and some other JavaScript changes, but it is very close to WordPress 3.1.4 performance. WordPress 3.3 is some 7% on server-side, and (too) big 14% on the client side off from WP 3.2.1.

Overall Speed Index

Website front-end

I didn’t test new WordPress on the front-end. From using it in the past few weeks while in Beta and RC, I didn’t noticed any changes. I imagine that using some of the permalinks structures will improve speed due to permalinks changes, but other than that all 4 WordPress versions in 3.x line have very similar performance on the front end.

Conclusion

I can’t end this benchmark on a positive note as I did back in July for WordPress 3.2. I can understand that WordPress is evolving and that new features can need more resources. But, in WordPress 3.2 six months ago, features and changes were followed by considerable optimization, and that resulted in faster WordPress. This time, we got no significant new features or improvements, apart from cosmetic ones (and some of them are questionable at best) and some changes that affected only some features (uploader and editor), and yet new WordPress is gone back a full year in terms of performance, and it is comparable to WP 3.1 or even WP 3.0 in some cases.

I am sure that some developers will say that these results are not important. I agree that half a second is not much in terms of speed and that most users will not even notice the difference, but it shows that current development of WordPress is not done right. Adding new features and sacrificing speed and resource usage is not a good way to go. Big part of the blame is on development cycle, that is targeting 2 major versions each year (well, we got whole 3 major versions this year alone). Because of that, testing and optimization is not high on priorities list, developers don’t have enough time for everything. Even now, 3.3 is about one month late from projected development roadmap.

I really hope that this new WordPress performance is a ‘glitch’ in the development, and that next WordPress 3.4 will get it back on track. I also wish that WP 3.4 takes more time, and not to be rushed by May or June just for sake of having new WordPress. Lets have 9 to 12 months development cycles, and I am sure that released product will be better and more appealing to end users to get with faster upgrades.

For now, WordPress 3.2.1 is clear winner in terms of performance and resource usage between all 4 major releases in 3.x line.

Edit:

Server side Memory and Hooks charts replaced with new ones where Y axis starts from 0.

Widget

This will also be our very first theme that will be HTML5 based and will rely on CSS3. Layout will use no images, it will use CSS3 for shadows, gradients, borders. CSS code will contain elements made for different browsers, and so far it looks great in Opera, Chrome, Firefox, Safari. As for IE browsers, IE9 supports most of the elements used, IE7 and IE8 will ignore some of the styling, and I will try to add some support library that can transform the styles for IE7/8. I am not sure yet, if all the next themes will HTML5, this will be sort of a test to see how the theme will work and what are problems still with the compatibility.

Slider

Image on the left is a widget using gradient background and shadow for the whole widget. And the image on the right is detail of the slider area for the front page layout. Normal layout and front layout will use different configuration for sliders and different set of options. Normal layout will use same settings as the R8 theme used for Nivo Slider.

Right now front layout is done and working, and some elements for the normal layout are completed.  Theme is expected in the next 7-8 days.

There are still bugs in bbPress 2.0 plugin, and you will get same issues with xScape themes, most important bug is with broken permalinks generating if the permalinks in WordPress are disabled. bbPress is close to stable release, so, hopefully this will be fixed soon. New xScape fixes few issues with the menu rendering and also is fixing issues with the comments template.

Nivo slider used in R8 theme was a bit outdated, and there were some issues with jQuery 1.6 and also with latest Firefox 6.0. Slider is updated to latest 2.6 version, and this brings 6 more slide transitions.

Promo Codes

For 10 more days you can take advantage of big summer sale and 40% and 50% discounts. Hurry up, offer is limited to number of licenses each promo code can be used: xScape Themes Big Summer Sale.

Demo Website

Test all themes, and try them with a free test drive, for both front end and back-end before deciding what is right for you. Free registration is disabled, so you need to send the request for the test account using the contact form.

Demo Loader: http://xscape.info/load/
Demo Home: http://xscape.info/

Test Environment

For tests I have used WordPress 3.0.4, WordPress 3.1.4 and WordPress 3.2. Test machine is CentOS powered VPS server with PHP 5.3.6 and mySQL 5.1.57. All WP installations used only GD Press Tools 4.0.9 Pro plugin, and all had exactly the same content. GD Press Tools Pro had all its security related features activated, and they add about 3 SQL queries per page, and these queries are counted in the results below. Since I run GD Press Tools Pro as a part of all my WordPress installations, I think of it as logical and essential expansion of WordPress. Other than that, no caching plugins, APC on server (or other similar extensions) are used for the benchmark.

Each test for each WP version is repeated 10 times, highest and lowest results are removed, and the average is calculated from the rest of the measured values. Same method is used for server and client (browser) side. For client side measurements I have used Firefox 5.0, and before each measurement, all cached data was emptied. I use Lenovo IdeaPad Y560 with Intel Core i5 and 8GB RAM.

Testing is done on 4 most used pages in WordPress: dashboard, posts list, post editor and comments list. Other pages are similar to these 4, and they will not show much difference in overall results.

Server Side Execution

For client side I have measured 3 elements: used PHP memory to generate the page, number of SQL queries executed and time server needed to generate the page. WordPress 3.2 uses a bit more memory from 3.0.4 and 3.1.4 as it is expected, but on the other hand, it needs less SQL queries and less time to do it.

Admin, Server Side: PHP Memory

Admin, Server Side: SQL Queries

Admin, Server Side: Execution Time

As you can see, WP 3.2 uses about 1% more memory from WP 3.1.4. In case you add 10-20 plugins (common number of active plugins on any website), this relative difference will remain the same in 1% to 2% range increase.

The only anomaly for the WordPress 3.2, is that it uses much more SQL queries on the dashboard to prepare the page, but considering that page is generated and loaded faster anyway, this is not a big deal. These extra queries are very simple and they are executed very fast. On some pages this speed difference is significant, making WP 3.2 is some cases even 40% faster on the server side. WP 3.1 is the slowest of the three.

Client Side Execution

WordPress pages continue to grow and they need more JavaScript for all the new and improved features. And this size was noticeable with WordPress 3.1, a version that you can feel its slower than earlier one. But now, with WordPress 3.2 we have very interesting situation: pages are growing, but overall loading is faster. As I said, all measurements are taken with no caching in the browser. And first charts show improvement in WP 3.2 but not by much. Things change much more when you take into account that browsers always use cache, and there WP 3.2 shines.

Admin, Client Side: Page Size

Admin, Client Side: JavaScript Size

Admin, Client Side: Page Load

Pages with new WP are some 10% bigger than previous WP 3.1, JavaScript also, and yet times are same or lower. Reason for this is in the speed of the JavaScript code. The extra time needed to transfer more data is compensated by faster jQuery library and all jQuery used code. I haven’t seen detailed of all JavaScript changes in WP 3.2, but the results are impressive.

And all this is with no browser caching. Speed increases much more when you take into account browser caching and then you can see and feel the speed of new WordPress as soon as you try it.

Client Side Execution, Cached

Two charts below show page load time when cache is active, and relative speed change in page load when you calculate page size against load time.

Admin, Client Side: Page Load Cached

In almost all instances, pages load faster when cache is used as it normally is in the browser, and that speed is very obvious. Also, these are Firefox 5.0 measurements. Opera 11/11.5 and Chrome 11/12 are much, much faster than Firefox, almost 50% and even more in some cases, so new WP will be faster if you use these browsers. Just to compare, with Opera 11.5 post edit page in WP 3.2 loads in 2.4 seconds, almost 3 seconds faster than in Firefox!

Admin, Client Side: Relative Page Speed

Last chart shows one interesting comparison. Compared value take into account page size and loading speed with cache and shows relative change between versions. Lower value is better. If we take WP 3.0.4 as a referent version (normalized to 1.0 for all pages), you can see that WP 3.1.4 is slower in almost all cases from WP 3.0.4, but WP 3.2 is faster in all cases from both 3.0.4 and 3.1.4 in some cases even 40% faster, in the case where matters the most: post editor. Post editor is typically the slowest part of WordPress, and now that has changed and all is good.

Conclusion

So, as you can see, new WordPress 3.2 is significant improvement over the earlier 3.x versions. Only issue with new WP is that some users don’t like visual changes. Some of my clients expressed that they don’t like so many interface changes with every major version, and it would be good to leave interface as it is for some time and that interface changes should be reserved for major, number changing versions like 4.0 or 5.0.

For my part, I like new interface, but more I like the new WordPress speed, and I will be switching all my websites to WP 3.2 as soon as I make sure that all plugins I use work with it. Before upgrading to WP 3.2, check out the system requirements of your server. If you want to read more on new WordPress, check out my review. And benchmark of the front end for all 3 WP version is coming in the next couple of days.

Previous GD Star Rating had standard star ratings, multi star ratings and thumbs ratings. Now, we will have one more: multi thumbs ratings. For all of them, a brand new CSS and jQuery code is written from scratch with new format for images. Now, each set will have all stars/thumbs sizes in one file instead of having separate files for each stars/thumbs size. By default, plugin will support these sizes: 8px, 12px, 16px, 20px, 24px, 32px, 40px and 48px. But, CSS for handling it is now very, very simple and will be easy to change to support bigger sizes and even non square dimensions. Combined CSS code for all sizes for thumbs and stars is under 10KB and it will be static, unlike in current versions.

New Settings panel in GD Star Rating 2.0

Image on the right shows new settings panel that borrows visual elements from xScape settings panel. It’s still a work in progress, but plugin will have same interface look as all the other Dev4Press premium plugins.

jQuery code is also 100% rewritten to support better dynamic code adding (if you add stars through ajax for instance, or use some cache or dynamic loading) using jQuery live methods. New code will also allow for vote changing feature and it will be faster and more reliable for cross browser compatibility. But, IE6 will not be supported. New code can’t be made to work with that browser, and tests for now show that it works fine with IE7 and newer versions, with Safari, Opera, Firefox and Chrome.

By default plugin will have 2 stars and 2 thumbs sets included. New sets for download will be available to premium support users on Dev4Press, but as before, anyone can make new set with own images. When plugin is done, I plan to offer unusual sets that are not star based, sets with non square object and with non symmetrical patterns.

As for rating types, plugin will by default support rating for posts (default post/page and custom post types), comments and users. Each rating type will support site based rating or network based for multisites, or combination (for users). BuddyPress specific data types are also planned, but new data and code organization will allow for adding of new rating types that may be images, links or anything else. Comment integration for review purposes will be also supported. Review by admin/editor also will be there as before. I also plan to support rating block integration for GravityForms plugin. Plugin will have modular loading structure to make easier for additional code to be added for new rating types.

I can’t give any schedule yet, but good thing is that many core components are done. Main task is to put all things together for first phase of beta testing, and I really hope that will happen soon.

Opera 11 with Dragonfly Debugger

Opera 11: Intro

Even with only 3% share of the browsers marked worldwide, I think that Opera is best overall browser available. Opera now has everything other browsers have (extensions were the only big flaw of Opera, but Opera 11 has them), and offers much more. Major issue with Opera is that is too standard oriented (yeah, the irony), and because of that some websites (very, very rare) can look a bit wrong in Opera. Most website problems are caused not by Opera but by websites that use browser sniffing code that intentionally cripples website for some browsers, without even testing it, and Opera is usually targeted. These are rare things, and even despite that Opera is the best browser available now.

For web development, Opera has Dragonfly. Dragonfly started slow some 2 years ago, but now it can do anything Firebug for Firefox can do. Biggest problem is that you need some time to get used to different interface and different controls layout. But out of the box, you get much more than with Firebug including: support for HTML5 storage, Color Picker with palette editor, comprehensive CSS and JS errors panel (with extra info on errors in SVG, Java, HTML, XML XSLT including CSS filter settings), amazing JavaScript debugger with syntax color coding and much more. For some of the advanced features you need to install more Firebug related extensions in Firefox and that will make it slower and slower. That’s not happening with Opera and I really don’t remember when Dragonfly in Opera crashed even with 40 or more tabs open.

Firefox 4 with Firebug Debugger

Firefox 4: Intro

I never was fan of Firefox. But, for the long time, Firefox had one very important advantage (from developers point of view): Firebug extension for web development.

Last week, a long time overdue, Firefox 4.0 was released. I tried several beta versions over the past 4-5 months, and they were actually worse than 3.6 versions. But, things changed for better, and Firefox turned out to be better browser than I expected. Most important thing is the speed and lower memory usage. Apart from cosmetic changes, Firefox 4 has important updates to security, support for latest web technologies, and many changes to the tabs. New tab groups feature is total rubbish, it’s slow and confusing. Opera’s tab stacking is much, much better. Firefox ‘borrowed’ many features Opera has for sometime now like new orange button replacement for top menu.

But, since I use Firefox for development only, I am happy that Firefox is faster and that it’s crashing far less then 3.6. Firebug extension is standard tool for every developer, but depending on what you need to do, debugging can be nightmare due to crashes and memory leaks. Debugging large document with a lot of JavaScript and DOM changes will easily crash on a Quad Core computer with 8GB RAM leaking couple of GB of memory in Firefox.

Compared to Dragonfly, you will need to add few more Firebug related extensions for cookies and color picker that are standard in Opera. So far (as far as I know) there is no HTML5 storage support in Firebug and error reporting in Firebug is not as good as in Opera.

Opera 11: Stability & Speed

Even if you use alpha and beta development versions, Opera is very, very stable browser, even for development and debugging. On the average, I have 20-40 tabs opened in Opera non stop (stacked in few stacks), and Opera is always running on both my computers, one of them is now running for 44 days without restart and Opera is on for 44 days without crashing once (stable 11.0)! On my development laptop I use always latest development versions and they do crash once in every few days.

Opera is fast. Very, very, very fast. Only Google Chrome can be compared to it. There is nothing more to say, because even with new 4.0, Firefox is still much slower not as nearly comfortable to use. Opera is fast and stable even with many extensions active (I have 10 extensions active in Opera).

Firefox 4: Stability & Speed

Firefox 4 is more stable and faster than 3.6. But, it’s still nowhere stable enough for smooth development work I need it to be. Even when I use only one or two tabs active, every 2 hours of work, and I have to close it to free up memory and to close JavaScript that I was trying to debug and that will crash Firefox on it’s own if left on for a bit longer. Opening more than 5-6 tabs for debug purposes makes it very hard to work with. And, more extensions active, more instability. Speed is not that bad as it was in 3.6, but when you do intensive debug work it can get very annoying to wait for something I can do in Opera almost instantly.

When used for casual browsing, Firefox is not bad, but with many tabs active is unusable. New tab groups are massive fail: slow, confusing and nowhere near intuitive to use as tab staking in Opera, and if you are not careful, you can easily close all your tabs with one button click.

Most important thing with all this: things I can do in Opera with debugging I can never do with Firefox with same level of comfort. Only reason I still have Firefox on is to test code compatibility just in case, and because I still didn’t quite used to Dragonfly in Opera. Well, years of using Firebug has taken its toll.

Why no Chrome (or Safari) in this comparison?

I very rarely use Google Chrome and I don’t like it’s debugger and development tools as too confusing. I only use Chrome (as I do Safari or IE) for testing. IE is awful browser in any version (including new 9.0) and debug in it is a nightmare. Only (proper) way to debug in IE is with Visual Studio.

Opera 11 vs Firefox 4

I am web developer for some 10 years, and I used every browser in that period. Opera has come a long way, and right now it’s the best browser for any use. For development, I am now doing 90% of my debug work in Opera, and I will not go back to Firefox until Mozilla do a right thing and make a fully rounded browser that is fast and stable. As it looks right now, that’s not gonna happen anytime soon.

If you are developer stuck to Firefox and all it’s bugs and many problems, slowness and instability, I highly recommend you try Opera 11. You will be surprised how good it is.

Dev4Press / xScape and IE6

Since I started making themes some 6-7 months ago, major problem was to make themes compatible with wide range of browsers. And for the most part there are no problems here. They work in Opera, Safari, Firefox and Chrome, and for the most part in Internet Explorer browsers. There are few minor problems with IE8 that were easy to take care of, several issues with IE7 that causes some troubles, and many problems with IE6. For IE6 I used several solutions to make themes as compatible with it as possible, without loosing too much of the theme functionality.

In some cases, you simply can’t make things work in IE6. PNG alpha transparency works with some hacks under very specific conditions, in most cases it will not work, CSS selector combinations will work in some cases only, and amount of CSS hacks you need to include is great, and still it’s not fixing many of the problems. All xScape themes you can get on Dev4Press, include hacks for IE browsers, but some things simply can’t work in IE6.

Browser Market Share

But, the question is if the support for IE6 (and IE7 for that matter) is needed at all. The thing is that IE6 mostly remained in use in companies that are unwilling to upgrade their old Windows XP (or even older 98/NT), and those companies usually restrict Internet access anyway. Or maybe they have some old software made specifically for this browser dinosaur that refuses to be instinct. I know that most theme developers only partially support IE6, many major websites don’t support it at all.

According to W3C, current global browser market has IE6 finally dropping to 5.6% in September 2010, fall from 11% IE6 had in December 2009. With more tech oriented users, IE6 usage is almost negligible, and is under 2%. On all my websites, in the past year, IE6 is used by less than 1% of all visitors.

So, what now?

Should theme developers even support old browsers like IE6? Is it good idea to waste time fixing bugs that can’t be fixed, is it a good idea to code specifically for IE6 and duplicate functionalities, making mess of your code for few percent of users that still use this browser relic? Tell us what you think.

Dev4Press and xScape themes will continue to have support for IE6 as much as possible, but some things will never get to work in IE6 no matter what we try to do. And you can expect that some themes in the future will be labeled as noIE6 theme.

Operating Systems

MS Windows is the most used OS in the world, and this chart shows the same for visits on this website. These 5 OS here made up 96.2% of all OS tracked. Different Linux distributions and mobile phones tracked the rest 3.8%.

OS Charts for visits on Dev4Press: may 1 2010 - aug 1 2010

Browsers

There are 2 browsers charts. First one shows browsers regardless of the browser version. Firefox browsers dominate, with Google Chrome in second position.

Browsers for visits on Dev4Press: may 1 2010 - aug 1 2010

If we take a look at browser versions, chart shows that Firefox 3.6 and Chrome 5 are most popular choices.

Browsers for visits on Dev4Press: may 1 2010 - aug 1 2010

MS Internet Explorer is still most used browsers in the world, but for individual websites and websites that are specialized as Dev4Press is, you see that visitors are more informed and are using browsers that are leading in the web standards implementation. I prefer using Opera, but these charts don’t include data from my visits to the website.

Conclusion

In November, I will post another overview and compare it to this.

To check the results from first part of the benchmark, go the this post. There you have test setup and results for memory usage, page generation speed and executed SQL queries.

Test 4: Generated Page Size and JavaScript

This test will show how the big pages are, including HTML, CSS, JavaScript and images send to the browser. There is a slight increase in the data send, but this not a big deal, considering the results from Test 5 you can see later. More JavaScript shows that interaction is better, and more elements are now using AJAX or animate for better user experience.

Generate Page Size: WP 3.0 makes slightly larger pages

Page JavaScript: WordPress 3.0 adds slightly more JS

This is not very important test, because standard Internet connections today are broadband everywhere, and that can handle a bit bigger pages. But, it’s a good idea to keep the track of everything and don’t allow to grow out of control.

Test 5: Client Side Execution

Well, new jQuery and better JavaScript code payed of and the WordPress 3.0 executes faster now. But, this is highly dependent on the browser and there are big differences in speed. My measurements are done with Firefox 3.6.3, and here is the chart:

Clientside Page Execution: WordPress 3.0 is faster

WP 2.9.2 is a bit faster on post edit panel, but in WP 3.0 there is much more going on there, more AJAX, so this is not a big surprise. In all other cases WP 3.0 is faster. But, if you want it fast that don’t use Firefox! And don’t use MS Internet Explorer. Opera 10.5/10.6 is 3-4 times faster than Firefox, and in Opera a page renders usually under 3 seconds. Google Chrome 4 is 2 times faster than Firefox, and Chrome 5/6 is 4 times faster. Safari 4/5 is 2 times faster than Firefox. Internet Explorer (even IE8) in some cases can take 20 seconds to render some pages in WordPress.

For administration of all my WP websites I use Opera, and I always get frustrated when I have to use Firefox because it slows me down, since I am so used to Opera and speed it provides. Browsers race in improved JS speed is a good thing, and with every new version Opera, Chrome and Safari keep getting faster. I don’t know what’s wrong with Mozilla, but Firefox right now is very slow compared to these 3 browsers, and I hope that Mozilla will make some important changes and get back in the speed game with Firefox 4 (for 3.7 is already too late, and it’s not faster than 3.6).

Conclusion

So, WordPress 3.0 is faster now and gives much better user experience, and more things are changed and improved to provide better administration features. AJAX is used much more, and there are more interactive elements all over. Despite some problems with memory usage and other things I talked about in previous part of this benchmark, there is no doubt that WordPress 3.0 is the best and most important release of this platform in last 2 years.

Long time ago, there were only few browsers available, most of them (except for Opera) were pretty bad. But then, we got a great browser called Firefox. And soon after that we got another tool, more important than any other tool for web development. This tool was extension for Firefox, and it’s called Firebug. And while we had Firefox 1.0, and Firefox 1.5 everything was fine. But then, they made Firefox 2.0. And if it wasn’t for Firebug, that was the point I wanted to delete Firefox and never use it again.

It was slow, used too much memory, and was unable to handle many open tabs for a long periods of time. They were releasing updates left and right, but nothing really changed. The things were made worse once the 64bit Windows was used more and more. I started using 64bit XP few years ago and using Firefox was simply frustrating. And in that time I started using Opera as a main browser because everything was much better than Firefox. Except one thing. Opera had nothing like Firebug was. And I had to use Firefox still… Yes, I know, there are many new features added over the years, but with all that there are many more new problems.

Good thing was that I wasn’t the only one with these problems, and some people released 64bit version of Firefox. Most extensions were not working, but it was still much better than regular Firefox. Another good thing was that after some time, Mozilla finally admitted that memory management in Firefox is bad and that they will fix that in Firefox 3.

Guess what? They didn’t. On Vista x64 Firefox 3 is slower than IE7 or now IE8, takes forever to load and crashes regularly very, very often. To make things worse, Firebug was causing as many problems as Firefox on it’s own was. Endless alpha/beta version, problems and crashes, but still nothing comes close to Firebug. Or so it looked like. But all other major browsers were on the rise, and things were changing for better.

Opera released first preview version of Dragonfly development tool that over time has grown, and it can do almost everything Firebug can. Major problem with Dragonfly is that it looks differently from Firebug, so it will take some time getting used to. Take into account that Opera is extremely stable  browser. On my desktop machine that’s working without restart for more than 20 days now, Opera 9.64 is running from the moment Vista booted (yeas, it’s running 20 days without problems), without restart, with 10-20 tabs opened at all times, and uses some 200MB for all that tabs. On laptop I use Opera 10 Beta 2 and things are also very smooth considering that’s still in beta stages. At this moment I have 34 tabs (I am not kidding, working on few projects right now, researching and testing) opened in Opera 10 with Dragonfly active and it uses 270MB. Good luck trying to open 34 tabs in Firefox (2, 3, 3.5) and let it run for a few hours. I tried that my self (with same 34 urls opened in Opera) with both 3 and 3.5, and it crashed after 21 tabs on 3 and 28 tabs on 3.5. FF3.5 in the moment it crashed used 730MB. Browser closed and the firefox.exe process still remained running taking full CPU load and I had to kill it using task manager.

Google Chrome browser also has development tools, but they are still not very usable, but that will change. Chrome is also very stable browser and it doesn’t cause problems. Many people I know have switched to Chrome as a major browser.

But the real frustration is trying to debug something with Firebug either with FF3 or FF3.5. In the past 4-5 hours I FF crashed 25 times! It works with a single tab (debugging some things in WordPress and jQuery), but still I hit reload few times, and everything stops. I close it, but even the window is gone, FF process is still working, eating a lot of memory. And I have only Firebug extension installed, nothing more. Many people told me to disable extensions if Firefox is causing troubles. But disable all extensions, and what you get? What’s the point of Firefox without extensions. Many things you need them for, you already have built in Opera. And on Firefox I use ONLY Firebug, nothing more. If I disable Firebug, I don’t need Firefox anymore. And Firebug is the last reason I have Firefox installed at all.

My best guess is that most of the problems Firefox has are caused by the fact that it’s not working well with 64bit operating systems. And that’s used as a excuse a lot. But that’s not right, because Opera and Chrome are 32bit programs running under 64bit, and they work fine. Also, 90% of all programs still have only 32bit versions and rarely they have problems. And for Mozilla finding excuses simply is not an option since they want to rule the browsers market. They were announcing 64bit version when 3.0 was announced. Nothing. Again with 3.5 another announcement for 64bit version. And, again nothing. But, if the 32bit version was written as it should, they wouldn’t need 64bit version.

I know that many people are using Firefox just fine. They need 2-3 tabs opened, they are not developers and they don’t need browser to run all days, for days. But I need, and most of the developers do. So, there you have it, I really, really hate Firefox.

Go download Opera and give it a try. You will be pleasantly surprised.