WooCommerce Speed Optimization & Consulting

0:00Start With Your Speed Goal

Hey, it's Brendan from WP Speed Fix. I have a video here on WooCommerce speed optimization, something we probably should have done a while ago. If you have a WooCommerce site and it's slow, it's going to cause problems with conversion rate, with SEO and with paid traffic. So speed is really important, extra important on a WooCommerce site, and there are a lot of different places WooCommerce can be slow. Let's get into it.

The first place to start is looking at what your goal is. What are you trying to do, and what are you trying to fix? WooCommerce can be slow in a lot of different ways. It could be the back end, the front end, or passing Core Web Vitals. It could be the logged-in user speed, where everything's fast but as soon as the user logs into the front end, things are slow. It could be that add to cart is slow, or the cart or the checkout is slow. Managing orders can be slow, or managing products, and doing big exports of data can be slow or even just time out.

1:33Measuring Core Web Vitals And TTFB

As a starting point, I would say Core Web Vitals should be where you look. The reason is that there are so many tools available to make the front of the website fast that you should be passing Core Web Vitals. If you're not passing Core Web Vitals, start there, and those tools will typically make all the other things faster as well. It'll make the back end faster, the cart and checkout faster, and everything else. So start there.

If you're not aware, Core Web Vitals is the real-world speed of the website. Every time a user visits your website, if they're on a Chrome-based browser, Google grabs the speed out of their Chrome browser and collects it. That data is the Core Web Vitals data, so it's the real user speed on the website. It's not the PageSpeed Insights score, and it's not about getting a 100 score on PageSpeed Insights. It's about passing those Core Web Vitals metrics.

We have a report on our website that will show you the last 12 weeks of site speed, how your site's been performing. If you go to this link, you'll get this page here. We actually have free email reports as well, so if you want to keep track of it over time, you can. Basically you just enter your website URL. Here is a membership site that we use in a lot of our videos that we know is slow. You get a report like this and it will give you the metrics. These are the three Core Web Vitals metrics: LCP, INP and CLS. LCP needs to be under 2.5 seconds for 75% or more of your visitors. You can see this site is a little bit slower at 3.3, so that should be 2.5. There's a graph here with the breakdown. You can see 65% of users are getting a good LCP time, so it's fast for 65% of people, which is pretty good. Then we have 19% poor, which is not great, and 16% needs improvement. This report is completely free, so run it as many times as you want.

If you scroll down, you'll get a breakdown of this over the last 12 weeks. You can see the site was actually slower two months ago, and the time to first byte was very poor. If you see the graph and it's kind of 50/50 red and green, a little bit like this, usually that means there's some sort of technical issue or some sort of big issue under the bonnet. This is a membership site and this is why it's poor: it has bad membership site software. In your case, if you're seeing all red and a little bit of yellow, it usually indicates there's a technical issue that needs to be fixed. It's not just speed optimization that's the problem, it's more of a configuration issue or a hosting issue.

LCP needs to be 2.5 seconds or under. INP needs to be under 200 milliseconds. INP responds to inputs, so this is fine at 100 milliseconds. CLS is how much the website moves around when it's loading, how stable it is. CLS is best explained by this experience: you go to a website while it's loading, you go to click on something, it finishes loading and now you click in the wrong spot. That's layout shift, and we don't want that. It needs to be under 0.1. Layout shift is not a speed metric, it's a computed metric of how that stuff is moving around. So those are the three Core Web Vitals metrics.

These other two metrics are important too because they are speed metrics. Largest Contentful Paint is when the site has finished loading, so that's when the visitor perceives it as having loaded. First Contentful Paint is the start of the load, so that's when the visitor perceives the site as having started to load. That needs to be 1.8 seconds. This one's actually quite poor at 2.9 seconds, and the reason for this is the time to first byte is poor. Time to first byte is how quickly the server is sending stuff to the visitor when their browser requests it, and that needs to be under 800 milliseconds. That's the target there. For a membership site it's going to be a bit high, but you really should be aiming for around 500 milliseconds to make everything fast. If we dropped that down to 500 milliseconds, so if we took a second off it, then these other metrics would likely come down too. This one would definitely come down by a second, this one probably close to a second, and they'd come into the passing zone.

