How To Speed Up WordPress & WooCommerce For Logged-In Users

0:00Why Logged-In User Sessions Are Slow

Hello. Hey, it's Brendan from WP Speed Fix. In this video, we're going to talk about speeding up WordPress for logged-in user sessions. This is a common problem for sites that are running WooCommerce, and for membership sites. So let's run through some notes. Let's talk about the problem so you understand what we're trying to fix here. By default, logged-in users in WordPress bypass all the page caching. Their sessions are not cached, which means that they are typically two to five times slower than regular cached sessions for logged out users. Generally the problem is that the time to first byte is super high for logged-in users. Every page has to be built from scratch.

That's not great, because the logged-in users are probably your most engaged visitors or customers. On WooCommerce, if they're logged in, they're looking to buy. If you have a membership site, they are people who've bought your membership product or are actively engaged with your site. So this is an important problem to solve, and one that kind of goes under the radar. It's kind of hidden.

Let's talk about the logged-in user experience for administrators. One problem we also see is sites that have a lot of active editing going on, a lot of changes, where admins are logged in all the time making edits. Those sessions also contribute to Core Web Vitals scores, and if you have a lot of staff doing that and their sessions are very slow, then your Core Web Vitals numbers are not going to look great. We've also seen this issue where staff in a call center are logged in and taking orders for customers and putting them through the WooCommerce site as well. So that can be a problem.

First up, and it's not even in the notes here, if you have admin users spending a lot of time on the site, having them use a browser other than Chrome, something that's not Chromium-based like Safari or Firefox, will help somewhat, as Google doesn't pull the Core Web Vitals data from those browsers. So that's one way to work around that problem.

1:58Turning On Caching for Logged-In Users

But let's talk about the logged-in users. What we're really talking about is customers or public visitors logged into the site. The first step is to turn on caching for those users. I'll show you here. I've got WP Rocket. That's what we use on our WP Speed Fix site. In WP Rocket it's not turned on by default. You go to Settings, WP Rocket, and Add-ons, and you'll see here there's a section for User Cache. We don't have users logged into this site, because we use a different system for customer orders, but it's just a simple case of turning it on like that.

One caveat here, and we have it in the notes, we'll talk about it in a minute, is the Query Monitor plugin. If you have the Query Monitor plugin installed and the caching turned on, it won't actually work, because Query Monitor disables that caching. So if you're using Query Monitor, make sure it's disabled when you're not doing any troubleshooting. Otherwise that caching is not going to work. So I'll turn that off, because we had that on already.

WP Rocket does it easily. So does FlyingPress. FlyingPress is a little bit different. It's the other plugin we typically recommend for speed, and you can cache by types of users on that one. I won't give you a demo here. You can go look it up on the FlyingPress website, flyingpress.net. If you're using a managed host, different managed hosts manage caching differently. They do caching at the server layer. The easiest way to solve that problem is probably to log a ticket with their support and ask how to do that. It's probably in their knowledge base as well. But if you have a managed host, there's going to be a different solution here. Having one of these plugins isn't going to fix it out of the box, because their server does the caching at the server level, or server layer.

So that's turning it on. Step one is to turn on caching for logged-in users. Different plugins will have different settings. If you're using LiteSpeed, there'll be a setting in there for logged-in users as well. So that gets us started. That's kind of the baseline.

3:49Just-in-Time Preloading and Speculative Loading

The next problem we have is that those pages still aren't cached by default. They're not cached until the user visits them. The typical WooCommerce user or membership site user is logging in, and the pages won't be in the cache from the last time they logged in, because they probably haven't logged in for a while, or at least a week. So their sessions are still going to be slow. Generally the caching will only speed up the second time they visit the page, not the first time. So we still have this problem where we need to build the pages in advance, so they're in the cache.

