How to Speed Up Localhost Performance on Windows (XAMPP, WAMP, Laragon & WSL2)

What you'll need	Notes
Windows 10 or 11	Steps apply to both; menu wording differs slightly (noted below)
Administrator access	Required for Windows Defender exclusions, hosts file, and power plan changes
A local server stack	XAMPP, WAMP, Laragon, or Local — steps note stack-specific file paths where relevant
A plain-text code editor	Notepad++, VS Code, or similar (avoid Word/rich-text editors for config files)
~15 minutes	Most steps below take 1–2 minutes each; MySQL tuning takes a bit longer to test

This guide walks through the most common, reproducible causes of a slow localhost on Windows when running Joomla or WordPress locally for development — and how to fix each one, regardless of whether you use XAMPP, WAMP, Laragon, or Local. Applies to Windows 10 and Windows 11.

Step 1: Exclude Your Project Folder From Windows Defender

Windows Defender's real-time protection inspects files as they're read and written. A PHP request that touches dozens of files (core, plugins, theme, cache) triggers a scan on each one, and this overhead compounds with every page load — it's one of the most frequently reported causes of a sluggish XAMPP, WAMP, or Laragon setup on Windows.

1. Open Windows Security → Virus & threat protection.
2. Under Virus & threat protection settings, click Manage settings.
3. Scroll to Exclusions and click Add or remove exclusions.
4. Click Add an exclusion → Folder, then select your local server's web root — for example C:\xampp\htdocs, C:\wamp64\www, or C:\laragon\www.

If you use a different antivirus product instead of (or alongside) Windows Defender, add the same folder exclusion there too — third-party antivirus real-time scanning causes the identical slowdown.

Step 2: Use 127.0.0.1 Instead of localhost

On some Windows configurations, resolving the hostname localhost triggers an IPv6 lookup first, which times out or adds latency before falling back to IPv4 — this has been widely reported as a cause of slow page loads and slow MySQL/MariaDB connections in XAMPP and WAMP setups.

• Browse to http://127.0.0.1/ instead of http://localhost/.
• In Joomla's configuration.php or WordPress's wp-config.php, set the database host to 127.0.0.1 instead of localhost.
• Optionally, open C:\Windows\System32\drivers\etc\hosts as Administrator in a text editor and confirm the line 127.0.0.1 localhost is present and not commented out with a #.

Step 3: Switch Your Windows Power Plan to High Performance

Windows' default Balanced power plan throttles CPU clock speed to save energy, including on desktop machines that are plugged in. This directly slows down Apache/Nginx request handling and PHP execution.