If we were working on this website, we would be looking at how we can improve the time to first byte. That's really the problem with this website: the hosting, the site or the server is slow to respond to user requests. Start there. That's what you need to be in the green zone for first, and then look at these other issues.

On big exports of data: if you have a large site, it's probably smarter and wiser long term to hook the site up to either Zapier or n8n. Instead of doing big exports of data, use the API to send data to these tools. If you're exporting new customers, send them as they come in as opposed to exporting them all at once. Basically, connect the site to something else and stream that data instead of exporting in bulk, and that'll solve that problem. If you're doing a big export of thousands of customers or thousands of orders, that is going to be slow. There's no way around that because it's a big database query, but some of the things here will speed that up.

6:34Hosting Requirements For WooCommerce

Okay, so let's get into action items. For WooCommerce, you need to be on good hosting. We've said this in so many videos: the cost of a good host versus a crappy host is like the cost of a cup of coffee compared to a nice lunch. If you're spending less than 10 bucks a month on your hosting, it's probably not going to be good enough for running a WooCommerce site. That's just commercial reality. Spending 50 to 100 bucks a month is kind of a starting point, and that should be decent hosting. There are two options there: WP Alpha, which is our managed hosting platform, or Cloudways, cways.net, is another good option.

Good hosting should support the HTTP/3 protocol. That is a must. That's the protocol that web browsers use to connect to the hosting, and if the hosting doesn't support it, it's just going to be slow. We still see hosting that only supports HTTP 1.1. The difference in speed between version 1.1 and version 2 is 50 to 100%, and the speed difference from version 2 to 3 is 10 to 20% more. So it's a no-brainer. It's a free optimization, and if your hosting doesn't support it, it sucks.

Hosting needs to be reliable, of course, and you should get uptime monitoring in place. I've written a note there: use simpleuptime.co. That's our uptime monitoring solution. Your hosting should also send email through a proper SMTP provider like SendGrid, to make sure emails get delivered. Order emails are super important, so you don't want the hosting sending the email directly, because that will have deliverability issues. That's an important point.

If you are on a VPS like Cloudways, or if you're running your own, use fast DNS servers. Let me make a note here: use 8.8.8.8 and 1.1.1.1. That's Google and Cloudflare. Quite often you'll see VPSs using the DNS from the provider they're on, and that DNS hosting is usually quite slow. If you use these two, these are fast DNS. This is important when the site is connecting out to things like payment providers and shipping providers, because if that DNS is slow, then things like cart and checkout are going to be slow. Uptime monitoring, covered. Then use the highest version of PHP your site supports. I'm going to add another one: Redis for object caching. Object caching is database caching, basically. It's not exactly, but it's basically.

That's kind of your checkbox for hosting. Your hosting really should do those things if you have a WooCommerce site. I think that's pretty straightforward, and I don't think we need to go on about that too much. We do still see customers on Bluehost or HostGator or GoDaddy. Those guys are like a low-cost airline. They are cheap, but they will gouge you for all the add-ons, and they're cheap because they're kind of shitty. What do you expect when you're spending five bucks a month? You're not going to get a good quality product and you're certainly not going to get good support. So just be realistic about what you're spending versus what your expectation is. If you want it to be fast and rock solid, spend a few bucks more and you'll get the right solution.

10:05Page, Object And Edge Caching

