Myth: WordPress is slow for big sites

STATUS: FALSE-ish (unless you have poor hosting or a sloppily built site)

We at Kyosei love WordPress. It’s a rock solid piece of tech, and, with a good dev team, WordPress can easily be customized to suit nearly any conventional web project. Occasionally, however, we hear complaints that WordPress is slow, especially for big websites.

In ancient times, people got a bit spooked by things they didn’t understand. Lightning. Fire. Puberty. Coleslaw. Just about everything had mythological (and not entirely factual) explanations. Today, we’ve replaced those gods with technology platforms like iOS and WordPress. But in the process, these platforms have developed their own mythology. In this series, we investigate the truth beyond some of WordPress’s most persistent myths.

Read more WordPress myths here.

The bottom line: WordPress can run big sites – if you do it right

WordPress bloat is a common concern for potential converts. And it’s a legitimate concern — up to a point. WordPress does come with a set of features – an admin interface, a posts model etc. – and if you’re not using any of them, you can call them bloat. But for a typical site, WordPress takes care of a lot of important tasks. Sure, you could get better performance by creating a site from the ground up and limiting features, but then it’s on you (or your developer) to maintain the site into the future. And frankly, it’s only a matter of time before that lone ball gets dropped. This is something that we in the industry call a “single point of failure” and try to avoid at all costs.

Also it will cost more. A lot more.

The bigger problem isn’t so much the bloat of WordPress itself, but that of many of the third-party themes and plugins that run off of WordPress. It’s not too much of a stretch to see how the problem starts: a developer creates a new theme and, to sweeten the deal, includes a few more features than the other themes on the market. And so on. And since it’s easier to market a range of functionality (and not talk about performance) than defend limited functionality for the sake of good performance, this pattern gets repeated again and again until themes are unwieldy, slow and a pain to work with. explains it this way:

“A typical marketplace theme will contain hundreds of shortcodes, ten different sliders, they’ll package plugins into themes; the list is endless.

This causes ‘theme lock-in’ – making it tedious and time-consuming for a user to change themes, countless incompatibilities, licensing issues, performance problems, and a wide variety of unhappy end-users.”

The other issue is implementation. If even good quality, lean plugins and themes are haphazardly implemented, your site will be slow and glitchy. If your WordPress site is slow and glitchy (in the immortal words of the ski instructor from South Park) “You’re gonna have a bad time.”

Worst of all, your USERS are gonna have a bad time.

This is further compounded by what we term “plugin addiction.” That is, the need to have absolutely everything running, regardless of its usefulness or current applicability. Since every running plugin uses a small percentage of available server resources, it’s not hard to overwhelm small shared hosts (and even the odd large dedicated or VPS server).

With careful implementation, plugin bloat can be mitigated. This might mean auditioning several different candidates, testing resource loads, checking error logs on the server, combining plugin features that don’t change into one plugin to reduce database calls – or even creating a custom plugin – but it can be done.

In terms of speed and performance, WordPress has something else going for it: a horde of fantastic options for caching and other speed boosts (such as gzip compression, minification and CDN options) that can easily counteract a little bit of server-side load.

One major caveat: Slow Appearance/Menus on the admin end

We recently completed a large site for a governmental organization. The site had hundreds of pages. With some caching, the site ran quickly on the front end; however, managing 200-item menus got very, very slow and somewhat glitchy with WordPress’ underpowered menu editor. This, I believe, has something to do with the way that WordPress performs queries for menus. Each menu item contains a lot of different pieces of information, and, if WordPress has to bring down all of that at once, it’s going to take some time. You’re also likely to hit PHP limits and struggle with the UI. Both of these are fixable – to a degree.

For PHP limitations: if you have access to your own php.ini, you may have to up the limit or “max_input_vars”. If you don’t, you’ll have to ask your host to do it for you.

For the UI, there is a decent fix. Enter “Menu Management Enhancer,” which allows you to skip around, minimize sections and perform other useful tasks. This is critical when you’re dealing with many large, complicated, multi-layer menus.

But, even with these fixes, the Appearance/Menus screen can get slow. It’s a bit of an annoyance, but since this is not a task most users face we don’t consider it a deal breaker. If menu resource load becomes a problem for front-end users, the burden can be distributed by choosing a CDN to diversify load and/or by moving to a hosting environment (VPS or dedicated) that gives you enough horsepower to load more of the menu into memory and/or database cache.

In the end, if you’re going to build a massive platform with Facebook-sized ambitions, it doesn’t make much sense to use WordPress beyond early proof of concept and functional prototyping (like Groupon did). If you’re a  serious web dev considering a major project, you probably already know this. Massive platforms aside, WordPress is an indisputably flexible and scalable platform for the other 95% of user needs. That’s why it’s been so successful, and that’s why we use it for most of our web projects.

This god heard that WordPress was slow, and he wants a fast website. Can you make a fast website with WordPress?

Feature photo © Ezume Images / Dollar Photo Club

Like what you see? Click to read more from and