Author: Cal Evans

Optimizing a website for speed is a never ending quest. There is always something you can tweak to shame milliseconds off each load. While that might not sound like a lot, each tweak ads up.

I’ve talked about caching before, but that was all server-side caching. That’s the low-hanging fruit because you can control it a lot more and it will make a bigger overall difference. 

Once you’ve plucked the low-hanging fruit though, there are still things you can do to speed things up. One of those things is taking advantage of browser caching. 

Differences Between Browser Caching And Server Caching

Previously we discussed server-side caching. That is, saving off the results of expensive operations so that we don’t execute them on every page load. API calls and complex database queries are good examples of things that should be cached server side. Our video on object caching can help you figure out this better:

On the contrary, browser caching has nothing to do with “expensive operations” and is all about reducing the actual number of bytes that are pulled across the wire each time someone loads a page from your website. 

What Is Browser Caching?

All modern browsers set aside a portion of your file system to temporarily store things. This is called its cache. Modern websites are made of a lot of different pieces of content:

• HTML
  
• Images
  
• CSS
  
• JavaScript
  
• Other media
  

Some of these pieces of content are static, in that they never or rarely change. For example, your company’s logo probably won’t change often. Storing the graphic of your company’s logo in the browser’s cache means that’s one less thing that has to actually be fetched from your server for your image to paint.

How Browser Caching Works In WordPress

When a user types a URL into a browser, it starts a conversation between the browser and the server.

Browser: Hey, do you host this page?

Server: Yes, here’s the HTML

Browser: [Reads HTML and builds a list of the things it needs to request to display the page]

Browser: Ok, here’s the list of other things I need to display the page

Server: Here ya go…

Server: Here ya go…

Server: Here ya go…

The server keeps going until it has given the browser all the things it has requested. Sometimes these are small graphics, other times these are large JavaScript files or CSS files. Regardless of what they are, without browser caching, the browser has to ask for each and every one of these items, every time.

What if a user is visiting your shop and browsing? They may click 5,10,15 pages. Most of the pieces of these pages are the same thing over and over again. Your base CSS, your JavaScript, your company’s logo… never change between pages. But the browser has to ask for it each time and the server has to send it.

Browser caching lets the browser decide to temporarily store some of these pieces and reuse them. This shortens the conversation between the browser and the server. After the server hands the browser the HTML of the page, the browser builds its list of things it needs to display the page. With browser caching, it then looks at the list of things it already has and strikes them from the list before continuing the discussion with the server.

Controlling The Browser Cache

The problem is that browsers aren’t that bright. Left to their own devices, they would simply cache everything and never request anything. While this would make the user experience very fast, eventually the browser would be showing the user old data. 

Can you imagine your browser storing the current score of your favorite sports-ball match? No matter how much time passed or how many times you hit refresh, the score would never change because the browser has cached the score already. 

So obviously we need some way to tell the browser what can and cannot be cached. Even for the things that can be cached, we want to tell the browser when it’s no longer any good so it knows to ask for a new copy. For that, we use “Headers”.

In the conversation between the browser and the server, there is data that is passed both ways on each request, these are called “headers”. Users never see headers but they can affect the content that the user sees.

Servers send different headers to the browser to help it figure out what it can cache and where. There are several different headers and values that the server and browser can exchange to control caching- For the most part, it boils down to these 2:

1. Cache-Control

The Cache-Control header is the first one looked at by the browser. It tells the browser what it can do with the entity it just received. The most important possible values are:

• no-cache
  This tells the browser it’s ok to cache this resource but it has to check with the server to make sure it has the most recent version.
  
• public
  This tells the browser – or an intermediary like a CDN – that it’s ok to cache this resource.
  
• private
  This means that this is a cacheable resource but only by the browser. CDNs canc’e cache this resource. 
  
• no-store
  This tells the browser that this resource should never be cached.
  

2. Expires

This header tells the browser when this resource should be considered “stale”. This means that after this date and time, the browser needs to request a new copy of the resource.

With these 2 headers, a browser can now make an intelligent decision about caching any given resource.

So really, the only thing we need to know now is how to set the headers that our server sends to a browser.

How To Leverage Browser Caching In WordPress?

As with everything in WordPress, there’s the hard way and the easy way to do it. The hard way is usually the way we used to do it before someone figured out the easy way. The hard way almost always involves editing a file manually and usually involves hiring a developer to help you. The easy way almost always involves installing and configuring a plugin. 

The Hard Way: Leveraging Browser Caching By Setting Caching Headers Manually

If you are dead-set on doing things the hard way, this involves modifying a file in the root of your website named “.htaccess”.  (The leading dot is important)

If you open this file in an editor, you can add “ExpiresByType” lines to define how long a specific type of resource should be cached.

For instance:

ExpiresByType text/css “access 1 month”

This tells the server to tell the browser that any given CSS resource can be cached in the browser’s cache for 1 month before requesting a new copy.

You need to make this decision for every type of resource that you serve and add a record into the file for it. This is a time-consuming process and you have to remember you did it this way in case you want to manually adjust the times.

Here is a common set of headings you can use in your .htaccess file.

<IfModule mod_expires.c>

  ExpiresActive On

  ExpiresByType image/jpg “access 1 year”

  ExpiresByType image/jpg “access 1 year”

  ExpiresByType image/gif “access 1 year”

  ExpiresByType image/png “access 1 year”

  ExpiresByType text/css “access 1 month”

  ExpiresByType application/pdf “access 1 month”

  ExpiresByType application/javascript “access 1 month”

  ExpiresByType application/x-javascript “access 1 month”

  ExpiresByType application/x-shockwave-flash “access 1 month”

  ExpiresByType image/x-icon “access 1 year”

  ExpiresDefault “access 2 days”

</IfModule>

That covers most types of resources that your server will serve. 

The upside to the hard way is that it gives you absolute control over the caching on the browser. 

Personally, this is my preferred way to set caching headers. That having been said, I am a programmer and enjoy doing things the hard way. You may want to look at a plugin to leverage browser caching easily.