Okay, let's talk about caching. You absolutely need caching in place. In WooCommerce land you need a few different caches. First, you need page cache. When a page is built, there are a lot of database lookups and PHP processing that need to happen to build that page. What page caching does is it does that in advance and saves the page so it's ready to go when the visitor requests it. So you need that caching in place. Your hosting might do that if you're on something like WP Engine, but we would recommend using a plugin anyway, and one of these two plugins here, wprocketplugin.com or flyingpress.net. Those are pretty much the two leading plugins on the market, and they do a whole bunch of stuff to make that page cache work better. That's why it's worth using a plugin even if your hosting has caching. See our pages on the WP Rocket settings and the FlyingPress settings.

Next is caching for logged-in users. You want to turn this on, and both plugins have that option. You want to cache logged-in user sessions as well. By default a logged-in session is usually not cached, but in WooCommerce we want that, because we have customers logging in to their My Account section or logging in to make a cart or orders or whatever. If you don't cache their sessions, those sessions are going to be slow. They will still be slower than a regular session because the pages aren't being built in advance. We do have some ways around that, which I'll talk about in a few minutes, but you need that enabled in the first instance. So make sure you have caching for logged-in users enabled. It's easy with both those plugins.

Then Redis caching. You need Redis to support an object caching plugin. Object caching is a type of database caching. The object cache sits in front of the database, so when a request comes through it talks to the object cache first, and if the data is in there it loads from RAM, from memory, rather than having to ask the database. So it reduces load again.

The third type of caching is edge caching with a content delivery network. What that means is you have a content delivery network, a network of servers around the world that serve some or all of the website. If my hosting is in the US and I have someone from Australia visiting the site, then most of that page will actually load from a server in Australia. That reduces the impact of geography, and it also moves the workload off the hosting onto the CDN server. What edge caching does is it caches more of the stuff. It's basically page caching on the CDN. With that enabled, if I'm in Australia in that scenario, the entire page just comes off a local server in Australia. So we've almost completely removed the impact of geography. In some cases we don't need to go back to the server in the US at all for some of the page loads. That's a huge deal.

Let's talk about the Cloudflare APO service. It's $5 a month, so that's dirt cheap, and it will substantially increase the hosting's capacity to deal with a lot of users, because Cloudflare is just doing so much of the work. FlyingPress, like we talked about, has a version of this where you can use edge caching without Cloudflare APO, but it's not super reliable and there are some edge cases where it breaks stuff. If you're on a budget, using the FlyingPress plugin will give you something similar. So that's caching. You need caching, and without it things are going to go slow.

13:42CDN, Firewall Rules And robots.txt

Let's talk about CDN, content delivery network. We kind of covered that off just now. We recommend Cloudflare. It's the biggest CDN in the world, and it just works. It also does a bunch of other stuff like firewall and security. See our post on the benefits of Cloudflare.

Never use two CDNs together. You'll see that both FlyingPress and WP Rocket are selling their own CDN service, and Automattic, WordPress, also have their Jetpack plugin that is doing that too. If you add two CDNs on top of each other, things will actually go slower, because the traffic has to go from one CDN to the next one to the hosting. You're just adding more steps into the traffic. So don't do that. We see a lot of sites come to us that have Cloudflare and then have bought the WP Rocket CDN, which is a bad idea. It makes everything slower. Let me make a note there: two CDNs makes things slower. I'll add these notes into the video description.

We say use Cloudflare and the paid plan. I think it's $25 a month. It includes the firewall and image optimization. If you have a bigger site, that paid plan has a real firewall that will filter a lot of garbage and attacks before it hits the hosting, and it has image optimization as well. In Cloudflare we also add some custom Cloudflare rules, and we have a post on our website about that. One of the things we do is filter brute force attacks. We have this rule set here to filter brute force attacks on the back end of the website. A typical WordPress site gets anywhere from 1,000 to 10,000 brute force attacks a day. With that Cloudflare rule we can filter a lot of that crap and just remove that workload from the hosting, and it also makes things more secure.