The next tactic we have there is to use just-in-time preloading and speculative preloading. These are two different types of preloading. Let me show you this website. Okay, so this kind of explains how just-in-time preloading works. There is a gap between hovering over a link and clicking the link, in which the page can be loaded. You can see here if I hover over it, there's nearly half a second of time for the browser to start loading the page. So we can use just-in-time preloading to do this. When a user is on a website, they're hovering around, hovering over menu items, and we can use just-in-time preloading to tell the browser to go and get that page, which then builds it in the cache. That is a simple technique to speed up the cache efficiency, I guess you could call it, for logged-in users.

Both WP Rocket and Flying Pages have this built in. In WP Rocket, it's under Preload, I think, and it's called Enable Link Preloading. It does the same thing as that instant.page code. We actually use the Flying Pages plugin separately. They have a free plugin that does it. This one is a bit different and it's more aggressive. It does the preload on hover, but what it also does is start to background load every single link on the page. You can see here we've set it to delay, so wait 3 seconds after the page is loaded to start doing that, and then load one page a second. Adding more than this will typically start to overload the hosting. So you want to avoid doing this too much. Just by having this by default, it's going to increase the load on the hosting, so you want to use the safest settings possible. If you have a WooCommerce site, you might want to exclude some of the pages here. You'll see by default it's excluded some, like checkout and add to cart, but maybe you want to exclude things like orders pages or the My Account section, so it doesn't go loading up a whole bunch of stuff that's not likely to be clicked.

That's just-in-time preloading. Speculative preloading is something else. It's similar but different. It's now built into WordPress 6.8, and there's also a separate plugin if you don't have the latest version of WordPress. It's under the Reading settings here. In General, Reading, you'll see there's prefetch and prerender. You need to be careful with these settings. Prefetch does something similar to the just-in-time preloading. What it will do is go and load that page, so it's cached, but it'll also load all the assets from that page. So it's another step above. It's not just loading the HTML file. It's loading all the assets of that page. That means all the images, JavaScript and CSS are also cached in the browser. So the page has been downloaded and cached in the browser, and it'll be much faster. It's the next level up over the top of just-in-time preloading.

You want to avoid prerender. What prerender does is actually render the whole page. It fires the JavaScript. It's essentially like loading all the pages in a hidden tab. If you enable that, it's going to fire the analytics code, the marketing code, all sorts of tracking code, everything on that page essentially. It's like the user has loaded that page. So you probably want to avoid prerender in 99% of cases, because it's going to mess up your site big time and mess up your stats. These are the safe but aggressive settings we use. We use prefetch, so we're not rendering the page, and we're using eager, which is quite aggressive. Anywhere we're coming near a link, essentially it's loading that page. That will prime the cache. It'll tell WordPress to go and cache the page, so it's more likely that the page is cached and ready for the user. So we resolve that time to first byte issue, but speculative loading is also downloading a whole page to the browser, so it's even the next level above that in terms of speed optimization. That's how we kind of trick the browser into loading the pages in advance. So I think that covers that.

8:02Speeding Up Page Generation Time

Now let's talk about the page generation time. What we're doing with the just-in-time preloading is actually telling the server to go and load the pages, or cache the pages, and download them to the browser. What we want to do is also speed up the generation of those pages. Typically a WordPress page will take anywhere from 1 to 5 seconds to generate, sometimes longer if you've got problems or a heavy site, particularly with a WooCommerce site. So let's talk about some ways to speed that up.

Number one is to speed up the database. There are two things to do here. There's a whole bunch of stuff, and I'll link you over to this article. We have a whole article on our website about speeding up the database. But there are two main things to do. One is to get object caching working. Object caching is a type of database caching, and it will speed up how quickly things can be read from the database. The InnoDB storage engine generally speeds up how quickly things can be written to the database. There's a whole section on this page about it, if I scroll down to the bottom.

