16 Tips on How to Optimize a WordPress Websites

The majority of consumers have already formed the opinion that concerns the services of web-hosting. If you need to search for reviews about any hosting provider, you will find dozens of results. And usually, there are more negative reviews than positive ones. I think I can fix it, so I share with you the tasks that I have faced myself.

• I’ve compiled a list of bad web solutions, as well as recommendations on what to do on your site is not worth it.
• The list is based on thousands of hours of communication with customers, as well as support and troubleshooting that I encounter every day. Something from the proposed will be quite primitive, and some questions will be more advanced level.
• Many of the described can separate a successful site from WordPress from a failed one. After all, despite the fact that choosing the right web hosting is very important, you should give enough time to optimize the site on WordPress, so that it is successful.

I often notice that experienced developers focus on the fact that they are good at creating certain web solutions, which makes them neglect or simply forget about studying and applying the actual optimization methods. Regardless of whether you are new to WordPress, or an experienced developer, the following tips will help you create much faster and more optimized sites on WordPress.

1. Changing a hosting provider – not always a solution to the problem

• One of the most important things that people should realize is that changing web hosting does not solve any problems by itself. If your site on WordPress has problems with the code or conflicting plug-ins, your site will not fix wherever you put it.
• Administered hosting will provide you with as much support and assistance as you can, but will not debug code or plug-ins. Writing good PHP code, creating and editing plugin functionality and themes, editing integration, and filling the site with content is not the responsibility of web hosting. This can be done by an experienced developer who will understand the work of the site, investigate the problem and solve it.

2. Working sites are not intended for development

• I can repeat this a thousand times. Never use working sites for development! Now, almost all the major administrated WordPress web hosts have development and run-in environments, and certainly not without reason. The use of these solutions saves us from the crash of the working site due to unsuccessful attempts to test something.
• If you do not want to use such solutions, you can use local development and testing, using what some call LAMP or LEMP-stack. They are designed to work with Linux, Apache / Nginx, MySQL, and PHP. And tools such as WAMP and MAMP will simplify and speed up the assembly of the server for local development.
• All these tools have improved and evolved over time, however, local development has its own problems, for example, an environment that does not exactly simulate your published site.
• First of all, you will have to figure out how to redirect your work from the local machine to the work site so that you do not have to overwrite existing data, and the site has not fallen. Depending on your settings, this process can be a separate issue. Some difficulties can arise with conflicting ports or errors due to differences in MySQL versions.
• To avoid such problems, I recommend using tools such as DesktopServer and Local, which are created solely to speed up your workflow when you are working locally with WordPress. They include simplified ways to transfer data to a work site, and also have additional functions, such as working with WP-CLI and built-in support for the multi-site mode. The multisite support itself can be invaluable since working with large local copies of WordPress can sometimes be quite complicated.

Run-in environments and local testing can help you cope with problems before they break your site.

3. Not a developer? – Do not get into code

• People who are either not familiar with WordPress, or do not know the basics of programming, should not edit files. One of the most common reasons why sites on WordPress fall is that someone is editing a PHP file directly from the appearance editor in the control panel. In addition, you do not have to edit a working site, as already mentioned.

• Recommendation for administrators: put the following code in the wp-config.php file, replacing edit_themes, edit_plugins, and edit_files for all users. This prevents users from dropping the site by editing the code.

Define (‘DISALLOW_FILE_EDIT’, true);

• Also, disable the ability to edit theme files or install plug-ins for users. To do this, put the following code in the wp-config.php file.

Define (‘DISALLOW_FILE_MODS’, true);

Note, the above commands also disable the file editor for themes and plug-ins. More information in WordPress Codex.

4. Do not save on themes and plug-ins

• It’s clear that you would like to save a couple of dollars, but do not do it at the expense of themes and plug-ins. WordPress should be the backbone of your site, and themes and plug-ins are the glue that holds the functionality of the project together. Try to adhere to authoritative developers when choosing plug-ins. In advance, learn the history of product support by the developer, review the ratings and read reviews. Such a study can be a daunting task, taking into account more than 50,000 plugins in the WordPress catalog.
• Very often obsolete or substandard themes and plug-ins are susceptible to the introduction of malware or are involved in the installation of malicious content and links to your site. According to the research of WP Loop, almost half of all published plug-ins have not been updated for more than two years. This is both shocking and frightening.

