Use proper testing tools!
First things first. Don’t rely on GtMetrix or PageSpeed Insights. If you absolutely must, test using GTMetrix with proper settings.
The best testing tool for performance would be anything that generates traffic to your website. SEO Spider tools that show request rates are good. One example is SEO Frog Spider. The free version will suffice for testing performance just fine.
We can also recommend the following online tests:
- WebPageTest.org – it puts an accent onto the Time to First Byte metric, which is great!
- Test if your images are better with another format by using Cloudinary Website Speed Test
- Pingdom has a good test that is concentrated on total load time
- Our own performance test does the job of checking your server via HTTP headers and give you configuration suggestions that can be used by a Linux expert
Improve SQL queries performance
WordPress makes dozens of SQL queries on each page request. So any slow query produced by a random plugin will absolutely slow things down.
Ensure performance-friendly indexes. You can use Index WP MySQL For Speed plugin.
Mode details in our post on improving WordPress database performance with cleanup and maintenance.
Sane updates approach
Updating to the latest version of WordPress and its plugins is good.
But the more plugins you have – the more frequent updates will be, and thus having to clear the cache.
Batch your updates instead and instead of relying on automatic updates provided by WordPress, use your own system.
For example, create a cron job that runs WordPress upgrades and its plugins only once a month.
That means your cache is fully cleared only that often.
Use Sphinx
Sphinx provides significant performance improvement for delivery search results. Supporting plugin.
Don’t use Visual Composer
Visual composer ruins performance with its ajax-ed grids. Each grid block sends a slow POST request to admin-ajax.php which can’t be cached because it includes nonces (security tokens). Bad plugin design!
Choose proper hosting
Needless to say: if you are on shared hosting like GoDaddy, SiteGround, or Dreamhost, etc. – forget about performance. There’s little chance that you can grow the number of website visitors if you stay with a shared hosting plan. There’s nearly zero chance you can earn from your website if you stay with a shared plan.
There’s a 100% guarantee though, that your account may be suspended, in case your website does receive any decent traffic (many visitors).
Don’t worry, you can change hosting easily. Pay the same amount of money and get guaranteed RAM, CPU usage, and bandwidth. All these are features of VPS or dedicated servers.
Budget hosting. VPS
At this time, our recommendation is Linode. Get a 2GB server for only $10 / month. It’s an offering from a very notorious VPS company that has been there for over a decade and is known for its stability.
DigitalOcean and Vultr can be considered as well, but they can’t beat the latest Linode’s price offer yet.
Higher end. Dedicated server
We have had a good experience with Hetzner servers.
Another alternative is OVH.
Setup WordPress cron properly
WordPress is usually run on a Linux-powered web server. What best way to run WordPress scheduled tasks on a Linux server? Of course, the answer is – the cron service of a Linux server 🙂 Provided you make use of the real Linux service for scheduled tasks and not some emulated PHP-based WordPress calls – you will have increased performance and scheduled tasks will not be missed. We’ve covered this in WordPress cron optimization post.
Enable Conditional HTTP get
Conditional HTTP GET can be implemented in WordPress easily. It allows to preserve the bandwidth and thus allows for faster repeat page access.
Set up Persistent Object Cache
WordPress performance for dynamic pages like WordPress admin can be significantly improved by setting up a general cache powered by Redis.
Use a full page cache plugin, or Varnish
A full-page cache plugin is a must, if you don’t make use of Varnish.
For those, who don’t know what Varnish is – it’s a web accelerator and caching server which is the key component to excellent WordPress performance (read about it below).
Our FPC plugin of choice is W3 Total Cache. We did not select it by rolling the dice. The plugin supports a number of different backends for storing its cache easily. It also comes with Varnish invalidation support, so you can disable W3TC’s own page cache and only use the W3TC plugin for hole-punching Varnish cache automatically, after editing your website content.
Use Varnish
Let’s admit it – PHP frameworks are slow. WordPress is one of the frameworks with dozens of PHP files that are parsed on every page request. Having W3TC cache pages to memory is one thing. Having Varnish cache pages to memory is another – it’s a more scalable approach since you can scale your server to many instances.
With the right cache plugin, Varnish can cache pages using forms with WordPress nonces, using its ESI implementation.
Also, with our Cacheability plugin, you can automatically warm up pages in the cache after they were modified.
Use AMP
AMP stands for Accelerated Mobile Pages.
Use AMP plugin for speeding up visitors who are landing up from Google search.
Secure your WordPress
Securing your WordPress is actually very important in terms of performance. As WordPress represents more than 20% of all websites, most malicious bots target WordPress URLs and create unnecessary CPU load.
Client-side optimizations
The client-side optimizations are usually your last worry.
Async your scripts
Make sure to use async attribute for loading javascript:
<!-- Modern browsers will use 'async', older browsers will use 'defer' -->
<script src="//somehost.com/awesome-widget.js" async defer></script>
Obsolete Techniques
Some optimizations become unneeded or even unwanted, as the web evolves. We include them here for historical purposes.
Use Cookieless domain for static files
For better cacheability, configure your nginx + WordPress installation with cookieless domain for images and other static files.
How it’s obsolete: HTTP/2 is supported universally across the web. Headers, including Cookie: are compressed. Moreover, use of multiple domains will negate some of the HTTP/2 performance features, request multiplexing. Depends on your TLS setup and specific browser.