How to optimize Local WP on Windows so it loads faster

For cloning a website locally Local WP is great. The problem is that sometimes it starts to slow down, even right from the start and on powerful machines.

And of course, when it’s slow, it gets pretty frustrating. Because, besides security, you’re supposed to be working locally to go faster, not to wait three seconds every time you open an admin page.

It was happening to me on the project for my new website, but I didn’t want to change tools. I didn’t want to set up Docker, scrap the environment, or start from scratch. I wanted Local WP to become (very) usable again.

After trying several things, these are the five steps that genuinely worked for me.

There are several other optimization options, but I stuck to these and now my local setup runs like a rocket.

1. Confirm that Xdebug was disabled

The first thing I checked was Xdebug.

Xdebug is used to debug PHP. If you’re going to set breakpoints, inspect variables and do serious debugging, perfect. That’s what it’s for.

But if you’re not using it, it can slow the environment down quite a bit.

In Local WP you can check it from the site panel:

Local WP > your site > Overview / Tools tab > Xdebug

In my case it was already disabled, so I didn’t have to touch anything. But from experience, it was the first suspect to rule out.

The rule is simple: if you’re not actively debugging PHP, keep Xdebug disabled.

Here it wasn’t “the solution” in my case, because it was already off, but it costs nothing to check before going crazy with other things.

2. Change the domain from .local to .test

This change was noticeable.

I had the site on a domain ending in .local (yg.local) and changed it to yg.test.

In Local WP you do it like this:

1. Open Local WP.
2. Select the site.
3. Go to the Overview tab.
4. Find the Site domain field.
5. Click Change.
6. Change the domain from .local to .test.
7. Confirm the change.
8. Restart the site.

Then, go in with the new URL:

https://yg.test

Or, if you don’t have SSL enabled in Local:

http://yg.test

Why does it work? 

Because .local can cause trouble in some environments because of how it is resolved at network level. .test is much more intended for local development and avoids part of that absurd friction.

It’s a simple change that helped in my case.

3. Exclude Local WP folders from Windows Defender

Another important tweak.

If you work on Windows, Windows Defender may be constantly scanning WordPress files, plugins, themes, uploads, the database, logs, caches and Local’s internal services.

And of course, WordPress locally moves a huge number of small files. If the antivirus starts inspecting everything touched by PHP, MySQL or nginx, performance suffers.

Of course I didn’t disable the antivirus; what I did was add exclusions.

In Windows:

1. Open Windows Security.
2. Go to Virus & threat protection.
3. Scroll down to Virus & threat protection settings.
4. Click Manage settings.
5. Scroll down to Exclusions.
6. Click Add or remove exclusions.
7. Add folder exclusions.

The important folder is the one for local sites:

C:UsersYOUR_USERLocal Sites

And also Local’s internal folders, which are usually in paths such as:

C:UsersYOUR_USERAppDataLocalProgramsLocal

And:

C:UsersYOUR_USERAppDataRoamingLocal

In my case, excluding Local Sites was especially important, because that is where the website really is: WordPress, plugins, themes, uploads and everything Local is constantly touching.

After adding the exclusions, it’s worth stopping and starting the site again from Local WP.

4. Disable plugins I didn’t need locally

The next step was pretty obvious, but sometimes we forget it or prefer not to do it so we can simulate the production environment better.

There are plugins that make external calls, scheduled tasks, security checks, backups, logs, caches, SEO analysis, newsletter integrations, monitoring, image optimization and a thousand other things.

All of that may be unnecessary locally, depending on what you’re testing.

So I reviewed the plugin list and disabled the ones I didn’t need for the work I was doing at that moment.

The question was this: 

Do I need this plugin active for what I’m doing right now?

If the answer was no, I disabled it.

In my case:

1. Backup plugins.
2. Genesis plugins.
3. Security plugins.
4. Cache plugins.
5. Analytics plugins.
6. Plugins that launch scheduled tasks

Fewer active plugins means less load, fewer background processes and fewer things competing for resources.

Even so, I didn’t see a big improvement here, so it might be better to leave this step for the end if everything else is not enough.

5. Clean the database from the Local shell

The last step was cleaning the database.

WordPress accumulates junk very easily: revisions, auto-drafts, transients expired ones, trashed comments, spam, orphaned metadata and plugin leftovers.

To do it, I opened the site shell from Local WP:

Local WP > your site > Open Site Shell

Before cleaning, I made a database backup:

wp db export backup-before-cleanup.sql

Then I ran this cleanup block:

wp post delete $(wp post list --post_type='revision' --format=ids) --force
wp post delete $(wp post list --post_status='auto-draft' --format=ids) --force

wp post delete $(wp post list --post_status='trash' --format=ids) --force

wp comment delete $(wp comment list --status=spam --format=ids) --force

wp comment delete $(wp comment list --status=trash --format=ids) --force

wp transient delete --expired

wp db query "DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON p.ID = pm.post_id WHERE p.ID IS NULL;"

wp db query "DELETE cm FROM wp_commentmeta cm LEFT JOIN wp_comments c ON c.comment_ID = cm.comment_id WHERE c.comment_ID IS NULL;"

wp db query "DELETE tm FROM wp_termmeta tm LEFT JOIN wp_terms t ON t.term_id = tm.term_id WHERE t.term_id IS NULL;"

wp db query "DELETE um FROM wp_usermeta um LEFT JOIN wp_users u ON u.ID = um.user_id WHERE u.ID IS NULL;"

wp db optimize

One thing to watch out for: this assumes the table prefix is wp_.

If you’re on Windows and that variable syntax doesn’t work for you, use the prefix it returns directly:

wp db prefix

and replace it manually.

This step is not something to do casually in production. Locally, with a prior backup, yes.

Result

After these five steps, Local WP started running quite a bit better. Logical, because my Ryzen 7 2700 Pro with NVMe and 24GB is considerably more powerful than the production server.

That’s why it was clear to me that it was worth spending a bit of time.

Now it runs as it should and has saved me a lot of small waits.

The summary would be:

1. Check that Xdebug is disabled.
2. Change the domain from .local to .test.
3. Exclude Local WP folders in Windows Defender.
4. Disable unnecessary plugins locally.
5. Clean the database from the shell.

Basically, take some weight off the environment.

In this case Local WP is not slow for one single reason, but because of the sum of small things: domain resolution, antivirus looking at every file, unnecessary plugins and a database full of leftovers.

I didn’t measure each one with a stopwatch, but by feel. That’s why I know what worked for me.

Now I have my local copy running like a rocket, so I’ve run out of excuses for working in production and not testing.

And you, are you still using the same excuse?