Basically WordPress has two database formats. One is the older MyISAM and the newer one is InnoDB. You'll see here there's a graphical representation of the main difference from a performance perspective. If you have an old WordPress site, you might have some of the older format tables. With this older table, when something is writing to a database table, and you can think of a database table as a sheet in an Excel spreadsheet or a Google Sheet, the whole sheet is locked when something's writing to it. So nothing else can be written to it. The writes queue up in a row, so only one can happen at a time. With the newer format, InnoDB, and it's not that new, it's several years old, only the row that's been written to in the table is locked. So multiple writes can happen at a time to a single table. That speeds things up substantially, because a lot of writes can be happening simultaneously, and that basically speeds up the page generation time. It makes a huge difference on a busy site. If you have MyISAM tables, converting to InnoDB will make a big difference.

I'll add another one here. It's actually not in here. I'd say also use High Performance Order Storage for WooCommerce. In one of the recent WooCommerce releases, they changed the way the database works. Previously WooCommerce was kind of hacked into WordPress, and used the same database tables as pages and posts. What this new update does is create new database tables for the WooCommerce-specific stuff: orders, customers, anything to do with e-commerce. As you can imagine, that dramatically speeds things up, because those tables are optimized for WooCommerce stuff. Things like adding to the cart, or clicking around the back end as a customer, will be faster. So converting to High Performance Order Storage is a big deal in terms of performance. It'll speed up the logged-in sessions, but also anything related to WooCommerce, like orders or e-commerce stuff. So that's well worth doing as well. I won't go into that too much. It's a pretty simple process to convert, and there's a big article on the WooCommerce site on how to do that.

Next one. PHP is the programming language WordPress runs on, so using the highest version that your site supports will speed things up. Every version of PHP is faster than the last one. 8.4 is the current version at the time we're recording this video. So if you're running version 7.4 or 8.0, and you can run 8.4, then you'll get a speed boost. Keep in mind that all your plugins, custom code and theme have to be compatible with that. Just because your hosting supports it doesn't mean the site supports it. So there are several steps there. A lot of hosts have testing tools built in to test compatibility, and that'll capture 90 to 95% of compatibility issues. Just keep in mind that changing the version is a big deal. It's not just something you can flick a switch on and it works. You need to test it and make sure it's not breaking anything.

But using a higher version of PHP will speed up that page generation time, as will fixing PHP errors. PHP errors, and any other errors that are happening under the bonnet, typically happen because of a PHP version issue. Quite often you've got a higher PHP version than your site or plugin supports. The easiest way to troubleshoot for those is this plugin called Query Monitor, which we mentioned before. If I just search Query Monitor plugin, you'll see here it's free. What it does is add a section in the admin bar in the browser, and it will show you the warnings and errors and any notices that appear when a page is being loaded or generated. So fixing the warnings and errors in there will make things faster. It'll show these numbers across the top here. This one here is the page generation time. This is how much memory the page used when it was generating. This is the amount of time it took to query the database, and this is the number of database queries. If one of these numbers is really high, if these database numbers are high, then you've got a database issue. Typically if this number here, the page generation time, is high, you've got some sort of PHP thing going on. It might be errors. It might be that it's a heavy page, it has heavy queries, or you might have a plugin that's making it do a lot of work. But basically this plugin will help you uncover issues that are affecting performance. So I'll leave you with that one. That one's a whole video in itself.

This is another PHP one. You can optimize PHP. These are the optimized PHP settings, and I'll put this in the description. These are the optimized PHP settings we use that squeeze more juice out of the opcode caching for PHP. These are reliable. We've used them on hundreds of sites. It will basically speed up how quickly a page is generated. I won't get into how you can add those settings into your PHP here, because it's different depending on your host, but you can get a developer to do that and it'll squeeze more performance out of your PHP.

14:12Infrastructure, Edge Caching and Checking Your Core Web Vitals