The Easy Way: Leveraging Browser Caching Using A WordPress Plugin

As with everything in WordPress, “there’s a plugin for that”. Leveraging the browser cache is no exception. Many of the most popular caching plugins have options that you can use to fine-tune the browser cache headers. By default, WordPress will add “Cache-Control” headers to all static resources (CSS, JS, etc) The plugins will add them to more than just that as well as give you more granular control.

If SiteGround is your hosting partner, you don’t need to worry about this. These headers are already configured for you. Nevertheless, If you are not yet hosting your WordPress site with SiteGround, you can use the SiteGround Optimizer plugin to insert the caching headers into your .htaccess file for you.

If you already have the SiteGround Optimizer plugin installed – and you should – Select the “Environment” menu option from the main menu or click on “Go To Environment” on the dashboard page.

There, you will find “Browser Caching” in the middle of the page. Click the slider to green and you are good to go. This option won’t be visible in the SiteGround Optimizer plugin installed on websites, hosted with us, because we manage this for our clients.

Cache Busting

Regardless of how you set your cache headers, sometimes you want to tell the browser “Hey, I know I said hold on to this resource for a month, but I’ve got a new copy and you need to ask for it.” This is called “Cache Busting”.

In WordPress, the way we bust caches is to append a version number to the name of the file.

For example:

<script src=”/js/jquery.js” />

Regardless of how many times we update jquery.js, the browser isn’t going to request a new copy until this one expires based on the rules we set. That is why most resources that are loaded in WordPress include a version number as part of the query string.

<script src=”/js/jquery.min.js?ver=3.6.0” />

The browser stores the complete file name jquery.min.js?ver=3.6.0 as the key for this resource. So if we change the ver= part, it thinks it’s a new resource and requests it regardless of the status of the caching headers.

<script src=”/js/jquery.min.js?ver=3.6.1” />

That’s how we bust caches and request fresh resources even if the ones we have haven’t expired.

Speed Results After Leveraging Browser Caching

So does all of this make any difference? A lot of that depends on your other optimizations already implemented. For one of my production sites, I had implemented all the SG Optimizer plugin recommendations. This took me to a Google Page Score of 87.

Then, I added the caching headers described above to my .htaccess file. This was the only change I made to the site. Now when I run SG Optimizer Speed Test, I get a score of 92!

So yes, five points on Google Page Speed score was worth the 2 minutes it took me to leverage browser caching. 

I hope your results are even better!

[subscribe_cta]

Are you looking for free ways to make your website faster? One way that every website owner can get a little free speed is to turn on compression at the server. When both the webserver and the browser it is conversing with understand a common compression algorithm, then the data that is actually sent over the wire can be compressed. Compressed data is smaller. Smaller data is received faster. 

What is Compression?

When you type in a URL into your browser, your browser starts a conversation with the server and one of the things it tells it is if it can decompress content and if so, what compression “algorithms” it understands.

Your server listens, and if you have turned on compression and it knows one of the compression algorithms the browser does, it will compress all the data and send it to the browser.

Most modern web browsers understand or “accept” content encoded in one of three algorithms:

• Deflate
  
• Gzip
  
• Brotli
  

When a web browser contacts a server, it sends a header that looks like this:

Accept-Encoding: br, gzip

That tells the server that it understands data compressed in either Brotli (br) or Gzip (gzip). Servers do have the option of ignoring this and returning uncompressed data as well. 

Overall though, compressed data travels faster than uncompressed data. So your website gets to the browser faster if the data is compressed.

Compression mainly applies to text:

• HTML
  
• JavaScript
  
• CSS
  

These make up a large chunk of modern websites these days and all of these can be compressed by server-side compression algorithms. 

On the other hand, most image formats (jpg, png, etc.), most audio formats (mp3s) and other non-text binary files are already compressed. Compressing these won’t make any difference so regardless of the Accept-Encoding header, servers will send these as it is.

As stated above, most modern web browsers will accept 3 main compression algorithms. Most servers have now migrated to one or both of the two most popular ones, Gzip and Brotli.

What is Gzip Compression?

The two most common compression algorithms are Gzip and Brotli. Gzip is the oldest and most common of the two. It was written by Jean-loup Gailly and Mark Adler. The initial beta release was made in 1992. The first actual version, version 1.0, was released in early 1993.  back in 1992 just as the web was coming online for most people. 

Gzip was designed as an all-purpose compression library. The theories behind Gzip were based on the earlier compression algorithm, DEFLATE. 

Because of its popularity – and the fact that it is very good at making files small – it is still widely used today both in different operating systems as well as a primary compression algorithm for web servers. 

What is Brotli Compression?

Brotli was developed by Google employees Jyrki Alakuijala and Zoltán Szabadka in 2013. Google was originally looking for a better way to compress WOT files which are web fonts. 

Gzip was originally intended to compress files and has been adapted to compressing streams so it could work on the web. Brotli on the other hand,  was designed from the beginning to compress streams. This makes it a better choice for web servers to compress content before streaming it to a browser.

In 2015, Google released the Brotli specification for HTTP. In addition to specifying how the browser should notify the server that it can decompress Brotli by sending a “Content-Encoding: br” header, Google engineers also made other improvements to Brotli that made it even faster for compressing web content.

What’s The Difference Between Brotli and Gzip Compression?

While they both have their origins in the LZ77 algorithm, Gzip was designed specifically to compress files. The library has been incorporated into a lot of different programs that need to compress files. The library was incorporated into web servers as compressing content started to be the norm. It was one of two compression algorithms specified in RFC 2616, the HTTPS 1.1 specification. While it wasn’t specifically designed for streaming operations like web servers, it was adapted to it.

Brotli, on the other hand, was specifically designed for the web. Google recognized the need for a way to compress streams more efficiently so they designed Brotli.

Both algorithms do a good job at what they were designed to do. Gzip still continues to be used on the web because it is still better than nothing at all. However, as Brotli grows in popularity, more and more web servers are preferring Brotli over Gzip. Given the choice of the two, Brotli is the default many servers will use. It’s been the default choice on all SiteGround servers for a while now.