We also filter traffic outside your target country. If you're only targeting the US or North America, for example, you can run traffic from outside, in this case, US and Canada, through a Cloudflare CAPTCHA-type setup. You'll have seen this around the web, where you go to a website and it says "checking your security". That's you being checked to see if you're a bot. Filtering traffic outside your target country doesn't block legitimate users. Some proportion of real users might be outside your home country, they might be traveling or on a corporate VPN, but it will dramatically reduce the workload on the hosting. It will cut out a lot of crawlers and scrapers and garbage traffic hitting the hosting, and it'll also make the site more secure. That's an easy one, and it's free, even on the Cloudflare free plans.

We would also say use the Wordfence plugin, and the free plan is fine for that. Usually we would say use three layers of firewall. Use the hosting firewall, because most hosting has some sort of firewall built in. Then use Wordfence on the website itself, because there are some website-level attacks that Cloudflare won't pick up. Then use those custom Cloudflare rules. All of that security section is about filtering traffic and making the site more secure, but a lot of that traffic is probing for holes and it's just jacking up the load on the hosting and making things slow. It comes in spurts. It's not consistent, even traffic. It'll hit the site and send 100 requests in a minute or something, and the site will be slow for that minute or that period of time. So the idea is just reducing that garbage traffic and making the site more secure.

This one here, optimize the robots.txt file, is kind of similar. Google and other crawlers do try and crawl a lot of stuff. Depending on your WooCommerce theme, they'll try and crawl things like the My Account section and the add-to-cart links, and a lot of that can make the site super slow. We very often see things like Google crawlers coming along and hitting the add-to-cart or add-to-wishlist links multiple times a second. They're sending hundreds of requests every minute to the hosting. An easy way to deal with that is to update the robots.txt file to filter that traffic. Genuine bots, genuine crawlers, will look at this file and honor what you're telling them to do. Here is a sample file that you can just copy and paste. We have it stopping crawling of login pages, stopping search pages being crawled, add to cart and wishlist, currency and order-by filters. Crawlers don't need to crawl those, and there are a few other things there. We also have aggressive SEO bots that we're blocking there too, because those SEO bots can come along and crawl a whole bunch of stuff and knock the hosting over. That's a cheap way to filter garbage traffic, or garbage legitimate traffic, or legitimate crawlers.

18:47Database Optimizations: InnoDB And HPOS

This is a big one. Anything in the back end, this one is important. Let's talk about a few of these. We have an article on our website, speed up database queries, that talks about one of these, the InnoDB one. Let's talk about that, because it's super simple.

The WordPress database can use two different formats. One is MyISAM, which is the older format, and the other is InnoDB. If you have an older WooCommerce site that's 5 or 10 years old, you're much more likely to be running the older table format. What happens with the older format is that when the website tries to write to the database, it locks the database table. Think about a database table as a spreadsheet. If you've got a WooCommerce site, you might have 30 to 50 database tables, and each one of those is like a spreadsheet. When someone's adding to the cart, for example, or checking out, the site is writing to the database, and that table will be locked. Nothing else can be written to it in that period of time. That means if you're getting a lot of add to carts or a lot of things happening on the site, those requests have to queue up, which causes a delay. The users will experience that as a delay in their browser. If you're doing a lot of editing of orders in the back end, you'll get the same experience, because your browser is waiting for those database writes while that table is locked.

With the InnoDB format, only the row in that table or sheet, if you think about the spreadsheet again, is locked. So I can have multiple writes to that database table happening at once without that queueing effect. If I have lots of add to carts happening, they're not queuing up, they can all happen at the same time. So it's really important that we're using this newer format. This plugin here, Servebolt Optimizer, is from a hosting company called Servebolt and will do that conversion for you, and it will happen very quickly. Back up your database before you do it. It'll do the conversion and add some indexes to the tables, and it will dramatically speed up database operations. That one's a no-brainer. So that's the InnoDB storage engine, or database format.