Okay, next one. Use server-based WP cron jobs. Instead of using the built-in WordPress cron, and cron is a scheduled job that runs in the background and does a whole bunch of WordPress stuff under the bonnet, if you're not using server-based crons, basically the cron job will run on one in every five or 10 page loads. For logged-in users, that can make their page load time something like 20 or 30 seconds, depending on how long the cron job runs. So using a server-based cron will speed up their sessions. Again, this is kind of developer level stuff. I won't go into the details here, but this is something to ask your developer about. It's quite technical, but it is something to add to the checklist.

This one you should already be doing if you're watching this video. You should already have a content delivery network. We recommend Cloudflare. Ideally, use edge caching with your CDN. In Cloudflare that's called APO, and it's also generally called edge caching. It means basically the entire page is hosted on Cloudflare and served up by Cloudflare. When a user is logged in, it bypasses that edge caching, so the page is served up by the hosting. But the idea behind this recommendation is that you're moving the workload off the hosting onto Cloudflare. That frees up your web hosting to do only the things the web hosting can. It saves server resources and allows the hosting to focus on a smaller number of tasks, and Cloudflare can do a lot of the work for general user stuff and logged out sessions. Cloudflare APO is only five bucks a month, so it's dirt cheap. It's also available on the $20 a month plan, or it's 25 bucks a month depending on whether you go with monthly or yearly billing, but it's well worth it and will make a huge difference to performance in general, not just for logged-in users.

We talked about this before: if you've got the Query Monitor plugin enabled, it will actually disable this logged-in caching. So when you finish using it, disable it. Very simple. What else? Do the usual speed optimization. If you're not passing Core Web Vitals, generally speaking, for logged out users, then that's a problem. General speed optimization will improve the speed for everyone, logged in and logged out users. If you want to know how your Core Web Vitals are doing, this page here on our website will give you a free Core Web Vitals report. Just stick in your URL there and hit Generate Report. It takes 60 to 90 seconds and you'll get a report of how your site's doing right now. This video here has a breakdown of how to read that report. In particular, you want to look at the time to first byte section.

17:18Reading the Report and Running a Site Audit

If we do it here for an example site, this is a membership site that does have some speed problems. We'll just let that load for a couple of seconds. This is a membership site, so there are a lot of logged-in users. It has some problems right now that we're working through. You'll see here that the speed isn't great. I'll just make this April 2025, so that's last month. Ideally these need to be 75% or more green to be in the passing zone. There's some work here, and we do have some CLS issues here. But if we click over to the time to first byte section, we'll see that there are some problems here. This is because it's a membership site, so a lot of the sessions are not cached. When we see a report like this, where the green is pretty small and the red and yellow, red and orange, are quite big, that usually indicates a technical problem. There's a discrete or specific problem we have to solve. This one here is a work in progress at the moment, and the problem to solve is the logged-in user session speed. But this report will give you a quick overview of how you're doing. Generally, improving the speed overall will improve the logged-in user speed.

If you want to look at that speed in more detail, this is our tool, Vital Signs Tracker. Run the same report on the site, last 28 days. We have the ability to track logged-in versus logged-out user speed. If I scroll down here to the bottom, you'll see I've got the list of pages and it's segmented out. These are logged-in users, and you can see time to first byte is horrible. For logged-out users, actually, the speed is okay. So it's the logged-in users generally that are pulling us down and need some work. There are some issues here, like the My Account page is slow. There's also an issue with query strings on paid traffic. I think I have that in the notes here: be mindful of query strings and paid traffic. That also blows up the time to first byte. Query strings by default will bypass all caching, so you need to ignore whatever custom query strings you're using on your Google Ads traffic. You can see that's a problem with this site here. Ad traffic was getting a 3.6 second time to first byte. That's horrible speed for paid traffic, so that needs to be fixed.

Okay, so that's speed stuff. Do a plugin audit. Fewer plugins is better. Any plugins or code that you have in the site, third party code, just do a quick audit and get rid of anything that you're not using. Very straightforward. Every plugin adds code. Every piece of JavaScript adds bloat. So if you're not using it, get rid of it. Very simple.