• Another source of plug-ins and topics worth exploring are third-party catalogs offering premium solutions at a low price. If you select this source, you do not support the developer. In addition, you rely on an unreliable source of updates, which is also not very good.
• Waiting for updates to installed plugins is a huge problem for WordPress users who buy solutions in third-party directories, such as ThemeForest. Many theme developers embed in them additional plug-ins, such as Revolution Slider or Visual Composer. The point here is that when vulnerabilities are detected in the built-in plug-in, the user has to wait for updates from the theme developer, although the plug-in itself could be fixed right away. This makes many sites very vulnerable to hackers.

5. Monitor AJAX requests

• Keep track of how AJAX requests are used on the site, as well as for plugins that use AJAX. For example, the WordPress API Heartbeat uses /wp-admin/admin-ajax.php to access AJAX via a browser. Many of these appeals are superfluous. Especially frequent use of this file occurs when surges in traffic and CPU utilization. This can significantly slow down your site. It’s a bit like launching a DDoS attack against yourself.

• If there are third-party plug-ins using admin-ajax.php, make sure that they interact with it correctly. You can easily track HTTP POST requests and, based on the name, determine which plug-in they are called. For example, the one I found, get_shares_count, turned out to be a popular plug-in for interacting with social networks, which overloaded admin-ajax.php. On a site with high traffic, the overload would increase many times.

However, AJAX is loaded only after the page is loaded, so if you see the appropriate warnings in the speed test, it’s not always a problem in AJAX.

6. Be careful when working with ad networks and external services

• Most sites with high traffic earn on advertising, and the rejection of third-party suppliers of advertisements is not possible. Nevertheless, it is important that the number of third-party services is minimal – you must understand how much they load your site.

Here is a brief comparison of how ad networks can affect your site on WordPress.

• Test parameters: for the test resource, I added three ads from Google AdSense, the size of 300 × 250. The site has a default theme – Twenty Sixteen. I measured the download speed before installing AdSense, and after.

Before AdSense (test results)

1. First download: 1,372 sec.
2. Reload: 1.013 sec.

Content breakdown by connections:

After AdSense (test results)

1. First download: 4.103 sec.
2. Reloading: 3,712 sec.

Content breakdown by connections:

• Simply by installing 3 Google AdSense ads, we added 6 additional connections. The site on WordPress with advertisements is 2.7 times slower than without them. This is mainly due to the additional time of DNS lookup and the use of JavaScript on the page. All this should create a picture of what is happening on the major sites, inserting 10 ads per page. No matter how fast hosting you use, it will not fix the delays from third-party advertising connections.

Below is another example of a site with a large number of external HTTP advertising requests, which caused a heavy load on WordPress.

There were so many requests that the application server did not load at all. The site was simply unavailable, trying to fulfill all external requests.

Another good example is the Huffington Post. If you test the download speed, you will see a huge number of HTTP requests to the ad networks. A quick test showed a download speed of over 13 seconds!

1. First download: 15,908 sec. | 221 HTTP request
2. Re-download: 13.957 sec. | 66 HTTP requests

• But the simple removal of advertising is unlikely to be a good solution because many sites receive most of the revenue from it. I’ll have to work on optimizing the loading of my scripts. You can use asynchronous loading of scripts or postpone loading them so that they do not interrupt the rendering of your pages. When it comes to performance, you always have to balance between perceived and actual performance.

An example of asynchronous JavaScript:

Src = “example.js” async

JavaScript example:

Src = “example.js” defer

• Patrick Sexton has another method of delaying JavaScript. WordPress version 4.1 and higher has a filter, with which you can easily add async or defer attributes to your scripts.
• Typically, using external services, you want to cache the answers. What for? Because if you do not, a “white screen of death” problem may arise. Each external service you add must be from a reliable and trusted source. In the end, if they fall, it will affect your entire site or your business operations.

7. Excessive optimization can damage performance

• On the Internet, there are thousands of articles that give “tips” on how to speed up and optimize the site on WordPress. But there’s nothing worse than when users over-optimize their sites. Yes, it happens much more often than you think. Owners of WordPress sites often think that adding something, it will double the download speed.