• Windows 11: Settings → System → Power & battery → Power mode → select Best Performance.
• Windows 10: Control Panel → Power Options → select High performance (click "Show additional plans" if it isn't listed).

On a laptop running on battery, this trades battery life for speed — switch back to Balanced when you're not actively developing.

Step 4: Enable and Configure PHP OPcache

Without OPcache, PHP re-parses and re-compiles every script on every single request. OPcache stores the compiled bytecode in memory so repeat requests skip that step entirely, which is one of the highest-impact PHP performance settings available — and it ships with PHP but is disabled by default in many local stack installs.

Open the correct php.ini and confirm or add the following in the [opcache] section (uncomment the zend_extension line if it's commented out):

zend_extension=php_opcache.dll

[opcache]
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=1
opcache.validate_timestamps=1

Keep opcache.validate_timestamps=1 for local development so OPcache re-checks files when you edit them. Restart Apache after saving.

Step 5: Turn Off Xdebug When You're Not Actively Debugging

Xdebug is essential for step-through debugging, but it hooks into every function call while active, which adds measurable overhead — this is especially noticeable on WordPress sites with WooCommerce or Joomla sites with many third-party extensions loaded on each page.

[xdebug]
xdebug.mode=off

Set xdebug.mode=off in your php.ini when you're just browsing your site locally, and switch it back to debug only when you need to attach a debugger in your IDE. Restart Apache after changing this setting.

Step 6: Increase the MySQL/MariaDB Buffer Pool Size

The default my.ini that ships with XAMPP and similar stacks is tuned conservatively for low-memory machines. Raising innodb_buffer_pool_size lets MySQL/MariaDB keep more table data in RAM instead of reading from disk on every query, which speeds up Joomla and WordPress admin screens in particular since they run many small queries per page.

Locate my.ini (in XAMPP: C:\xampp\mysql\bin\my.ini, not to be confused with C:\xampp\mysql\data\my.ini) and adjust the [mysqld] section:

[mysqld]
innodb_buffer_pool_size=512M
innodb_log_file_size=64M
key_buffer_size=64M

Restart the MySQL/MariaDB service after saving. If it fails to start, lower the value and try again.

Step 7: Keep Your Project Off OneDrive, Dropbox, or Network Drives

Cloud-sync clients (OneDrive, Dropbox, Google Drive) watch and intercept file writes inside synced folders, which adds latency to every file save and every cache write your local site performs. Network drives and external USB drives add similar overhead from the connection itself.

• Keep your htdocs/www folder on a local SSD path that isn't inside a synced folder (avoid C:\Users\you\OneDrive\...).
• If your local stack's default install location happens to sit inside a synced folder, move the project folder or reinstall the stack outside it.

Step 8: Enable KeepAlive and Disable Unused Apache Modules

Apache's httpd.conf loads a long list of modules by default, most of which a typical Joomla/WordPress dev site never uses. Fewer loaded modules means less memory and startup overhead per worker.

# In httpd.conf
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

Comment out (add a # in front of) LoadModule lines for modules you're not using, such as unused language modules or protocol handlers you never enabled — check with your team or hosting provider before disabling anything used in production, since disabling a module your live site depends on will make local testing miss real bugs.

Step 9: Consider a Different Local Stack or WSL2

If you've applied the steps above and localhost is still noticeably slow, the local server stack itself may be the bottleneck:

• Laragon is frequently reported by Windows developers as faster to start and lighter on background overhead than a default XAMPP install, and it makes switching PHP/MySQL versions simpler.
• Local (by WP Engine) is purpose-built for WordPress and runs each site in an isolated lightweight environment, which can reduce the "everything shares one Apache/MySQL instance" contention you get with XAMPP/WAMP.
• WSL2 (Windows Subsystem for Linux) lets you run a native Linux LEMP stack, which can outperform Windows-native Apache/MySQL for filesystem-heavy PHP work — but only if your project files live inside the Linux filesystem itself. Accessing files across the Windows/WSL2 boundary (e.g., a project stored on C:\ but served from WSL2) is slow and defeats the benefit.

Step 10: Turn Off Windows Search Indexing on Your Project Folder

Windows Search continuously indexes file contents for the Start menu search feature. Large folders full of small files — vendor/, node_modules/, cache/ — generate constant disk I/O from this indexing that competes with your local server.

1. Right-click your project folder → Properties.
2. Click Advanced (under the General tab).
3. Uncheck Allow files in this folder to have contents indexed in addition to file properties.
4. Click OK, then confirm applying the change to all subfolders and files.

❓ FAQ

Why is localhost slower than a live production server?

A live server typically has OPcache and production-tuned MySQL settings enabled by default, while default local installs on Windows often ship with OPcache off, Xdebug on, and real-time antivirus scanning every file. These are configuration differences, not something inherent to running locally.

Does antivirus really slow down XAMPP or WAMP that much?

Real-time scanning checks files as PHP reads and writes them, and this is one of the most commonly reported fixes across XAMPP, WAMP, and Laragon communities. The impact varies by machine and antivirus product, but excluding your project folder is a quick, low-risk test.

Should I always use 127.0.0.1 instead of localhost?

For local development, yes — it skips a hostname resolution step that can add latency on some Windows setups, particularly for MySQL/MariaDB connections. It has no downside for a local-only environment.

Does Xdebug slow down WordPress and Joomla sites locally?

Yes, whenever it's active — Xdebug hooks into every function call, which adds up on sites with many plugins or extensions. Leave it off during normal browsing and enable it only when you're actively stepping through code in your IDE.

Is Laragon actually faster than XAMPP?

Many Windows developers report Laragon feels faster and lighter, largely due to easier version switching and less background overhead by default — but a well-tuned XAMPP install (following the steps in this guide) can close most of that gap.

Do I need WSL2 for faster local PHP development on Windows?

Not necessarily. WSL2 can be faster for filesystem-heavy workloads, but only when your project files live inside the Linux filesystem rather than being accessed across the Windows/WSL2 boundary. For most Joomla/WordPress dev work, the steps in this guide are enough without switching to WSL2.

🧯 Common Mistakes to Avoid

• Excluding your entire C: drive from Windows Defender instead of just the project folder — this removes real-time protection from areas where it matters most.
• Editing the CLI php.ini instead of the one your web server module actually loads — always confirm with phpinfo() first.
• Forgetting to restart Apache/MySQL after changing php.ini or my.ini — config changes don't take effect until the service restarts.
• Setting innodb_buffer_pool_size too high for the machine's available RAM, which can prevent MySQL from starting at all.
• Leaving Xdebug on by default and forgetting it's the reason every page feels sluggish during normal browsing.
• Storing the project inside a OneDrive-synced folder without realizing the sync client is adding latency to every file write.