This is a common one we see as well. Make sure all the menu links are pointing to the right URL. Sometimes we see menu links pointed to HTTP, so not HTTPS, or they're not using the correct www or no www, or they don't have a forward slash on the end of the URL. The problem with this is that when someone goes to the menu system, the site has to redirect them to the right page. That adds one to 3 seconds of perceived load time into that user session. That's a common problem that will be missed in speed test tools, but it is one we see all the time: the menu is using a mix of www and no www, or some of the URLs don't have a forward slash on the end. So it makes things slow.

Okay, just a few more. Fixing all of the 404 errors. It's a common problem. A 404 is bad for speed and bad for SEO. Just run some sort of SEO audit tool over your site and it'll pick up all the 404 errors. This matters particularly for logged-in users, because their sessions are already going to be a little bit slower by default, so 404s are even going to be worse for them. Just fix any of those, particularly if they're sitewide. If there's a 404 coming from the footer or the header or the page template, that's going to slow down every single page on the site. So fixing that is an easy win across the board. It's good for speed, good for SEO, and just good in general for users. Typically a 404 error somewhere in the template, or somewhere that's sitewide, can add anywhere from 1 to 5 seconds to the page load. It's because the browser has to figure out what to do. It gets to a 404 and then it has to manage that error and work around it. Different devices and different browsers will react differently. Some will be fine, particularly on desktop and Chrome, that'll be okay, but on mobile devices it's going to struggle, and it's going to present as a weird kind of delay or lag. So, very simple: fix 404 errors.

21:03Best Practices and What Does Not Work

Okay, just a couple more. Make sure your host supports the HTTP/3 protocol. That will speed up how quickly browsers can connect to the hosting, and it will speed up how quickly they can download stuff from the hosting. Also make sure you've got something called HSTS enabled. We have a video somewhere about how to enable that in Cloudflare. It's a security header that speeds up a few things around the first connection to the site, and it affects the speed at which stuff can be downloaded from the hosting. So those are kind of simple check boxes. They won't make or break things, but they will add a little bit of speed for everybody, not just logged-in users. We talked about this: be mindful of query strings.

Now let's talk about some things that don't work that are usually recommended. Increasing PHP memory won't do anything at all. It will only do something if you're getting errors about PHP memory, which you would see, because pages just wouldn't load. Minifying CSS and JavaScript does nothing for speed. It does nothing for logged-in users, so it's a waste of time. It actually can make things slower. It can break caching in some circumstances. Messing with the WordPress heartbeat is a nonsense recommendation that doesn't do anything. It's such a minor optimization that it's a waste of time. So it doesn't do anything either and won't solve your problem. These three are just wasting time. PHP memory: if you're getting memory errors, yes, it will do something. Otherwise, more memory is not going to make a difference. As we talked about, you can track logged-in user speed with Vital Signs Tracker. You can see that on our website if you want to use that.

So that's pretty much it for this video. If you want more help, there are a few ways we can help you. There are free tools on our website. There's a free SEO audit, which will pick up 404 errors. There's the Core Web Vitals report I showed you. There's our site speed tool, which will give you AI-based recommendations on how to speed up your site. All these tools take about 90 seconds to run and there's no opt-in required. If you want help, go to the homepage. If you want paid help, submit a free audit request here and one of the team will have a look at your site and tell you what we can do to fix it, if we can fix it, and the service we recommend. So that's it for this video. If you need anything else or have any questions, just post in the comments below. Cheers.

0:00Why Logged In Sessions Skew Your Speed Data

WP Speed Fix. In this video, I want to talk about our Vital Signs Tracker software, just a short demo video. One of the features we built into Vital Signs Tracker is the ability to track the speed of logged in user sessions versus logged out WordPress user sessions, and there's a big difference between the two. By default, logged in users' sessions in WordPress are not cached. So every page is going to be slow, essentially, because it has to be built from scratch.

