We're generally pretty busy working on client sites, but recently had the opportunity to redesign and redevelop our company site.  When working on the new design, we had to make a tough decision as to whether or not we would stay with WordPress and finally decided to move away from it.  Here's why.

Easier updates and page management

At some point we realized that we weren't managing our site through WordPress as much as it was managing us.  The appeal is an easy-to-use Content Management System that makes it easy to update and maintain your site.  This is great even for developers who are well-versed in code.  No point in creating potential user error when WordPress will auto-generate everything for us, right?

This is really great for simple things, but when you have a more complex structure (e.g., sales data, payments, and contract information) it feels like you're constantly hacking around WordPress to make it fit your product.  Most WordPress plugins make use of the the WordPress wp_posts table which is used for everything from pages and posts all the way to products and sliders.  These are items that in an ideal world, don't belong in a posts table and for items like sliders and contact forms probably should not belong in a table at all.  I can look past the latter since at the end of the day it is a CMS and you need some way users can store and access data.  But the real problem comes with storing all the non-traditional data in the wp_postmeta table.  The posts table was originally only meant to handle simple items, like the post content itself, the author, date created, etc.  Information  that doesn't fall under this must be stored in the wp_postmeta table and since so many plugins make use of this functionality, complex MySQL calls (or hundreds of calls per page) are needed to pull all the information.

Of course plugin authors have the option to create separate tables, but you'll lose the native functions WordPress offers to interact with that data.  Because of this, many authors avoid creating separate tables which is why we commonly see wp_postmeta tables that occasionally have into the millions of entries.

Faster site loading and cleaner output

But here's the major reason we switched away; we wanted our site to be even faster.  We've talked a lot on the site about how to improve WordPress site speed and it's very possible to do.  But the more complex your website or application becomes, the more intensive it is on you WordPress database.  

Websites loading time matters.Earlier we talked a bit about overcrowding in the wp_postmeta table.  This might not seem like a big deal, but when you start getting in the millions of entries and you have over 200 calls to this table on one page, you're slamming your database on every single page and this will be the bottleneck for your site performance.  Now with caching, you can definitely reduce the amount of times this is done, but it can't compare to a site that makes 1-2 database calls per page.  It's pretty crazy to have hundreds of database calls on a page that basically hosts static content, but this often happens because of extra plugins and widgets loaded in the sidebar or footer.  

One of the best things about WordPress is the large pool of plugins available.  But even free plugins are not without a cost.  Some plugins load several different stylesheets and scripts onto your site on top of the weight carried by your theme.  What's worse is that these plugins sometimes rely on some basic components like bootstrap which may already be used in your theme.  Now you're loading duplicate code and possibly conflicting styles.  With our latest theme we managed to pick out our favorite plugins and dequeue their styles and scripts in favor of our own.  We were able to reduce the weight on some pages by over 500kb by doing this.  The end result was one of the fastest themes on the marketplace that still had all the bells and whistles of the most popular themes, but this took a lot of time to do.  While it was worthwhile in a consumer product, it wouldn't make sense for us to go through this trouble for our own site. 

Is WordPress really that bad?

Why did we move away from WordPress?Not at all.  And this post certainly isn't meant to slam WordPress or some of the great people who have contributed to it.  WordPress is a fantastic CMS in a lot of respects, especially when it comes to pure blogging.  It handles a lot of functionality out of the box and has so many plugin options.  We realized the amount of little things that we took for granted in WordPress when creating our own custom CMS for our blog.

Unfortunately, a lot of poorly coded themes and plugins don't help WordPress's reputation.  Bloated code with lots of duplication and errors turn a brilliant system into a spaghetti mess of code.  On top of that, WordPress really shines when it comes to blogging.  However, the community seems to be shifting more and more to allow users to create custom pages and many sites don't even take advantage of the blogging platform itself.


W3 Total Cache is one of our favorites plugins

For static pages, caching is a great way to reduce the load to your database and improve site speed.  And of course, WordPress has a plugin for that.  But the plugins available don't always do a great job of this, by no fault of their own.  They are still limited by server configuration and what they are able to rewrite.  W3 Total Cache is one of our favorites and managed to bring our previous WordPress site down from 7 seconds to about 5 seconds in load time.  This is a pretty significant jump, but it wasn't until we disabled it and setup our own caching configuration with Varnish that we saw load times drop to around 2 seconds.

In retrospect

After finishing transitioning the site, I had to ask if this was all worth it.  We probably could have wrapped up a site redesign in 25% of the time had we stayed on WordPress and modified from there.  Since we still blog and have other back-end functionality for our site, we essentially had to recreate many things that are taken for granted in a basic WordPress installation.

Speed test result

However, the ability to add new features on to our site now with half the work and no decrease in performance has made this endeavor completely worth it.  We managed to get a load time of 586ms (a huge step up from our previous 2105ms) and far greater control of our site than before.