The document discusses techniques for optimizing WordPress performance from server configurations to caching strategies. It emphasizes the importance of speed for SEO and revenue, providing actionable tips for site and database optimization. Key recommendations include leveraging caching plugins, proper MySQL configuration, and employing dedicated server resources for enhanced efficiency.

1. Optimizing WordPress from the server up
Anthony Somerset

2.  Anthony Somerset (@anthonysomerset)
 Currently Senior Products Engineer, Liquid
Telecom
 Worked with WordPress in some way for over 10
years
 Huge focus on site optimization and server
optimization
 Worked with W3EDGE team (W3 Total Cache
Plugin)
 Supported many other large scale websites
WordPress or otherwise
 Motorsport Nut (the 4 wheel variety!)

3.  Baby steps – plugins to help speed up your
WordPress site and other tips and tricks
 Getting more advanced – dedicated resources
 For the really advanced – custom tuning
 Configuring & Optimizing MySQL (Including
general WP based optimizations)
 Configuring PHP for efficient memory usage
 Configuring Opcache– Common Caveats
 Questions?

4.  Google uses speed as a ranking factor for
searches
 Amazon worked out for every 100ms delay they
lost 1% revenue
 You could be losing money by lost traffic or lost
sales:
 Ad Revenue
 Goods Sold
 Services rendered as a result of visiting
website

5. This applies generally to any environment

6. Don’t worry, there is a lot you can do to work around
it

7.  Delete Spam comments – don’t just leave them hanging
around
 Clear out old post/page revisions and limit number of
created revisions - http://codex.wordpress.org/Editing_wp-
config.php#Post_Revisions
 Limit the auto-save interval, useful if you have lots of
editors - http://codex.wordpress.org/Editing_wp-
config.php#Modify_AutoSave_Interval
 Clear out trash posts, can even be automated via wp_cron -
http://codex.wordpress.org/Editing_wp-
config.php#Empty_Trash
 Consider using an alternative comment system – e.g.
Disqus
 If you can, avoid hitting the database as much as possible…

10.  WP Super Cache
 Wordfence
 Primarily Security focused but has a caching aspect
 W3 Total Cache
 WP Rocket
 WP Fastest Cache
 Zen Cache
 Many Many More!
 Test a few and pick the one that works best in your use case…
However the one I have found most reliable/consistent is:

11.  The Defaults are only a fail safe – they will not give you the best overall
performance
 Best config for a single server is not the best for a multi server setup
 Page Cache – Use Disk Enhanced for single servers, Memcached for multiple –
Nginx/Apache Rewrites are generally much faster than PHP or Memcached
but consistency needed when multiple servers in play
 Minify – same applies here, Disk for single server, Memcached for multiple
 DB – Avoid Disk if you can. Memcached works very well here for both single
and multiple server setups – APC is better than file if you don’t have
Memcached if you use Disk make sure your Disks are fast – and prefer no
caching if your DB is faster than File caching
 Object – APC is fastest here, use Memcached if you have to for multiple
servers
 CDN – Enable it! – origin pull is generally easiest and simplest to manage –
make use of any available API’s if we support it (e.g. MaxCDN/NetDNA,
Amazon CloudFront)

12.  Enable all the options under Browser Cache.
 Do Not Process 404s – make sure that any plugins that require
WordPress for static files have there files whitelisted – e.g.
WordPress SEO by Yoast – sitemap feature requires whitelisting
(there is direct integration between these 2 plugins now)
 Prevent caching of objects after settings change – this appends a
query string to all static file URL’s allowing you to set very long
expires times (the default in W3TC if expires enabled)
 If using CDN, make sure to enable the set cookie domain option to
make sure new users cant send cookies in requests to your CDN
resources
 eTags are often not needed for sites using single servers – leave
them disabled unless you know they are needed, it reduces the
http header response size.

13.  Enabling cache 404 pages in page cache – this returns a 200
error which can have an adverse effect on SEO use at your
peril! Better to make sure your 404 page is efficient in its WP
calls and that you generally have no 404’s in the first place
 Don't cache pages for logged in users – if you disable this
beware of the admin bar appearing for logged out users – with
a logged in users username! A good idea to disable the admin
bar on the front end when you do this
 Cache Feeds if you can – even if you redirect to FeedBurner or
similar services, w3tc will purge the feed from its cache every
time you update/publish a post
 Use a sitemap plugin and prime your cache with the sitemap

15.  Dedicated Servers or VPS means you are not contending
for resources
 Other users won’t crowd you out
 You won’t risk hosting provider turning you off for
being too hungry on resources (yes some providers
have this policy!)
 You can often make better optimizations when your
server only has to worry about 1 site
 See later!
 Custom Stuff like Memory caching and Custom Search
engines are now possible

16.  It’s more expensive!
 It’s not always necessary so might be a waste of
money
 If in doubt speak to someone with more experience
than you
 You have to become a SysAdmin (or pay someone to
handle it)
 There are lots of security risks if not done right or
monitored correctly

17.  Start with Centos (7.x) and cPanel unless you really know
what you are doing
 Will automatically manage certain aspects of the hosting for
you
 Restricts some of your ability to tweak
 Not a replacement for a sysadmin though
 cPanel is cheap about $15 per month licensing on top of
server costs
 Avoid physical ”iron”
 Disaster recovery takes longer than a VM
 VM’s have more flexibility for upgrades and downgrades
 BACKUP BACKUP BACKUP!

19.  You need a dedicated server or VPS to do 90% of the following
stuff and root level access
 I’m assuming you already have the Web Stack built whether that
