WordPress Performance
Due to the quantity of WordPress installations we have and the distributed nature of many of our WordPress codebases, performance is paramount to our engineering.
In our codebases, microoptimizations can add up and unoptimized files can burden update processes, runtime execution and our storage and bandwidth.
Only autoload WordPress Options when necessary
WordPress uses a concept of autoloading at runtime to load options from the key-value store in the MySQL database.
If an option is required at every runtime, regardless of context, setting $autoload helps WordPress craft efficient MySQL queries.
However, if an option is contextual, only necessary inside the WordPress Admin, only necessary within a specific REST endpoint, only necessary within certain scoped situation, options shouldn’t autoload.
Avoid query_posts(), use WP_Query or perhaps get_posts().
Prefer isset() to in_array() when checking array keys.
While in_array() can certainly find whether a key is within an array, it’s less efficient than doing an isset( $array['key'] ) check. Even doing array_values( $array ) && isset( $array['value']) can be faster than in_array().
If children aren’t required on taxonomy queries, set include_children => false
Because WordPress terms can have hiearchal relationships, when using a WP_Tax_Query consider whether child terms are necesary in the query response. Whenever possible, set include_children to false if they’re not needed.
Avoid ORDER BY RAND in custom MySQL queries – pick random result instead
Often it is faster to over-query a dataset and randomly pick a result using mt_rand() in PHP than to use ORDER BY RAND in MySQL.
Avoid short-duration crons – use short-duration transients if necessary
Regardless of whether WP_Cron is configured to run via a reliable system cron or not, short-duration transients should always be considered first. If data expires regularly but is only loaded conditionally, checking an expired transient likely means fewer executions than running a cron every 10 minutes.
If system cron is configured and that condition isn’t met every ten minutes, it’s running more frequently than it should. If WP_Cron is running the default way and that condition isn’t met each runtime, that code can drag a site frontend.
Crons should only be used when it’s mission-critical for it to be tied to cron.
Minimize wp_kses_*(), shortcodes and methods that rely on regex and heavy recursion
The kses methods that filter HTML from content, WordPress shortcodes and other technologies lean on regex. Used lightly, their performance impact is nominal, but used repeatedly, recursively and liberally these methods can drag on performance.
When performing computationally-expensive operations such as these, you should always consider running some profiling to know what the performance impact is on different samples. If expensive, consider whether the operation is a good candidate for fragment caching.
Cache remote request responses and expensive database queries
When interacting with remote APIs or running particularly expensive database queries, consider how necessary realtime data is or whether the result can be cached using the the Transients API and the cadence it needs refresh.