Below I listed a few problems that I meet regularly:

An attempt to caching

• Unlike typical VPS or conventional servers, many WordPress web host’s have their own caching, which runs at the server level (for example, Redis or Memcache). Many providers prohibit the use of caching plugins, because their use can cause all types of problems, but more often, 502 Bad Gateway. The attempt to “cache a cache,” as I call it, is never a good idea.
• Plug-ins, such as WP Rocket and Cache Enabler, is great, but they were developed for servers that need additional help in speeding up your site. I recommend reading more about how to cache objects – the popular server-side form of caching, often used today.

2 × CDN = 2 × download speed, right?

• CDN can really significantly reduce the time of content downloading in different geographic regions, but only with proper tuning. One of the most popular services – Cloudflare, is technically a proxy server, and it differs a bit from the usual CDN provider, because you send all your DNS to it, not just the content of the site.
• Usually, I see how users connect Cloudflare, then add KeyCDN or MaxCDN in addition. This is often due to the fact that they read someone’s blog posts, where they see recommendations to try new services. They install new services, forgetting about the already connected ones, and, although this combination can work under certain scenarios, more often than not, everything ends up in a mess. In most cases, it’s worth using either Cloudflare or a third-party CDN vendor, each of which has its advantages and disadvantages.

A huge number of SEO-plugins does not provide a higher position in the SERP

• You want to dominate the search results, it’s understandable. But the addition of 3 plug-ins for SEO will not help you achieve this goal. In fact, there are many compatibility issues that arise when using All In One SEO, Yoast and other plug-ins for SEO simultaneously, for example, the output of duplicate meta tags. Installing additional plugins does not guarantee the improvement of your search engine optimization.

8. Popular performance problems are easy to diagnose

• Even if you are not an advanced WordPress user, the general performance problems are fairly easy to detect. For advanced users, I recommend using WebPageTest, because it supports the latest HTTP / 2 protocols. For the rest, Pingdom is suitable. A simple cascading analysis will show you if you have unnecessary redirects, missing files, excessive DNS queries, or site overloading through third-party scripts or ad networks.

Take a look at the performance scores and response codes, and you’ll learn how to start solving errors on your site.

9. Changing the WordPress kernel, this is bad

• Take for the rule: making changes to the WordPress kernel to make your code work is a bad idea. Especially on a working site. Such manipulations can create vulnerabilities on your site. And if you did not provide updates for the new kernel versions, your edits will be lost with every new WordPress update. It is best if you use the built-in tools and functions of WordPress, plugins, child themes and hooks.

10. Ensure compatibility with PHP 7 and HHVM before moving the site

• It is known that PHP 7 and HHVM greatly enhance the performance of sites on WordPress. And of course, it is always pleasant to use the latest and the best. But first, you need to make sure that your site is compatible with these technologies. For example, if you are upgrading from PHP 5.6 to PHP 7, you should test all the functions of your site on WordPress in a running environment or locally to make sure there are no compatibility issues. One obsolete but very important plugin for you may not work with PHP 7, which means you’ll have to wait for it to update before moving on to more recent technology solutions.

11. Large sites should optimize databases

• One of the easiest ways to slow down a large site on WordPress is not to optimize the database. Simple tasks, such as cleaning up traces of old versions of WordPress or removing unused tables, can protect your site from slowing down. Also, I noticed that many of the old sites still use MyISAM in their databases. InnoDB, at the moment, is a much faster and more reliable solution.
• You can convert your tables in just a few simple steps. To start, make sure that you are using MySQL 5.6.4 or newer, and also that you made a backup, as a precaution. This example uses the wp_comments table. Just run the ALTER command to convert to work with InnoDB.

ALTER TABLE wp_comments ENGINE = InnoDB;

If you are working with the current version of phpMyAdmin, you can open the required table, go to the “Operations” tab and change the storage mechanism there.

• Another simple way to optimize is to disable or limit the number of stored fixes in the database. You can add the following to your wp-config.php to completely disable them.

Define (‘WP_POST_REVISIONS’, false);

• Or just change the amount stored for each post or page:

Define (‘WP_POST_REVISIONS’, 3);