That can dramatically skew our speed data. Even though the site might be super fast for logged out users, slow logged in user sessions can skew the speed data and put the site into the fail zone for Core Web Vitals. That's why we built this feature. It's only supported on WordPress, because WordPress sends particular headers when the user is logged in versus logged out.

0:46Setting Up the Logged In vs Logged Out Report

I'll just show you a report here. I'm inside Vital Signs Tracker and I've gone to Web Vitals, which is where you run the reports. I'm going to choose this site. It's a membership site, so I know it has logged in and logged out users. These types of reports are particularly useful for WooCommerce sites and membership sites, which are generally the two types of sites that have users logging into them.

By default, the comparison it shows for this data will be desktop traffic versus mobile. So we want to change that, choose segments, and choose logged in user versus logged out WP user. We hit that, choose the date range, and here we go. Here's the report.

1:32Comparing LCP for Logged In and Logged Out Users

You can see the data is very different. Just to refresh you, these numbers are in milliseconds, so 2500 milliseconds is the passing zone. This is actually in the fail zone: 2.8 seconds, nearly 2.9 seconds, for the last 28 days anyway. That was the LCP time for 75% of the users. Logged in users, though, are horrible at nearly 5.4 seconds, or 5.3 seconds. So it's a big difference. Basically, logged in user sessions are twice as slow as logged out sessions, and that is a problem.

One of the things you can also do with these reports is click these and view just one set of the data, like this. You can see logged in users are very slow here. Some of them are getting some fast sessions, but generally it's pretty horrible. I'll just undo that. If we scroll down, INP is pretty good, that's good across the board. No layout shift either.

2:21Slow Time To First Byte Is the Root Cause

Okay, FCP. FCP, First Contentful Paint, you can see here it's horrible as well. This needs to be 1.8 seconds or under, and we're really bad here. That is a function of this. Really, the core problem is that the time to first byte is really high for logged in users, because every page has to be pre-built from scratch. It's 4.5 seconds for the time to first byte, so users are basically sitting there looking at blank pages for the most part.

Again, if we look at just the logged in users, 75% are getting on average 4.5 seconds. We can see the distribution here. There are some users getting fast sessions, but mostly they're 3 seconds and above, so that's not ideal. Really, the root cause of our problem here is a time to first byte issue. So we need to fix caching for logged in users.

3:08Speed by Country and by Page

Here you can see the data by country. In Australia, the logged out users are fine, with a 2 second LCP, which is pretty good. The US is a bit of a problem. I think this site is hosted in Australia, so this is probably to do with the geography. Some work needs to be done here to prime the cache. The UK is kind of similar, and Germany similar. New Zealand, again look at the geography, is in the passing zone. So there's a geography issue here with the loading speed, but regardless you can see the LCP is pretty horrible in the US, 7.6 seconds, 6 seconds. That's really slow, so that's not good.

If we scroll down, we can see it page by page. Generally pages are looking pretty good across the board for logged out users. There are some that are a bit weird, like this My Account page, which is like a login page and probably shouldn't be accessible by logged out users. Generally pages are fast unless the user's logged in, so probably some work is required there on that time to first byte.

4:19Scheduling Reports and Fixing the Cause

Anyway, that's a demo of the logged in versus logged out user sessions. You can also set up a scheduled report for this. If you want to track this on an ongoing basis, click Schedule Report and put the data in for the emails. You can do it every week or every two weeks if you have a membership site or WooCommerce site.

In terms of the fix, in this case the fix is getting caching working for those logged in user sessions. It might be different for your website, but usually that is the case, that those logged in sessions aren't cached. Anyway, I'll leave you to it. If you have any questions, hit up our support team. Just go to the website and log a support request on the contact us page, or post a comment on the video below, but it's probably better to hit up support if you are a paying customer. Anyway, I'll leave you to it. Cheers.