One of the huge benefits of WordPress is that it caters to the entire spectrum of websites, from small hobby projects all the way up to enterprise-level clients. However, it doesn’t scale without a bit of help.
We both develop our own plugins and recommend others. Plugins maintained by Human Made are marked with a icon.
All other plugins we recommend are maintained externally, but we believe they’re best-in-class, and stable for production environments.
These plugins are absolutely necessary to run on our platform. Without them, WordPress won’t function properly or scale to more than a few requests a second.
S3 Uploads takes files uploaded via WordPress and saves them into an S3 bucket.
This is required on our platform, as the regular filesystem is available only on a single EC2 instance. This would break in multi-instance architectures (almost every site) or when autoscaling deprovisions the server.
AWS SES wp_mail() Drop-in
The AWS SES wp_mail() Drop-in replaces WordPress’ default mail functionality with sending via Amazon’s SES infrastructure.
This is required on our platform, as regular system mail is disabled.
Sites may also use other mail drop-ins, such as Mandrill, however mail will not work without at least one drop-in.
Memcache Object Cache (HM fork)
The Memcache object cache enables persistent object caching in WordPress. We point this to the Elasticache server for the stack automatically.
This is required on our platform in order to accomodate basically any amount of traffic. Sites without this plugin are prone to dying immediately.
The Human Made fork of the original object cache includes important changes, including a fundamental change to how autoloading options works in WordPress. Concurrency problems in WordPress usually boil down to this bug (commonly known as the “alloptions” bug) in some shape or form.
We also use Zack Tollman’s Memcached object cache on PHP 7, however this does not include the alloptions fix. Be extremely careful running this without extensive testing.
Recommended (for most sites)
We strongly recommend the following plugins. Without these plugins, sites might not operate to their full capacity, or may not be able to scale to large amounts of traffic.
These plugins aren’t always required, depending on the specific requirements of the project.
LudicrousDB is a database class that supports replication, failover, load balancing, & partitioning, based on Automattic’s HyperDB drop-in. Ludicrous is developed and maintained by John James Jacoby as part of the Stuttter project.
Ludicrous allows using multiple database servers, including read and write replicas. This is necessary for horizontal database scaling to work correctly.
Why use this?
When the database becomes a significant bottleneck to the site, you need to either horizontally or vertically scale the database server. Horizontal scaling is generally the preferred solution, but implementing this with databases can be tricky. Ludicrous handles all of this for you in the WordPress context.
We recommend Ludicrous over Automattic’s HyperDB for several reasons. Firstly and most importantly, Ludicrous is actively maintained, with several active developers from multiple organisations. Ludicrous is also designed for and in production across a variety of different uses, whereas HyperDB is tailored specifically for WordPress.com, which can cause issues with other system architectures. Ludicrous also supports mysqli and PHP 7, unlike HyperDB.
Batcache (HM fork)
Batcache is a full-page caching solution for WordPress. Batcache uses the WordPress object cache to share cached pages across all app servers.
Why use this?
When you need full-page caching, Batcache is the answer. Unlike nginx caching, the cache is shared across all app servers via Memcache, providing a higher hit rate than per-server caching.
The Human Made fork of Batcache contains several changes, including additional headers for monitoring hit rates, as well as significantly improved support for the REST API. It also supports serving stale cache pages while regenerating a page, decreasing the potential for cache stampedes.
Cavalcade is a replacement for WordPress’ built-in cron (scheduled task system). It consists of two parts: a plugin on the site, and the daemon running on the server.
Cavalcade allows cron processing to scale horizontally. As you bring more app servers online, the new Cavalcade daemons on each will coordinate and spread the workload between the servers. This works transparently with multisite as well, using a central task queue rather than one per site.
Why use this?
Cavalcade is not required, but is highly recommended for sites with more than a few scheduled tasks, or any multisite installation.
The built-in WordPress cron depends on users visiting the site to trigger the tasks, which can cause jobs to be delayed with high levels of caching or on large, rarely-visited multisite installations. While it’s possible to run wp-cron via the command line, this does not work with multisite without various hacks.
Tachyon is an image resizing processor built to be used with Amazon S3 as an image backend, with a CDN such as Amazon CloudFront sitting in front of it.
Why use this?
Tachyon handles resizing images to create thumbnails for WordPress. This avoids needing to generate and store them ahead of time, decreasing required disk space.
Unlike other services (including Jetpack’s Photon), Tachyon is hooked directly to the S3 bucket used by S3 Uploads. This reduces latency from external fetches, and allows more control over exactly how images are handled.
Mercator is a modern domain mapping system for WordPress, allowing complex multi-domain multisite installations.
When should I use it?
When you need domain aliases in a multisite network. If you just need a custom domain for a site, use WordPress’ built-in functionality by simply changing the site URL.
Mercator includes other useful functionality, including support for administration on multiple domains, single sign-on support, and the ability to map networks.
Unlike other plugins such as WPMU Domain Mapping, Mercator is fully object cached and tuned for performance. It also uses functionality available in newer versions of WordPress, rather than fully replacing parts of WordPress.
Custom Meta Boxes / Fieldmanager
Custom Meta Boxes and Fieldmanager are frameworks for building UI for custom post meta.
When should I use them?
Any time you need custom UI for meta, an existing framework is typically a better choice than writing the UI from scratch.
We use both projects, depending on the use case. Generally speaking, CMB is a bit more basic, while Fieldmanager is more powerful but the UI isn’t as nice.