• I came across a lot of sites with more than 200 versions of posts. If your hosting does not have internal optimization, WordPress settings will have to be set manually, because, by default, it will store an unlimited number of fixes.
• If many changes are saved on your site, you can run this script in phpMyAdmin to delete them:

DELETE FROM wp_posts WHERE post_type = “revision”;

You can also use the WP-Optimize plugin for these purposes.

12. Do you really need a universal theme?

• There is a huge problem that I see in the WordPress community. People buy universal themes, but use only 1% of its functionality or even less. They look at the demo pages and see beautiful sliders and customized blocks that convince them of the need to purchase, however, in fact, these features may never be useful to them. You can buy a simpler and less functional topic, and thus save both money and time, which, in the end, will be spent on optimizing it, because a simple topic will be faster straight out of the box.

I do not want to say that all the universal themes are bad. In fact, with proper configuration, they can work very quickly – here is an example with the Avada theme, which is downloaded in 700 ms.

• However, to optimize the existing topic, it will take a lot of knowledge and time. For most WordPress users, if they do not use half of the theme functionality, using simpler themes is an option. Do not let beautiful banners and fancy sliders fool you. Most often, all this set of options will only slow down your site.

13. The error log is your friend

• If you know how to behave with WordPress files and the wp-config.php file, the error log can serve you well. Regularly checking it, you will save yourself from all sorts of headaches, and also get a deeper insight into the work of WordPress. Few users look at the log before contacting technical support for hosting. With a few simple settings in wp-config.php, you can enable error logging, which by default is saved to /wp-content/debug.log.

Enabling Logging:

Define (‘WP_DEBUG_LOG’, true);

Log output on the page:

Define (‘WP_DEBUG_DISPLAY’, true);

More details in WP_DEBUG codex.

14. Google is here for a reason

• Do not be afraid to look for answers in Google. The Internet is full of tips and solutions. Within a couple of minutes, you can fix most of your problems. Answers to typical questions like “how to change DNS in GoDaddy” or “how to use sFTP” can easily be found in Google.
• On the Internet there are large resources dedicated to working with WordPress, such as StackExchange and WordPress Codex, not to mention hundreds of blogs with training articles.
• In addition, a good hosting WordPress will most likely have its own convenient knowledge base, which will help users find answers to questions, and host – to reduce the time to support users in typical cases.

15. 123456 is no longer allowed

• SpashData collects a list of the most commonly used passwords (more than 2 million) each year. Not surprisingly, in 2015 the most popular password was “123456” – the same as in 2014. This is quite unpleasant for hosting, as using such passwords keeps sites literally a step away from hacking. One of the best solutions is the use of KeePass or its analogs. Encrypted password in the cloud is always much safer than “123456”.

16. Scripts do not always have to be loaded throughout the site

• Unfortunately, unlike a static website that is manually controlled, the site on WordPress is at the mercy of the theme developers and plug-ins. And not all developers care about the performance of their solutions. There is a huge number of plugins that download their scripts to all pages of the site, although the plugin itself is only used on one of them. If you consider that there can be several dozen plug-ins, the problem multiplies, and the site slows down.

One such example is the popular Contact Form 7 plugin. As shown below, it downloads CSS and JavaScript files to the home page of the site, although no contact form is used there.

• There are several ways to fix this. The first is to use the wp_dequeue_script () function introduced in WordPress 3.1. It allows you to delete scripts from the download queue on your site. Here is an example of using this function with Contact Form 7. The Contact Form 7 developer also has documentation on how to use JavaScript and CSS only where necessary.
• The second way is to use special plugins for WordPress, for example, Gonzalez or Plugin Organizer. Below is an example of using Gonzalez on our website. A convenient settings window allows you to remove JavaScript and CSS files of the Contact Form 7 plug-in for a couple of mouse clicks from all pages except for the contacts page, thereby increasing the download speed of the rest of the site.

Conclusion

There are reasons why WordPress is used on more than 28% of all websites. This is a very reliable, convenient and multifunctional CMS. Everyone, from authors of home blogs to several hundred companies, relies on him every day. But just like with most platforms, if you use WordPress incorrectly or do not optimize it, working with it can quickly turn into a headache.