This next one, High-Performance Order Storage, is a newer database format for WooCommerce. WooCommerce was originally hacked into WordPress, so orders were just like pages in the database, which isn't a great way to do it if you have a lot of orders or a lot of products. What High-Performance Order Storage does is set up a new set of tables for the WooCommerce-specific stuff: customers, products, orders, and I think a couple of other ones. That will dramatically speed up things like managing orders, products, adding to cart, things like that. You can do this in the WooCommerce settings. This site's actually not done yet. If you go to WooCommerce settings, I think you need to be on the Advanced tab and then Features, and you'll see High-Performance Order Storage here. It will tell you if there are plugins that are not compatible. In this case there is actually an incompatible plugin, so that plugin needs to be dealt with, updated or removed. I don't think this site is using this plugin. Anyway, once that's fixed you can turn this on, and it will convert the database to this newer format. What it needs to do is clone the orders and all the database information into the new table structure. If you have 50,000 orders, that will take some time, a couple of days, and then it'll be ready to switch over fully. That will make anything WooCommerce related much, much faster.

There are also, in the more recent versions of WooCommerce over the last 6 or 12 months, since High-Performance Order Storage came out, some new optimizations in here that aren't turned on by default. Let's talk about a few of these. Rate limit in the cart and checkout is an important one to stop spam orders, and it can also reduce load on the website if something is hammering it. You can turn that one on, generally speaking, pretty safely. Just be mindful when you're playing with stuff in here. This is the advanced section. For High-Performance Order Storage caching, turn this on. Some of these are going to change the way the website works, so just be mindful if something weird happens. For example, if you searched for orders in a particular way before and that stopped working, it might be something to do with some of these settings, because they change the way the database works. Again, you'll see High-Performance Order Storage full text search indexes. That'll make things faster when you're searching for stuff or doing things that are database heavy related to orders.

You can see here "clear empty sessions". That just removes junk from the database. Then there's API caching. A lot of things talk to the WordPress API. If you have a shipping plugin, where you're taking orders and sending shipping data somewhere else, the API is talking to that tool, so this will speed that up. Then this one here, caching the product objects. Again, some of these are risky, especially if you're using variations or weird things on orders. So just keep in mind that if you turn them on and something goes astray, turn them off. This API caching needs a couple of other settings, so let's see if they show up in here. Here you go. You need an object cache for some of these. You'll see it requires an external object cache. But you can cache these API responses, which you probably should do if you have something talking to the API, because that will make those API requests faster. Even if you're using AI, you saw there was a WooCommerce MCP on that last page. If you're using AI especially, you probably want to turn that on to make things faster. If I go back one page, this WooCommerce MCP allows your AI to connect to it more easily. So those are the WooCommerce inbuilt optimizations.

24:59JavaScript, Images, Video And Preloading

Let's talk about optimizing JavaScript and third-party code. Move code to Google Tag Manager, and use the Window Loaded trigger where possible. That's probably one of the biggest JavaScript optimizations, especially for live chat codes. Moving the code to Google Tag Manager with that Window Loaded trigger will change the code firing order so it fires a little bit later and makes the page load faster. Then use JavaScript defer in your caching plugin. I would say do not use delay JavaScript, because it's going to break your tracking and things like that. I'd avoid delaying the JavaScript. You'll see these companies guaranteeing you a 100 score on PageSpeed Insights, and one way they do that is to delay or not fire the JavaScript on the front of the website until the user interacts with the site. That looks great in a page speed test because the site isn't fully loading. The problem with that is it breaks the website. It can break the tracking, it can break the way it works, and it can cause all sorts of errors under the bonnet. Especially on a WooCommerce site, don't do that. I won't go into that too much further because it's kind of technical, and that could be its own video.

Next one: use as few plugins as possible. This is pretty straightforward. Do a plugin audit and get rid of any of the junk that shouldn't be there. I don't think we need to talk about that anymore, it's self-explanatory.

Compressing images. Of course, this is straightforward. Use EWWW Image Optimizer. That's a simple one, and it's a plugin we use. Most optimization plugins are all the same: they compress images and make them smaller. We like this one because it can do the compression on the hosting without using an API or a paid service, so it works for free.