Check the following video for more reference on the differences between Brotli and Gzip!

Benchmarking Brotli And Gzip

When Brotli was benchmarked against gzip, it was found that it compresses files better:

• 14% smaller JavaScript files
  
• 21% smaller HTML files
  
• 17% smaller CSS files
  

Since Brotli was designed to compress streams on the fly, it is faster at both compressing content on the server and decompressing it in the browser than in gzip. In some cases the overall front-end decompression is up to 64% faster than gzip.

How Can I Enable Compression On My Website?

In simple terms, “turning on compression” simply means telling your web server to compress everything before it sends it to a browser that has announced it can handle compression.

If you are a server administrator, you know how to edit config files. If you are not a server administrator, skip this section and scroll straight to the “If I am not a server administrator” section below.

If I Use Apache

If you are using the Apache web server, there are 2 steps to enabling Brotli compression:

• Firstly, enable the apache Brotli module. It is included by default but may not be enabled:

$ sudo a2enmod brotli 

• Next, you need to edit your web hosts config file and tell the server what you want to apply the compression to:

<IfModule mod_brotli.c>

            AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css text/javascript application/javascript

</IfModule>

In the example above, we are telling the web server to compress:

• HTML
  
• Plain Text
  
• CSS
  
• JavaScript
  

These are the main types of files that can be compressed.

If I Use Nginx

Nginx is another very popular web server. Like Apache, it is controlled by config files. You need to locate your nginx.conf file and add the following two lines:

load_module modules/ngx_http_brotli_filter_module.so;

load_module modules/ngx_http_brotli_static_module.so;

Then in your website’s individual conf file, you need to add the following:

brotli on;

brotli_static on;

brotli_types *;

After making the changes, either Apache or Nginx, restart your web server and now it will respond with a “Content-Encoding” header if the browser sends a “Accept-Encoding” header.

If I Am Not A Server Administrator

If you are not a server administrator, it’s actually much easier for you to enable compression on your server. You simply pick a host like SiteGround that turns it on by default. It’s that easy. 

Most top-tier hosts like SiteGround are interested in both making your site as fast as possible, and conserving as much bandwidth as possible. These are the two biggest benefits of enabling compression. Therefore, top-tier hosts turn on compression by default. 

If you are not a SiteGround client, then you need to make sure that your web host turns on compression on your web server. If they don’t and they won’t turn it on for you, it’s time to find a new host.

How Can I Test Brotli and Gzip Compression?

So how can you tell if compression is turned on for your website? There are a couple of ways to do this. 

The Hard Way

• Open a browser. I’m going to use Chrome in this example but the concept will work with any browser. The names of the options might change a little though between brands of browsers.
  
• Right click anywhere on the browser and select “Inspect”
  
• This will open a window on the side or bottom and it is a very busy window. The window has several tabs with names like this.
  
  • Elements
    
  • Console
    
  • Sources
    
  • Network
    
  • Performance
    
  • Etc…

• Find the “Network” tab.
  
• In the URL box above, enter your website’s URL and press enter. This is going to fill the network tab with a lot of different records. Scroll back up to the very first record. It should just be the name of your domain.

• Click on that first record.

• Locate the “accept-encoding” header. It will be located in the “Request Headers” section. These are the headers that your browser sent to the server. If you don’t have this header then try a different browser because the server won’t compress if the browser doesn’t send the compression header.

• Finally, locate the “content-encoding” header. This will be located in the “Response Headers” section. These are the headers that your server sent to the browser before it sent your website. This tells the browser that the server chose Brotli as the compression and it should uncompress the content streams as they come in before displaying them.
  

Honestly, most developers – myself included – do it this way. Yes, for the uninitiated, it is the hard way. If you don’t normally use the Inspect tab to dig into the conversation that your browser and the server are having then it can be confusing. However, once you understand what to look for and where, this way requires very little effort and is available everywhere.

The Easy Way

Still, there are those people who are not comfortable doing it this way. For those of you that are reading this article and fall into this category, I present to you, the easy way.

• Point a browser at the URL https://www.giftofspeed.com/gzip-test/
  
• Enter your website’s domain name in the box provided.
  
• Click the “Check” button.
  

Seriously, that’s it. When checking my site, I got the following results.

Not only does this tell me that my web server is capable of encoding my website in Brotli, it also tells me that 80.66% of my website came across encrypted.

Wrap Up

Compression in websites is now the norm because it helps your site load faster. 

Currently, Brotli is the best compression algorithm available for websites. If you see you are not offering Brotli, move to a web hosting partner that has it enabled. A hosting partner like SiteGround! You can get +15-20% smaller files with Brotli and smaller files mean a faster loading website. Check out more about SiteGround’s implementation in our article, More Site Speed Gains with Brotli Compression Algorithm. You can also harness all of our other speed boosters that will make your site fly.

[subscribe_cta]

The days of a web ruled by white pages, black text, and blue links are fading into history. These days, if you want to get noticed your page has to “Pop”. JavaScript, CSS, and images all add to the pop of your website. Fonts also add a lot to the distinctive look of your website.

Unlike some of the other elements of your website though, fonts can be large blocks of data that – if not handled properly – can slow down the loading of your website. Speed is king these days so while pop is important, you need to make sure you don’t impact the speed of your site when using fonts.

In this article we are going to look at fonts and how they relate to WordPress, how to change fonts in WordPress, how to use Google fonts within WordPress, and finally, we will take a look at how you can organize your fonts so that they make your WordPress site look good while not impacting the speed of your site. 

So let’s get to fonting, shall we?

How to add new WordPress fonts to your site

1. Pick a font in the right format

The first step you need to do when working with fonts, is to select your font and get it into your site. If you search around, you will find that there are a lot of free fonts available for use. These fonts come in a variety of formats. You need to make sure that when selecting a font, you pick one that is available in the right format. As with everything on the web, you’ve got options and not all options are created equal.

• EOF: Embedded OpenType Fonts
  