be LEMP, LAMP etc.
 I’m assuming Linux is the OS being used! – Sorry no WAMP here
please!
 I’m assuming you are comfortable with SSH, command line,
Vim/Nano etc.
 Recommended Resources (just some of many)
 http://www.if-not-true-then-false.com/2011/nginx-and-php-fpm-
configuration-and-optimizing-tips-and-tricks/
 https://www.digitalocean.com/community/articles/how-to-install-linux-
nginx-mysql-php-lemp-stack-on-ubuntu-12-04
 http://wiki.nginx.org/Wordpress
 http://codex.wordpress.org/Nginx

20.  The DB is often the first bottleneck in WordPress
 Config file most commonly located in /etc/my.cnf
 Debian/Ubuntu symlinks this to /etc/mysql/my.cnf
 Most config options often don’t need a restart (they will have a
matching set @@global. Query)
 /etc/init.d/mysql reload does not work reliably on all systems –
restart is safer
 Useful Tools (direct download links to latest version):
 Mysqltuner - http://sts.io/mysqltuner
 Tuning-primer - http://sts.io/tuningprimer

21.  Convert MyISAM tables to InnoDB
 You can lose default WP search (which was never that great
anyway)
 Some alternative search plugins:
 http://wordpress.org/extend/plugins/wordpress-sphinx-plugin/ - you need
sphinx installed and running – the plugin can do this though
 http://wordpress.org/extend/plugins/google-custom-search/ - requires no
extra running software, but does need signing up for at Google
 InnoDB scales better because it does row level locking instead
of table level locking
 This has greater impact for busier sites, lots of wp-admin traffic or
lots of comments
 InnoDB has better memory caching support than MyISAM – whole
DB can be stored in RAM (if you have it available)

22.  max_connections – make sure its set to the max number of DB
connections you see at peak time + 20%
 skip_name_resolve – can save up to 20% time on initial
connection performance
 Caveat – you cannot use hostnames in MySQL user permissions only
IP’s
 Doesn’t have any effect if you are using MySQL sockets (e.g. localhost)
– which are faster than TCP anyway!
 query_cache_size – don’t set to more than 128M the cost to clear it
above that generally is worse than the performance gained by the
larger cache
 tmp_table_size, max_heap_table_size – set both to at least size of
your largest table (if you have the ram)
 innodb_buffer_pool_size – set this to the overall size of your
InnoDB tables + 15%

23.  innodb_file_per_table – great on multi disk Hardware RAID
arrays (note, avoid RAID 5 or RAID 6 and variants for MySQL if
you can RAID 10 is still fastest with least problems in event of a
disk failure)
 innodb_flush_method = O_DIRECT – great if you have Hardware
raid and Battery backup
 innodb_log_file_size = 1024M – stop MySQL before you make this
change! Saves file descriptors being used for too many log files
 innodb_log_buffer_size = 32M – set this adequately to avoid
writing to disk too much but not so high that you could lose a
large amount of data in the event of failure
 Only enable the Slow log if you are actively debugging – leave it
disabled otherwise

24.  Config files in various locations depending on the OS and may or
may not use an included files based system
 Debian/Ubuntu /etc/php5/…. And users/etc/php5/conf.d/
 Red Hat/CentOS /etc/php.ini /etc/php.d/
 Generally need to restart PHP service to activate changes (except
when using apache/mod_php)
 Using an Opcode Cache (like APC) is often where biggest gains
are had.
 Only enable/compile the minimum modules needed to run your
site
 Only do the required tasks in WordPress/PHP – e.g. don’t use WP
plugins to do site backups – use a proper DB/File backup tool – if
you use VaultPress – use the (S)FTP and MySQL connection
options to reduce impact on the site code

25.  Watch your memory usage – if you consistently need more than 128M
memory_limit then look at what parts of your site/code is using large
amounts of memory
 Don’t extend max_execution_time – if something takes more than 30
seconds to process then something is wrong or should be done outside of
the webserver process
 Disable WP_Cron and switch it to a system cron task – wp-config.php:
define('DISABLE_WP_CRON', true); - reduces number of PHP calls quite
a bit and prevents race conditions in PHP on some busier sites – running
it at regular defined intervals is more reliable and often more efficient
 Remember to set post_max_size and upload_max_filesize for your uploads
 Set date.timezone – it will save a warning in your logs which could cause
slow downs because of disk writes on busy servers (I have seen this
happen!)
 If using multiple webservers – then set session.save_handler to use Redis
or similar

26.  It’s a Byte Code Cacher within PHP
 Comes with PHP > 5.5 (you should be using 5.6 or 7.0 at least
anyway… seriously)
 Can massively speed up site performance on its own
 Very tweakable but for 95% of users the defaults are fine after
enabling

27. opcache.enable=1 # This one should be obvious!
opcache.memory_consumption=128 # Amount of RAM to use in
MB for cache – tweak to your exact requirements
opcache.interned_strings_buffer=8 # memory for stored strings –
you don’t need much here generally
opcache.max_accelerated_files=4000 # adjust this to the number
of PHP files in your install but don’t get too far beyond 8000
opcache.validate_timestamps=0 #

28.  opcache.validate_timestamps = setting to 0 means it wont check
for file changes
 Means you have to manually clear Opcache caches
 But gives much much more scale to servers by saving on many file
system calls
 Make sure opcache.memory_consumption is large enough for
your cache
 Too much and you run out of RAM causing bigger problems
 Too little and you can hit cache slam because it will restart (empty)
the cache when it gets full in most cases
 More in depth reading: https://tideways.io/profiler/blog/fine-
tune-your-opcache-configuration-to-avoid-caching-suprises