Optimizing WordPress for Performance

Building on last week’s topic of how many visitors a hosting plan can handle is this week’s post: Optimizing WordPress for Performance. Even with the highest quality hosting and the most optimized and performant MySQL/MariaDB server poor content and database optimization can still bite you.

I am going to share with you some of the optimizations we have found that have helped our clients do more with less faster. Your results may vary and it is suggested that you take a full backup of your site, both files and database, before you make any changes.

If you are a client of ours and would like us to take a look at your WordPress site(s) please don’t hesitate to reach out. We perform optimization on a regular basis for our clients at no additional charge and we are happy to help as much a we can.

Look at your database in phpMyAdmin and sort by table size.

It is often possible to simply look at the structure of your database and the sizes of the tables to determine what kind of optimizations you should perform. If, for example, your posts table is 10 megabytes but your postmeta table is 800 megabytes you will probably want to purge revisions and drafts. If your options table is 1 gigabyte and your entire database is only 1.1 gigabytes. Before you make any changes you should back up your database.

While you’re in phpMyAdmin you can take a look at your tables to see if you are using MyISAM or InnoDB. For a tiny site it doesn’t make a huge difference but for a site that is large or has been online for a long time InnoDB can be beneficial.

InnoDB instead of MyISAM

I do recommend using InnoDB instead of MyISAM for your database tables. Newer installations of WordPress will come with tables that are already InnoDB but older installations may have been configured when MyISAM was the default on most servers.

InnoDB has numerous benefits over MyISAM and here are examples although this is not an exhaustive list:

  • InnoDB is transactional and can automatically roll back writes if they are not completed successfully.
  • InnoDB uses row-level locking rather than table-level locking allowing multiple rows to be updated by multiple users simultaneously.
  • InnoDB supports Foreign Keys which will help protect the integrity of your database structure.
  • InnoDB is protected by transaction logs which can be used to repair and recover a damaged database.

Converting your WordPress Database to InnoDB from MyISAM

First – check to make sure your database is not already using InnoDB. I find the easiest way to do this is to look at the database structure via phpMyAdmin. If the “Type” column says “InnoDB” then you are already using InnoDB and you do not need to make any changes.

If the “Type” column shows MyISAM the first thing you will want to do is to take a backup of your database. This step is important should any errors occur during the change to InnoDB. Once you’ve taken a backup you can execute a query such as the following to convert all tables to InnoDB. This can be done via phpMyAdmin or any way you prefer to work with your database.

The SQL below will convert the default WordPress tables to InnoDB although this is assuming your table prefix is the default “wp_”. If your prefix is not “wp_” you will need to modify this SQL to reflect the proper prefix and you may need to run additional SQL to convert non-default tables such as those added by plugins or themes, etc.

ALTER TABLE `wp_usermeta` ENGINE=InnoDB;
ALTER TABLE `wp_term_taxonomy` ENGINE=InnoDB;
ALTER TABLE `wp_term_relationships` ENGINE=InnoDB;
ALTER TABLE `wp_termmeta` ENGINE=InnoDB;
ALTER TABLE `wp_postmeta` ENGINE=InnoDB;
ALTER TABLE `wp_options` ENGINE=InnoDB;
ALTER TABLE `wp_comments` ENGINE=InnoDB;
ALTER TABLE `wp_commentmeta` ENGINE=InnoDB;

Optimizing WordPress Revisions and removing extra unused data.

As you create new WordPress posts and make revisions WordPress will save these revisions in the database. Additionally as you are working on new posts auto-saves will create copies of the post and changes you make in the database as well.

Having the autosaves and revisions on posts you’re actively working on is fantastic but often times there are numerous revisions of every post on your WordPress site whether or not the post was written today or many years ago. Often it’s not necessary to keep this additional information around and you can use a plugin like “WP Sweep” to clean this up.

WP Sweep can do more than just remove your revisions and drafts although that is the primary use I have had for it. As with any changes you should take a backup before using this tool.

Adding high performance keys to your databases.

WordPress by default does have some keys that do improve performance but improvements can be made. Personally I like the “Index WP MySQL For Speed” plugin. This plugin will allow you to monitor your database usage and recommend keys or you can simply choose to install high performance keys on whichever tables you prefer. Additionally you can restore the default keys back to the tables should you run into any issues.

This isn’t as helpful on very small sites but it has unlocked substantial performance gains in my experience on large and complex websites. As with any modification you should take a backup before using this tool just in case.

Quality Caching is critical.

If you were tasked with designing and handing out 200 flyers would you draft each flyer individually for each person or would you draft it once and then make copies of it? It doesn’t make much sense to go through the work of building the flyer from scratch for each person you want to hand it to – so why build each page on your site for each new visitor if the information hasn’t changed?

Caching will take the output of your site when it is generated or updated and will store the results of that generation as a static file. High quality caching will serve this statically cached file without involving any PHP processes so there is little overhead and maximum speed. Without caching every page is generated from scratch for every visitor even if the content hasn’t changed – this is wasteful and will slow your site down.

As we run LiteSpeed powered web servers we do recommend the LiteSpeed Cache for WordPress as we have found it to be faster and less latent than competing caching solutions in our testing. That isn’t to say WP Rocket, or any other caching plugin you like, isn’t a bad option either as any high quality caching plugin is better than no caching at all.

Profile your website with PHP X-Ray, a CloudLinux Feature.

We offer PHP X-Ray although not all providers do. X-Ray is not included with the base version of CloudLinux and a hosting provider has to pay extra for their clients to be able to use this very powerful tool.

You can start a trace in your cPanel under the “X-Ray App” option on your website to collect information on the requests made to the site. The detailed reports are helpful in identifying which plugins, themes, or queries are slowing your site down and by how much. We have often been able to use the information gathered from an X-Ray scan to improve a website’s performance by 200% or more. For our clients we do have a knoweldgebase article on running an X-Ray scan.

This list of recommendations is not exhaustive and there is almost always more you can do.

I have listed some of the most common optimizations that have helped our clients although the list is not exhaustive. If you have a favorite optimization technique or plugin please don’t hesitate to comment below and let us know!

Leave a Reply

Your email address will not be published. Required fields are marked *