This one we see all the time, surprisingly. If you're hosting videos, host them on YouTube where possible. We see a lot of sites using Vimeo or just hosting the videos directly. That's fine, it's not a problem. But from an SEO perspective, especially in the AI world, having the videos on YouTube with a keyword-friendly title that doesn't have a date in it, make sure it has no dates in it so the video doesn't look old in two years, can help your SEO quite a bit, especially because you've got AI snippets in Google now. If you have a YouTube video that's linked to the page, it'll help the page rank higher, and the video itself has SEO juice. You'll see on most search results on Google now, you've got ads, you've got an AI snippet, then you've got a video snippet, and then the regular SEO results below that. So the YouTube ones can put you higher up on the page. This is somewhat of a performance thing, but it's more of an SEO thing and a marketing thing. So host the videos on YouTube where possible and make the title of the video keyword or search friendly. Don't spam it and don't stuff it full of keywords, but if you have a product video, make the title of that YouTube video the product name, product demonstration, or whatever it is, model XYZ product demo. That will likely get some SEO traffic versus hosting the video directly or using something like Vimeo.

Speculative loading and just-in-time preloading. These are features of those two plugins that I talked about before, WP Rocket and FlyingPress. Just-in-time preloading is probably best demonstrated at instant.page. There is a gap between when you hover over a link and when you click on it. You can see here there's a button, and if I hover over that, it's 1.4 seconds between my hover and my click. In that gap, the browser can load the page. What just-in-time preloading does is enable this functionality. If I'm hovering over these links, they start loading in the background before I click, and when I do click, the page is already in my browser ready to go. It's usually just called preload. So that's what just-in-time preloading is.

Speculative loading, or speculation rules, is something else that does something similar, but instead of just loading the HTML when I hover over something, it actually loads the entire page, so it loads the images and the JavaScript and CSS. That's the next level of that. I would say install the Speculative Loading plugin, enable prefetch, not prerender. Don't do prerender, and I'll talk about this in a sec. Also enable eager mode. Speculative loading has two modes. It can do prefetch, where it downloads the page in advance, and it can do prerender, which actually loads the full page and executes all the JavaScript. Prefetch is good because everything will be cached in our browser. If we do prerender, it will mess up the tracking. It actually goes and loads the pages and loads lots of analytics code, so it'll look like that visitor is visiting a bunch of stuff on the site when they're not. So don't use prerender. It will break tracking on a WooCommerce site. There are scenarios where it's useful, but not in this one. Then enable eager mode, which is the most aggressive mode, so it'll preload the most stuff. That is a free plugin from Automattic, WordPress, and it will allow you to configure those more aggressive settings.

31:12What Does Not Work

That's the broad overview. What doesn't work? You'll see stuff around the web. Minification doesn't do anything, so don't waste your time on it. Minifying CSS, minifying JavaScript, and combining CSS and JavaScript don't do anything. They actually make things slower. There is a tiny, tiny amount of bandwidth saved by minifying things, but usually when plugins minify stuff, they change the file name. They'll change the CSS file name or JavaScript file name, which then breaks the caching. If I've gone to the website last week and I come back this week, the CSS files have a new name and my browser has to download them again. Whereas if they were just left alone, my browser already has a copy and doesn't have to download them. So it makes caching worse and doesn't do anything for speed. Combining files like this doesn't do anything on the modern web. If anything, it makes things slower. So for minify and combining anything, ignore it. It's a waste of time. Servers have Brotli and gzip compression, so stuff is compressed.