This format is more compact OTF fonts.

• OTF: Open Type Fonts
  

These are the most commonly used web fonts.

• TTF: True Type Fonts
  

This is an older format developed in the 1980’s by Microsoft and Apple. 

• WOFF 1.0: Web Open Font Format
  

This format is broadly used for web pages and recommended by the W3C.

• WOFF 2.0: Web Open Font Format
  

This is a better option than WOFF 1.0 due to better compression abilities. 

As of this writing, all formats were supported by the current version of all modern web browsers. (HINT: Internet Explorer is not a modern web browser.)

All of the formats above will work, however, for performance sake, whenever possible, use WOFF2 fonts. Since they are compressed, they load faster.

2. Add the WordPress font to your site

There are a few different ways you can add custom fonts to your theme. Let’s look at two options: how you can do it manually and how you can do it through themes and plugins.  

Option 1: Add fonts manually through the File Manager

First, let’s look at the hard way. Loading it manually. 

The first thing we need to do is locate a font. I pulled one from one of my personal sites but you can search around and find one you like. 

Next we need to upload the actual font file to our website. Since my test site is hosted on SiteGround, I use the SiteTools > File Manager to do this. 

I am using the current WordPress default theme, twentytwentyone. So in that directory I create a directory named “fonts” and upload my font file there.

Next, we need to tell our theme that it has a new font to work with. We do this with a @font-face section in our stylesheet.

@font-face {

    font-family: “ace_sansbold”;

    src: url(‘fonts/acesans-bold-webfont.woff2’)  format(‘woff2’);

    font-weight: normal;

    font-style: normal;

}

This tells our theme that there is a new font family named ace_sansbold and it can be loaded from fonts/acesans-bold-webfont.woff2.

That’s all fine and good but just having a font doesn’t make any difference, we need to apply the font. I want this font used in my site’s title. To do that we find the style selector used for that and change it.

In twentytwentyone, that is the .site-title selector. By default it looks like this:

.site-title {

color: var(–branding–color-link);

font-family: var(–branding–title–font-family);

font-size: var(–branding–title–font-size-mobile);

letter-spacing: normal;

text-transform: var(–branding–title–text-transform);

line-height: var(–global–line-height-heading);

margin-bottom: calc(var(–global–spacing-vertical) / 6);

}

We want to make one change. We want to change the font-family line to this.

font-family: “ace_sansbold”;

This will tell our theme to use our new font instead of the one selected in the Theme customizer. The final will look like this:

.site-title {

color: var(–branding–color-link);

font-family: “ace_sansbold“;

font-size: var(–branding–title–font-size-mobile);

letter-spacing: normal;

text-transform: var(–branding–title–text-transform);

line-height: var(–global–line-height-heading);

margin-bottom: calc(var(–global–spacing-vertical) / 6);

}

Here is what my site title looked like before I added the font.

After I followed the instructions above, it looks like this:

Option 2: Add and edit fonts through themes and plugins

Ok, we did it the hard way, now let’s dive in the straightforward way, that is to take advantage of the themes and plugins to add fonts to your site easily. 

How to add fonts using the Theme Editor

Most modern themes have some way of adding fonts in and assigning them to parts of the site. I use the Astra WordPress theme on one of my sites and it comes with a feature called “Custom Fonts”. Instead of having to manually apply CSS and upload files, I am presented with a simple form that allows me to add or edit fonts.

Once I save it, everything is automagically handled for me. Not only is the font placed where it should be and readily accessible, but the new fonts now appear in my Theme Editor, ready for me to use. No hacking CSS!

As a bonus, Astra comes ready for me to use any of the Google Fonts. They are already programmed in and ready for me to use.

How to add fonts using WordPress Font Plugins

If your current WordPress theme doesn’t include fonts out of the box, there are still options as freemium plugins.

Fonts Plugin

“Fonts Plugin” gives you all of the Google fonts ready to use in WordPress. Additionally, it will let you enter in your Adobe API key if you have one, to use all of the Adobe fonts as well. 

One of the things this plugin won’t do is allow you to upload custom fonts like described above. The pro version may allow you to do that, but the documentation is unclear on this point.

One really nice feature of this plugin is that it gives you a new Gutenberg block called a “Google Fonts” block. This is an extension of the Paragraph block and it gives you the option to select a font for the block. Changing fonts for a text element in Gutenberg is difficult to say the least. It’s nice to see someone figuring that out.

There are other plugins that you can use to add fonts to your existing WordPress website theme. Take a quick look at the WordPress Plugin Repository and you’ll find several that will do the job. 

How to change fonts in the Theme Customizer

Some WordPress themes have font selectors for different parts of your page or site. By default, twentytwentyone does not, but as shown above, Astra does. In Astra, the “Global” option has a “Typography” option. Clicking into Typography, you are presented with selectors to allow you to set different fonts and weights for things like:

• Body
  
• Headings (H1-H6)
  

This gives you broad control over the fonts that are displayed on your site. Different themes and plugins will add other options to the Theme Customizer to allow you more fine-grain control over what fonts are used where. A good example of this is the Font Plugin described above. It adds a section to the Theme Customizer for twentytwentyone to allow users to select and assign fonts.

You can pick fonts, weights, and sizes for most of the standard elements. For instance, above we manually replaced the font family for the .site-title selector. Using the Font Plugin, it is as simple as going to Advanced Settings > Branding.

There you can select the Site Title Typography options.

Bonus: How to keep fonts from slowing your site down

We’ve talked a lot about how to get fonts into your system and use them. Fonts, however, are just one more thing that a browser has to load to view your site. Things a browser has to load are just things that can slow it down. How can you deal with this? The solution is to preload your font files. Thankfully, if you host your website with SiteGround, you have access to the SiteGround Optimizer plugin which will make this task for you really straightforward. If you click through to the Optimizer Settings > Frontend > General you will find the “Fonts Preloading” feature.

This option is a little different than most of the other options in the plugin because it is not an on or off, you have to enter the URL to your font so they can be preloaded.

