Do you need help in optimizing the speed of your WordPress website? Back-end optimization makes it easy for search engines like Google, to crawl your website and improve ranking.
The purpose of this guide is to take you through various techniques that help in optimizing the back-end of a WordPress website to improve its speed. Back-end operations often include PHP, GZIP compression, HTTP cache headers, and other server-side functions.
Let’s get started.
Make a 404 Page That Isn’t Too Heavy
Highly dynamic sites can generate a lot of 404 errors. It’s possible that your website generates more than you realize!
Since many 404 pages consume plenty of resources, these mistakes are problematic. Avoid using a hefty 404 page, especially on a highly dynamic WordPress site. Build a basic 404 template that minimizes further database queries as much as possible. Also, take some time to resolve the 404 errors as they are inefficient in resource consumption and degrade the user experience.
PHP Workers Should Be Increased
PHP workers is a term you may not be familiar with, but several hosts use it to limit requests instead of limiting your CPU or RAM, as most shared hosting companies do.
The number of concurrent requests your WordPress site can serve is determined by PHP workers. In other words, a PHP Worker is in charge of handling all uncached requests for your website. For example, if your site receives four requests simultaneously and has two PHP workers, two requests will be processed immediately, while the other two would be queued until the first two are completed.
Uncached requests are one of the major issues with WordPress membership sites? Because PHP workers must perform work for each request, they become incredibly crucial. As a result, these sites will almost always need more PHP workers to guarantee that all requests are executed quickly and successfully.
When your PHP workers are consistently maxed out, the queue begins to push out older requests, potentially resulting in 500 errors on your site.
Make Use of GZIP Compression
GZIP is a software program for compressing and decompressing files and also serves as a file format.
The server’s GZIP compression is enabled, allowing you to further minimize the size of your HTML, JavaScript files, and stylesheets.
When a web browser accesses a website, it looks for the content-encoding: gzip HTTP header to discover if the webserver supports GZIP compression. If the header is available, the compressed and reduced files are served, and if not, it will provide the files in their original format. If you don’t enable GZIP on your site – performance testing tools like GTmetrix and Google PageSpeed Insights will most likely show warnings and errors.
Using GZIP compression reduces the size of your webpage. As a result, the time it takes to download the resource is reduced, the client’s data usage is reduced, and the time it takes for your pages to render is improved.
Hotlink Protection Should Be Enabled
Hotlinking is a simple idea to grasp. You choose an image from the web and include the image’s URL on your website. This image will appear on your website, but it’ll be served from its original source. Although this is handy for the hotlinker, it is technically theft because it uses the resources of the hotlinked site.
Hotlinking can put a significant strain on the target server’s resources. Consider what would happen if you were using a shared WordPress hosting account and Daily Mail suddenly linked to your images. You may go from a few hundred to several hundred thousand requests each hour on your website. Your hosting account may be suspended because of this. This is why it’s essential to utilize a high-performance host (one that can withstand scenarios like this) and to set up hotlink protection to prevent this from happening.
Redirects Should Be Kept to a Minimum and Added at the Server Level
It’s always a good idea to keep an eye out for excessive redirects. Simple redirects, such as HTTP to HTTPS, a single 301 redirect, or www to non-www (and vice versa), are perfectly acceptable. And they’re frequently required in specific areas of your site. However, each comes with a price in terms of your site’s performance. It’s also vital to understand how redirects affect your site if you begin stacking them on top of one another. This holds true for all post and page redirects, as well as image redirects.
When implementing redirects using free WordPress plugins, performance problems can emerge. This is because many of them use the wp_redirect function, which demands more resources and code execution. Some of them further overload your database by adding autoloaded data to the wp_options table. As such, they should be added at the server level.
Get Your Cron Jobs Under Control
CRON jobs (WP-Cron) are used to automate your WordPress site’s repetitive operations. Unfortunately, these can spiral out of control over time, resulting in performance problems. To keep track of all the Cron tasks running on your site, install the free WP Control plugin.
WP-Cron, the built-in Cron manager in WordPress, has also shown performance concerns. When a site has insufficient PHP workers, a request will be sent to WordPress, which will activate the cron. However, because the cron needs to wait for the worker, it simply stays there. Disabling WP-Cron and instead of using the system cron is a wiser choice. This is even suggested in the official Plugin user guide.
Insert this code into your wp-config.php file for disabling WP-cron just before the line that reads, “That’s all, stop editing! Happy blogging.”
define(‘DISABLE_WP_CRON’, true);
This stops it from executing when the page loads, but not when you use wp-cron.php to activate it directly.
Then, from your server, schedule wp-cron.php. Server crons can also be managed via the command line if you’re proficient with SSH.
Establishing Cache Length Using Cache-Control and Expires Headers
An HTTP cache header specifies when the file’s cache expires and must be included in each script on your WordPress site. To address this, make sure your WordPress host is using the right cache-control and expires headers. If you don’t, performance testing tools will most likely notify you that you need to include the expires headers or use browser caching.
The expires header is used to indicate a particular point in time when a resource is no longer valid. In contrast, the cache-control header enables client-side caching and specifies the resource’s max-age. While you can use both headers together, you don’t have to. cache-control is a more recent method that is generally preferred. These headers can be manually added to your server if they are missing.
Through Nginx
Adding Cache-Control Header
Cache-control headers can be added to Nginx by inserting the following to the server location or block in the server config.
location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
expires 30d;
add_header Cache-Control “public, no-transform”; }
Adding Expires Header
Expires headers can be added in Nginx by inserting the following code to your server block. You can see how to set different expiration times for different file types in this example.
location ~* \.(jpg|jpeg|gif|png|svg)$ {
expires 365d;
}
location ~* \.(pdf|css|html|js|swf)$ { expires 2d;
}
Through Apache
Adding Cache-Control Header
Cache-control headers can be added to Apache by including the following code in your .htaccess file. Code snippets can be inserted into the file’s top or bottom (prior to # BEGIN WordPress or following # END WordPress).
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$"> Header set Cache-Control “max-age=84600, public” </filesMatch>
Adding Expires Header
Expires headers can be added in Apache by inserting the following code into your .htaccess file.
## EXPIRES HEADER CACHING ## <IfModule mod_expires.c> ExpiresActive On ExpiresByType image/jpg "access 1 year" ExpiresByType image/jpeg "access 1 year" ExpiresByType image/gif "access 1 year" ExpiresByType image/png "access 1 year" ExpiresByType image/svg "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> ## EXPIRES HEADER CACHING ##
It’s also worth noting that HTTP cache headers can only be added to server-side resources. If you receive a notification that you should use browser caching for a third-party request, there isn’t anything you can do about it because you don’t have access to their server. The Google Analytics script, as well as marketing pixels from Facebook and Twitter, are common offenders.
If you’re having trouble with the Google Analytics script, you can use a plugin like Perfmatters or WP Rocket to host it locally or on your CDN.
Validating Cache by Using Last-Modified and ETag Headers
Following that, we have two more headers: last-modified and ETag.
While the cache-control and expires headers help the browser figure out if the file has been updated since it was last accessed, the last-modified and ETag headers validate and establish the cache length and must be present in each response from the origin server. You might get a notification that you need to “Specify a cache validator” if these aren’t configured correctly.
If the headers aren’t detected, it will repeatedly request the resource, increasing the strain on your server. Using cache headers prevents subsequent requests from being loaded from the server, conserving bandwidth and boosting user performance.
You can’t manually configure these HTTP headers on external resources like with cache-control and expires.
Last-Modified Header
In most cases, the server usually sends the last-modified header automatically, so you won’t have to add it manually. The purpose is to check if the content in the browser’s cache has changed since it was last requested. To examine the value of the last-modified header, check the header request using Pingdom or Chrome DevTools.
ETag Header
The last-modified header and the ETag header are incredibly similar. It’s also used to check if a file’s cache is valid. The ETag header is added automatically via the FileETag directive if you’re using Apache 2.4 or higher. And, since 2016, Nginx has had the ETag header enabled as standard.
You can enable the ETag header in Nginx manually using the following code:
etag on
Adding a Vary: Accept-Encoding Header
Every response from the origin server should include the vary: Accept-Encoding header, which notifies the browser if the client can process compressed content. You may see a message that you need to “Specify a Vary: Accept-Encoding Header” if this isn’t configured correctly.
Let’s imagine you have an outdated browser that doesn’t support gzip compression and a newer browser that does. If you don’t use the Vary: Accept-Encoding header, your web server or CDN may cache the uncompressed file and provide it to current browsers by accident, causing your WordPress site to perform poorly. You can guarantee that your web server or CDN provides the correct version by utilizing the header.
You can’t set this header manually on external resources, much like the cache headers we’ve discussed thus far.
Through Apache
The vary: Accept-Encoding header can be enabled in Apache by inserting the following code to your .htaccess file.
<IfModule mod_headers.c> <FilesMatch ".(js|css|xml|gz|html)$"> Header append Vary: Accept-Encoding </FilesMatch> </IfModule>
Through Nginx
The vary: Accept-Encoding header can be enabled in Nginx by inserting the following to the config file. The /etc/nginx/ directory contains all Nginx configuration files. /etc/nginx/nginx.conf is the main configuration file.
gzip_vary on
Modifying the WordPress Memory Limit Through the wp-config.php
According to the WordPress Codex, the WP_MEMORY_LIMIT option in WordPress Version 2.5 allows you to determine the max memory space that PHP can use. If you get a notification like “Allowed memory size of ‘xxxxxx’ bytes exhausted” this modification may be required.
WordPress will boost PHP memory allocation to 40MB for single sites and 64MB for multi sites by default. Lines 32–44 of the file./wp-includes/default-constants.php define the memory limitations.
Your hosting provider may also apply a PHP_memory_limit on the server. These are not the same thing. You can consider adjusting the PHP memory limit via WordPress if you’re getting the memory size exhausted warning.
Just before the line saying, “That’s all, stop editing! Happy blogging.” insert the following code to your wp-config.php file.
define( 'WP_MEMORY_LIMIT', '256M' );
You can also use a variation of the code. Rather than manually defining the amount, you can use the PHP memory limit value.
define( 'WP_MEMORY_LIMIT', ini_get( 'memory_limit' ) );
In Closing
Confused? Not sure how to optimize the back-end of your site? We can help! Get in touch by sending us a proposal, with the specific service you need our assistance with.