Trying to make your WordPress site faster is an already technically complex process, further obscured by all the jargon you have to understand. Here’s an overview of some commonly used site “speed up” terms. I hope it helps demystify the process!
General web terms
The program you open to get on the internet: Chrome, Firefox, Safari are the most common examples.
A special computer, provided by your hosting company, where your website actually lives. By “lives”, I mean where all the files and the database are stored. This machine delivers your website to all your website visitors.
Just like your phone and computer run on a certain software – Windows or MacOS for example – there are a few different types of software your server may run on.
Normally you don’t have to worry too much about this – it’s a decision made by your host and you don’t need to get your hands dirty. But if you get really into optimization, there can be a few differences depending on your server environment.
These are the most common examples of server software:
Apache is an open source software and most caching plugins can and will provide additional optimizations by default for this platform.
NGINX is an alternative server software and it’s very versatile. It can be used as an alternative to Apache, or it can actually be used in conjunction with Apache to provide a faster layer on top of Apache. This set up is becoming increasingly common for hosts. You may see it referred to in this way as “NGINX on top of Apache”, “NGINX in front of Apache” or “NGINX as a reverse proxy for Apache.”
HTML is the most fundamental building block of any website. If your web page is a house, the HTML is like the blueprint. It outlines where the main components go. Where does the header go? Where does the sidebar and footer go? etc. It provides the structural framework for all your content.
This stands for Cascading Style Sheets. Fancy name aside, CSS is the interior designer of your house. It controls the color scheme, the typography, basically everything that makes your page look cool.
Without any CSS, your page would be very plain.
Very generally, it means the amount of time it takes for your web page to display in the visitor’s browser.
However, this is a general metric that can be divided into more specific ones.
The amount of time it takes for your page to completely load in a visitor’s browser. That means all files have been downloaded and executed, and it usually includes a couple of seconds of waiting time, to make sure there’s no more activity. This is the default metric used by GT Metrix.
Depending on your site this number might be similar to, or less than the fully loaded time. This is the default metric used by Pingdom.
Whereas fully loaded waits for everything to download and execute, onload occurs sooner. It’s when all the files have downloaded, but not necessarily executed.
onload could be considered closer to the user experience because usually you can start using a page before everything has executed.
But fully loaded is useful if you want to find out the entire page size and get the most complete picture of performance.
Perceived performance / speed
This isn’t a metric in itself but a term for the user experience of loading time. Even if the fully load time is longer, if your site can display the critical content quickly, users will perceive it as being fast. The next term tries to accomodate this as a metric.
First contentful paint / first meaningful paint
These are very similar and it’s basically the time it takes before something useful appears on the screen – a “hero” image, some content etc. As a visitor to a site, if you’re staring at a blank screen, the site will feel slow. But the faster you start to see some content, the faster you’ll feel the page is, even if the entire page hasn’t loaded yet.
These are the vanity grades given by tools like PageSpeed Insights, GT Metrix etc. You should largely ignore these since they are not correlated to load time. That means it’s possible to have a mediocre score and a fast site and vice versa. The only metric that affects SEO and user experience is the load time, so you should ignore the score – it’s a gross over-simplification of your site’s performance and is often misleading.
There are several types of caching available (object, browser, PHP etc). When you read guides about optimizing WordPress and they recommend using a caching plugin, it’s typically for the purpose of page caching.
WordPress has several moving parts that have to run when a visitor goes to a page on your site. Caching helps your site work smarter, not harder. Caching runs that process once per page, then it takes the finished page and stores it on the server. When the next person comes to the page, they get the pre-assembled page which can be delivered much faster.
When someone comes to your house, do you wait for them to arrive before assembling that IKEA chair? That’s what WordPress does if you don’t have caching – it creates that page from scratch every time someone wants to see it.
Or do you have some furniture already assembled that they can sit on? With caching, the page is already generated and saved, ready to deliver to the visitor.
This type of caching can be provided by any one of a number of WordPress plugins (WP Rocket, Fastest Cache, Super Cache etc)
Technically Varnish is a “reverse proxy HTTP accelerator.” Yeah, I know, what does that even mean? Basically it’s a type of server-side full page caching that stores the cache in the server memory.
Mmmm, yeah, what does that even mean?
It’s performing a similar pre-assembly process for your pages as described above, but because it runs at the server-level, it means you can’t add Varnish to your site with a WordPress plugin. Your host has to provide it. A lot of managed WordPress hosts provide this kind of caching. Although it can run at the same time as a WordPress caching plugin, if configured correctly, server-side caching should be faster.
Browser caching allows the browser to keep some of those puzzle pieces in place, that is, stored in the browser itself (on your computer), so that the next time you visit that page, it doesn’t have to fetch them again from the server.
The purpose of browser caching is to make repeat visits to the same site much faster for the visitor.
There are 2 main compression methods – GZIP and a newer one called Brotli. The purpose is the same – to compress all the puzzle pieces so that they download faster from the server to your browser. Smaller files = faster download from server to browser = faster page. Many caching and optimization plugins provide rules to apply compression for various file types, but it has to be enabled on the server in order to be applied.
Minification of HTML, JS, CSS
Minification is the process of stripping out extraneous whitespace and comments from code, to reduce the file size.
Smaller files = faster download from server to browser = faster page.
It’s similar to reducing the amount of paper you would use by using single-spacing instead of double-spacing. It won’t make too much difference to files that are already efficient, but can make a difference for bigger ones.
Concatenation / Combination
The process of joining together multiple CSS or JS files into 1 file. This reduces the number of puzzle pieces the browser has to fetch from the server. The advent of HTTP/2 (see below) reduces the necessity for this technique but it can still be useful.
When the browser is assembling the puzzle pieces to display, or render, the web page, there are some files which stop the process until the browser deals with them. That means these files are “render-blocking”. It’s bad for perceived performance to have too many files which are render-blocking.
In the days when people read newspapers, above the fold referred to the content that was visible at the top when the paper was folded in half.
With responsive websites and a multitude of devices, each with different screen sizes, the “fold”, that is the visible part of the page before you scroll, doesn’t have a set size. The fold on one device is different than another. So it’s not fixed anymore but the concept still relates to “content the visitor can see without scrolling.”
For perceived performance, above-the-fold content should be displayed as quickly as possible.
Chunky images are one of the most common factors in slow pages. Your images should be optimized in 2 ways:
1. Sized to the correct dimensions. ie. don’t use a 2000 pixel wide image when only a 500 pixel size is needed.
2. Compressed to reduce file size further. You can do this with your graphics editing program or with a WordPress plugin.
A Content Delivery Network is a service that provides servers all over the world that can store your website’s assets, then deliver it to the visitor from the closest server to them, making it faster. This is typically a paid service, through a company like KeyCDN, Stackpath, CDN77 etc.
Cloudflare is a service that can improve the performance and security of your site. They do have a free plan with many benefits. Many people refer to it as a CDN and it does fulfill a similar function, but technically it’s different because it works at the DNS level.
This isn’t a service per se. What this actually is, is super-techy and boring to explain. What you need to know is that it’s a new and improved, that is faster, method used to deliver web pages from the server to the browser. There are 3 conditions:
- Browsers have to support it – most of them do now.]
- Servers have to support it. Many do, ask your host about it. If they don’t, using Cloudflare will enable HTTP/2
- Your site has to use https.
After that, you don’t really need to do anything specific – your site is just faster. I’m mentioning it because there are some optimization techniques which may have been applicable before (HTTP/1) which are no longer applicable when HTTP/2 is enabled for your site.