WordPress website running slow? The beauty of WordPress is that WordPress has plugins for everything. So it’s as simple as installing W3 Total Cache plugin. And there are at least 10 good WordPress caching plugin. So why not install them all? Should boost up the speed at least x10?
The law of diminishing returns comes into play. On top of it, it’s just not technically possible to make 10 WordPress plugins do the same work alongside each other.
Finally if you don’t know why your WordPress website is slow, there’s little hope of fixing the root cause.
There are two things that a website does to your business.
- It kills your business silently.
- It sends your customers to your competitors.
There are several reasons why your website is slow. Consider the path to your website. This is what a typical request to website looks like:
- User (with money) opens browser, types yourwebsite.com, hits enter and waits.
- The user’s connection speed and the server’s connection speed determines how fast or slow the request is passed to your website hosting server.
- The server receives the request, does some abracadabra, churns out the requested page and sends it back to the user.
- The server’s connection speed and the user’s connection speed determines how fast or slow the request is passed to your website hosting server.
Here’s what the process looks like for a slow website:
- User (with money) opens browser, types yourwebsite.com, hits enter and waits.
- The network has latency, takes time to connect. User’s connection speed and the server’s connection speed determines how fast or slow the request is passed to your website hosting server.
- The server receives the request, does some abracadabra, hangs, churns out the requested page and sends it back to the user.
- The network has latency, takes time to connect. The server’s connection speed and the user’s connection speed determines how fast or slow the request is passed to your website hosting server.
- User (with money) is on a different browser-tab with your competitor’s website open and is in the middle of the purchase or request or submitting the form etc.
In this entire process, there are things you can change and things that you can’t.
User’s location & Network latency
If your customer is on the other side of the world, the request for your website passes through half the globe, across wires and under-seas cables etc. If the user is perhaps next door to the hosting data-center, this distance is less. The bigger the distance the more the time required to serve the website. You can’t change it. But you can use a CDN on your website. A CDN is a Content Delivery Network. It’s basically a system of distributed servers (network) that deliver pages and other Web content to a user, based on the geographic locations of the user, the origin of the webpage and the content delivery server. It’s basically like hosting your website at multiple locations across the globe and the server closest to the user’s location gets the request and serves the customer.
User’s internet speed
This is the internet speed offered by the ISP or the mobile carrier. It will vary with the purchase plan and also often with location and mobile connectivity. Not every customer lives in the US.
Server-Performance
Finally the request reaches the server and it’s time for the server to kick in and figure out what needs to be done:
- Which page of the website does the visitor need? Homepage? About Us? Blog entry? etc.
- Does the page exist in the cache? Or does it need to be built up?
- Do the needful and return the requested page.
In here, the process in pt. 2 is complex and depending on the website hosting and configuration may take a lot of time or none at all.
Caching
Scary jargon like “caching” is simple to break down.
Case 1: Let’s say you come to your desktop and want to view a word file. You double-click on the file, the computer opens up the word-processor program (like Microsoft Word etc.), the word-processor program requests the operating-system for the requested file. The OS requests the hard-drive to figure out where the requested file is stored and returns the data to the word-processor. The word-processor reads this data and presents you this data in the form of readable information.
The above is pretty much what happens without cache. Now consider this:
Case 2: You come to your desktop and want to view a word file. The is already open in the word-processor.
The only difference between case 1 and case 2 is that in case 1 the CPU had to do most of the work and load the file into RAM whereas in case 2 the file was already loaded into the RAM and ready on the screen.
Caching is just a compromise between using CPU versus using RAM for running your website.
WordPress websites are dynamic in nature. When the customer opens up a page on your website the server does a lot of things to build up the page and send it to the visitor.
Once the server receives a request to a WordPress page, WordPress kicks in with PHP. This is a lot of PHP files. PHP determines if the page is cached to disk or RAM else it connects to the MariaDB / MySQL server and fetches the information. Finally it passes this information to the WordPress theme which displays the information with all the bells and whistles of header, sidebar, footer and it works.
Understanding the caching internals is beyond the purpose of this article. But don’t let me scare you by saying that there are several types of caching, many different software programs to address the caching, each with its own merits and pitfalls, good and bad software perform better or worse than their design subject to the engineer who has installed and configured them.
Here’s the scary part though: The designer that you’ve hired to work on your WordPress website has no clue about caching. All they can do is install a plugin and tell you that “it works”.
It’s time to ask them what’s OS cache, hardware cache, web-server cache, disk cache vs in-memory cache and may be ask them “Could you please repeat what you said?” You’d be surprised how vastly different the iteration comes out to be.
Finally, the server having figured out what to return to the user, sends the webpage which follows the same return path as the initial going through network latency, network speed and eventually reaching the customer’s browser.
WordPress performance optimisation is a complex architecture. And many experts find it a challenge to get it right. That’s not because they are not good at caching optimisation but because it requires a strong understanding of WordPress internals and a deep knowledge of how WordPress integrates with various caching solutions, knowing on a case-by-case basis as to which option is better suited for your website and then some more.
In part 2 I’ll cover some server-configuration basics and touch upon how to address the various elements involved.