In our case, the URL would be https://example.com/wp-content/themes/twentytwentyone/fonts/acesans-bold-webfont.woff2. We enter that URL in and click Confirm.

This will insert the proper link tag with rel=”preload” in it so that the font file is the first thing that is loaded. You can see this by opening your website in a different browser, one that you are not logged into, visiting the page, and then click Inspect and Network. Then reload the page.

<link 

  rel=”preload” 

  as=”font”

  href=”https://example.com/wp-content/themes/twentytwentyone/fonts/acesans-bold-webfont.woff2″ 

  Crossorigin

/>

The first entry is the actual page you requested but the second entry will be the font file. It gets loaded as the first asset.

Wrap Up

Fonts are a good way to make your site look distinctive. Used sparingly they can set your site apart without significantly impacting its performance.

As with all good things, less is more. Too many fonts will slow your site down and also make your site more difficult for your users to read. The end results are the same in both cases, users bounce to the next site, so, as with everything, use website fonts wisely and make sure you keep them optimized.

[subscribe_cta]

I’ve been managing (and mis-managing) SQL databases for almost 37 years now. SQL was the second programming language I mastered and to this day it is still one of my favorites.

In all that time of wrangling databases, one thing has remained constant, you have to actively manage your database and at times, that means cleanup and maintenance. WordPress databases are no different.

Why Clean Your WordPress Database?

One of the most important reasons to do WordPress database cleanup is because your database is the second slowest part of your entire system. The only thing slower is the file system itself. So making sure that your database is operating at optimal speed is important not only to your site health but to your search engine rankings. Most of the major search engines use page speed as a factor in ranking a page. For optimum WordPress performance, you want to keep the database clean. Cleaning your WordPress database is part of an overall process of WordPress performance tuning.

The vast majority of WordPress installs use a MySQL (or MariaDB) Relational Database Management System (RDBMS). That is what we will focus on in this article. Even so, most of the advice will apply to whatever datastore you are using for your WordPress database.

Steps to Take for an optimal WordPress Database Cleanup

Back Up First

Before you embark on this journey, make sure you create a fresh backup. Yes, you should have nightly backups from the past 30 days nearby but things may have changed since your backup. You want to make sure that if you mess something up, you can easily restore things to the point where you started.

If your hosting partner offers an on-demand backup system like SiteGround does, make one now.

If not, before you go any further, install a plugin that will allow you to create and restore database backups.

There are many good plugins out there that will do the job. I’ve worked with several of them and looked at others. For this job, backing up and restoring, I like UpdraftPlus WordPress Backup Plugin because it has a very easy to understand restore feature. The free version will get the job done for our purposes but the paid version adds a lot of nice to have things. (like support for WP-CLI… that is really important to me in most plugins.)

Once you get the plugin installed, go ahead and make a backup. Unless you are deleting files, there is no reason to backup everything, just backup the database.

After you make your backup, go ahead and restore it so you can see what it’s like before you get in an emergency situation. Remember, if you have an untested backup system, you don’t have disaster recovery, you have hopes and wishes.

Leftover tables in the WordPress Database

Now that you’ve got your backup system ready, this first item is one that you may want to bring a developer in on. I’ma  big fan of bringing in professional help when I’m in over my head and this task may put a lot of people in over their heads.

If your site has been around a while, the chances are good that you have installed and uninstalled a lot of plugins. My personal site has been running WordPress since 2005. Many plugins, especially the older ones, did not clean up after themselves. This means that during install, they may have created tables in your database that they did not delete when you uninstalled them. Look at your list of tables – if you don’t know how, you don’t need to be doing this without help – and try and identify any that are no longer in use. Remove those tables from your database.

Once you’ve removed them, test EVERYTHING. It is these kinds of operations that make me recommend having a staging environment up and running and test these things in staging first. Still, if you have your backup, you should be good to go. 

I looked at the database for my personal site a year or so ago. There are over 500 tables in it. The standard WordPress install has around 40. I really need to take the time to clean things up myself.

There are plugins that will help you with this task if you do not have a developer available. One of them is mentioned below, WP-Optimize. 

Don’t be alarmed if when you try and remove a table it fails. The database user that your WordPress install runs under may not – probably SHOULD NOT – have table delete privileges. Still, you can show this list to your developer and they will know how to safely remove these tables.

Revisions

Next up, let’s talk about Post revisions. As you are working on a Post or Page, WordPress is constantly saving it in the background. To allow you to go back and restore one of these versions at a later date, each revision is stored as a separate record in the posts database. Once you have finished editing your Post and pushed it live, these revisions serve no purpose. 

If you have a developer on staff, they can easily delete these records from the table without having to install any plugins. If you don’t have a developer, or you want to make a change that will keep this problem solved for you, check out WP Revisions Control. This simple plugin will allow you to set how many revisions to keep and it will keep your database clean for you, automatically.

Draft Posts

Another source of “cruft” in your database is old posts that you started but never released. Again, using my personal site as an example, I looked one time and I had well over 50 posts in DRAFT status. This means not only did I have 50 records in my database I didn’t need but I also had revisions for each of them just hanging around. Get rid of those old posts that you are never going to release.

Empty the Trash

As an administrator of a WordPress installation, you have deleted old posts, pages, and other things. WordPress doesn’t actually remove these old entries from your system, it moves them into “the trash”. (From a technical perspective it changes the status of these items.)

The Trash is great if you need to go back and retrieve something later on but after a certain amount of time, you can be fairly confident that you aren’t going to need what you trashed. So empty “The Trash”. When you do this, you actually delete the items that WordPress has marked as trash. This gets them out of your database and keeps them from hanging around and cluttering things up.

Things Not To Worry About

There is a lot of advice on what you should do to clean your WordPress database out on the Internet. Some of it is well meaning but not all that useful. Here are a couple of things that you don’t need to worry about.

Cleaning Transients