Cart fragments, same thing. This comes from an old era of speed optimization. A cart fragment is basically an Ajax call to the website. Your browser is doing a form of API query to the website to get the data about what you have saved in your cart so it can update the little cart icon in the header. That's what a cart fragment is. Disabling that doesn't speed anything up if we're using real measures of speed, Core Web Vitals. Core Web Vitals is the measure of the real load time of the website in the real world, and cart fragments don't impact that. They do add a little bit of extra load, but that's fine, that's not a big deal. Cart fragments will make the site look slower in an older speed test tool like Pingdom, but in reality they don't impact the real speed, so just ignore that. Messing around with cart fragments can break the cart or break the header, so don't touch that. We don't do anything with that, and we haven't in about five years. Don't waste your time with cart fragments.

There's probably another one here: Cloudflare. You'll see custom Cloudflare caching rules. You'll see people around the web saying to add all these rules to Cloudflare for caching. Don't do this. Use Cloudflare APO instead. A lot of people break their sites by adding all these custom rules for WooCommerce. You don't need any custom rules. Just use the Cloudflare APO service. So that's the stuff that doesn't work.

33:53Other Important Basics: Theme, Domain, Email And Patching

Other things you should probably do that are important or adjacent to speed. Use an e-commerce focused theme. E-commerce themes, mature ones, are usually built for speed, and they have a whole lot of e-commerce features like upsells and things that are just useful for selling more stuff, as opposed to a vanilla, non-e-commerce-focused theme. As long as you're using an e-commerce focused theme and it's mature, you'll usually be fine. Don't switch themes for speed. Most of the time the theme is not a speed issue. We get a lot of questions about what's the fastest theme. Who cares? It's not really affecting the speed at all in the real world unless it's really, really bad, and in that case you probably know it's bad. So use an e-commerce focused theme, but it's not really a focus of speed optimization.

Renew your domain name for as long as possible. A .com can be renewed for 10 years, so renew the domain for 10 years. The reason for that is to avoid it expiring. Most of the downtime we see from our customers and clients is because they forgot to renew domains. Even I have that. The other day one of our obscure domains expired, my personal domain expired, and it was down for a day and I thought, "Oh, totally forgot about this domain." So just renew the domains for as long as possible. Some are 5 years, some are 10. It's cheap insurance, and it's probably cheaper to renew it for 10 years anyway.

Make sure you've got SPF, DKIM and DMARC records set up. This is not a speed thing but it is an email thing, and without these your emails are probably going to go to spam.

Then patch WooCommerce regularly. Patching things regularly ensures the site is secure, and it also protects you from particular attacks. We see a lot of WooCommerce sites get hacked, and one of the reasons is that users can register on the site. The most common exploit we see on WooCommerce is that you can make an account as a customer and then do what's called a privilege escalation. You can turn that customer account into an administrator account and get control over the site. I've written a note there: protect from privilege escalation attacks. That's probably one of the main reasons to patch. There are other security holes of course, but that's probably the most prominent way we see WooCommerce sites getting hacked. It's also a case of people using obscure paid plugins that haven't been updated for years and have exploits that allow privilege escalation attacks. So make sure you patch regularly, and try to manually check paid plugins.

36:42Tracking Your Speed And Getting Help

Okay, I think that's it. That covers the basics. Check those boxes and your site should be pretty fast. Like I said, you can use this report on our website to see the speed on an ongoing basis and see the history. It will also email you speed reports for free on whatever basis you choose. I think there are weekly and monthly options there. If you scroll down to the bottom, there you go, weekly and monthly. This report also shows you, like I said, the history for the last 12 weeks. Sometimes there might be gaps. Maybe there's not enough traffic that week. I don't know why that one has a gap, but the threshold for Core Web Vitals data is generally 50 to 100 visits a day, so if you drop below that threshold, then you won't have data. You can see the data plotted out here on the graphs as well.

If you do need help with your website, come to our website, wpspeedfix.com, and claim a free website audit. Tell us what you need help with and one of the team will come back to you and tell you how we can help. There's a whole other bunch of stuff on the website: a free SEO audit, a mailing list as well, and a WordPress speed test tool that will give you insights and recommendations on how to make your site faster. I think that's everything. If you have any questions or something wasn't clear, post in the comments and we'll come back to you. Cheers.