MemberPress is one of my go-to plugins for easily protecting and charging for access to your content. I appreciate the fact that they stay focused on this core goal and don’t overload it with extraneous features. So it does not have a member directory feature built-in, but by using an additional free plugin you can add this capability.
In this use-case the requirements of the directory are simple: a front-end listing of site members, that other users can browse.
When people register for your MemberPress offerings, they are added to the existing user system within WordPress. That means that any plugin which taps into that to display WordPress users should work fine with MemberPress. You don’t have to look for anything that is MemberPress-specific.
There are several fully-featured and fairly complex directory plugins available on the WordPress repo, but they are generally aimed at being all-in-one solutions for creating and monetizing the directory. They aren’t really designed to be used in conjunction with an existing membership site.
There are fewer plugins that take a simpler approach, and even fewer that do a good job.
After activating, go to Settings > Dynamic User Directory to grab the shortcode. Place that in a page to display the directory.
There are numerous display and sort options you can choose to configure. I’ll highlight just a couple of the important ones here, such as Directory Type.
Alphabet Letter Links looks like this:
This is probably best if you have many members to display.
Otherwise you can choose Single Page Directory:
Customize the displayed info
Each of your MemberPress users has a profile within WordPress containing their username, email address etc. You can choose which profile information to show in the directory. MemberPress also allows you to collect additional custom information. You can modify the information asked for at sign-up by going to:
MemberPress > Options > Fields > Custom User Information Fields.
For example, here I have added Company Name as a field on the registration form:
Dynamic User Directory also allows you to show such custom information in your directory if you choose. To do that you’ll need the Meta Fields Settings. Each field that you have set up in MemberPress will be listed in the WordPress Meta Key Names box, prefixed with mepr_:
To display one of these fields, copy/paste the name into one of the Meta Key Name fields below and give it a label, i.e. the text that will show on the front end:
In the Layout Settings section at the bottom, you can drag n’ drop to order the display of the information:
The free version of Dynamic User Directory will be adequate for many sites, but should you need additional functionality, there are several paid add-ons available which offer even more options and customization. They are very reasonably priced, should you need to purchase any.
All in all, Dynamic User Directory is fantastic for non-technical site owners who just want something easy to get up and running with.
The best solution for developers
On the other hand, if you are a developer, want a bit more control and don’t mind doing some PHP, I would highly recommend having a look at Simple User Listing.
There aren’t any settings for this plugin – just a shortcode that you place in a page to output a list of all your users. In the shortcode you can sort the output according to the parameters of the WP_User_Query class.
But to more deeply customize it, you can override any of the plugin’s templates by copying the template file into a “simple-user-listing” folder in your theme. This gives you all the flexibility that you need. Expect to do some CSS as well to tweak the visual display.
This approach is great for developers who want a lightweight solution and more control over the output and display.
Whichever plugin you choose, you can decide whether you want the directory to be 100% public to non-paying visitors to your site, or whether it’s a benefit of one of your memberships. In the latter case you would just protect it with a MemberPress rule like any other content on your site.
If you’ve come across other solutions for user directories with MemberPress, please share in the comments!
They cause so much grief in the WordPress editor don’t they? They just don’t seem to do what you expect of them. Unfortunately the WordPress editor is not a drag n’ drop interface which is how people generally expect it to work.
With the release of WordPress 5.0, the content editing experience has been revamped with the “Gutenberg” block editor. So it’s time to revamp this post. Gutenberg is not completely drag n’ drop, but it is a more visual way of creating content. Some parts of it make your life a lot easier, but not all issues are resolved.
If you haven’t yet upgraded to WordPress 5+, the Classic Editor section of this post is for you.
WordPress 5+ : the Gutenberg Block Editor
A quick note about my setup. In these demos and screenshots, I use Gutenberg with the Top Toolbar option activated. This puts the controls for each block in the toolbar at the top of the page instead of hovering over each block, which I find a bit annoying.
Insert an image
Let’s start with the basics of inserting an image.
As with everything in the new editor, images are now added using their own block. Whereas before you would have inserted an image directly into a paragraph of text, now your paragraph will be one discrete block and your image will be another block.
In this example I have a couple of paragraphs of text and I want to add an image between them.
Click the +, either in the top toolbar on between blocks. Then insert an image block.
You can then choose to Upload, insert from URL, or choose from the media library. The latter option brings up a familiar modal media library window. The insertion process is familiar but you may notice you have fewer options in the attachment details column. These will be surfaced elsewhere in the Gutenberg interface.
The default insertion size seems to be large size (as defined by your theme), or full if large doesn’t exist, with no alignment.
In order to set the alternate text and size, you’ll use the Block settings on the right side. However, alignment is found in the toolbar. (I don’t know why these controls are in separate places.)
By default, blocks in Gutenberg simply stack in a vertical fashion. So immediately upon insertion, the text is above and below the image, each in their own block.
What do the alignment options do?
In many cases you’ll want the image to be in the flow of text, with text wrapped around it. While Gutenberg is supposed to be a more true to life What You See Is What You Get experience, it’s not perfect, so you should still consider what you see in the post editor to be an approximation and double-check using the Preview.
Generally speaking, the alignment options work as you would expect.
Here’s the image I selected with left alignment.
The text now wraps to the right of the image. Since the image is wide and takes up almost the full width of the content area, it of course doesn’t look very good wrapped. If I want it to wrap, I should use a smaller image.
Editing An Image After It Is In Your Post
Once you’ve added an image block, you can resize the image in a variety of ways:
Drag the blue dots to resize – it will stay in proportion
Use the preset Image Size dropdown – these are the sizes provided by your theme and plugins
Manually enter image dimensions
There are some buggy parts of methods #1 and #3, (as of WP 5.0.2) , but I see a lot of related discussion on Github so it looks like it will be worked on. For more reliability, I would currently suggest using the image size dropdown or the percentage options.
If you want to do more advanced edits like cropping or rotating, you still have access to the original media editor.
Clicking the pencil icon brings up the Media Library modal for that image.
You can click Edit Image to get into the familiar Edit Media screen where you can make edits such as cropping, scaling etc.
Alignment can still be tricky
A familiar problem that has existed forever in the classic editor, is that of escaping the alignment. Meaning, you insert an image, align it, and then everything else after it also has the alignment applied, sucking it up around the image.
What if you only want a small piece of text aligned next to your image, and you want your next piece of content below the image? This is what I call escaping, or clearing the alignment, and it’s still an issue currently in Gutenberg.
Hitting enter a couple of times to create empty paragraphs looks like it should work, (you’ll see empty paragraph blocks in the editor), but it doesn’t. The empty blocks are ignored on the front end.
In the original version of this post, the Classic Editor section below, I recommended a plugin called Spacer to fix this problem.
Well, Gutenberg has a block called Spacer you can use. Insert this and then fiddle with the pixel number to get the amount of space you need.
It’s quite simple to use but there is a downside: responsiveness, or lack thereof. This method doesn’t play well on mobile devices because the block is using a fixed pixel measurement, instead of a relative measurement which can scale.
So it looks great on my laptop:
But on mobile there’s more space than I would like:
I only added 35 pixels of space here. The more you have to add on desktop, the worse it will be on mobile.
So there’s still not a good solution for this common problem, even in 5.0
If you’re a developer and handy with CSS, you could use the CSS class field to add a custom class with the necessary styles to clear the float.
New alignment options
In addition to the typical left, right and center alignment options, Gutenberg introduces the possibility of 2 more: wide width and full width.
These have to be enabled and supported by your theme, so if you don’t see these options, your theme hasn’t added them.
The exact width of wide width will be defined by your theme; essentially it will be wider than the content area, but not full width:
Full width will span the full width of the screen.
These options provide a nice way to break out of the constraints of the content area.
Multiple Images on One Line
In Gutenberg you can no longer do the trick where you select multiple images and insert them at once. But there are other ways to add multiple images in a row:
Use a Gallery block
Use a Columns block, each with an image block inside
The interface of the Gallery block is very similar to the Image block, but it allows you to select as many images as you’d like.
After selecting the images and clicking Create a new gallery, you’ll be on the Edit gallery screen. Here you can specify the order of the images and caption them.
In the Gallery block settings you can choose how many columns to arrange the image in, and whether or not to crop the thumbnails to make the images uniformly sized.
Images in the galley will always fill the width of the content area automatically.
The drawback of the Gallery block is the link settings. You cannot currently link each image in the gallery to a custom url. You can only choose between the media file or attachment page. If you want to have more control over this, or the sizes of the images, I’d recommend the Columns method instead.
No more faking columns
A great thing about Gutenberg is that we have real columns now and we don’t have to fake them. This makes it much easier to create more interesting layouts.
To use images with the Columns block, first add a Columns block, which is found under Layout Elements.
Columns uses what’s been dubbed “Nested Blocks”. That means you can add other blocks within the Columns block. In this example we’re focused on images, but you can use any other kind of content in your columns.
It’s a handy feature – the only finicky part is being able to select the Columns block to edit the settings, vs. selecting the blocks within it. Using the mouse to hover over will normally end up selecting the nested block. The trick is to select the block above, then use the down arrow key on your keyboard to move down to the Columns block.
The columns block settings on the right enables you to add or remove columns. Currently they are equally divided across the space available.
Then just click within each column to add an image block in each:
Media & Text block
This block is similar to using columns but has a couple of different features that could be useful in specific cases. The basic block sets up a media element next to a text block. The default is the image on the left and text on the right, but you can flip that in the settings:
If your theme supports the wide and full alignment options, you can apply those to this block.
The two differences between using this and the Columns block are:
1) The Media & Text block auto-adjusts the width of each column based on the image size. So, the smaller the image, the wider the text column will be and vice versa:
2) The Media & Text block gives an option to stack the columns on mobile, or..
Without boring the pants off you, HTTP/2 is an updated and more efficient way of delivering web site components from server to 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
Now that it’s becoming increasingly widespread, most articles on the topic make sweeping promises of faster performance, “just like that”, simply by enabling it. But there are fewer articles which actually back up these claims with test results.
I recently converted a couple of sites from HTTP to HTTPS and decided to take the opportunity to see what difference, if any, enabling HTTP/2 made.
BONUS PDF: Demystify the jargon! Download this guide to common speed optimization terms.
The sites I tested are hosted in the US with Siteground’s Grow Big plan, using SSL certificates from Let’s Encrypt, which are provided by Siteground for free.
The first site I tested has a blog-style homepage with several images and some external content in the form of two YouTube videos and one Vimeo video. These are the specs:
Benchmark without any optimizations
The first set of tests were done from a US-server, without any caching or optimizations.
Winner: Too close to call.
The results were incredibly similar with the exception of the one outlying result on the HTTP/1.1 side which was caused by the 3rd party files loading slowly. So simply by enabling HTTP/2, there’s not any astounding improvement.
This isn’t really surprising in this case for a couple of reasons:
This particular page has a lot of external content on it, and that will tank your performance every time, HTTP/2 or not. It will always cause more fluctuation in loading times. There’s no fix besides removing it.
There are only 18 assets loaded from the origin server (i.e. from the site’s own domain rather than 3rd parties), so it doesn’t really take advantage of HTTP/2’s multiplexing, that is, the ability to serve many files over one connection, improving efficiency.
Caching and combining assets
Next I activated page caching along with combining CSS, JS and Google fonts (using WP Rocket). Combining these asset types results in fewer HTTP requests, that is, fewer individual files to be downloaded.
To some extent that’s expected due to the common wisdom of combining files being a best practice for HTTP/1 but not necessarily for HTTP/2. However this can certainly vary from site to site, and as you can see, the margin of difference is not huge, so you should definitely test it for yourself.
Caching and minifying assets
In this set of tests I used caching with only minification of assets, but without combining:
This is expected since combining assets is not beneficial for HTTP/2 performance, and detrimental to HTTP/1 performance. The margin of victory here is more significant than in the previous set of tests using combining.
For the next set of tests I decided to try a different kind of page on a different site – one without any external content, and with a higher number of requests:
Benchmark without any optimizations
Winner: HTTP/2… just
HTTP/2 has a slight edge here, likely because there’s more internal content which can take advantage of multiplexing. By comparing the waterfall charts below, you can see, file by file, how much faster they are on HTTP/2.
The green section of the bar represents connecting time and the beige section is the blocking time. Per GT Metrix, blocking is the time the request spent waiting in the browser’s queue to start the request.
Both blocking and connecting are greatly reduced on each request with HTTP/2.
Caching and Minifying
Winner: Dead heat
This was a little surprising. I would expect HTTP/2 to win here, since the lack of combining assets should favor HTTP/2.
Caching and combining assets
This matches the Round 1 result in this category – combining being an effective technique for optimization on HTTP/1.1
Overall, a mixed bag of results here, without showing a clear advantage for HTTP/2.
One of the assumed benefits of HTTP/2 is that it’s more efficient in higher latency scenarios. That means scenarios where it would typically take longer for data to be downloaded. Physical distance between the server where the site lives and the user requesting the web page, increases latency. So, to test this I did a set of tests from the China server location on GT Metrix, which would certainly increase the load time when a CDN is not being used.
China: No caching
Here we see the biggest difference between the two, with HTTP/2 being almost a second faster, confirming the hypothesis that it performs better in high-latency situations.
China: Caching and minifying
HTTP/2 has a clear advantage in this scenario.
China: Caching and combining assets
Perhaps surprisingly, once the page is optimized for HTTP/1.1 it becomes just as effective as HTTP/2, even in this scenario.
Time To First Byte
Some people, and speed testing tools have been using Time To First Byte (TTFB) for a long time as an indicator of how fast a site is. In the HTTP/2 world, this isn’t necessarily going to be relevant. You will consistently see a longer TTFB on HTTP/2 enabled sites, and there are expected reasons for that.
Many people, as I was in these tests, will be moving from sites using HTTP/1.1 without SSL, to adding an SSL. Many hosts are automatically enabling HTTP/2 for SSL sites. Since the HTTP/1.1 version didn’t have use HTTPS, the speed comparison is not completely apples-to-apples. The SSL negotiation does add something to the TTFB. It would have been a more accurate test to compare HTTP/1.1 with SSL and HTTP/2 with SSL, in order to establish how much of that longer time is only due to HTTP/2.
And on the Akamai forums, a user gives a great analogy, comparing the difference to the old vs new ordering system at McDonalds. Essentially, the same processes have to happen and you have to do some waiting in either case, but you’re just waiting in a different part of the process. The takeaway is that, though the TTFB may appear longer with HTTP/2 it’s not relevant because other parts of the process are much faster now.
Let’s compare these two tests:
In the screenshots below we see that the TTFB for the HTTP/1.1 result is actually a lot faster, but HTTP/2 still ends up being quicker overall, and the first paint is faster, relatively speaking.
Here’s the HTTP/2 result:
The first request takes 2.14s
The first paint relative to the start is 1.35s
Here’s the HTTP/1 result:
The first request takes 1.68s
The first paint relative to the start is 3.34s
Perceived Speed Metrics
With the relative speed displayed above, you’d probably expect metrics like First Render and First Contentful Paint to be much faster with HTTP/2. I did not find this to be the case. Comparing these metrics across numerous tests produced a real mixed bag of results.
Comparing the Contentful Paint metric of the above two tests may be surprising.
Contentful paint: 3.3s
DOM loaded: 4.8s
Contentful paint: 3.5s
DOM loaded: 3.7s
The overall load time is 1 second faster for HTTP/2 but the Contentful Paint doesn’t show that much of a difference. There’s a much smaller gap between Contentful Paint and DOM loaded which is likely why the overall Speed Index is better. After viewing the mobile results below, this could be misleading.
What I observed in my tests was that First Contentful Paint wasn’t significantly faster, if at all, with HTTP/2.
What you may be noticing at this point is that measuring HTTP/2 performance thus far is pretty confusing and your mileage will vary according to what you feel the important metrics are. Most typical users won’t really be looking at the nuances here and the most common testing tools – GT Metrix, Pingdom, PageSpeed generally fall short when it comes to HTTP/2. This is going to make it difficult to fully understand what’s happening on your site, unless you’re already really knowledgeable on the topic.
There were some instances where HTTP/2 produced a faster First Contentful Paint even with a longer load time. For example, in comparing these two reports, we can see that the overall load time is 0.2s longer on HTTP/2, but the First Contentful Paint is 0.4s faster on HTTP/2.
Note that the TTFB is also almost twice as long with HTTP/2 but this doesn’t negatively impact the outcome since the efficiency of downloading the assets more than makes up for it.
But what was more often the case was that there wasn’t an overarching trend as to which performed better for perceived speed. Now there could be other reasons for this before jumping to the conclusion, “HTTP/2 is bad”.
For example, a big factor is the optimization of the server itself, specifically for HTTP/2. If you’re really into the technical aspects of this, I recommend you check out this Twitter exchange on the topic, since it really demonstrates how the server prioritization settings play a role in all this.
Things are even muddier when you start testing mobile. This would need a lot more testing on various sites, but there doesn’t seem to be any real advantage to HTTP/2 on mobile yet.
In these 2 tests I compared the uncached page on HTTP/1.1 and HTTP/2 using the mobile testing at webpagetest.org, and simulating a fast 3G connection. This is slower than most US/European users would experience since we mostly have fast 4G. But typically the slower the connection, the bigger the differences in optimization you can see. Optimization, or lack thereof, affects users in the worse conditions, not those with the best.
The overall load time is significantly faster with HTTP/2, but HTTP/1 has a clear edge in showing content earlier, as seen in the Start Render times:
Visually comparing the loading process of HTTP/1 and HTTP/2 shows that the former starts to render more meaningful content, in this case, the title of the post, much sooner. But relatively speaking it takes longer to get to visually complete from that point.
Whereas on HTTP/2, the user is kept waiting longer for anything meaningful (not typically good for perceived speed) but then everything loads in much faster from that point. This echoes the results above from GT Metrix desktop tests where the gap between Contentful Paint and DOM loaded or onload was much smaller on HTTP/2 than HTTP/1.1.
HTTP/1: The title shows at 9 seconds, the images at 13 seconds:
HTTP/2: The title shows at 14.5 seconds, the images at 15.5s:
Given that every article you’ll read will tell you how good HTTP/2 will be for mobile, this is surprising. I think the assumption is that mobile users face higher latency issues, and in desktop tests, HTTP/2 did better in such circumstances. But mobile devices have other issues, such as packet loss, and in those cases, HTTP/2 does worse. I don’t know how to test for packet loss, so I can’t say if that’s the reason for these results.
An important caveat is that in these tests I haven’t tried to optimize the site specifically for HTTP/2, using available techniques like server push. It’s possible that once you really optimize specifically in this way, the results could be much different. This may be the topic of another post ;)
The commonly held wisdom of “just turn it on and your site will be faster” is not necessarily true. It’s important to remember that these results are based on testing only a couple of sites and cannot be considered representative of the entire internet :) But, as with anything related to performance, HTTP/2 is no silver bullet.
It’s certainly going to be the foundation of the web going forward so I’m definitely not suggesting resisting the change. But time and effort should be spent re-optimizing your site for HTTP/2 in order to see some benefits. Certainly a site optimized for HTTP/1 and simply switched to HTTP/2 without any changes won’t do any better.
Generally HTTP/2 is faster when there’s no caching or performance optimizations. The benefits of HTTP/2 are compounded the worse the page and the worse the latency.
On a page that’s already pretty light, the gain isn’t so obvious. Optimizing for HTTP/1.1 can be just as effective as using HTTP/2 .
The wisdom of not combining when on HTTP/2 does seem to stand true, since in all the tests where combining was done,..
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.”
BONUS PDF: Demystify the jargon! Download this guide to common speed optimization terms.
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.
BONUS PDF: Demystify the jargon! Download this guide to common speed optimization terms.
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.
Many issues that arise on your WordPress site will be plugin-related. Whether it’s a conflict between plugins, between a plugin and your theme, a buggy update, or whatever else may happen, the standard troubleshooting procedure is to deactivate all your plugins, then turn them back on one at a time until the issue reappears. This process lets you isolate exactly which plugin is at the source of the conflict. However, if you have more than a handful of plugins on your site, which almost everyone does, this can be a time-consuming and frustrating process.
The interface is very slick. Once you’ve installed the plugin, you can launch the process from the Troubleshooting link in the admin toolbar.
This opens your site within the troubleshooting interface and you then navigate to the page, backend or front end where you’re having the issue.
This is where the fun really begins. Detective Otto Bot rounds up the plugin suspects on your site , interrogates them, clears them and eventually, with your input at each stage, reveals the culprit. This demo video will show you the process:
If that wasn’t enough, perhaps the most mind-blowing feature of this plugin is that it will work even if your site is white-screened. That’s right, instead of having to rename your plugins folder in order to gain access to the site, you can visit:
and you’ll be able to log in and complete the troubleshooting process.
Facing a white screen and without the ability to log in to the admin area to do anything about it, can be a panic-inducing experience for website owners. So this feature is a real gem.
Advanced users may not have the need for this plugin, but for less technical users I think this plugin is a godsend!
Listen, let’s keep it real, I don’t think you should use PageSpeed Insights unless you’re a developer. PageSpeed has its heart in the right place, but it’s not intended for the average WordPress site owner and the reports it provides are ripe for misinterpretation.
Have you ever watched the show Silicon Valley? One of the main characters is Richard, the CEO of a tech startup. He’s a programming genius but socially inept. He has great intentions and a grand vision, but as a leader, he doesn’t do the best job at communicating his vision and is notoriously ineffective at public speaking.
PageSpeed Insights has a lot in common with Richard: they both have great ideas and communicate them poorly.
The basic message of PageSpeed Insights could be translated as follows:
Keep your pages light and simple.
Avoid unnecessary fanciness.
Consider mobile users, particularly those who pay for every byte of data.
However, it goes about communicating these very solid principles in obscure and unhelpful ways.
Since the actual verbiage is hard to understand people instead fall back on the parts that seem clear: the grade and the color. Misunderstanding and confusion abounds!
So let’s take a common sense look at what this tool does and how to interpret it’s socially awkward communication.
The underlying problem
In recent years, the popularity of WordPress and other content management systems has made it really easy for people with minimal, or no development skills at all, to build overloaded sites that violate all the basic rules of performance. Web pages have become bloated and slow.
PageSpeed is basically saying, “Look, if you’re gonna put all that junk on your page, here’s what to look out for and how to mitigate the godawful performance impact.”
The fact is, if you just build a simple, lightweight page, it will automatically score better, and more importantly, your site will be faster.
The fact is, if you just build a simple, lightweight page, it will automatically score better, and more importantly, your site will be faster. Click To Tweet
What does PageSpeed do?
PageSpeed Insights evaluates every website according to a few rules. The same rules are applied to every website, no matter its audience, content or purpose.
What PageSpeed Insights does not do, is measure the loading time. So it doesn’t actually tell you if your page is fast. It only tells you if you’re obeying the rules or not. In theory, obeying the rules would get you a fast site, but that’s not always the case and in reality the situation is far more nuanced that the story PSI tells. It’s the equivalent of saying that someone who doesn’t perform well on high pressure standardized tests, isn’t intelligent. Of course, we know that’s not the case.
PageSpeed’s focus on specific rules abstracts and masks some underlying issues. It makes people focus on a superficial grade rather than on fixing the issues that affect performance at a foundational level.
Let’s have a closer look at the rules, what they mean, and how much you should care about obeying them.
To make any sense of the reports it gives you, you must click on the specifics of each message, by clicking “Show how to fix” to see the details. Do not just stop at the score without digging deeper, this won’t help you at all.
A note about data
I’m writing this article admittedly from my own perspective as someone who lives in a place where data is currently inexpensive. I’m a site owner whose primary audience is in first world countries where data is also cheap and who are overwhelmingly using desktop computers to access my site. However, if the audience for your site consists of people who rely on mobile devices for internet access and for whom data is expensive, you will need to take some of the recommendations more seriously. I may not worry about removing an extra 20KB of data from my page, but you may have to.
A note about 3rd party content
I’m going to refer to 3rd party content a lot in this post. 3rd party content means files loaded on your site from domains that are not yours. When you click “show how to fix” and are presented with a list of files, simply look at the domain to determine if the content is served from your own domain, or external, 3rd party sources. The most common types of 3rd party content are social media widgets/buttons, tracking scripts like Google Analytics, and ad scripts. Too much 3rd party content is going to make your site slower.
And now, the rules…
Avoid landing page redirects
What it actually means: Basically, test the right version of your URL. If it’s https, use https not http
If you use www, use that version of the url, not the version without www.
In reality it’s fine that the other versions of your URL redirect to the primary one – that’s desirable so that if a visitor for some reason tries to use the wrong one, they do end up at the correct version.
But since those redirects take time, as much as possible all links to your site should use the primary version so that users don’t experience any unnecessary delays. When testing your site on any tool, you should use the primary version to avoid adding unnecessary time.
Here’s an example. The primary version of my url is https://webtrainingwheels.com
Note the https and lack of www.
So if I test http://www.webtrainingwheels.com, I’ll get this message:
How much should you care?
A lot because you should be aware of what the main version of your URL is. Otherwise all the speed tests you do will be skewed. Fortunately it’s very easy to fix – just type in the correct URL!
Improve server response time
What it actually means: your server is slow.
The faster your server responds, the faster the webpage can be delivered to the visitor. There are a lot of possible reasons why the server would be slow. As far as WordPress sites go, the most common are:
Lack of caching
If you do already have caching and get this message, try running the test again in case it hit an uncached page previously. If you don’t have caching at the server level (ask your host), then definitely add a page caching plugin (e.g. WP Rocket, Fastest Cache etc).
How much should you care?
A lot! Although PageSpeed isn’t doing a full speed test, a slow server response can be the beginning of a slow load time and can indicate underlying issues. Even an Olympic sprinter will find it hard to make up the time against the rest of the field if she gets a slow start.
What it actually means: the file sizes of the images on your page are too large.
Big, chunky images are one of main causes of web page slowness, but fortunately it’s easy for you to control. This recommendation is very important except when it’s complaining about a few bytes of data. So you really have to pay attention to the amount of data it says you can save. This can be especially true if you’ve already optimized your images, it may still complain about a few bytes here and there. Look at the total amount to be saved and then the savings per image to decide if you can and should take action. Chances are, if you haven’t done anything already to optimize your images, you will need to take action here.
In the following example the savings is 699 bytes which is tiny and I’m not going to worry about it.
PageSpeed will flag any and all images on your site, even if they come from 3rd parties. For example, if you have an Instagram widget on your site those images will likely be listed. But you can’t optimize those because you have no control over them, only Instagram does. So either remove them from your site, reduce the quantity, or accept they are going to slow down your page and PageSpeed will always warn you about them.
How much you should care?
A lot! Optimizing your images is an easy win. If you have too many 3rd party images, you should certainly consider removing them. In a case where PSI is splitting hairs about a few bytes of data, then don’t worry and go about your life.
What it actually means: Compression, either using GZIP or Brotli, is a way to reduce the size of files as they are transferred from the server to the visitor’s browser.
How much should you care?
If the files are served from your domain then you should care a lot! Smaller files means faster transfer and faster loading time. So this is a very important feature to have on your site. Most caching plugins will apply the necessary directives to compress your files, and most servers support this by default these days, and if they don’t you should seriously consider moving hosts – it’s that important and rudimentary.
However, you can’t apply compression to files from 3rd parties. If the list of external files is short, don’t worry and move on. But, the longer the list of 3rd party files, the more you should try to reassess if you need those at all.
Leverage browser caching
What it actually means: Browser caching improves performance for visitors who visit multiple pages on your site or visit your site multiple times. It allows their computer to store commonly used files in the browser which means pages can be displayed faster on those repeat visits. Most servers support it by default.
How much should you care? If the files are served from your domain you should care a lot! Like compression, it’s a foundational optimization technique. Most caching plugins will apply this for you. But as with other rules, it can only be applied to files served from your own site, not those from 3rd parties.
If the list of 3rd party files is long then it’s an indicator that you have too much 3rd party content and you should consider removing some.
How much is too much? This can really vary depending on what the content is, but if there’s more than say, 4 files listed, it could be something to look at.
Minify resources – HTML, JS, CSS
Because it does have the ability to reduce file size, it’s considered to be a best practice. In reality it’s unlikely to save a significant enough amount of data to really have an impact on loading time. More and more themes and plugins are minifying their files so you don’t have to. Sometimes minification can break something on your site, so you also have to watch out for that.
Again, you have to click the details to see how much data can be saved, and in many cases, it’s very minimal.
How much should you care?
It’s very easy to do – many plugins exist for this purpose, including caching plugins – so you may as well try it. The more data that can be saved, the more you should care about it. But in most cases it doesn’t affect the actual load time of the page, so unless the overall savings is significant, don’t lose sleep about it.
The next three messages are essentially attempts to mitigate the negative performance impact of building overly complex pages.
Prioritize visible content
What it actually means: This is a tough one to wrap your head around if you’re not a developer. Imagine your webpage is like a jigsaw puzzle. The pieces are HTML, CSS and JS files. Your theme and every plugin each provide multiple puzzle pieces. The browser has to retrieve all the pieces and then fit them together to form the whole picture of your page and that takes time. The top part of your page, that which the user sees without scrolling, is the most important for perceived performance, that is, how fast it feels for the visitor.
Now imagine that top part of the puzzle is 1 single piece that could be identified and displayed quickly, and the rest could be assembled after because the user already has something to look at. The site would feel faster to the visitor.
This is the goal of this rule. PageSpeed wants the top part of your site to display using as few pieces as possible – ideally just 1 – a block of HTML that contains enough info to display and style the visible part of the page. If the browser has to go find other pieces from the box to complete the top part of the puzzle, you’ll get the “Prioritize visible content” message.
A popular site that suffers from this issue is Mashable.com. That’s because the content that is ultimately displayed at the top of the page doesn’t load in until after other elements, so you’re left waiting with a partially blank screen and no real content to view while the page is assembled: http://recordit.co/uQrrsA9pu2
In more technical terms, if the critical path CSS for your site is not accurate and other CSS files, or JS files are required to display the visible part of the page, you’ll see this message. This article has one of the better explanations I’ve found of why this message is displayed.
How much should you care?
This message is mostly about perceived performance, and user experience, not overall load time. So you should test your site on desktop and mobile and see how bad the issue is. If the site feels fast, don’t worry. This could be hard to fix as a non-developer if you don’t have the skills, or the money to pay someone who does have the skills. I mean, Mashable.com can’t even fix it ;)
Optimize CSS Delivery
What it actually means: The visual display of your site is controlled by CSS files. Your theme and plugins will all load their own CSS files. Going back to the puzzle analogy, each CSS file is a puzzle piece that needs to be retrieved, so the more you have, the longer it could take to compose the puzzle. But we know Google wants that first puzzle piece to contain all the necessary info. So it wants you to figure out which CSS is needed only for the top of the site, and instead of loading it in its own file, or puzzle piece, instead integrate that into the that first puzzle piece. This is called the Critical Path CSS. This will give the fastest perceived loading time. All the other stuff will still be loaded, but later.
When you have a WordPress site with multiple components – theme, plugins etc it’s pretty hard to achieve this without being a developer. The difficulty lies in the fact that not all sites play well with this optimization technique. You can easily break the display of your site by doing this and it’s hard for non-developers to troubleshoot.
The effects can be useful particularly for mobile, improving perceived performance by 0.5 seconds or more, per my own tests (your mileage may vary).
But due to the complexity, if an automated tool, like a plugin, doesn’t work for you, either pay a developer or focus your energy on the things you can more easily control.
How much should you care?
This is not where you should spend the most time or energy. In fact almost everything else on the list should be prioritized over this. Having a heavyweight page but trying to apply this technique is like trying to patch up a dam with a band-aid, and it has the potential to cause display issues. Simplifying your page would be the better way to approach this.
How much should you care?
Final Word on PageSpeed
In general, PageSpeed is a tool that can wave its hand generally in the direction of some issues on your site, while missing some very important rules like applying caching, reducing page weight etc. It’s best used by developers; the average user will probably come away with the wrong impression of their site’s performance. So make sure you’re using a real speed testing tool as well.
Not all WordPress themes provide a way to have totally different sidebar content on different pages of your site. Some may provide a little flexibility with, for example a sidebar for the blog and a different sidebar for static pages, but sometimes you need more comprehensive control. You may need an additional set of navigation on a certain set of sub-pages, or you may want to hide some widgets on mobile devices, or for other specific conditions.
There are several different plugins that help you gain this type of flexibility with your site.
Control Widgets Within Sidebars
Widget Context is a very simple and easy to use plugin which lets you hide or show widgets based on various conditions:
It’s great if you want to control widgets based on the section of the site e.g, home page, blog page, posts, pages, custom post types, or specific URLs. You can also base it according to word count which is a pretty specific but potentially useful option:
While it’s great for content-related control, it won’t do the trick for more complex conditions such as hiding content on mobile, or according to logged in / logged out status etc. For more complex conditions, read on.
Widget Options is another solid and easy to use plugin. It has both free and premium versions. In the free version you can easily hide or show widgets according to content type, similar to Widget Context. There are a couple of differences. Whereas in Widget Context you can target specific URLs, in the free version of Widget Options, you can only target specific page URLs, not post URLs. However it does come with a built-in logic field, so if you know how to use WordPress conditional tags you can do whatever you want.
However what I really like about the free version of this plugin is that it allows you to target widgets for mobile, desktop and tablet. This is really useful for optimizing the mobile version of your site by hiding unnecessary widgets.
Widget Logic Plugin
I’m including this in the list for more advanced users who don’t want to deal with checkboxes and are comfortable with WordPress conditional tags. This plugin adds a simple field to each widget which requires you use a conditional tag to control where the widget displays. It’s not too hard once you understand it, but definitely not user-friendly off the bat.
For example, to make the widget show up only on single post pages, you would enter the tag: is_single()
To make it show up on a specific post or page you need the ID number of the page which is not readily available on any admin screen. You need to actually look in the URL when editing a post/page to look for the id number. Or you can install this handy plugin called Reveal IDs which will conveniently show the IDs in a column inside the admin area. So you identify a page/post that you want a widget to display on, locate the ID and use the following tag: is_single( ‘106’ )
where 106 is the ID of that page/post.
You can do all sorts of combinations to test for things like sub-pages etc. Anything you can do with a conditional tag, you can apply to a widget.
These three plugins so far have given you control over where and how individual widgets show up in the existing sidebars your theme already provides. So this means that when in your Widgets screen, you’ll see a sidebar are with several widgets inside, some of which show throughout the site, and some that show only on certain pages. There’s nothing wrong with this set up, although if you have a lot of widgets it could be confusing to keep things organized and to determine at a glance which widget is going to show up in which sidebar.
So another approach is to use a plugin that enables you to create entirely new sidebar areas that appear on your Widgets screen.
Content Aware Sidebars
Let’s say your theme provides 1 sidebar that shows by default on all pages. With Content Aware Sidebars you can create a new sidebar and replace the default one on the pages you specify. In the screenshot below I’m creating a new sidebar that will replace the standard sidebar on my WooCommerce Product pages.
It’s possible to mix and match conditions and choose multiple rules for where you sidebar will display. And you can also target for logged-in or logged-out users. Other nifty features include the ability to schedule sidebars and add custom classes for design. The Pro version of course has even more features and fine-grained control.
These days it seems most WordPress users are aware of the need for speed on their websites: conversions, SEO, user experience etc. I won’t recycle all the usual stats here ;)
Maybe you’ve read some articles and seen that you need to speed test your site. So you click on whichever tool is mentioned, input your URL and proceed to freak out at the results.
But wait! Before freaking out, make sure you’re observing these rudimentary best practices when doing a performance test on your WordPress site.
1. Test the correct version of your URL
Most websites are available at several variations of their URL:
Using http or https
Including the www before the domain name, or without the www.
In most cases, there is a primary version of your URL, say https://example.com, and the desired behaviour is that no matter which version a user may type in, they will be redirected to the primary version.
However, for the purposes of speed testing, you should use the primary version of your URL to avoid lengthy redirects. This is what happens when you speed test a different version:
The first couple of lines represent redirects, each of which add some time to the overall load time.
2. Use the right server location
Geography is important! You may not often have reason to think about this, but your website actually lives on a computer – a physical server located somewhere in the world.
And that somewhere matters. If your website is hosted in London, England and you run a speed test from a server in Los Angeles, U.S.A, you will get a longer load time than if you ran a test from somewhere in England or Europe. Distance increases latency – that is the processing time to deliver that webpage.
Here’s an example. The site below is hosted in the US and does not use a CDN. I ran a couple of tests, the one on the left from a GTMetrix location in the US, and the one on the right used a server in Australia. It’s a lightweight site, but the speed difference is still significant – 2 seconds. On the average site which is a lot heavier, or with worse hosting the difference would be even more.
Generally speaking you should do a speed test from a server location closer to your host to get a better result.
There can be valid reasons to use other locations, for example, if you have website visitors from other parts of the world and want to see what their experience would be like.
In that case, however, you should either:
Get your web host to move your site onto a server in a region closest to your target audience
Or, if your audience is coming from diverse geographic locations, use a CDN
3. Look at the speed, not the grade
When using a performance testing tool, the goal is to find out how fast your site is.
The only metric that can tell you that is one that uses time-based units of measurements. That means milliseconds or seconds.
But. not. a. grade.
Usually the first thing you see in the analysis is some kind of a grade, or a score, which is typically highlighted in either red, orange or green. We’ve been socially conditioned to see green as “good” – everything’s A-OK and anything less than that as problematic and reason to worry. We then become blinded to everything else on the page and fixate on that score and color.
When speed testing, grades are only based on a set of generic rules which may or may not apply to your particular site. They do not tell you how fast your site is and in some cases there is no correlation. Here’s a perfect example:
Nobody wants a 17 second load time, even if the score is 92!
4. Don’t try to implement all recommendations
Each tool has a predetermined checklist of items it’s looking for, and each one has a weight. It doesn’t matter what type of website you have, or its hosting environment, target audience etc – the checklist is always the same.
Imagine if every car maintenance manual, no matter what type, had the same set of instructions. They would be generic and some would certainly apply in all cases (change your oil regularly) , but they would miss a lot of specifics. Speed tools are a bit like that.
So you have to understand that not all recommendations are supposed to be followed, and if you do want to follow them, they may require expert help.
Not only that, but the recommendations don’t necessarily correlate to the impact they will have on load time. Some of them are actually useless, such as GTMetrix’s “remove query strings” rule – it’s outdated and makes no difference to load time. This would be like using an outdated maintenance manual for your car. For example, most tools don’t check if your site supports HTTP/2, where the best practices are different.
While some can be useful or indicate problems, following all of them is not a requirement to improve load time.
Always focus on the speed itself.
5. Always click the details
Each recommendation will come with more specific details, but usually that requires an extra click and many people don’t bother. But there’s important information hidden in those details.
The most common problem with this is that the recommendation could be suggesting impossible changes – the most common offender is related to 3rd party resources. 3rd party, meaning files that are coming from a server that you do not control.
A really common example is the “leverage browser caching” message.
If you just saw that you scored a “C” for a particular rule, you may think something is horribly wrong:
But to really understand what is being communicated you have to click that message to get to the details:
Once you review the list of files, you’ll see that they are all from external, 3rd party web services, therefore you cannot apply browser caching to them- you simply don’t control those files.
6. Know what you’re measuring
Google PageSpeed Insights does not measure your load time. Pingdom and GTMetrix do, but they each use different metrics, and will give you quite different results. You have to understand what you’re testing in order to put the results in context. See this guide for more info on the differences between various tools.
These tools generally default to testing the desktop version of your site, so if you want to see what the mobile experience is like, you may need to use a different tool or at least to adjust the settings.
7. Run multiple tests
One, single test is not representative of the overall performance. There will be natural variance in results due to network conditions, server performance and other factors – don’t expect exactly the same result every time.
If the variance is drastic it could indicate underlying issues. And the worse your web host is, the more variance you’re likely to have.
Run several tests at a time to get an overall picture of performance. Most people usually only test their homepage but you should also test other critical pages on your site. For example if you have an ecommerce store, make sure you test product pages as well.
There is an overwhelming choice of web hosts these days and it can be hard to determine which would be a good fit. A Google search will reveal many blog posts on the subject which are really are just a roundup of that blog’s sub-par affiliates that haven’t been vetted for quality.
I’ve been running my own sites for over 14 years now, and have also had many years experience with client websites and all their various hosts. So I have direct experience with many different hosts and have also interacted with the technical support departments of many of them.
My recommendations have changed over the years as the landscape has evolved – previously reliable hosts have gone downhill, and a new segment of WordPress-specific hosts has developed and thrived.
There isn’t a host that is 100% trouble-free. You’ll always come across horror stories here and there, but with the reputable companies I work with, those stories are the exception and not the rule.
When choosing a host there are innumerable criteria you could use. In this short quiz I’ve distilled it to some key factors that should influence your selection. I have experience with all the hosts included either because, in most cases, I have my own sites hosted on them (this site is hosted on WP Engine) , or have worked with clients over a long period of time that have used their hosting. Some of the links are affiliate links and some are not. But I don’t include any host I haven’t or wouldn’t use myself.
WordPress Hosting Selection Quiz
What is your monthly budget?*
I want the cheapest possible ($15 or less)
I'm prepared to pay for the best solution
How many WordPress installs do you need?*
I use Multisite
1 single WordPress install
Multiple WordPress installs
How technical are you?*
I'm a developer, I like Git and nerdy things
The less technical stuff I have to deal with , the better
If you need to run multiple sites you should consider increasing your budget. At this budget level Cloudways is probably your best best. Siteground's GrowBig plan could work but has fewer technical features.
WP Engine or Flywheel are great choices for reliable hosting with lots of convenient features for a hands-off experience, and WordPress-specific support.
Recommended for you:
With multiple sites and decent traffic you shouldn't expect to spend bottom dollar. The best deal is probably Siteground's GoGeek plan.Cloudways could be a fit too, but requires a little technical know-how. If you are willing to spend more money you could get more reliable hosting that scales with traffic, for example with WP Engine.
Recommended for you:
My top choice would be WP Engine because their managed infrastructure will be able to handle the traffic and resources you'll need and you won't have to worry about the technical parts. Kinsta would be worth a look as well
Recommended for you:
Siteground's GrowBig plan would be the cheapest plan, but with this type of traffic, you could grow out of this price range very quickly. I would strongly advise increasing your budget.
Recommended for you:
WP Engine is always my top choice for reliable, scaleable hosting for non-technical users. But Flywheel
and Kinsta would be worth looking at as well.
Pantheon or Cloudways will give you the most techy tools to play with and can scale with traffic. Pantheon won't be the cheapest, but it's rock solid.
Recommended for you:
With a multisite install and this level of traffic, you really shouldn't be going for rock-bottom pricing - you should expect to pay a bit more to support the resources you'll need. Cloudways and Siteground probably offer the best value for money. But expect your costs to grow as traffic increases.
Cloudways is probably your best bet here. It's generally cost-effective but depending on how much your traffic grows, or how resource-intensive your site is, you should expect your costs to grow over time. You can easily scale as needed.
Measuring the loading time of your WordPress site is obviously a critical step in optimizing for speed. You have to be able to find where the bottlenecks are and where you can achieve the easiest and biggest performance “wins”. There are numerous tools, such as Pingdom, GTmetrix etc, available for measuring the performance of your site, each of them providing a different result, which is understandably confusing. Which one is “right” and which one should you use?
The answer depends on exactly what you want to measure and the level of detail that you want. They each provide different metrics which is why they provide different results, but it doesn’t mean that any of them is more “right” than the other.
However, no matter which tool(s) you use, what’s more important is understanding what information you’re actually getting, and being consistent with the tool you use. It’s not useful to compare results between tools – for example, between GTmetrix and Pingdom. It doesn’t matter if Pingdom says 2 seconds and GTmetrix says 5 seconds. You should only compare multiple results from the same tool, before and after you’ve made some changes.
Guidelines for Testing
Before you get started, a few ground rules for useful testing:
Run multiple tests every time to get an average and, if your site has any type of caching (plugin, server-side etc), discard the first result since it could be uncached and therefore misleading.
Geography matters – the further away the testing location from the location of your server, the longer the load time.
Choose a server location close to your host, which should also be close to your target audience
If there isn’t one, at least make sure to run all tests using the same server location for a consistent comparison
Loading time is the only metric you should be looking at, not the grade. Here’s an example of why that is. The grade does not correlate to speed:
The grade is great (88 and green) but it loads in 9+ seconds which is terrible!
OK, now let’s look at the top choices in free speed testing tools and see what the pros and cons are, to give some context to your decision.
Of all the tools, I think this is the most visually appealing – it’s easy to read and comprehend.
The summary at the top gives you an at-a-glance overview of the important info – load time, page size and requests:
Pingdom’s waterfall chart (the chart that breaks down each component of your site and how long it takes to load) is definitely the easiest to read of all the tools, and has some handy sorting features.
Tip: sort by Load Time to find any specific files causing a significant drain on load time:
I’ve blurred out the domain being tested for privacy, but you can see in the screenshot below that less than 50% of the content on this site is actually coming from the site itself. Everything else is coming from an external source.
There’s a choice of a few server locations (no account required)
The server selection has been reduced over recent months and at times there’s a long wait to run a test.
There’s no option to test mobile speed.
Does not support HTTP/2, so if your site uses HTTP/2, real life results in most modern browsers should actually be a little faster than reported.
What does it measure?
Technically speaking it uses a metric called “onload”. This is the time at which the browser has processed the page and all assets have been downloaded. It is usually shorter than “fully loaded” which is used by GT Metrix and why Pingdom typically gives faster results. You could say that this is a closer result to how the page appears for the user, since the page will be usable by the visitor by the time “onload” is reached, even if it’s not yet “fully loaded”.
On a site with a lot of external content like ads or huge videos streamed from a 3rd party vendor, you tend to see fluctuating load times. That’s because some of this activity happens after the ‘onload’ marker.
Great for a quick and easy assessment of issues.
Not good for specific use cases like mobile or http/2
Gtmetrix defaults to the “fully loaded” time, which as described above will give a longer result than Pingdom. Per their website :
” [Fully loaded] is the point after the Onload event fires and there has been no network activity for 2 seconds.”
Fully loaded can be considered more comprehensive since it waits for everything to download and execute. On a site with lots of ads etc you’ll really see a big difference in the load time. Now that could be misleading because if you site is developed well, it’s possible for the top part of your page to load quickly and be usable to the visitor, while the other stuff loads in the background, not interrupting the experience too much. But getting a comprehensive picture of the weight of the page and the impact of 3rd party content, is very useful. If your audience is in a place where mobile phone usage is prominent or where data is expensive, the total page weight could seriously affect them since they’re paying for all that data to download.
If you’re going to use GT Metrix, I strongly suggest signing up for a free account because that’s where this tool becomes really useful.
This list pertains to the free account:
Choice of several server locations
One mobile option available
Throttle network connection option – this allows you to test your site on slower internet connections
Ad block option – very handy to enable if you want to see the impact that ads have on the performance of your site
Saves a history of tests allowing for comparison – this makes it easy to track your site’s progress
Uses browsers that support HTTP/2
Timings tab gives you deeper metrics like Speed index, first contentful paint etc:
Tests are run using browsers that support HTTP/2, but the recommendations provided are not tailored for HTTP/2
Recommendations are bit outdated, and some of them are simply quite useless. “Remove query strings” is outdated and won’t have an impact on the load time of your site.
The waterfall is not as easy to read or sort as Pingdom’s:
A free account is a must-have
Provides a fair balance between ease-of-use and more advanced options
This is the grandaddy of all speed testing tools and it’s still the most comprehensive. It just looks like it’s right out of 1998. But if you can get past that, you can get a lot of great information from it. If you’re a hardcore performance junkie you’ll probably want to use this since it has the most technical and comprehensive set of details.
Largest choice of server location
Largest selection of mobile testing options
Most configurable – for power testers it has the most options
Very detailed reports showing multiple metrics such as time to first byte, start render, speed index etc:
Could be a little overwhelming for optimization novices
This is a trick because this is not a speed testing tool.
Let me just say that again in case you weren’t listening. This is not a speed testing tool.
It does not measure the load time of your website so you cannot use it to see how fast your site is. It does have some uses, but speed testing is not one of them.
The score it gives you is not related to the speed of your site, it’s just based on some generic rules which may or may not impact loading time. the score does not affect your SEO or ranking – only the actual load time does that.
Based on some recent changes they’ve implemented, you may start to see some actual speed metrics, but so far these are only showing for larger sites with a lot of traffic. For the average site, the report is still heavily based on adherence to their ruleset and not actual speed.
In short, don’t use it to measure the speed of your site.
This is a mobile-specific tool. Don’t be horrified by the long load times of your mobile page. It’s normal for your site to take longer to load on a mobile device than on a desktop.
Easy to use
Nicely designed interface and results summary
Very quick way to see how your mobile site performs
The analysis is a little bit limited. You can opt to receive a report via email which provides a few more details, but it’s not especially comprehensive.
Some of the recommendations are dubious. Since it’s a Google tool, they of course use it as a way to push AMP for example, which may not be a good solution for every site.
Good for a quick at-a-glance report on mobile performance
But if your site is not performing well in this test you would then need to use a more in-depth tool to find out why.
So now that you know a little about these tools you can try them out and see which one suits you best. It’s not necessary to use all of them to test your site. Pick one and use it consistently to benchmark the before and after results of changes you’re making on your site, and you’ll be in good shape. I personally use Pingdom and GTmetrix the most, with Webpagetest begin my go-to if I want to get really nerdy with the results.