Transients are little pieces of information that WordPress and plugins need to store temporarily. Transients have an expiration date. Some people will advise you to make sure you cleanup expired transients every once in a while. Don’t bother. WordPress’ cron system will do this for you every night. At best, you may delete a few hundred records a few hours early. The effort you put into managing transients is effort you could better spend making your site pretties, faster, or more useful to your readers. 

Optimizing Tables

A lot of places will tell you to “optimize your tables”. Some might even explain what this means while others just used it as a magic incantation that is supposed to make you feel better about your database. The truth is that there was a time when optimizing database tables was important. Thankfully those days are long gone. These days most MySQL databases use tables that don’t require optimization. Even my crusty old personal site’s database no longer needs to be optimized. Technically, it is no longer necessary to do this for 99.9% of WordPress installations out there. If you are part of the other .01%, instead of optimizing your tables, move your site to a modern version of MySQL with a table type that does not need optimization

Plugins that do all of this for you

Yes, there are things you need to do on a regular basis to keep your database clean and healthy. Yes, you or a programmer working for you can do these things manually on a regular basis. However, if you are like most of us, you don’t like having to remember to clean things up. For those cases, there are plugins that can do all of this and much more for you, automatically.  Think of them as the Roomba for your site. These plugins will come out while you aren’t around and take care of cleaning up the dusty corners of your site for you on a regular basis.

Here are four options you can consider:

Advanced Database Cleaner

This plugin is available in both free and premium. The free version will do all of the basics you need done. You can even schedule it to run on a regular basis so that your database stays clean. The Pro version will give you many more options. I recommend starting with the free until you understand what it does and then if you feel the need, move to the Pro.

Optimize Database after Deleting Revisions

This is another good choice although it does offer “tabel optimization” that I just got through telling you was unnecessary. It will keep your database clean of old posts, comments, revisions, and a bunch of other things. There aren’t as many options as Advanced Database Cleaner but the ones you really need are there. This plugin is free and there is a link to donate to the author if you use it and find it useful. (and I always suggest you donate to the authors of free plugins if you use their plugins) 

If you do choose to analyze the tables, it will attempt to run analysis on them but if you are using a table type that doesn’t require this feature, it will tell you that. It won’t harm your database or any of your data.

WP-Optimize – Cache, Clean, Compress

Probably my favorite option though (and the one I have loaded on my personal site) is WP-Optimize. This performs all the functions we’ve discussed here plus a lot of other things. Like the previous two, you can schedule this plugin to run automatically. However, since this is written by the same team that wrote the very first plugin I recommended, UpdraftPlus WordPress Backup Plugin, it integrates with that seamlessly and gives you the option to automatically back your database up before it performs maintenance. This is a nice feature. Like Updraft Plus, WP-Optimize comes in a free and paid version. I’ll leave it to you to decide whether you need the features present in the paid version.

Speed Optimizer

If SiteGround is your hosting partner then make sure you have the Speed Optimizer plugin installed. This is a MUST INSTALL plugin for every site hosted with SiteGround because it’s free speed. This is an easy plugin to install and while the database is not it’s primary focus, it does do routine database maintenance. It also does a LOT more to speed your site up and keep it fast. For the full details on this great plugin, check out this blog post.

Wrap Up

Keeping your WordPress database clean is an important step to making sure that your site always runs quickly. Either invest the time to manually clean your site on a regular basis or install and configure one of the recommended plugins to do it for you. Either way, it is time well spent.

[subscribe_cta]

Making your website secure is not a one-time thing. It’s not a switch you can flip to “SECURE” and then not worry about it again. Web security is built in layers. The point of each layer is to make it a little more difficult for bad actors to get in and do bad things. Our goal is to put up just enough layers so that they give up and move on to a site with fewer layers.

Exactly, what is “WordPress Security”?

A lot of web site owners I talk to think that WordPress security is a plugin they install or a service they buy. Nothing could be further from the truth. Security is a mindset, it’s not a specific thing. It is something you should think about in every decision you make about your website.

• Want a new theme? What is the theme developers reputation security-wise?
• Want to add a new plugin in? How secure is it? Have there been any vulnerabilities reported in it?
• Want to hire a new contractor? What do others have to say about their work? Is their code secure?

Every decision you make needs to be wrapped in the question “How will this affect the security of my site?” If you can’t say for sure that the answer to that question is either increase it or at least not hurt it, then you need to re-think the decision.

The other analogy I use a lot is that security is not one specific action, but a series of layers you wrap around your site.

• The top layer is a network firewall
• The next layer is is your application firewall (in WordPress, this is usually a plugin)
• The next layer in is strong passwords
• The next layer in is Two-Factor authentication
• The next layer in is moving your wp-admin directory to a different name.
• The next layer in is not using the login name “admin”
• The next lawyer is to disable XML-RPC

None of these things by themselves are going to make your site secure. However, all of them together may make your site secure so that bad actors move on to a site with less security. Another good news is that you can nowadays easily secure your website by hosting your website with a high quality hosting partner that commits to security.

You may notice that Installing an SSL certificate is not in the list above. This is because having an SSL certificate is what we call “table stakes” these days. This means that it’s not a security measure, it’s something you should do when you setup any and every website. They improve your security and your search engine ranking. Since they are now free, there is absolutely no reason for any website to be running without one. Moreover, on SiteGround, they install free Let’s Encrypt SSL certificates shortly after the creation of each website to make it even simpler for you.

>> If you are interested in knowing more about WordPress Security, download now for free our eBook 21 Tips to Keep Your WordPress Secure <<

What are the best WordPress security plugins to secure each layer of your WordPress site?

To set up the layered setup described above will take most people some time. As mentioned before, almost everything can be accomplished these days by non-technical site owners. That having been said, if you are nervous about it or unsure of your ability to commit the time to do things right, hire someone you trust to do it for you.

Network Firewall

If you are using a reputable hosting partner like SiteGround, this will be configured for you. If you are unsure if your hosting partner provides this service for you, ask them. If you don’t get a very clear “Yes, we provide you with a network level firewall.” consider finding a new hosting partner.

Application Firewall

In the WordPress ecosystem, “Application Firewall” usually means a plugin. There are several good ones with solid reputations to choose from. I don’t usually recommend specific plugins because as soon as I do, someone writes to me to tell me how my recommendations are wrong. Still, since a lot of users have asked me for recommendations about security plugins, I am going to break my rule and make a few recommendations. It is important to note that these are in no particular order.

By the way, most of these plugins do a lot more than just APplication Firewall. 

• Malware scanning
• Security audits
• Security hardening
• Website firewall

Some of the companies behind these plugins also provide malware removal and hacked site cleanup. If you are looking for peace of mind, that’s a great feature to have.

Jetpack

Jetpack is Automattic’s omnibus plugin. It has a lot of functionality and most of it doesn’t deal with security. It does however have some security features built into it. If you already have Jetpack installed, consider purchasing the security features.  

If you don’t currently have Jetpack installed and don’t need any of the other features, this might not be the best solution.

Sucuri Security

Sucuri has been around for a while and has a great reputation. In addition to offering a Web Application Firewall Sucuri offers a lot of other features:

• Malware Removal & Hack Cleanup
• Advanced DDoS Mitigation
• Malware & Hack Scan Frequency

These three features are important and covered by their basic level. All-in-all, Sucuri is a well rounded offering that would be an important lawyer in any website’s security.

iThemes Security Pro

I’ve actually used this one before. I am not currently using it but at the time I was using it it was one of the best – if not the best – on the market. (It is important to note that I do not think the plugin has degraded in any way, my needs changed.) 

The one thing that I remember about this plugin is that it’s admin page is complex. Make sure you block out a few hours over a couple of days to read and understand every option available to you so that you can make the right decisions. That advice is equally applicable to every security plugin. 

Unlike other plugins, iThemes gives you all of the features on every pricing level. The difference in price is based on the number of sites you want to protect.

Strong Passwords

Though there are plugins available for this layer, strong password support is thankfully built into the WordPress core. I strongly encourage you to enforce strong passwords on any user that has any security above Guest or Subscriber. If they can manage anything, they should have at the very least, a strong password.

WP 2FA

Two Factor Authentication (2FA) is one of the newer technologies to come to the web but it is an important one. Logins and passwords can be stolen online but a phone can’t. By adding 2FA as a layer to your security, you make it impossible for someone to access your site just because they got access to your login and password.

One plugin I’ve used over the years to implement 2FA is WP 2FA. It only does 2FA. If you already have an application firewall that implements 2FA, use that. But if you do not, WP-2FA is a good choice.

…and the rest

The other layers however, you still need some help with. I’ve tried combinations of dozens of different plugins to implement them and each time something didn’t go quite right. While I love the concept of “one plugin-one feature” Sometimes the plugins don’t play nice with each other and then you end up with a mess on your hands.

 That’s why I was excited when SiteGround released their in-house built WordPress Security plugin. It wraps a lot of security layers into one plugin.

Security Optimizer: The All-In-One WordPress Protection Plugin

This is a newcomer to the group but it has already become my favourite security plugin. I already have it installed on 4 of my WordPress installs, only one of those is actually hosted with SiteGround.

Security Optimizer comes with a lot of security features. Each of them can be turned on or off without bothering the rest of the features. My favourite 4 features of the plugin are as follows:

• Two-Factor authentication
• Disabling XML-RPC
• Disabling the login name “admin”
• Lock and protect system folders

I’ve installed stand-alone plugins that did each one of these things. Each time I ended up eventually removing the plugin because either it didn’t do the job the way I wanted it to or it became abandonware and was holding up my upgrading of my system.

Security Optimizer integrates all four of these important features in a single plugin. Because it’s created by SiteGround, I know that it won’t be abandoned.

It does a lot more than just these 4 things but these are the 4 that are the most important to me. To see everything it can do, install it, or watch this webinar I did on WordPress Security. In the webinar I install and configure it while you watch.

Concluding on WordPress Security

Spending time thinking about keeping your site secure is always time well invested. It is even more important as we are in vacation time now. Making sure you are up-to-date and as secure as possible means you can spend less time worrying about your site and more time focusing on your vacation activities.

Remember, the whole point of security is not to lock your system down tight so that nobody can get into it, because then…well, nobody can get into it. The point of security is to make it difficult enough so that bad actors move on to a site that is easier to break into. 

“Security is a journey, not a destination.” 

  — Cal Evans

[subscribe_cta]

In the root directory of every WordPress site is a file, xmlrpc.php that actually predates WordPress itself. Back before WordPress, during the b2 days, this file was created to give sites a way to communicate with each other and for other applications to communicate with the blog itself.

What is XMLRPC?

The name tells you everything you need to know about the functionality.

XML – This was designed to accept payloads in XML. These days JSON is a much more common format but XMLRPC predates JSON by quite a bit.

RPC – RPC stands for Remote Procedure Call. It was a standard by which one system could ask another system to do something. These days we use APIs – REST or Graph API – to do the same thing but before those existed, RPC was one of the ways we accomplished this.

How does XMLRPC work?

To make XMLRPC.php do something you had to POST a message to it. If you are not familiar with how browsers work, this is basically like clicking the Submit button on a form. That usually initiates a POST request. 

If you make a POST request to yourdomain.tld/xmlrpc.php and you hand it a properly formatted XML payload, you can do things like create a post on your site.

One of the things that XMLRPC was used for a lot back in the day was “pingbacks”. Those comments you see on posts that show that someone else linked to it on their blog. 

Potential security threats from WordPress’ XMLRPC

For a long time, XMLRPC was a useful tool. Those days are fading into history now. These days all of the functionality that XMLRPC used to be used for is handled by the built-in REST API. Even though it’s not used anymore. It’s still hanging around. Those who get nostalgic about such things see it and smile. Those that are worried about security see it and frown.

XMLRPC poses a couple of distinct security risks for WordPress sites that can result in severe WordPress XMLRPC attacks. 

The first type of WordPress XMLRPC attack is a simple Brute Force attack. Since part of the XML payload that is passed to WordPress is the login and password of the user that wants to take the action, it is an easy way for attackers to try out user name and password combos until they find one that works. Many security conscious site owners will limit the number of login attempts a user can make before locking them out but won’t bother to block XMLRPC requests thus leaving a back-door open for attackers to try and find a way in.

Brute Force Attacks via XMLRPC

Once an attacker finds credentials that work, they are free then to attempt to do damage to your site by injecting content into your site’s database. Whether these are Posts, Pages, or just comments, the end result is the same. Content that you did not approve and most likely do not want is being served by your site. 

At the very least, this means spam comments or posts. At the worst though, it could be innocuous posts or comments that have malware injected.

DDoS attacks using XMLRPC

Because one of the ways that XMLRPC was used was for pingbacks, malicious users can use it to overwhelm your server by issuing a lot of expensive requests all at once.

A pingback writes a record to your database. Writing to your database is an expensive task, resource wise. While a single pingback won’t hurt your site’s performance, hundreds or even thousands of them at once can bring even the beefiest server to its knees. 

This is called a DDos or Distributed Denial of Service attack. Distributed because it’s usually not a single machine making all the requests, usually it is a whole bunch of machines spread out all over the place.

How to disable XMLRPC in WordPress

There are a few ways you can disable XMLRPC. I highly recommend that you do it because honestly, you just don’t need it. 

Through your webserver’s config file 

If you are familiar with how to block requests via your webserver’s config files – and you have access to your webserver’s config files, this is a great way to block it. For Apache, you can add this code to the .htaccess file in the root directory of your site.

<Files xmlrpc.php>

order deny,allow

deny from all

</Files>

That will stop it dead in its tracks.

Through your theme’s functions.php file

If you are not one who likes to much around in your web server’s config files, you can add a single line of code to your theme’s functions.php file.

add_filter( ‘xmlrpc_enabled’, ‘__return_false’ );

Make sure and get that exactly right, there are 2 underscores before the word return. Again, this will turn it off. This tells WordPress itself that you don’t want to accept XMLRPC requests.

Installing a plugin

Finally, if don’t want to bother with adding code to your theme’s functions.php, you can disable XMLRPC in WordPress by installing a plugin. (Hint, the plug does the exact same thing as the previous tip.) There are several good ones out there that are free or you may already have this functionality available to you if you have one of the Application Firewall plugins installed.

If not, let me recommend my favourite one and what I use on all of my sites to turn off XMLRPC, SiteGround Security Plugin. Even if you aren’t hosting with SiteGround, you can use this free plugin to manage several different security tasks. If you only want it to turn off XMLRPC, then disable all the other options. That’s one of the things I love about this plugin, everything is optional.

XMLRPC served us well in it’s day, but it’s day has come and gone. It’s time to let it retire gracefully. Until the WordPress core developers decide it is time to remove it, you need to protect yourself and your site by disabling it.

[subscribe_cta]

Computer programmers like to give things big names. This is how we end up with something called the “Principle of Least Privilege” (POLP) to say something as simple as only let users do what they absolutely need to do.

That’s all we are talking about here. Make sure that all the users in your site have exactly the permissions they need, and nothing more. But since that doesn’t sound impressive, we are going to call it POLP from now on.

Application Users

The easiest user to talk about is the WordPress application user. 

• You probably have one or more administrator accounts. 
• You may have multiple “Editor” or “Author” accounts.
• Depending on your site, you may also have “Subscribers”.

POLP teaches us that you should absolutely limit the people that have administrator privileges to those that need it and can prove that they need it. In most systems, this usually means you need a primary administrator and a backup administrator in case something happens to the primary like they forget their password the same day you find out your password recovery mechanism isn’t working. By the way, securing your logins as best as possible is an absolute must, so we strongly recommend you to check this article on how to set up a 2-factor authentication on your WordPress.

Anyone else who requests administrator privileges should have to prove that they can’t get their daily job done without them. Yes, it is inconvenient to have to ask someone to do something for you but limiting administrator accounts limits that damage that can accidentally be done to your system.

Editor and Authors have less opportunity to do damage so you don’t have to be quite as strict about them but even so, everyone who has privilege in the system should have a reason for having that privilege. 

Database Users

The next “user” we need to discuss is your database user. Every WordPress site has a user and password it uses to access the database that runs WordPress. POLP teaches us that that user should have the least amount of privilege necessary to do the job. 

Unfortunately, since plugins use this user to create and delete tables, data, etc. this user has to be pretty powerful. Still, this user does not need to be all-powerful. There are two important things to check on the user that you use to access your database. (If you do not know how to check these, hire a developer, this particular part is pretty technical).

1. Your database user should not have GRANT privileges. This means that it cannot grant privileges to other users. There is no scenario in WordPress where the database user should be creating new users or granting them privileges to anything.
   
2. Your database user should not have access to any database other than the one that is attached to your WordPress site. That user should not be able to access data or make modifications to ANY other database on the server.

If you are looking to implement some changes based on the above section, you can check the following tutorial and see how to manage user’s privileges in your MySQL database.

Access to Control Panels

Finally, premium hosting partners like SiteGround have very powerful control panels that let you control things orbiting your site like email and performance. Many of these controls can do serious damage to your site if used improperly or maliciously.

SiteGround and other hosting partners allow you to add “collaborators” to accounts. Collaborators make it very easy for someone to help solve problems or perform maintenance for the site owner. This is a much better way to allow a developer to help you than sharing your login and password. You can also check our article on how to secure your login details in 5 simple steps.

Review POLP Regularly

Whether it’s your WordPress users, or your Control Panel collaborators, you need to regularly review who has elevated access to your system. At the very minimum, once a month it is a good idea to review and evaluate users who have elevated access and make sure they still require this access. When they don’t, demote them or remove them altogether until such time as you need them to have that level again.

These audits won’t take much time but could save you many hours of disaster recovery if a forgotten account gets compromised and used to harm your site, not to mention the damage it will do to your online reputation.

Remember, reputation grows slowly like a coconut tree and falls quickly like a coconut.

[subscribe_cta]